วีดีโอ

Да, вот: th-cam.com/video/UBpo2E5V0s4/w-d-xo.html

Ее совсем к какой части видео это относится (все уже не помню), но если речь про то, чтобы вместо создания монобехаов создавать обычный классы - да, норм, но полностью избавиться от монобехов не получится. Если нам нужно управлять объектом на сцене, то все равно же нужен скрипт, который бы связывал GameObject с кодом.

все в одно видео не впихнешь

Для физики

да, вот полное видео: th-cam.com/video/t9lkekE4_vk/w-d-xo.html

Спасибо. Постепенно буду делать еще ;)

Спасибо за комментарий и фидбек, будем улучшать)

По большей части для чистоты эксперимента (чтобы показать разницы сугубо в апдейтах) и удобства, но это хорошее замечание - в идеале эти классы могут быть вообще не монобехами.

хороший вопрос. вообще с точки зрения метода, в который передается делегат - ему зачастую все равно что ему передают, если только это не ломает состояние объекта, которому он принадлежит. И для этого в самом методе можно организовать проверки на валидность, например не является ли делегат null (очень частая ситуация), и бросать исключения если что-то не так. но то, что вернет делегат и как он там внутри вычисляет - уже ответственность клиента (того, кто передает делегат). надеюсь правильно понял вопрос. и рад быть полезным)

@@RuslanSmirnovGameDev Спасибо за ответ, интересно а есть вариант добавить что-то вроде where только для параметра делегата, я создал метод с делегатом для использование его только таймерами, я могу как-то более явно заявить о своих намерениях, я так понимаю в целом очень важно чтобы код был максимально предсказуемым,для этого ведь многие конструкции и придуманы(readonly, const и тд)

я думаю можно попробовать сделать ещё какие-то ограничения на дженериках. придумать какой-то класс-обёртка над данными, и пропускать аргумент-делегат с этим ограничением). Хотя без конкретного кода-примера сложно сказать)

Не соглашусь. Если человек пришел например из джавы (мой кейс, хотя конечно сейчас там уже есть аналог делегатов) , и/или прочел книгу по паттернам до того, как ознакомился с некоторыми фичами C#, то он абсолютно может не знать про делегаты, но очень быстро войдет в тему, когда ему предоставят знакомую аналогию. Ну а так, данный ролик конечно больше для новичков рассчитан, но которые уже знают основы C# (делегаты я основой все же не считаю)

@@RuslanSmirnovGameDev делегаты,события,лямбды-это все букварь,пусть и его финальные страницы..Не зная этого вообще нечего лезть в архитектуру(в смысле читать книжки по паттернам). Это мое мнение. Спасибо.

нет проблем) просто ООП штука такая, что можно без знания чего-то одного обойтись другим, и все равно получится неплохая архитектура. Вот как раз ситуация с делегатами - заменяем на интерфейсы (то что и делали в джаве), и получаем почти то же самое с точки зрения функционала.

планирую сделать уроки по паттернам, как появится больше времени. по поводу вопроса - как вариант хранить интерактивные объекты как коллекцию в какой-то сущности, с доступом по ключу (мб строке-имена). И при создании объектов состояния давать им ссылку (если организован DI), либо через синглтон напрямую обращаться.

да, надо бы сделать, возьму на заметку

как скажешь

да, есть полно примеров, которые я в том числе приводил и в видео. вот еще: news.ubisoft.com/en-us/article/61RI3EnTzPx29I0q4NtN5m/how-ubisoft-is-using-ai-to-make-its-games-and-the-real-world-better aibusiness.com/ml/how-ubisoft-is-using-ai-in-game-development news.ubisoft.com/en-gb/article/6Mv4hZqUMJoY1xpf1yiQPi/ubisoft-la-forge-pushing-stateoftheart-ai-in-games-to-create-the-next-generation-of-npcs

да, и кто знает сколько таких циклов симуляции на самом деле :)

@@RuslanSmirnovGameDev Вот именно, мы создадим симуляцию в которой будет все как в реальности, и чтобы полностью погрузиться, мы будем временно погружать себя в амнезию, чтобы мир симуляции был как реальный. А потом будет сложно как понять где реальность а где...) Симуляция колеса Сансары. )

@user-lc6lf5wn7p звучит стремно)

давай по порядку: то, что 100 врагов будут брать данные из SO, означает лишь то, что у них будет *ссылка* на сам SO, который будет храниться как ассет в проекте. Если враг уничтожается, это никак не затронет оригинальный ассет, хоть даже все враги уничтожатся. Касательного второго тезиса - да, если явно хранить поля у врагов, и инициализировать (по сути копировать) со скриптабл обжекта, то у каждого врага будут свои копии данных, которые и будут кушать память. Поэтому посыл такой - те данные, которые статические и не меняются по ходу игры (например, максимальное хп, скорость ходьбы, урон и тд) - лучше хранить в SO, и назначать ссылку на него во врагах. В общем точно также как в видео

