И сколько времени потребуется, чтобы набросать подобные абстракции? Теперь, каждый опытный и не опытный разработчик может использовать мой фремворк. Разве это плохо? Многие проекты, кстати, вообще не имеют четкой архитектуры. Для решения этой проблемы и были придуманы фреймворки типа ribs. Что именно выглядит не очень? У вас есть идеи получше? Предлагайте!
Есть прикол, что компилятор может неявно создавать копии readonly структур, чтобы гарантировать их имутабельность. И особенно прикольно, если это происходит в цикле...
И все IT в такой же ж***( Много новых языков и каждый со своими тараканами.
Проблема моей архитектуры в том, что получается оверкод. Наверное в оверкоде есть смысл, когда над проектом работают сотни людей на протяжении десятилетий. Но в играх важнее скорость написания и изменений. К сожалению, я наверное излишне переусложнил свой фреймворк.
Поэтому конструкторы вынесены на сторону движка
В теории можно было бы передавать в метод делегат, который создает объект. Но почему-то так нельзя. Может быть на это были причины. Может быть и не было никаких причин.
Если опираться на название, то я не согласен, что это лучшие практики. Советы крайней субъективные и вряд-ли похожи на распространенные "лучшие практики", так ещё и проверены на крайней меленьком проекте, что выглядит как минимум не убедительно. У разных людей разные привычки и предпочтения. Если вы привыкли к другим парадигмам, то это не значит, что мои идеи плохие. И я не думаю, что есть что-то лучше, чем идеи чистой архитектуры, которые я использовал.
Рассказывать про лучшие практики надо, когда есть проект в релизе, вам нравится как он написан и работает, и тогда уже есть смысл чем-то поделиться.
Сделав много проб и ошибок, и потратив много времени, я нашел достаточно хорошие решения (по-моему субъективному мнению). Было бы лучше, если бы никто о них не узнал?
В остальном, похоже на попытку перенести вебовские практики в игры и юнити, где это не очень уместно. Есть множество более удобных и простых вариантов построить архитектуру для малых, средних и большие проектов.
Почему в 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.
Я не представляю как выглядел мой проект, если бы каждый метод я выносил бы в отдельный класс. Где-то должна быть эта грань.
Все правильно.
И в чем тут проблема?
Возможно мелкие недочеты остались, но в целом все правильно.
Какие пёрлы? И чем вам не нравится Java стиль?
И сколько времени потребуется, чтобы набросать подобные абстракции? Теперь, каждый опытный и не опытный разработчик может использовать мой фремворк. Разве это плохо? Многие проекты, кстати, вообще не имеют четкой архитектуры. Для решения этой проблемы и были придуманы фреймворки типа ribs. Что именно выглядит не очень? У вас есть идеи получше? Предлагайте!
А кто-то делал подобное? MonoGame это совершенно другое.
И как же правильно надо реализовывать IDisposable?
Наверное я что-то перепутал. Но все равно поведение компилятора очень странное.
Есть прикол, что компилятор может неявно создавать копии readonly структур, чтобы гарантировать их имутабельность. И особенно прикольно, если это происходит в цикле...
И все IT в такой же ж***( Много новых языков и каждый со своими тараканами.
Нужно было изначально делать D и D++.
Проблема моей архитектуры в том, что получается оверкод. Наверное в оверкоде есть смысл, когда над проектом работают сотни людей на протяжении десятилетий. Но в играх важнее скорость написания и изменений. К сожалению, я наверное излишне переусложнил свой фреймворк.
Поэтому конструкторы вынесены на сторону движкаВ теории можно было бы передавать в метод делегат, который создает объект. Но почему-то так нельзя. Может быть на это были причины. Может быть и не было никаких причин.
Как бы там ни было, на 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.
Я не представляю как выглядел мой проект, если бы каждый метод я выносил бы в отдельный класс. Где-то должна быть эта грань.