Комментарии 13
Не совсем понятна цель статьи, больше похоже на поток мыслей и с претензиями к движку.
Про архитектуру и организацию проекта – вещь субъективная, "лучшей практикой" не назову, использовать ваш вариант не стал бы, выглядит очень переусложненной, вы и сами это говорите.
> Но даже такой простой проект очень быстро разросся и стал трудно поддерживаемым
Мне ближе по душе, то, как предлагает делать сама Unity. Она простая и очень понятная, поэтому другим людям будем проще вкатываться в проект.
Противоречивое сложилось ощущение после прочтения статьи, как будто вы боролись с ветреными мельницами (и не очевидно, кто выиграл).
Если опираться на название, то я не согласен, что это лучшие практики. Советы крайней субъективные и вряд-ли похожи на распространенные "лучшие практики", так ещё и проверены на крайней меленьком проекте, что выглядит как минимум не убедительно. Рассказывать про лучшие практики надо, когда есть проект в релизе, вам нравится как он написан и работает, и тогда уже есть смысл чем-то поделиться.
В остальном, похоже на попытку перенести вебовские практики в игры и юнити, где это не очень уместно. Есть множество более удобных и простых вариантов построить архитектуру для малых, средних и большие проектов.
Раздел с претензиям к статье не вяжется, непонятно зачем он здесь. Выглядит как "я программировал не игры, и когда имея опыт другой разработки пришёл в юнити, то мне многие вещи непонятны или не нравятся". Многие претензии уверен отпадут, если чуть больше поработать с игровым движком и вникнуть в технические ограничения, которые как вы сами заметили не только к юнити относятся.
Если опираться на название, то я не согласен, что это лучшие практики. Советы крайней субъективные и вряд-ли похожи на распространенные "лучшие практики", так ещё и проверены на крайней меленьком проекте, что выглядит как минимум не убедительно.
У разных людей разные привычки и предпочтения. Если вы привыкли к другим парадигмам, то это не значит, что мои идеи плохие. И я не думаю, что есть что-то лучше, чем идеи чистой архитектуры, которые я использовал.Рассказывать про лучшие практики надо, когда есть проект в релизе, вам нравится как он написан и работает, и тогда уже есть смысл чем-то поделиться.Сделав много проб и ошибок, и потратив много времени, я нашел достаточно хорошие решения (по-моему субъективному мнению). Было бы лучше, если бы никто о них не узнал?
В остальном, похоже на попытку перенести вебовские практики в игры и юнити, где это не очень уместно. Есть множество более удобных и простых вариантов построить архитектуру для малых, средних и большие проектов.Почему в Unity это не уместно? Чем Unity отличается от других областей разработки?
Раздел с претензиям к статье не вяжется, непонятно зачем он здесь. Выглядит как "я программировал не игры, и когда имея опыт другой разработки пришёл в юнити, то мне многие вещи непонятны или не нравятся".Именно так! Многие вещи мне не нравятся. Что-то можно было бы сделать лучше. Что-то в Unity могло бы быть лучше. И это тоже полезно знать.
Многие претензии уверен отпадут, если чуть больше поработать с игровым движком и вникнуть в технические ограничения, которые как вы сами заметили не только к юнити относятся.Каким образом они отпадут? Нет, не отпадут. Конечно же везде есть свои проблемы. И это всегда будет отнимать время и нервы.
Я хоть с часть претензий и согласен, тем не менее писать статьи это сложно. Так что как бы то ни было - молодец, продолжай, старайся:3
Почему в Unity это не уместно? Чем Unity отличается от других областей разработки?
Потому что для Unity, как и других движков, существуют некоторые рекомендации, которые применяются на существенно большем числе проектов. И этот вариант, который используется в индустрии, становится своего рода "стандартом". Отсюда возникает резонный вопрос - для чего делать не стандартными способами?
Касательно MonoBehaviour и AActor - это механизм, предовращающий прямой контроль над временем жизни объектов. Поэтому конструкторы вынесены на сторону движка, а наружу торчат только несколько методов, которые можно определить для инициализации. Насколько мне известно, этот способ актуален как минимум для UE и Unity, но лично видел еще в двух проприетарных движках.
Проблема моей архитектуры в том, что получается оверкод. Наверное в оверкоде есть смысл, когда над проектом работают сотни людей на протяжении десятилетий. Но в играх важнее скорость написания и изменений. К сожалению, я наверное излишне переусложнил свой фреймворк.
Поэтому конструкторы вынесены на сторону движка
В теории можно было бы передавать в метод делегат, который создает объект. Но почему-то так нельзя. Может быть на это были причины. Может быть и не было никаких причин.
Насчет MonoBehaviour конструкторов и невозможности их использования. Все C# компоненты, по сути, являются лишь обертками над нативными объектами Unity. Соответственно, их жизненный цикл возможно контролировать только через методы, которые предоставляет сам движок (Instantiate, Destroy, AddComponent). К тому же, насколько я понимаю, это необходимо для сериализации компонентов в редакторе.
Лучшая практика для Юнити = не использовать Юнити)
Устал листать статью из-за большего количества практически идентичных скриншотов (без них читалось бы лучше, ИМХО (не все естественно убрать, а которые не несут по сути полезно информативности).
Что касается сути статьи, как отметили выше - это субъективщина и называть лучшими ее конечно громко)
Далее про итог:
Монобех - поэтому используют методы инициализации, не совсем понятно (если логически думать) зачем тебе прям конструктор монобеха, ведь монобех это компонент объекта, а не сам игровой объект. Так что либо не используй монобех, либо используй метод инициализации /другие практики для создания объекта без конструктора.
Слушать сообщения Unity - делаешь управляющий класс, который содержит композицию сторонних объектов не монобехов и выполняешь исходя из нужной логики все это дело. Либо делаешь статичное событие и не монобехи на него привязываются. Да и в целом много вариантов.
Много возможностей кастомизировать окна/создавать свои (все ли не знаю, но в инспекторе достаточно возможностей). Для упрощения этого дела существует например ODIN.
Про выгрузку - так создай отдельную сцену под фичу и работай там с ней. Если не нагружать ее и не использовать для перехода в другие сцены - то по идее она отдельно билдится. Но тут могу ошибаться.
UIToolkit - днище если откровенны будем))) Надеюсь его доработают
Ну а последний пункт (да и к предпоследнему тоже относится) - Classic by Unity Team
Лучшие практики для Unity 3D проекта