тоже как вариант) правда думаю все же сложнее продвинуться до такого уровня, чем в It

@@RuslanSmirnovGameDev сложнее? На сварщика уходят после 9 класса и к 19 годам уже заканчивают техникумы, 50-70к уже будут получать. Если также уйти после 9го, то может тоже до таких зарплат дойдёшь к 19. А если через вышку, то начинают обычно подрабатывать по специальности на 3-4 курсе, обычно там 70к и не пахнет, ибо нам нужен специалист с законченными проектами, с опытом от 3х лет, умеющий и в код и в железо, с высшим образованием и всё это за 50к)) И в целом, как ты вы с этим самосовершенствованием в IT всё демпингуете и демпингуете оплату труда. У нас взносы по ипотеке сейчас для провинциального города 100-150к если брать на 30 лет, какие ещё джуновские зарплаты в 50-100к? Не, это было бы нормально, если бы брали вообще без опыта и образования, как курьеров, сами всему научим, но нет, туда ещё нужно пробиться

Спасибо за отзыв! Не совсем понял правда что имеется ввиду под техническим документом - это про ГДД речь, или про тех задание?) И какая у вас цель - научиться кодить или более общее : создать готовый продукт? Если 2е то в действительности не обязательно даже кодить - проще найти готовые ассеты на ассет сторе, там по и по контента, и по тулзам, в общем можно готовую игру склепать. А если речь про освоение программирования, то тут надо начинать наоборот с малого - нет смысла браться за супер-пупер проект мечты, так только выгорите) Попробуйте разделить ваш проект на отдельные части (например часть квестов, инвентаря, персонажа), и работать над ними как отдельными проектами, не смешивая. А в каждой части выделить ещё под-механики - для персонажа это может быть хождение, стрельба, управление. Для квестов - диалоги, прогресс, награды. И вот когда уже все это реализуете на более приемлемо уровне - тогда имеет смысл пытаться это все объединить в один большой проект

@@RuslanSmirnovGameDev @RuslanSmirnovGameDev Руслан, спасибо за ответ. Технический документ схож с диз. доком, только он не имеет маркетинговой составляющей. Тех. документ я написал очень лаконично в тетради, где по пунктам расписал от жанра и сюжета до всех игровых механик. Так я экономлю время на переработку проекта в самом Unity. Да, я понимаю, что надо разбить свой проект на отдельные части по реализации механик, не спешить всё сразу осуществить. Но в том-то и дело, что я уже использую свои 3d lowpoly объекты и 2d спрайты, большую часть объектов по плану будут мной созданные. Вы мне как блогер очень понравились в плане подачи материала, сейчас сложно найти такие понятные изложения материала. С Вами можно связаться в Telegram или WhatsApp? Я очень хочу набраться опыта, получить несколько советов, и вообще было бы здорово с Вами пообщаться в сфере 3d проектов на Unity.

Это хорошо что вы пытаетесь расписывать и планировать игру, но как бы это странно ни звучало - в каком то плане вредите себе) Штука в том, что у вас в голове идеальная игра, а на практике не получается, и это сильно демотивирует. Сам через такое проходил. Я думаю лучше все же создать другой документ для другой игры, взять ваши объекты и спрайты, но постараться придумать что-то попроще, реалистичнее. Пусть это будет самая простая казуалка. Зато на ней вы сможете отточить все базовые механики. Возможно сниму как-то видео даже на эту тему :) По поводу связи - как раз подумываю создать telegram канал или что-то вроде того, а пока можете писать на почту: rsmirnov.dev@gmail.com

@@RuslanSmirnovGameDev Руслан, спасибо большое! Да, соглашусь, я понимаю, что всё не реализую, буду делать по частям. Главное, что меня это очень увлекает, и есть необычные идеи, но и тем сложнее получается во всём разобраться. Не помогает особо TH-cam и документация Unity, так как там разбираются самые ходовые темы, а у меня же нюанс на нюансе. Зато так намного качественнее обрастаешь опытом, это как с новым городом, когда ты моментально запоминаешь незнакомые улицы, кварталы только если заблудился и спросил дорогу у местных, чем идти по карте в телефоне. Я Вам обязательно напишу, спасибо за контакт! (Яков Р.)

все будет хорошо, не грусти 😉

