Сомневаюсь, что такая архитектура это хорошая практика. Во первых, если речь о стратегия, то там MUST - dod, ибо перформенс. То что тут названо "нодами", это типичные контексты\скоупы, которые из коробки во всех известных DI-контейнерах. Ну и наконец про контекстые эвенты. Такой подход работает только в микро играх. В хоть сколько нибудь сложной игре, таких эвентов наберутся сотни и получится настоящий event-hell, а проект станет неподдерживаемым. Так что отмечу, что это концептуально не правильный подход. Ожидая эвент, мы как правило ожидаем, что какие то данные изменились, и нам нужно выполнить какие то действия, например обновить UI. Проблема в том, что это лишь предположение, которое держится на знаниях о проекте у разработчиков, но никак не поддерживается дизайном архитектуры. Следственно, если в проект добавить разработчика, то он может что то сломать, сам того не зная. Вместо эвентов, нужно отслеживать изменения данных которые реально нужны. Но что бы выстроить такой дизайн, как раз и нужно реально уметь в архитектуру.
DOD и перформанс - это разные вещи. Задача DOD - разделить данные и логику, чтобы код механик можно было переиспользовать и собирать из них игровые модели как конструктор. Задача перформанса - увеличить производительность и уменьшить расходы памяти. По поводу эвентов, ивенты должны быть только системные. В остальных случаях применяется обычный паттерн "Наблюдатель", которые как раз и подписываются на изменения данных :)
@@CodeCraftUnityEdition Снова хромает матчасть. DOD только и создано для обеспечения перфоманса. Данные встают впереди абстракций и поддерживаемости только в целях производительности. К нему идут свою плюшки такие как параллельность и простота тестирования, но тестируемым кодом на видео и не пахнет) Само утверждение что "при DOD можно переиспользовать код" означает слабое понимание ООП и его возможностей... Жаль, что в настоящее время Senior Unity Developer'ы, создающие каждый день собственные архитектуры, так и не узнали что все архитектуры уже давно создали)
@@CodeCraftUnityEdition dod это data oriented design. Дизайн ориентированный на данные, это вовсе не про: "разделить данные и логику", а про организацию испольняемого кода (включая данные в памяти офк) таким образом, что бы он был кешлайн френдли, для извлечения перформенса который мы теряем при классическом подходе. А разделение данных и логики, это вообще база, которая относится чуть меньше чем к любому подходу. Что касается обычного паттерна наблюдателя, то обычная реализация должна реализовывать IObservable. Если этого не делается, значит это уже не обычная реализация. А если не обычная, то возникает вопрос, зачем? Вы используте IObservable? Если нет, то почему?
братан от души)), а на самом деле спасибо вам огромное за то что делитесь опытом проектирования архитектуры. После таких видео дополнительно прорабатываешь материал и понемногу саморазвиваешься)
А что если нужно посчитать дамаг игрока 1 по игроку 2 учитывая атаку игрока 1 и защиту игрока 2? Я хочу сказать, что когда я делал игру с двумя игроками мне пришлось сперва инжектить дочерние а потом родительские контексты. Потому что нужны были глобальные сервисы имеющие ссылки на сервисы обоих игроков чтобы организовывать их взаимодействие. У вас только стрелки вниз. Может я не понимаю как это сделать? Или у вас получается ecs косвенно ссылается на данные всех игроков?
Так то идея того же зенжекта была простая изначально. Просто потом туда начали добавляю свою фабрику, свои пулы и кучу других инструментов, в итоге раздувая плагин и усложняя быстрое освоение.
А зачем называть контексты "нодами"?) Типа чтобы выглядело как СОБСТВЕННАЯ НЕ ТАКАЯ КАК ВСЕ АРХИТЕКТУРА? А не просто как калька на любой DI фреймворк? Выглядит просто как попытка скрыть непонимание существующих принципов за "созданием новых решений" Жаль что видимо на хабре не сложилось засорять умы такими "революционными" решениями, пришлось идти на ютуб за более несмышленной аудиторией)
На самом деле, это, действительно, собственная архитектура для моего проекта, и я ее назвал нодовой, потому что она фактически строится на одном классе контекста. А статья на хабре будет :)
@@CodeCraftUnityEdition Все еще не звучит как хоть какая-то разница между этим и любым DI-фреймворком) Скорее как неумение им пользоваться С тем же успехом можно назвать Model-View-Controller как Data-Presentation-Manager и назвать это "собственной архитектурой для моего проекта"
разочарую вас этот подход как раз более простой и уже давно придуман, в юнити как раз реализован более сложный и более подходящий для игр архитектурный подход
@@CodeCraftUnityEdition еще раз пересмотрел, спустя два месяца собственных подуг в разработке (я еще совсем новичок). По-другому восприниматеся. Сам столкнулся с проблемой инициализации компонентов в игре и с жесткой привязкой к монобехам. Попробую базовые принципы перенять. Спасибо. Ты молодец!
