The Frosted: По ту сторону экрана
Третий пост в преддверии нашего прототипа на #индиджем от DTF. Здесь кратко расскажем про техническую реализацию в разработке.
В мае, после нескольких брэйнстормов, мы определились с концепцией проекта и быстро собрали первый прототип для проверки работоспособности идеи. В качестве движка был выбран Unity, так как с ним мы все были более-менее знакомы, и в целом движок весьма неплохо подходит для 2D. После того, как команда определилась с тем, что мы будем делать, встал вопрос выбора архитектуры проекта. Выбирали исходя из удобства использования, возможности поддержки и масштабирования, знакомства команды с архитектурой.
В итоге выбрали Singleton Main, управляющий контроллерами, так как большинство из нас с такой архитектурой знакомы. Вкратце работает это следующим образом. У нас существует Singleton класс Main, экземпляр которого находится на сцене в единственном числе. В нем содержатся некоторые сведения, которые там необходимо хранить, а главное - те самые контроллеры, управляющие объектами игровой сцены, UI, Инпутом и т. д. Единственные объекты, которые обрабатываются в Update, это те самые контроллеры, не наследуемые от MonoBehaviour, что, очевидно, положительно сказывается на производительности, так как мы не тянем кучу бесполезного кода в Update. И уже далее эти контроллеры управляют теми игровыми объектами, для которых предназначены, будь это враги, UI, персонаж игрока или что-либо другое. Использование контроллеров в принципе обеспечивает удобные инструменты взаимодействия c группами однотипных объектов, принадлежащих контроллеру. Также контроллеры очень просто включаются и отключаются через Main.
В целом выбранной архитектурой мы довольны, у нее есть как очевидные плюсы, так и некоторые недостатки.
К плюсам мы отнесём:
- удобный рефакторинг кода;
- общая компактность кода;
- хорошая производительность при правильном соблюдении архитектуры;
- легкая масштабируемость;
- общая универсальность – ее легко можно использовать в других проектах.
Минусы следуют из нюансов самой архитектуры:
- каждый новый созданный тип объекта должен быть включен в обработку контроллером (тем или иным методом), что иногда бывает не так быстро;
- не самый низкий порог вхождения при начале работы - сначала нужно осознать строение приложения, что может быть не совсем удобно на крупных проектах и при планировании разделения работ по участкам.
Вот такой устойчивый фундамент мы используем для реализации планов и задумок нашего геймдизайнера.
Поднимайте пост, если уделяете внимание оптимизации и производительности своего кода и следите за нашими новостями!
P.S. Выложим прототип прям впритык со сроками, ибо не хотим спешить. Если есть время, то почему бы не использовать его впрок?