Документация нужна наверное уже для огромных компаний со своими плагинами, а не для индикодеров. Называешь классы, методы и переменные адекватно и не надо никаких документаций писать, открыл скрипт, пролистал до метода и понял для чего его писал 49:15 "абилити систем, это основная система, которая управляет абилками" и тут Леонид Аркадьевич из видоса "Да ладна" (С) Нужен более яркий пример того, что документация нужна в игрострое, а то эта документация смахивает на сборник комментариев для того, чтобы потешить своё ЧСВ (вон я сколько кода написал, да ещё и документацию к этому), кажется я видел в видосах, где одни кодеры говорят, что новичкам нужно писать комментарии к своему коду, а другие говорят, что нужно писать читаемый код чтобы его логика была понятна, и не приходилось писать комментарии к тому, как работает какой-то метод
ну может про абилити систем и кажется в духе капитана очевидность, но у нас есть также CompositeAbilitySystem и SimpleAbilitySystem, поэтому человек может просто глянуть в доку и понять от какой системы можно отталкиваться в первую очередь, и какая система в каких случаях ему нужна. Плюс документация нужна для того чтобы понять где копать (фильтрация по тегам), не шерстя всю кодобазу, которая как мы знаем неминуемо расширяется.
@@user-kt8rw7wu7o ну, как я и сказал, нужен более яркий пример, если бы затронули 2 этих понятия в ролике и в кратце рассказали для чего они нужны, то возможно я и не написал бы этот вопрос )
Есть два вопроса. 1. Применяют ли при проектировании игр Event Storming? 2. Про пример с абилкой - не понял, зачем в объект абилки включать и иконку, и урон и т.п? По тому же DDD лучше выявить ограниченные контексты, а в них уже описывать свои сущности абилок, которые отвечают требованиям этих контекстов.
Оппонирую по поводу композиции: тут много недосказанно. Композиция нормально работает только если у нас есть разделение по ограниченным контекстам, иначе неизбежна копипаста одного и того же кода. К сожалению, тактические DDD паттерны работают хорошо только вместе с стратегическим проектированием.
@@user-kt8rw7wu7o композит Автомобиль может содержать подмодуль с какой либо логикой, колесо. В соответствии с DDD, к данному модулю можно получить доступ только в контексте основной сущности (автомобиль). Так что если нам нужно будет положить колесо как отдельностоящую сущность, придётся «закопать» остальной автомобиль, или копипастить (например, иметь wheel и wheelEntity с копипастной моделью). Но если у нас есть разделение на ограниченные контексты (опять же из того ddd), то колесо может быть отдельной сущностью просто в другом контексте. Основной смысл в том, тактики ddd (например, композит), плохо работают без DDD стратегий (например,, ограниченный контекст).
@@KawIntSpb тут ключевой вопрос в том - какое поведение будет у колеса как отдельной сущности, и колеса которое является частью композиции автомобиля. Если у них разное поведение, то это в принципе разные объекты, возможно внутри они будут иметь похожую логику/данные, если она идентична, всегда можно вынести её в отдельный класс/тип/набор классов и переиспользовать как в рамках композиции, так и в рамках наследования (чтобы исключить повторения одинаковых данных/полей у колёс). Если мы в целом придерживаемся композиции, это же не означает что мы напрочь исключаем наследование. Допустим у нас наследование исключено, (в рамках pure ECS фреймворка, например компоненты стракты). В этих условиях за счёт атомарности и компонентов тегов, мы можем сформировать достаточно контекста для сущности, чтобы определить её поведение и сделать это довольно кардинально. У нас может быть сколько угодно колёс, с сколько угодно разным ожидаемым поведением.
@@user-kt8rw7wu7o а наследование никто не исключает. Просто без «ограниченных контекстов» мы получим жесткую путаницу, а наследование прибьёт гвоздями сущности.
@@KawIntSpb =) чувствую прям ситуацию про 2а стула, мне тут сложно аргументировать, я бы конечно посмотрел на решения для конкретного проекта, и возможно нашёл бы разумные компромиссы )
Мда. Строить архитектуру исходя из того что наймёшь кучу дешёвых мидлов, которые уже будут знать весь стэк - это очень наивное решение. Так же другие очень спорные моменты, передёргивания и выход в крайности при принятии решений, выдают очень маленький опыт автора в построении этой самой архитектуры. Никто так не делает. Обучить мидлов нужным фреймворкам и библиотекам гораздо проще, быстрее, надёжнее, а самое главное более правильное решение т.к. позволяет сделать проект "так как задумывалось", а не "так как толпа дешёвых мидлов смогла". Хотя судя по дальнейшему изложению, виден опыт построения кода. С одной стороны таких вот докладов про архитектуру мало, а с другой стороны такие реализации только вводят в заблуждение людей и увеличивают энтропию...
в индустрии геймдева очень важна скорость разработки, все хотят дешего получить продукт, нанимать мидлов и обучать их, такое мало кто себе может позволить, обычно берут уже тех кто знает выбранную архитектуру/стек, в ру индустрии это чаще что то наподобие MVP/MVVM, с зенжектом или каким то видом сервис локатора. У меня более 20 игр за плечами, плюс я видел код многих популярных проектов на рынке и знаю как они устроены. Поэтому не совсем понимаю в чем именно выражается моя наивность и маленький опыт. Я озвучиваю то что есть/ситуацию на рынке.
@@user-kt8rw7wu7o просто чувак самоутвердиться решил на тебе бро. Опусти другого чтобы выглядеть лучше самому. Пусть свой доклад запилит мы посмотрим похлопаем его гениальному интеллекту и знаниям архитектуры. "Никто так не делает" - если ты так не делаешь не значит что никто)) тупо манипуляция с его стороны.
@@alexandr_sirota не придирки. Может я просто еще не всретил статей где расскажут почему это хорошо. Но такой жирный класс, как какойнить контроллер, всегда противоречит ООП и солиду. Из тех, кто приходили в команду, с контроллерами было достаточно людей, и основной проблемой становится то, что на определенном этапе разработки, развивать дальше проект почти не получается, все уходит на переписывание и подгонку. И это в ГК.. в больших проектах не учавствовал, может там это както сработает, но чтот я сомневаюсь
@@qdesnikk я сижу немножко в шоке, так как самый распространённый паттерн MVC (среди многих языков, не только в шарпе) содержит в себе слово контроллер, и это самый популярный паттерн на просторах рунета, суть контроллера - отделить логику от данных (модели) и представления (view). И как раз апологетами SOLID и чистого кода, считается что лучший паттерн ( ну или его производные MVP, MVU, MVVM). Насчёт много спорных вопросов - в докладе фигурируют выдержки и мысли которые транслируются такими людьми как Robert Martin, Martin Fowler, Eric Evans. Это как раз люди которые сформировали многие практики и понятия в ООП. Я могу согласиться что в ГК например MVC не нужен, так как объективно он растягивает разработку, но первый раз слышу что MVC убивает проект ), опять же апологеты SOLID считают что только на MVC можно выпускать проекты.
@@user-kt8rw7wu7o да, вот только если заглянуть под капот, то зачастую там, не то что предлагает mvc. И вправду в первом посте я написал не корректно. Почти всегда у не опытных людей эти классы имеют много 'чужого' и управляют еще этим.
О, про архитектуру, ура
Круто!
Хочу больше видео с Евгением...
Женя, молодец. Помню как он в Азуре кодил :) 3000 строк кода для функционала открытия сундука:)
да, было дело ) помоему там вообще 4тысячи строк было )
@@user-kt8rw7wu7o на самом деле - молодец.
@@user-kt8rw7wu7o а с вами можно связаться в вк телеге или линкедне?
Сенк, успехов в Ваших проетах.
Спасибо!
Женя - крутой! С каждым годом серьёзный рост, как профи.
Звуки из хоррора на фоне чтоб архитектура казалась страшнее
Это звуки juniors во время code review 🔥
Документация нужна наверное уже для огромных компаний со своими плагинами, а не для индикодеров. Называешь классы, методы и переменные адекватно и не надо никаких документаций писать, открыл скрипт, пролистал до метода и понял для чего его писал
49:15 "абилити систем, это основная система, которая управляет абилками" и тут Леонид Аркадьевич из видоса "Да ладна" (С)
Нужен более яркий пример того, что документация нужна в игрострое, а то эта документация смахивает на сборник комментариев для того, чтобы потешить своё ЧСВ (вон я сколько кода написал, да ещё и документацию к этому), кажется я видел в видосах, где одни кодеры говорят, что новичкам нужно писать комментарии к своему коду, а другие говорят, что нужно писать читаемый код чтобы его логика была понятна, и не приходилось писать комментарии к тому, как работает какой-то метод
ну может про абилити систем и кажется в духе капитана очевидность, но у нас есть также CompositeAbilitySystem и SimpleAbilitySystem, поэтому человек может просто глянуть в доку и понять от какой системы можно отталкиваться в первую очередь, и какая система в каких случаях ему нужна. Плюс документация нужна для того чтобы понять где копать (фильтрация по тегам), не шерстя всю кодобазу, которая как мы знаем неминуемо расширяется.
@@user-kt8rw7wu7o ну, как я и сказал, нужен более яркий пример, если бы затронули 2 этих понятия в ролике и в кратце рассказали для чего они нужны, то возможно я и не написал бы этот вопрос )
А ваша гибридная реализация ESC фреймворка это закрытая технология или можно с ней ознакомится на гитхабе?
Есть два вопроса.
1. Применяют ли при проектировании игр Event Storming?
2. Про пример с абилкой - не понял, зачем в объект абилки включать и иконку, и урон и т.п? По тому же DDD лучше выявить ограниченные контексты, а в них уже описывать свои сущности абилок, которые отвечают требованиям этих контекстов.
52:50 почему бы вы смотрели в сторону анрила, если на юньке на раз два можно написать свой эдиторскрипт и даже отдельные панельки и окна?
Анрил мне нравится, возможно сделаю проект и на нём однажды. Но реалии индустрии таковы, что это в первую очередь сегмент мобильных игр/юнити.
Оппонирую по поводу композиции: тут много недосказанно. Композиция нормально работает только если у нас есть разделение по ограниченным контекстам, иначе неизбежна копипаста одного и того же кода. К сожалению, тактические DDD паттерны работают хорошо только вместе с стратегическим проектированием.
Можно живой пример в студию, мне просто сложно представить случаи где композиция привела бы к дублированию кода и нарушению принципа DRY
@@user-kt8rw7wu7o композит Автомобиль может содержать подмодуль с какой либо логикой, колесо. В соответствии с DDD, к данному модулю можно получить доступ только в контексте основной сущности (автомобиль). Так что если нам нужно будет положить колесо как отдельностоящую сущность, придётся «закопать» остальной автомобиль, или копипастить (например, иметь wheel и wheelEntity с копипастной моделью).
Но если у нас есть разделение на ограниченные контексты (опять же из того ddd), то колесо может быть отдельной сущностью просто в другом контексте.
Основной смысл в том, тактики ddd (например, композит), плохо работают без DDD стратегий (например,, ограниченный контекст).
@@KawIntSpb тут ключевой вопрос в том - какое поведение будет у колеса как отдельной сущности, и колеса которое является частью композиции автомобиля. Если у них разное поведение, то это в принципе разные объекты, возможно внутри они будут иметь похожую логику/данные, если она идентична, всегда можно вынести её в отдельный класс/тип/набор классов и переиспользовать как в рамках композиции, так и в рамках наследования (чтобы исключить повторения одинаковых данных/полей у колёс).
Если мы в целом придерживаемся композиции, это же не означает что мы напрочь исключаем наследование. Допустим у нас наследование исключено, (в рамках pure ECS фреймворка, например компоненты стракты). В этих условиях за счёт атомарности и компонентов тегов, мы можем сформировать достаточно контекста для сущности, чтобы определить её поведение и сделать это довольно кардинально. У нас может быть сколько угодно колёс, с сколько угодно разным ожидаемым поведением.
@@user-kt8rw7wu7o а наследование никто не исключает. Просто без «ограниченных контекстов» мы получим жесткую путаницу, а наследование прибьёт гвоздями сущности.
@@KawIntSpb =) чувствую прям ситуацию про 2а стула, мне тут сложно аргументировать, я бы конечно посмотрел на решения для конкретного проекта, и возможно нашёл бы разумные компромиссы )
Мда. Строить архитектуру исходя из того что наймёшь кучу дешёвых мидлов, которые уже будут знать весь стэк - это очень наивное решение.
Так же другие очень спорные моменты, передёргивания и выход в крайности при принятии решений, выдают очень маленький опыт автора в построении этой самой архитектуры.
Никто так не делает. Обучить мидлов нужным фреймворкам и библиотекам гораздо проще, быстрее, надёжнее, а самое главное более правильное решение т.к. позволяет сделать проект "так как задумывалось", а не "так как толпа дешёвых мидлов смогла".
Хотя судя по дальнейшему изложению, виден опыт построения кода.
С одной стороны таких вот докладов про архитектуру мало, а с другой стороны такие реализации только вводят в заблуждение людей и увеличивают энтропию...
в индустрии геймдева очень важна скорость разработки, все хотят дешего получить продукт, нанимать мидлов и обучать их, такое мало кто себе может позволить, обычно берут уже тех кто знает выбранную архитектуру/стек, в ру индустрии это чаще что то наподобие MVP/MVVM, с зенжектом или каким то видом сервис локатора. У меня более 20 игр за плечами, плюс я видел код многих популярных проектов на рынке и знаю как они устроены. Поэтому не совсем понимаю в чем именно выражается моя наивность и маленький опыт. Я озвучиваю то что есть/ситуацию на рынке.
@@user-kt8rw7wu7o просто чувак самоутвердиться решил на тебе бро. Опусти другого чтобы выглядеть лучше самому. Пусть свой доклад запилит мы посмотрим похлопаем его гениальному интеллекту и знаниям архитектуры.
"Никто так не делает" - если ты так не делаешь не значит что никто)) тупо манипуляция с его стороны.
Контроллеры. Плохая практика. Да и в целом много вопросов спорных..
А можно поподробнее, please, для тех, кто собаку не съел?)
придирки к слову "контроллер"? или про что?
@@alexandr_sirota не придирки. Может я просто еще не всретил статей где расскажут почему это хорошо. Но такой жирный класс, как какойнить контроллер, всегда противоречит ООП и солиду. Из тех, кто приходили в команду, с контроллерами было достаточно людей, и основной проблемой становится то, что на определенном этапе разработки, развивать дальше проект почти не получается, все уходит на переписывание и подгонку. И это в ГК.. в больших проектах не учавствовал, может там это както сработает, но чтот я сомневаюсь
@@qdesnikk я сижу немножко в шоке, так как самый распространённый паттерн MVC (среди многих языков, не только в шарпе)
содержит в себе слово контроллер, и это самый популярный паттерн на просторах рунета, суть контроллера - отделить логику от данных (модели) и представления (view). И как раз апологетами SOLID и чистого кода, считается что лучший паттерн ( ну или его производные MVP, MVU, MVVM). Насчёт много спорных вопросов - в докладе фигурируют выдержки и мысли которые транслируются такими людьми как Robert Martin, Martin Fowler, Eric Evans. Это как раз люди которые сформировали многие практики и понятия в ООП. Я могу согласиться что в ГК например MVC не нужен, так как объективно он растягивает разработку, но первый раз слышу что MVC убивает проект ), опять же апологеты SOLID считают что только на MVC можно выпускать проекты.
@@user-kt8rw7wu7o да, вот только если заглянуть под капот, то зачастую там, не то что предлагает mvc. И вправду в первом посте я написал не корректно. Почти всегда у не опытных людей эти классы имеют много 'чужого' и управляют еще этим.