Комментарии 8
Ох.
Спасибо за пример, но чего уж тут, давайте сразу с критики.
С примером все нормально в целом, и такая организация может быть, но хотелось бы небольшое вступительное слово, потому что это как то считается само по себе разумеющимся, а на самом деле про это нифига никто не говорит. Говорят конечно, в более крупных статьях, но границы применимости довольно редко указывают.
- Зачем вам нужен Zenject и DI. В целом зачем нужна инъекция зависимостей и в каких случаях стоит ее применять (и в каких не стоит). Все ли игровые сущности стоит делать сервисами? На каком масштабе это делать опраавданно, а на каком лучше даже и не думать.
- Какие есть альтернативы. Сама по себе Unity - это мощнейщий Di, который с префабами и ScriptableObject покрывает типа 90% потребностей DI и не требует костылей, потому что оные обеспечены Unity.
- Когда и зачем вам может быть оправданно отвязаться от Mono Behaviour и в целом unity типов и начать дублировать их своими костылями.
- Для чего нужны тесты, что вы предлагаете тестировать? Ну вот правда, расскажите о своем опыте, Я видел примерно нифига тестов в игровой индустрии. Точнее видел конечно много, но в основном на детали - сервера, некоторые виды логики, валидаторы. Тесты игрового процесса видел лишь одну серьезную попытку - тестирование логики фишек в Match 3 игре.
- О каком размере команды идет речь? Используете ли вы эти подходы как solo developer и считаете ли оправданным?
В отрыве от всего этого статья пустовата, как сниппет - делайте вот так и вот так. Все корректно, но нафига вам интерфейс?
Спасибо за критику, мои теги снизу. Возможно вы не согласитесь, про написанное ниже, но писать воду, не хотелось)
Я пытался написать, максимально короткую и обогащенную по теме статью. Не стал писать большое вступление, потому-что думаю, что людям, которым интересна архитектура в Unity с Zenject, уже имеют знания об самом движке и DI-контейнере.
У меня сервисы, это не сущности, это логика этих сущностей. Масштаб игр, особо не важен, логику, можно переиспользовать и в других проектах, даже если у вас казуалки.
Согласен юнити это мощный инструмент, но архитектура построенная вокруг скриптовых объектов и префабов не лучший вариант, в итоге все превратится в спагетти код. Их лучше использовать вместе с другими архитектурными паттернами, не обязательно как у меня, можно например впихнуть в ECS архитектуру, но полагаться только на скриптовые объекты и префабы не стоит.
В своем роде моно скрипты и есть костыли над языком, а в моем случае пишется чистый c# код, у которого нет минусов моно поведения, особенно в асинхронности. Если есть возможность отвязаться от моно поведения, нужно отвязываться. В своих играх я оставляю моно классы, только как точки входа в игровой объект. Своего рода игровой объект у меня это endpoint.
Согласен тестирование в игровой индустрии не особо развито (под тестированием я подразумеваю авто/плей тесты), что уж говорить об инди-студиях. Но это не означает что тестирование не нужно, наоборот, чем больше ваша игра, тем больше вы должны покрывать ее тестами, чтобы в будущем, отсутствие тестов не стрельнуло вам в колено.
Я использую данную архитектура, в основном как соло разработчик или в команде из 3 человек. Оправдано ли, я считаю, да, но в случае если это не проект, а разработка полноценной игры. У меня есть два основных подхода к играм, это ООП и ДОП, если ООП, то беру архитектуру, которую описал в статье, если ДОП, то LeoECS, который отлично подходит в данную парадигму. Так как подходы не изменяются, то я могу спокойно переиспользовать логику из других проектов.
Надеюсь, я подробно ответил на ваши вопросы
Не возьмусь критиковать, а скорее в целях самообразования спрошу:
- зачем для Movement интерфейс? Только ради того, чтобы в DI пробрасывать? Или подразумевается еще какие-то управляемые геймобжекты со своей реализацией передвижения?
- в чем удобство тестирования не MonoBehaviour классов? На текущем уровне моих скилов мне крайне удобно смотреть за состоянием класса, глядя на его поля в инспекторе, пока что не представляю удобства, о котором говорите.
- почему поля speed и jumpForce не в самом Movement? Чтобы изменить что-то в классе А, лезть в класс Б как-то странно, по-моему. groundCheck вообще дублируется, какой из двух в итоге нам нужен, я затрудняюсь прокомментировать
- зачем в Movement занесли SpriteRenderer? Рендеринг и передвижение - будто бы слои разные и надо бы это разделить
1) Интерфейсы нужны чтобы легче тестировать игру, через авто/плей тесты. Так же они помогают легко переключать реализацию, что важно. Например у вас поменялась логика движения и вместо того, чтобы исправлять ее в раскинутых по классам местах, вы создаете новую реализацию интерфейса и привязываете ее, и все, везде где вы используете данный интерфейсы, логика будет другой.
2)Тестирование, про которое я говорю, это Unit/Integrations тесты. Но когда у меня возникает необходимость в проверке состояния объекта, я использую логирование, что как по мне удобнее, я могу узнать в каком порядке все вызывалось.
3)Вы правы, поля speed и jumpForce должны храниться в Movement, но у меня в PlayerBehaviour, есть еще логика, которая принимает те же параметры, что и Movement, поэтому я храню скорость и силу прыжка в моно классе.
4) Полностью согласен, это нарушает принцип единственной ответственности. Конкретно в моем случае, я нарушаю специально, т.к SOLID, это не монуал, которому нужно безоговорочно следовать. У меня из рендеренга, только Flip и все, делать ради одной функции, новую реализацию, не вижу смысла, это наоборот усложнит код.
Понял, спасибо!
По логированию согласен, следить за последовательностью выполнения кода бывает крайне полезно. Не раз уже спотыкался на этом. А по SOLID и прочей ерунде. Ну, если над проектом работаете только вы, тогда вопросов тем более нет. Вы прекрасно знаете в какой класс за каким полем и методом идти, и проблем никаких. А если в команде работа, то уже могу быть проблемы. Но это только предположение. В команде работать пока не доводилось
Ты неосознанно заставил меня создать аккаунт на хабре. Начну сразу с причины этого, а причина в том, что, хватит, ставить, запятые, там, где, не, нужно, потому, что, читать, невозможно. Ты хоть сам свой текст перечитывал?! Да, меня это сильно задело. Много бессмысленных запятых, много странноватых потоков твоих мыслей. В остальном все норм
Архитектура игр в Unity с использованием Zenject