На около-игровом проекте использовал такой подход (своя реализация с небольшой код-генерацией). Из плюсов могу добавить: - удобно синхронизировать несколько инстансов билда (такая специфика) по сети - значения переменных можно смотреть в менеджере (если таковой написать), тут и дебаг и т.д. - значения можно сохранить (всякие настройки и т.д.) вплоть до системы сохранения и запоминания состояния билда. Была задача при запуске следующего инстанса передать ему состояние. - удобно добавлять реакции на изменения, похоже на извращенный реактивный подход. - можно сделать несложные скрипты. Удобнее работать с такими переменными в средствах визуального программирования. - много гд/бизнес логики собирают другие люди, чьей квалификации достаточно для такого подхода.. короче до определенной границы это дешевле. - модульность, действительно очень низкая связность. Тут без дополнительных инструментов (самописных) непросто. Например есть расширение редактора, которое пытается построить граф зависимостей, но см усложнением проекта и это не помогает. Тут выручают слои-группы, т.е. определение неких областей видимости, где переменные группируются и определяется, какая группа какие другие "видит". Все минусы в видео справедливые. Особенно размывание логики по инспекторам, сложность дебага, и вообще хоть сколько-нибудь сложные вещи (а сложное - в этом случае все, что больше 2-3 переменных). В долгосрочной перспективе такой подход может навредить.
Поддерживаю хейтспич. Тут не то что другие члены команды, ты сам через день забыть свои связи можешь и хрен разберёшь потом. Отлаживать совсем боль. А ещё постоянно следить за их состоянием и обнулять... Бррр
Ну я юзаю SO только в нужных местах, таких как инвентари и пр, это для удобности типа создание айтемов удобно делать. Ну короче полностью архитектуру строить на них это действительно такое себе решение ))
Есть история. Был человек, пригласил в команду по разработке игры, ну я не сильно прям такой кодер, не использовал SO или что-то там еще, обычно делал именно в Mono behaviour. Ну допустим согласился, дал мне проект, посмотрел я на скрипты, конечно, было не понятно(прошлый человек использовал ивенты и SO), но у меня немного была другая задача. Начал делать по своему, прошел где то месяц, игру заморозили, потом через полгода пишет тот самый человек, говорит, мол, возвращайся, будем делать. Сначала мягко сказал, что не понимает моего кода(да я не комментировал, ибо зачем. Я думал, что сам руководитель не будет лезть в код так, как он ничего не понимает в нем), ну а потом обосрал, говорит что у тебя слишком высока зависимость скриптов между собой, надо переделывать, ну ладно я сказал, ебись сам с этим, ведь игра и так прекрасно работала. Весь сюр в том, что человек даже не заплатил, но зато обосрал)
Хм... на текущем проекте использую SO для интерактивных объектов, которые могут поддерживать несколько действий. Например, для электрогенератора: заправить генератор, начать подключение, завершить подключение. Основное требование было: позволить ГД навесить любые экшены на любые интерактивные объекты. Также, было требование: позволить ГД самим заводить новые объекты. То есть, создавать новый айтем, например: "металлолом", задать ему ключи локализации для имени и описания, а также ссылку на иконку. Меня, как единственного кодера, это очень разгрузило, а вот как ГД будут менеджерить это все - другой вопрос. Возможно, будем парсить все с гуглтаблиц, либо придётся заводить отдельно Editor window для решения подобных вопросов. На момент выстраивания архитектуры, других вариантов, честно говоря, не видел. А ваше видео заставило насторожиться 😅
@@artUSUN ключи локализации, само собой, будут лежать в гугл таблицах. Ничего не мешает завести отдельную таблицу Items со столбцами, соответствующими полям моих SO. А потом, из редактора, кликом одной кнопки парсить и актуализировать все SO в проекте. Куда интереснее другой вопрос: ссылки на иконки как предлагаете хранить в таблице? Составлять относительные пути? Ну это вообще не вариант. Вероятность ошибки крайне высока.
@@Elledan3101 именно так и предлагаю) Для всяких спрайтов, звуков, префабов использовать строковые пути. А потом очень удобно скармливать все это адрессаблесам. Если копировать, а не переписывать пути - вероятность ошибки меньше. Но, согласен, жизнь показывает, что гд-шники порой и в ctrl+c,ctrl+v умеют ошибаться)) Лечится простой тулзой на сверку путей. Мне не понятно зачем в данном случае вообще нужна СО-шка. ГД имеют таблицу, в которой они, собственно, и будут всячески вертеть данные. Визуализировать в юнити вроде как ничего не нужно. Тогда зачем нам морочится с парсером и СО-шками, если можно использовать самый обычный класс? И потом этот же класс и парсер одним лёгким движением перенести на сервер
@@artUSUN далеко не всегда нужно все жёстко завязывать на таблицы. Если ГД нужно поиграться с параметрами, ему легче использовать SO в рантайме. К тому же, SO имеют сильное преимущество в сериализации/десериализации данных "из коробки", а также юнити очень хорошо их сжимает. На одном из проектов мы сохраняли в SO данные для воксельных уровней. В результате, SO был как минимум в 4-5 раз легче, чем исходная слайсовая текстура с разметкой из MagicaVoxel. Это из того, что я мог назвать навскидку.
Алексей, а как же ECS?) Говорят у вас в курсе этот вопрос не затрагивается, но помнится вы были воодушевлены подходом.) интересно что изменилось) ПЫ.СЫ Сами давно юзаем свою екс в проде и всем довольны, но любовь отчасти началась с вашего доклада)
Не изменилось) мы тоже продолжаем им пользоваться, в этот курс не влез просто. Надеемся сделать отдельный курс по ECS в каком-то там из вариантов будущего :)
Делал архитектуру на UnityEvent'ах, чтобы удобно конфигурировать лвла в головоломке. Было удобно, очень даже, но та запутанность, сложность мерджа и сопутствующее, о чем ты говорил очень мешала. Также и баги и отлавливание ошибок. На этом прям горел. За то ГК сделал нормальный))) Возможно для каких-то модулей это и актуально но не для элемента, нитью которого протянута вся игра...
И все же, почему юнити так топят за эту архитектуру?) Открыл их опен сорс проект, чтобы посмотреть как пишут люди более высокого уровня, чем я, и был сильно удивлен, что им по душе такая система, так как минусы оговоренные в видео довольно очевидны для такой архитектуры
Тут сложно конечно ответить точно, так как знает это только Unity, но мы можем попредполагать. Юнити всегда стремилась сделать максимально низкий порог входа. У этого подхода - довольно низкий. Сами по себе чуваки из юнити, по крайней мере по нашиму опыту общения, не так чтоб рекомендуют ее для продакшна :)
На данный момент, я пришел к следующей идеи. Всю логику делить на небольшие классы(не моно), которые являются компонентами и наследуются от базового. Там реализована логика, “магических” функций Awake, Start… , кэширована инфа о трансформе и классе сущности базового объекта. В самом классе сущности, есть контейнер этих компонентов. Ну и далее каждый игровой объект наследуется от сущности, имеет свой набор компонентов, которые потом кешируются в этот контейнер. И теперь, я легко могу получить из компонента другой компонент этого-же объекта или обратиться к нужной мне сущности и попытаться вытянуть нужный мне компонент. Также набор этих компонентов дает представление о самом поведении объекта.
Обычно нравятся ваши видео, но на это хочется поворчать. Изначально эта архитектура задумана и преподносится авторами как архитектура, позволяющая много делать дизайнерам. Т.е. она предполагает, что в команде много людей, не умеющих писать код. Недостатки подсвеченные в видео нерелевантны для такой ситуации. Я говорю про невозможность ревью кода, невозможность получать подсказки из IDE да даже проблемы с гитом. Если люди не умеют писать код, все эти преимущества им изначально недоступны. По сути, этот подход - это некоторый аналог визуального программирования, у которого есть все те же проблемы, озвученные в видео.
![일상 속 기분 좋음 [Proto disco meme]](http://i.ytimg.com/vi/DwmEIaZ7XGQ/mqdefault.jpg)
На около-игровом проекте использовал такой подход (своя реализация с небольшой код-генерацией). Из плюсов могу добавить:
- удобно синхронизировать несколько инстансов билда (такая специфика) по сети
- значения переменных можно смотреть в менеджере (если таковой написать), тут и дебаг и т.д.
- значения можно сохранить (всякие настройки и т.д.) вплоть до системы сохранения и запоминания состояния билда. Была задача при запуске следующего инстанса передать ему состояние.
- удобно добавлять реакции на изменения, похоже на извращенный реактивный подход.
- можно сделать несложные скрипты. Удобнее работать с такими переменными в средствах визуального программирования.
- много гд/бизнес логики собирают другие люди, чьей квалификации достаточно для такого подхода.. короче до определенной границы это дешевле.
- модульность, действительно очень низкая связность. Тут без дополнительных инструментов (самописных) непросто. Например есть расширение редактора, которое пытается построить граф зависимостей, но см усложнением проекта и это не помогает. Тут выручают слои-группы, т.е. определение неких областей видимости, где переменные группируются и определяется, какая группа какие другие "видит".
Все минусы в видео справедливые. Особенно размывание логики по инспекторам, сложность дебага, и вообще хоть сколько-нибудь сложные вещи (а сложное - в этом случае все, что больше 2-3 переменных).
В долгосрочной перспективе такой подход может навредить.
"Не делайте так, делайте как мы говорим, только заплатите"
Вот-вот, видос ни о чем
Люблю когда у человека есть деньги, а звук как из бочки.
Раз видос запилили, значит вопрос было очень много :D
Ахах
Ещё многие спрашивают, что за джинсовая куртка у Алексея
Ни на что не намекаю, но мерч вышел бы неплохой))0)
Поддерживаю хейтспич. Тут не то что другие члены команды, ты сам через день забыть свои связи можешь и хрен разберёшь потом.
Отлаживать совсем боль.
А ещё постоянно следить за их состоянием и обнулять... Бррр
самое главное постоянно слетают ссылки, было на какой то 17 версии юнити, каждый день на работе правишь ссылки
Ну я юзаю SO только в нужных местах, таких как инвентари и пр, это для удобности типа создание айтемов удобно делать. Ну короче полностью архитектуру строить на них это действительно такое себе решение ))
Есть история. Был человек, пригласил в команду по разработке игры, ну я не сильно прям такой кодер, не использовал SO или что-то там еще, обычно делал именно в Mono behaviour. Ну допустим согласился, дал мне проект, посмотрел я на скрипты, конечно, было не понятно(прошлый человек использовал ивенты и SO), но у меня немного была другая задача. Начал делать по своему, прошел где то месяц, игру заморозили, потом через полгода пишет тот самый человек, говорит, мол, возвращайся, будем делать. Сначала мягко сказал, что не понимает моего кода(да я не комментировал, ибо зачем. Я думал, что сам руководитель не будет лезть в код так, как он ничего не понимает в нем), ну а потом обосрал, говорит что у тебя слишком высока зависимость скриптов между собой, надо переделывать, ну ладно я сказал, ебись сам с этим, ведь игра и так прекрасно работала. Весь сюр в том, что человек даже не заплатил, но зато обосрал)
Хм... на текущем проекте использую SO для интерактивных объектов, которые могут поддерживать несколько действий. Например, для электрогенератора: заправить генератор, начать подключение, завершить подключение. Основное требование было: позволить ГД навесить любые экшены на любые интерактивные объекты.
Также, было требование: позволить ГД самим заводить новые объекты. То есть, создавать новый айтем, например: "металлолом", задать ему ключи локализации для имени и описания, а также ссылку на иконку.
Меня, как единственного кодера, это очень разгрузило, а вот как ГД будут менеджерить это все - другой вопрос. Возможно, будем парсить все с гуглтаблиц, либо придётся заводить отдельно Editor window для решения подобных вопросов.
На момент выстраивания архитектуры, других вариантов, честно говоря, не видел. А ваше видео заставило насторожиться 😅
А почему бы эти ключи локализации и ссылки на иконки не хранить сразу в гугл таблице?)
@@artUSUN ключи локализации, само собой, будут лежать в гугл таблицах. Ничего не мешает завести отдельную таблицу Items со столбцами, соответствующими полям моих SO. А потом, из редактора, кликом одной кнопки парсить и актуализировать все SO в проекте.
Куда интереснее другой вопрос: ссылки на иконки как предлагаете хранить в таблице?
Составлять относительные пути? Ну это вообще не вариант. Вероятность ошибки крайне высока.
@@Elledan3101 именно так и предлагаю)
Для всяких спрайтов, звуков, префабов использовать строковые пути. А потом очень удобно скармливать все это адрессаблесам.
Если копировать, а не переписывать пути - вероятность ошибки меньше. Но, согласен, жизнь показывает, что гд-шники порой и в ctrl+c,ctrl+v умеют ошибаться)) Лечится простой тулзой на сверку путей.
Мне не понятно зачем в данном случае вообще нужна СО-шка. ГД имеют таблицу, в которой они, собственно, и будут всячески вертеть данные. Визуализировать в юнити вроде как ничего не нужно. Тогда зачем нам морочится с парсером и СО-шками, если можно использовать самый обычный класс? И потом этот же класс и парсер одним лёгким движением перенести на сервер
@@artUSUN далеко не всегда нужно все жёстко завязывать на таблицы. Если ГД нужно поиграться с параметрами, ему легче использовать SO в рантайме. К тому же, SO имеют сильное преимущество в сериализации/десериализации данных "из коробки", а также юнити очень хорошо их сжимает. На одном из проектов мы сохраняли в SO данные для воксельных уровней. В результате, SO был как минимум в 4-5 раз легче, чем исходная слайсовая текстура с разметкой из MagicaVoxel.
Это из того, что я мог назвать навскидку.
Опыта у меня не много, но прототипы не уничтожают. Из них продолжают лепить.
Видос Отличный))) Зашел к курсу из далека))
Согласен. Но это не правильно. Прототип должен быть уничтожен, но вечная спешка и не хватка времени сделать этого не позволяет. )))
@@ilgiz2616 еще не разу такого не видел, максимум переписать плохие моменты)
Алексей, а как же ECS?) Говорят у вас в курсе этот вопрос не затрагивается, но помнится вы были воодушевлены подходом.) интересно что изменилось)
ПЫ.СЫ Сами давно юзаем свою екс в проде и всем довольны, но любовь отчасти началась с вашего доклада)
Не изменилось) мы тоже продолжаем им пользоваться, в этот курс не влез просто. Надеемся сделать отдельный курс по ECS в каком-то там из вариантов будущего :)
спасибо , все получилось
Код получился настолько слабо связным, что превратился в скриптовый язык.
Ага на столько слабо связанным что нейронные окончания тоже отказываются связываться друг с другом)
Делал архитектуру на UnityEvent'ах, чтобы удобно конфигурировать лвла в головоломке. Было удобно, очень даже, но та запутанность, сложность мерджа и сопутствующее, о чем ты говорил очень мешала. Также и баги и отлавливание ошибок. На этом прям горел. За то ГК сделал нормальный))) Возможно для каких-то модулей это и актуально но не для элемента, нитью которого протянута вся игра...
Архитектура убила выкачку денег с курсов вот он и бултыхается
И все же, почему юнити так топят за эту архитектуру?) Открыл их опен сорс проект, чтобы посмотреть как пишут люди более высокого уровня, чем я, и был сильно удивлен, что им по душе такая система, так как минусы оговоренные в видео довольно очевидны для такой архитектуры
Тут сложно конечно ответить точно, так как знает это только Unity, но мы можем попредполагать. Юнити всегда стремилась сделать максимально низкий порог входа. У этого подхода - довольно низкий. Сами по себе чуваки из юнити, по крайней мере по нашиму опыту общения, не так чтоб рекомендуют ее для продакшна :)
А если использовать другую систему контроля версий? Есть встроенный коллаб и Plastic SCM
Пластик вроде бы жутко платный, нет?
На данный момент, я пришел к следующей идеи. Всю логику делить на небольшие классы(не моно), которые являются компонентами и наследуются от базового. Там реализована логика, “магических” функций Awake, Start… , кэширована инфа о трансформе и классе сущности базового объекта. В самом классе сущности, есть контейнер этих компонентов. Ну и далее каждый игровой объект наследуется от сущности, имеет свой набор компонентов, которые потом кешируются в этот контейнер. И теперь, я легко могу получить из компонента другой компонент этого-же объекта или обратиться к нужной мне сущности и попытаться вытянуть нужный мне компонент. Также набор этих компонентов дает представление о самом поведении объекта.
Thanks)
Обычно нравятся ваши видео, но на это хочется поворчать.
Изначально эта архитектура задумана и преподносится авторами как архитектура, позволяющая много делать дизайнерам. Т.е. она предполагает, что в команде много людей, не умеющих писать код. Недостатки подсвеченные в видео нерелевантны для такой ситуации. Я говорю про невозможность ревью кода, невозможность получать подсказки из IDE да даже проблемы с гитом. Если люди не умеют писать код, все эти преимущества им изначально недоступны.
По сути, этот подход - это некоторый аналог визуального программирования, у которого есть все те же проблемы, озвученные в видео.