@@RuslanSmirnovGameDev th-cam.com/video/wTCSwX5AuwQ/w-d-xo.html

рад что был полезен 😉

думаю стронг джун, т.е. что-то посередине) на мой взгляд, просто джун должен быть способен просто реализовать подобные механики в игре, даже если это будет топорно, ли ж бы работало. А вот мидл должен сделать это более-менее расширяемым, с наследованием, декомпозицией.

В таком случае самый основной - это затраты на создание такого объекта. По схожему образу с вызовами, создание монобеха проходит тучу итерацией, и получаем сильно выше время (хотя и память тоже, но то уже такое) на инстанциирование кучи объектов, и соот-но загрузка сцены с большим кол-вом монобехов будет грузится в разы дольше, чем если б это были обычные классы.

@@RuslanSmirnovGameDev Понял, спасибо)

можно было, но я так понял у автора было требование использовать MVC

как правило, получение данных ввода пользователя должны быть на вью, причём и в Mvp и в Mvc, а вот их интерпретация (валидации, обработка) - уже ответственность контроллера (ну или презентера). Хотя как я говорил, интерпретация может разниться. Но отличия в Mvc и Mvp больше в зависимостях между компонентами, в частности в более пассивной вью.

@@RuslanSmirnovGameDev MVC классический был создан на основе философии компьютера, где controller это устройство ввода, view это устройство вывода, а model это бизнес модель. Но я согласен, что интерпретируют это все несколько по-разному сейчас.

@@sergeypogorelov7059 Разная интерпритация конректного паттерна от незнания кем и для чего "создавался" данный паттерн. Обычно такие люди не могут отличить MVC, MVP, MVVM, MVA. В особенности MVVM и MVA, так как у них "стрелочки почти одинаковые". Сейчас бы оригинальный MVC назвали сильно связанным, и любой di контаинер типо Zenject при попытке резолва такой зависимости выдал бы ошибку о "говнокоде" ) Да, перейти на события здравая идея (Как на схеме в начале видоса), но это уже и не MVC, тогда уж лучше пользоваться MVVM.

@@PragmaGames это да, в MVC действительно слишком много зависимостей, это очень непрактично, ну и как результат - почти нигде не используется (если говорить сугубо про геймдев).

оговорился, да fixed update)

я выбрал такой способ для простоты, в нем ничего страшного нет, если у тебя нет сложных физических вычислений, либо нагруженного рендера. Но с увеличением числа юнитов стоит перейти на физическое обновление, согласен

может и релизнут, но думаю разработчики будут переходить на него еще лет 5 )

почти во всех коммерческих, далеко не стратегий; объектам, которым потенциально может понадобиться апдейт, если не проводить никаких оптимизаций. Против ECS ничего не имею против, да, при правильной организации он явно производительнее привычного подхода, но это все таки абсолютно другой подход к архитектуре проекта; ролик больше про сравнение привычных подходов

​@@RuslanSmirnovGameDev Если проекты коммерческие, то ты сможешь назвать их, что бы мы посмотрели на них ) я на своей практике даже 5к не встречал... кроме того ты показал время вызова пустых методов, если эти методы заполнить чем-то, будет 10фпс что так, что так )

@@PragmaGames чем-то могу поделиться, чем-то нет, из недавнего play.google.com/store/apps/details?id=com.swiftappskom.catsimulator2 естественно сейчас там много оптимизаций, и не 50к апдейтящихся монобехов, но вполне могло быть если втупую везде создавать монобехи. насчёт пустых методов - в том то и прикол, что затраты на логику далеко не всегда > затрат на оверхед. Можно создать монобех с какой-то минимаььной функциональностью в апдейте, например простым движением юнита - и навесив его на кучу объектов получить фризы из ничего. Как раз чаще всего так и происходит

да, для рандомизации нужно через код делать - очень хороший вариант библиотека DoTween. Ну либо топорная альтернатива - сделать несколько пресетов анимаций, и проигрывать каждый раз рандомную

добрый день. возможно в будущем запишу такие ролики)

хочешь сказать для сложной игры этот принцип не работает?

@@RuslanSmirnovGameDev деление на классы со своей ответственностью этот верный подход, но строить классы внутри класса не запрещенно, в том числе анонимные.

@@Частныйсектор-х4я а чем это поможет в этой ситуации?

@@RuslanSmirnovGameDev разработчику возможно пользуется поиском и ныряет в свой код как ему удобнее по поисковому запросу, а не по классам. Возможно он хотел простой код, а потом стал усложнять. Конечно поддерживать такой код тяжелее, чем зеленный на классы. Но раз код написан, работает, он сделал так к примеру ради отработки анонимных классов.