Да, вы правы. При работе в команде, нужно для начало определиться со структурой и конвенциями проекта. Времени это занимает достаточно, но затем не возникнет проблем с чтением кода.
Спасибо за критику, мои теги снизу. Возможно вы не согласитесь, про написанное ниже, но писать воду, не хотелось) Я пытался написать, максимально короткую и обогащенную по теме статью. Не стал писать большое вступление, потому-что думаю, что людям, которым интересна архитектура в Unity с Zenject, уже имеют знания об самом движке и DI-контейнере.
У меня сервисы, это не сущности, это логика этих сущностей. Масштаб игр, особо не важен, логику, можно переиспользовать и в других проектах, даже если у вас казуалки.
Согласен юнити это мощный инструмент, но архитектура построенная вокруг скриптовых объектов и префабов не лучший вариант, в итоге все превратится в спагетти код. Их лучше использовать вместе с другими архитектурными паттернами, не обязательно как у меня, можно например впихнуть в ECS архитектуру, но полагаться только на скриптовые объекты и префабы не стоит.
В своем роде моно скрипты и есть костыли над языком, а в моем случае пишется чистый c# код, у которого нет минусов моно поведения, особенно в асинхронности. Если есть возможность отвязаться от моно поведения, нужно отвязываться. В своих играх я оставляю моно классы, только как точки входа в игровой объект. Своего рода игровой объект у меня это endpoint.
Согласен тестирование в игровой индустрии не особо развито (под тестированием я подразумеваю авто/плей тесты), что уж говорить об инди-студиях. Но это не означает что тестирование не нужно, наоборот, чем больше ваша игра, тем больше вы должны покрывать ее тестами, чтобы в будущем, отсутствие тестов не стрельнуло вам в колено.
Я использую данную архитектура, в основном как соло разработчик или в команде из 3 человек. Оправдано ли, я считаю, да, но в случае если это не проект, а разработка полноценной игры. У меня есть два основных подхода к играм, это ООП и ДОП, если ООП, то беру архитектуру, которую описал в статье, если ДОП, то LeoECS, который отлично подходит в данную парадигму. Так как подходы не изменяются, то я могу спокойно переиспользовать логику из других проектов.
1) Интерфейсы нужны чтобы легче тестировать игру, через авто/плей тесты. Так же они помогают легко переключать реализацию, что важно. Например у вас поменялась логика движения и вместо того, чтобы исправлять ее в раскинутых по классам местах, вы создаете новую реализацию интерфейса и привязываете ее, и все, везде где вы используете данный интерфейсы, логика будет другой.
2)Тестирование, про которое я говорю, это Unit/Integrations тесты. Но когда у меня возникает необходимость в проверке состояния объекта, я использую логирование, что как по мне удобнее, я могу узнать в каком порядке все вызывалось.
3)Вы правы, поля speed и jumpForce должны храниться в Movement, но у меня в PlayerBehaviour, есть еще логика, которая принимает те же параметры, что и Movement, поэтому я храню скорость и силу прыжка в моно классе. 4) Полностью согласен, это нарушает принцип единственной ответственности. Конкретно в моем случае, я нарушаю специально, т.к SOLID, это не монуал, которому нужно безоговорочно следовать. У меня из рендеренга, только Flip и все, делать ради одной функции, новую реализацию, не вижу смысла, это наоборот усложнит код.
Да, вы правы. При работе в команде, нужно для начало определиться со структурой и конвенциями проекта. Времени это занимает достаточно, но затем не возникнет проблем с чтением кода.
Сори, просто люблю запятые))
Статью поправил
Спасибо за критику, мои теги снизу. Возможно вы не согласитесь, про написанное ниже, но писать воду, не хотелось)
Я пытался написать, максимально короткую и обогащенную по теме статью. Не стал писать большое вступление, потому-что думаю, что людям, которым интересна архитектура в Unity с Zenject, уже имеют знания об самом движке и DI-контейнере.
У меня сервисы, это не сущности, это логика этих сущностей. Масштаб игр, особо не важен, логику, можно переиспользовать и в других проектах, даже если у вас казуалки.
Согласен юнити это мощный инструмент, но архитектура построенная вокруг скриптовых объектов и префабов не лучший вариант, в итоге все превратится в спагетти код. Их лучше использовать вместе с другими архитектурными паттернами, не обязательно как у меня, можно например впихнуть в ECS архитектуру, но полагаться только на скриптовые объекты и префабы не стоит.
В своем роде моно скрипты и есть костыли над языком, а в моем случае пишется чистый c# код, у которого нет минусов моно поведения, особенно в асинхронности. Если есть возможность отвязаться от моно поведения, нужно отвязываться. В своих играх я оставляю моно классы, только как точки входа в игровой объект. Своего рода игровой объект у меня это endpoint.
Согласен тестирование в игровой индустрии не особо развито (под тестированием я подразумеваю авто/плей тесты), что уж говорить об инди-студиях. Но это не означает что тестирование не нужно, наоборот, чем больше ваша игра, тем больше вы должны покрывать ее тестами, чтобы в будущем, отсутствие тестов не стрельнуло вам в колено.
Я использую данную архитектура, в основном как соло разработчик или в команде из 3 человек. Оправдано ли, я считаю, да, но в случае если это не проект, а разработка полноценной игры. У меня есть два основных подхода к играм, это ООП и ДОП, если ООП, то беру архитектуру, которую описал в статье, если ДОП, то LeoECS, который отлично подходит в данную парадигму. Так как подходы не изменяются, то я могу спокойно переиспользовать логику из других проектов.
Надеюсь, я подробно ответил на ваши вопросы
1) Интерфейсы нужны чтобы легче тестировать игру, через авто/плей тесты. Так же они помогают легко переключать реализацию, что важно. Например у вас поменялась логика движения и вместо того, чтобы исправлять ее в раскинутых по классам местах, вы создаете новую реализацию интерфейса и привязываете ее, и все, везде где вы используете данный интерфейсы, логика будет другой.
2)Тестирование, про которое я говорю, это Unit/Integrations тесты. Но когда у меня возникает необходимость в проверке состояния объекта, я использую логирование, что как по мне удобнее, я могу узнать в каком порядке все вызывалось.
3)Вы правы, поля speed и jumpForce должны храниться в Movement, но у меня в PlayerBehaviour, есть еще логика, которая принимает те же параметры, что и Movement, поэтому я храню скорость и силу прыжка в моно классе.
4) Полностью согласен, это нарушает принцип единственной ответственности. Конкретно в моем случае, я нарушаю специально, т.к SOLID, это не монуал, которому нужно безоговорочно следовать. У меня из рендеренга, только Flip и все, делать ради одной функции, новую реализацию, не вижу смысла, это наоборот усложнит код.