Проблема моей архитектуры в том, что получается оверкод. Наверное в оверкоде есть смысл, когда над проектом работают сотни людей на протяжении десятилетий. Но в играх важнее скорость написания и изменений. К сожалению, я наверное излишне переусложнил свой фреймворк.
Поэтому конструкторы вынесены на сторону движка
В теории можно было бы передавать в метод делегат, который создает объект. Но почему-то так нельзя. Может быть на это были причины. Может быть и не было никаких причин.
Если опираться на название, то я не согласен, что это лучшие практики. Советы крайней субъективные и вряд-ли похожи на распространенные "лучшие практики", так ещё и проверены на крайней меленьком проекте, что выглядит как минимум не убедительно. У разных людей разные привычки и предпочтения. Если вы привыкли к другим парадигмам, то это не значит, что мои идеи плохие. И я не думаю, что есть что-то лучше, чем идеи чистой архитектуры, которые я использовал.
Рассказывать про лучшие практики надо, когда есть проект в релизе, вам нравится как он написан и работает, и тогда уже есть смысл чем-то поделиться.
Сделав много проб и ошибок, и потратив много времени, я нашел достаточно хорошие решения (по-моему субъективному мнению). Было бы лучше, если бы никто о них не узнал?
В остальном, похоже на попытку перенести вебовские практики в игры и юнити, где это не очень уместно. Есть множество более удобных и простых вариантов построить архитектуру для малых, средних и большие проектов.
Почему в Unity это не уместно? Чем Unity отличается от других областей разработки?
Раздел с претензиям к статье не вяжется, непонятно зачем он здесь. Выглядит как "я программировал не игры, и когда имея опыт другой разработки пришёл в юнити, то мне многие вещи непонятны или не нравятся".
Именно так! Многие вещи мне не нравятся. Что-то можно было бы сделать лучше. Что-то в Unity могло бы быть лучше. И это тоже полезно знать.
Многие претензии уверен отпадут, если чуть больше поработать с игровым движком и вникнуть в технические ограничения, которые как вы сами заметили не только к юнити относятся.
Каким образом они отпадут? Нет, не отпадут. Конечно же везде есть свои проблемы. И это всегда будет отнимать время и нервы.
Я просто хотел поделится с миром своими идеями. Статья действительно весьма поверхностно описывает мой проект, но на мой взгляд все самое важное я рассказал.
Там еще контрольная группа была, которая жила в таких же условиях, но думала о чем-то другом. Вчера забыл про это.
В любом случае без подробной информации об улучшениях, сложно делать выводы. Возможно они чувствовали себе более счастливыми, вырабатывалось больше эндорфинов или чего-то подобного, что приводило к незначительному улучшению состояния.
Из вики (Эндорфины):
О том, что раны победителей заживают быстрее, чем раны побеждённых, было известно ещё в Древнем Риме.
А на сколько улучшилось зрение?
Мне кажется состояние людей могло улучшиться по другим причинам. Например: черно белый телевизор меньше влияет на зрение или лучше отдыхали, что могло улучшить память.
А как обстоят дела с модульностью в анриале?
В Unity есть лишь Plugins/Standard Assets, Editor и все остальное. Т.е. код в этих папках компилируется в разные сборки. И игровая сборка ничего не знает о других, что предотвращает некоторые ошибки. Но хотелось бы больше возможностей.
При использование Composition Root, все связи видны как на ладоне. Как минимум это должно упростить жизнь новым программистам на проекте.
Я сейчас читаю книгу «Dependency Injection in .NET». Там об этом написано. Хотя там написано про инициализацию зависимостей, но думаю к сигналам и командам это тоже относится.
Я в игре могу подвесится прям на команды как на события. И тоже строготипизированно. Выглядит как-то так:
В StrangeIoC есть два вида событий: старые событий и новые сигналы. Я это имел ввиду.
Чем упрощают? Что для вас «асинхронные» в данном контексте?)
Команда выполняется в течении нескольких кадров. Проще вызвать другую команду в конце асинхронной команды. Иначе нужен будет или callback или promise.
Чтобы просто не создавать классы размером в 1000 строк, можно использовать шаблон стратегия. Хотя я часто пишу статические классы — утилиты или хелперы.
Суть команд, мне кажется, больше, чем просто декомпозиция большого класса.
commandBinder.Bind(GameEvent.HIT).To<DestroyEnemyCommand>().To<UpdateScoreCommand>();
commandBinder.Bind(GameEvent.HIT).InSequence()
.To<CheckLevelClearedCommand>()
.To<EndLevelCommand>()
.To<GameOverCommand>();
injectionBinder.Bind<ICommandBinder>().To<SignalCommandBinder>().ToSingleton(); // сигналы - новые, строго типизированные события.
https://strangeioc.github.io/strangeioc/TheBigStrangeHowTo.html
Это должно проделываться в Composition Root. Вызов одной команды из другой это явно плохая практика.
Кстати, в StrangeIOC команды могут быть асинхронными, в этом случае они конечно упрощают жизнь. Хотя я для этого использовал Promise, которые очень популярные в JS.
файле на тысячи строк
Я не говорил, что надо вообще все в один файл писать. Но создавать файл для каждой функции, еще и в 1-5 строк… это странно для меня. Хотя конечно можно в одном файле написать несколько классов.
Но остается проблема с GC. У вас некоторые команды создавались в каждом update, рано или поздно это может внести свою лепту в понижение fps.
Я не представляю как выглядел мой проект, если бы каждый метод я выносил бы в отдельный класс. Где-то должна быть эта грань.
В чем удобность команд?
Читал про StrangeIOC, там можно создавать цепочки из сигналов и команд. Но у вас такого не видел.
Еще, возможно, когда в команде много программистов, то удобнее, когда каждая операция в своем файле (проще мерж, лучше видно историю изменений).
Но не нравится мне, что надо создавать класс/файл на каждый чих.
В последний версиях C# появился оператор nameof, который был бы очень полезным в нашем случае.
Unity обещают скоро обновить компилятор, может скоро сможем его заюзать.
Вообще мне кажется сериализация и редактор никак не связаны. FormerlySerializedAs должен работать вполне независимо от, использую ли я в редакторе SerializedObject или нет.
Я не пойму, а что хорошего в том, что изменения просто игнорируются? С несколькими сценами еще не работал, поэтому тоже не пойму, как эта фича повлияла на SetDirty.
В каких случаях Event.current.GetTypeForControl(controlId)
и Event.current.type могут иметь разные значения?
Всегда использовал просто Event.current.type и работало.
Вы понимаете как работает данный код?
HandleUtility.AddDefaultControl( GUIUtility.GetControlID( FocusType.Passive ) );
Давно использую этот код, чтобы отключить переключение кликом мыши на другой объект, но как это работает так и не понял.
За такое как SerializedObject надо бы по рукам бить, ибо имя переменной указывается строкой и легко допустить ошибку.
Не понимаю зачем они отказались от EditorUtility.SetDirty. Это удар ниже пояса.
Сами юнити, кстати, во всю используют SerializedObject т.к. это единственный способ получить доступ к приватному полю.
Проблема моей архитектуры в том, что получается оверкод. Наверное в оверкоде есть смысл, когда над проектом работают сотни людей на протяжении десятилетий. Но в играх важнее скорость написания и изменений. К сожалению, я наверное излишне переусложнил свой фреймворк.
Поэтому конструкторы вынесены на сторону движкаВ теории можно было бы передавать в метод делегат, который создает объект. Но почему-то так нельзя. Может быть на это были причины. Может быть и не было никаких причин.
Как бы там ни было, на Unity были созданы: Need for Speed World, Call of Duty: Mobile, Genshin Impact и наверное еще много сложных проектов.
Если опираться на название, то я не согласен, что это лучшие практики. Советы крайней субъективные и вряд-ли похожи на распространенные "лучшие практики", так ещё и проверены на крайней меленьком проекте, что выглядит как минимум не убедительно.У разных людей разные привычки и предпочтения. Если вы привыкли к другим парадигмам, то это не значит, что мои идеи плохие. И я не думаю, что есть что-то лучше, чем идеи чистой архитектуры, которые я использовал.
Рассказывать про лучшие практики надо, когда есть проект в релизе, вам нравится как он написан и работает, и тогда уже есть смысл чем-то поделиться.Сделав много проб и ошибок, и потратив много времени, я нашел достаточно хорошие решения (по-моему субъективному мнению). Было бы лучше, если бы никто о них не узнал?
В остальном, похоже на попытку перенести вебовские практики в игры и юнити, где это не очень уместно. Есть множество более удобных и простых вариантов построить архитектуру для малых, средних и большие проектов.Почему в Unity это не уместно? Чем Unity отличается от других областей разработки?
Раздел с претензиям к статье не вяжется, непонятно зачем он здесь. Выглядит как "я программировал не игры, и когда имея опыт другой разработки пришёл в юнити, то мне многие вещи непонятны или не нравятся".Именно так! Многие вещи мне не нравятся. Что-то можно было бы сделать лучше. Что-то в Unity могло бы быть лучше. И это тоже полезно знать.
Многие претензии уверен отпадут, если чуть больше поработать с игровым движком и вникнуть в технические ограничения, которые как вы сами заметили не только к юнити относятся.Каким образом они отпадут? Нет, не отпадут. Конечно же везде есть свои проблемы. И это всегда будет отнимать время и нервы.
Я просто хотел поделится с миром своими идеями. Статья действительно весьма поверхностно описывает мой проект, но на мой взгляд все самое важное я рассказал.
В любом случае без подробной информации об улучшениях, сложно делать выводы. Возможно они чувствовали себе более счастливыми, вырабатывалось больше эндорфинов или чего-то подобного, что приводило к незначительному улучшению состояния.
Из вики (Эндорфины):
Мне кажется состояние людей могло улучшиться по другим причинам. Например: черно белый телевизор меньше влияет на зрение или лучше отдыхали, что могло улучшить память.
В Unity есть лишь Plugins/Standard Assets, Editor и все остальное. Т.е. код в этих папках компилируется в разные сборки. И игровая сборка ничего не знает о других, что предотвращает некоторые ошибки. Но хотелось бы больше возможностей.
При использование Composition Root, все связи видны как на ладоне. Как минимум это должно упростить жизнь новым программистам на проекте.
Я сейчас читаю книгу «Dependency Injection in .NET». Там об этом написано. Хотя там написано про инициализацию зависимостей, но думаю к сигналам и командам это тоже относится.
В StrangeIoC есть два вида событий: старые событий и новые сигналы. Я это имел ввиду.
Команда выполняется в течении нескольких кадров. Проще вызвать другую команду в конце асинхронной команды. Иначе нужен будет или callback или promise.
Чтобы просто не создавать классы размером в 1000 строк, можно использовать шаблон стратегия. Хотя я часто пишу статические классы — утилиты или хелперы.
Суть команд, мне кажется, больше, чем просто декомпозиция большого класса.
https://strangeioc.github.io/strangeioc/TheBigStrangeHowTo.html
Это должно проделываться в Composition Root. Вызов одной команды из другой это явно плохая практика.
Кстати, в StrangeIOC команды могут быть асинхронными, в этом случае они конечно упрощают жизнь. Хотя я для этого использовал Promise, которые очень популярные в JS.
Я не говорил, что надо вообще все в один файл писать. Но создавать файл для каждой функции, еще и в 1-5 строк… это странно для меня. Хотя конечно можно в одном файле написать несколько классов.
Но остается проблема с GC. У вас некоторые команды создавались в каждом update, рано или поздно это может внести свою лепту в понижение fps.
Я не представляю как выглядел мой проект, если бы каждый метод я выносил бы в отдельный класс. Где-то должна быть эта грань.
Читал про StrangeIOC, там можно создавать цепочки из сигналов и команд. Но у вас такого не видел.
Еще, возможно, когда в команде много программистов, то удобнее, когда каждая операция в своем файле (проще мерж, лучше видно историю изменений).
Но не нравится мне, что надо создавать класс/файл на каждый чих.
Unity обещают скоро обновить компилятор, может скоро сможем его заюзать.
Вообще мне кажется сериализация и редактор никак не связаны. FormerlySerializedAs должен работать вполне независимо от, использую ли я в редакторе SerializedObject или нет.
Я не пойму, а что хорошего в том, что изменения просто игнорируются? С несколькими сценами еще не работал, поэтому тоже не пойму, как эта фича повлияла на SetDirty.
Всегда использовал просто Event.current.type и работало.
Вы понимаете как работает данный код?
HandleUtility.AddDefaultControl( GUIUtility.GetControlID( FocusType.Passive ) );
Давно использую этот код, чтобы отключить переключение кликом мыши на другой объект, но как это работает так и не понял.
Не понимаю зачем они отказались от EditorUtility.SetDirty. Это удар ниже пояса.
Сами юнити, кстати, во всю используют SerializedObject т.к. это единственный способ получить доступ к приватному полю.