На около-игровом проекте использовал такой подход (своя реализация с небольшой код-генерацией). Из плюсов могу добавить: - удобно синхронизировать несколько инстансов билда (такая специфика) по сети - значения переменных можно смотреть в менеджере (если таковой написать), тут и дебаг и т.д. - значения можно сохранить (всякие настройки и т.д.) вплоть до системы сохранения и запоминания состояния билда. Была задача при запуске следующего инстанса передать ему состояние. - удобно добавлять реакции на изменения, похоже на извращенный реактивный подход. - можно сделать несложные скрипты. Удобнее работать с такими переменными в средствах визуального программирования. - много гд/бизнес логики собирают другие люди, чьей квалификации достаточно для такого подхода.. короче до определенной границы это дешевле. - модульность, действительно очень низкая связность. Тут без дополнительных инструментов (самописных) непросто. Например есть расширение редактора, которое пытается построить граф зависимостей, но см усложнением проекта и это не помогает. Тут выручают слои-группы, т.е. определение неких областей видимости, где переменные группируются и определяется, какая группа какие другие "видит". Все минусы в видео справедливые. Особенно размывание логики по инспекторам, сложность дебага, и вообще хоть сколько-нибудь сложные вещи (а сложное - в этом случае все, что больше 2-3 переменных). В долгосрочной перспективе такой подход может навредить.

Раз видос запилили, значит вопрос было очень много :D

Ещё многие спрашивают, что за джинсовая куртка у Алексея

Люблю когда у человека есть деньги, а звук как из бочки.

"Не делайте так, делайте как мы говорим, только заплатите"

Опыта у меня не много, но прототипы не уничтожают. Из них продолжают лепить. Видос Отличный))) Зашел к курсу из далека))

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

спасибо , все получилось

Хм... на текущем проекте использую SO для интерактивных объектов, которые могут поддерживать несколько действий. Например, для электрогенератора: заправить генератор, начать подключение, завершить подключение. Основное требование было: позволить ГД навесить любые экшены на любые интерактивные объекты. Также, было требование: позволить ГД самим заводить новые объекты. То есть, создавать новый айтем, например: "металлолом", задать ему ключи локализации для имени и описания, а также ссылку на иконку. Меня, как единственного кодера, это очень разгрузило, а вот как ГД будут менеджерить это все - другой вопрос. Возможно, будем парсить все с гуглтаблиц, либо придётся заводить отдельно Editor window для решения подобных вопросов. На момент выстраивания архитектуры, других вариантов, честно говоря, не видел. А ваше видео заставило насторожиться 😅

Поддерживаю хейтспич. Тут не то что другие члены команды, ты сам через день забыть свои связи можешь и хрен разберёшь потом. Отлаживать совсем боль. А ещё постоянно следить за их состоянием и обнулять... Бррр

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

Делал архитектуру на UnityEvent'ах, чтобы удобно конфигурировать лвла в головоломке. Было удобно, очень даже, но та запутанность, сложность мерджа и сопутствующее, о чем ты говорил очень мешала. Также и баги и отлавливание ошибок. На этом прям горел. За то ГК сделал нормальный))) Возможно для каких-то модулей это и актуально но не для элемента, нитью которого протянута вся игра...

Есть история. Был человек, пригласил в команду по разработке игры, ну я не сильно прям такой кодер, не использовал SO или что-то там еще, обычно делал именно в Mono behaviour. Ну допустим согласился, дал мне проект, посмотрел я на скрипты, конечно, было не понятно(прошлый человек использовал ивенты и SO), но у меня немного была другая задача. Начал делать по своему, прошел где то месяц, игру заморозили, потом через полгода пишет тот самый человек, говорит, мол, возвращайся, будем делать. Сначала мягко сказал, что не понимает моего кода(да я не комментировал, ибо зачем. Я думал, что сам руководитель не будет лезть в код так, как он ничего не понимает в нем), ну а потом обосрал, говорит что у тебя слишком высока зависимость скриптов между собой, надо переделывать, ну ладно я сказал, ебись сам с этим, ведь игра и так прекрасно работала. Весь сюр в том, что человек даже не заплатил, но зато обосрал)

Thanks)

А если использовать другую систему контроля версий? Есть встроенный коллаб и Plastic SCM

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

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

На данный момент, я пришел к следующей идеи. Всю логику делить на небольшие классы(не моно), которые являются компонентами и наследуются от базового. Там реализована логика, “магических” функций Awake, Start… , кэширована инфа о трансформе и классе сущности базового объекта. В самом классе сущности, есть контейнер этих компонентов. Ну и далее каждый игровой объект наследуется от сущности, имеет свой набор компонентов, которые потом кешируются в этот контейнер. И теперь, я легко могу получить из компонента другой компонент этого-же объекта или обратиться к нужной мне сущности и попытаться вытянуть нужный мне компонент. Также набор этих компонентов дает представление о самом поведении объекта.

Обычно нравятся ваши видео, но на это хочется поворчать. Изначально эта архитектура задумана и преподносится авторами как архитектура, позволяющая много делать дизайнерам. Т.е. она предполагает, что в команде много людей, не умеющих писать код. Недостатки подсвеченные в видео нерелевантны для такой ситуации. Я говорю про невозможность ревью кода, невозможность получать подсказки из IDE да даже проблемы с гитом. Если люди не умеют писать код, все эти преимущества им изначально недоступны. По сути, этот подход - это некоторый аналог визуального программирования, у которого есть все те же проблемы, озвученные в видео.