Сомневаюсь, что такая архитектура это хорошая практика. Во первых, если речь о стратегия, то там 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 косвенно ссылается на данные всех игроков?
Разве Юнити не делалась для того что бы геймдизанеры и художники могли работать параллельно с программистами? Если Геймдиз подвигал и что то сломалось, то значит просто плохой прогер. Разве нет?
Так то идея того же зенжекта была простая изначально. Просто потом туда начали добавляю свою фабрику, свои пулы и кучу других инструментов, в итоге раздувая плагин и усложняя быстрое освоение.
@@CodeCraftUnityEdition еще раз пересмотрел, спустя два месяца собственных подуг в разработке (я еще совсем новичок). По-другому восприниматеся. Сам столкнулся с проблемой инициализации компонентов в игре и с жесткой привязкой к монобехам. Попробую базовые принципы перенять. Спасибо. Ты молодец!
А зачем называть контексты "нодами"?) Типа чтобы выглядело как СОБСТВЕННАЯ НЕ ТАКАЯ КАК ВСЕ АРХИТЕКТУРА? А не просто как калька на любой DI фреймворк? Выглядит просто как попытка скрыть непонимание существующих принципов за "созданием новых решений" Жаль что видимо на хабре не сложилось засорять умы такими "революционными" решениями, пришлось идти на ютуб за более несмышленной аудиторией)
На самом деле, это, действительно, собственная архитектура для моего проекта, и я ее назвал нодовой, потому что она фактически строится на одном классе контекста. А статья на хабре будет :)
@@CodeCraftUnityEdition Все еще не звучит как хоть какая-то разница между этим и любым DI-фреймворком) Скорее как неумение им пользоваться С тем же успехом можно назвать Model-View-Controller как Data-Presentation-Manager и назвать это "собственной архитектурой для моего проекта"
разочарую вас этот подход как раз более простой и уже давно придуман, в юнити как раз реализован более сложный и более подходящий для игр архитектурный подход
Сомневаюсь, что такая архитектура это хорошая практика. Во первых, если речь о стратегия, то там 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 косвенно ссылается на данные всех игроков?
Го видос про туман войны!
Реально годных ресурсов на эту тему на просторах просто нет.
Сделать бы еще туман войны... 😄
Круто! и доступно!
Сумасшедший контент, спасибо вам огромное за работу!
яхай! Снова годный контент по юньке подъехал. От души ❤
Спасибо.
И ещё четыре слова.
Шикарно 😊
КаеФ, спасибо за видео! 100500 лайков этому господину!🎉
Вызов событий у слушателей происходит в порядке добавления и если важен порядок вызова, то такая реализация не подходит.
В целом, все так, но обычно порядок вызова не важен :)
Разве Юнити не делалась для того что бы геймдизанеры и художники могли работать параллельно с программистами? Если Геймдиз подвигал и что то сломалось, то значит просто плохой прогер. Разве нет?
Так то идея того же зенжекта была простая изначально. Просто потом туда начали добавляю свою фабрику, свои пулы и кучу других инструментов, в итоге раздувая плагин и усложняя быстрое освоение.
Да, поэтому прелести Zenject'а можно вкурить только на большом проекте :)
За видосы по архитектуре можно по 10 лайков ставить, жаль нельзя!)
Могу ли я использовать эту архитектуру не только к стратегии, но или например к рпг, экшену и тд?
В целом да)
Эх нового видео долго нет. А люди ждут 😊
Скоро!
@@CodeCraftUnityEdition отлично !
Пожалуйста помогите как убрать розовый фон когда хочешь сделать проект
Какой розовый фон?
Так и не стало понятно, почему не подошел ZEnject? Чего в нем не хватило?
Zenject можно юзать, я просто люблю велосипеды :)
А так в Zenject'е нет системы игровых событий, ее нужно допиливать к нему
Понял, спасибо@@CodeCraftUnityEdition
@@CodeCraftUnityEdition В Zenject'e есть шина событий, просто называется она Signals)
Велосипедный спорт, но почему бы и нет
Думал, что здесь какая-то вариация акторной модели для игростроя
Не оч понял про акторную модель
@@CodeCraftUnityEdition название и постановка вопроса создали ложные представления
Не ври, все мы знаем, что ты делаешь велосипеды просто потому, что ты их любишь делать)!
а в чём прикол использовать старую систему ввода живущую в Update, а не новую на событиях?
Тут был просто пример на старой, особо на этом не фокусировал внимание :)
Ну, для меня, как для новичка, информация сложна. На малых проектах такое может и не нужно. Но, смотрю, опытные гуру в комментах тоже не довольны))
Привет!
На малых проектах такое, действительно, не нужно. В моем случае проект большой, поэтому мне такое нужно :)
@@CodeCraftUnityEdition еще раз пересмотрел, спустя два месяца собственных подуг в разработке (я еще совсем новичок). По-другому восприниматеся. Сам столкнулся с проблемой инициализации компонентов в игре и с жесткой привязкой к монобехам. Попробую базовые принципы перенять. Спасибо. Ты молодец!
А зачем называть контексты "нодами"?) Типа чтобы выглядело как СОБСТВЕННАЯ НЕ ТАКАЯ КАК ВСЕ АРХИТЕКТУРА? А не просто как калька на любой DI фреймворк?
Выглядит просто как попытка скрыть непонимание существующих принципов за "созданием новых решений"
Жаль что видимо на хабре не сложилось засорять умы такими "революционными" решениями, пришлось идти на ютуб за более несмышленной аудиторией)
На самом деле, это, действительно, собственная архитектура для моего проекта, и я ее назвал нодовой, потому что она фактически строится на одном классе контекста. А статья на хабре будет :)
@@CodeCraftUnityEdition Все еще не звучит как хоть какая-то разница между этим и любым DI-фреймворком) Скорее как неумение им пользоваться
С тем же успехом можно назвать Model-View-Controller как Data-Presentation-Manager и назвать это "собственной архитектурой для моего проекта"
разочарую вас этот подход как раз более простой и уже давно придуман, в юнити как раз реализован более сложный и более подходящий для игр архитектурный подход