The Frosted: По ту сторону экрана
Третий пост в преддверии нашего прототипа на #индиджем от DTF. Здесь кратко расскажем про техническую реализацию в разработке.
В мае, после нескольких брэйнстормов, мы определились с концепцией проекта и быстро собрали первый прототип для проверки работоспособности идеи. В качестве движка был выбран Unity, так как с ним мы все были более-менее знакомы, и в целом движок весьма неплохо подходит для 2D. После того, как команда определилась с тем, что мы будем делать, встал вопрос выбора архитектуры проекта. Выбирали исходя из удобства использования, возможности поддержки и масштабирования, знакомства команды с архитектурой.
В итоге выбрали Singleton Main, управляющий контроллерами, так как большинство из нас с такой архитектурой знакомы. Вкратце работает это следующим образом. У нас существует Singleton класс Main, экземпляр которого находится на сцене в единственном числе. В нем содержатся некоторые сведения, которые там необходимо хранить, а главное - те самые контроллеры, управляющие объектами игровой сцены, UI, Инпутом и т. д. Единственные объекты, которые обрабатываются в Update, это те самые контроллеры, не наследуемые от MonoBehaviour, что, очевидно, положительно сказывается на производительности, так как мы не тянем кучу бесполезного кода в Update. И уже далее эти контроллеры управляют теми игровыми объектами, для которых предназначены, будь это враги, UI, персонаж игрока или что-либо другое. Использование контроллеров в принципе обеспечивает удобные инструменты взаимодействия c группами однотипных объектов, принадлежащих контроллеру. Также контроллеры очень просто включаются и отключаются через Main.
В целом выбранной архитектурой мы довольны, у нее есть как очевидные плюсы, так и некоторые недостатки.
К плюсам мы отнесём:
- удобный рефакторинг кода;
- общая компактность кода;
- хорошая производительность при правильном соблюдении архитектуры;
- легкая масштабируемость;
- общая универсальность – ее легко можно использовать в других проектах.
Минусы следуют из нюансов самой архитектуры:
- каждый новый созданный тип объекта должен быть включен в обработку контроллером (тем или иным методом), что иногда бывает не так быстро;
- не самый низкий порог вхождения при начале работы - сначала нужно осознать строение приложения, что может быть не совсем удобно на крупных проектах и при планировании разделения работ по участкам.
Вот такой устойчивый фундамент мы используем для реализации планов и задумок нашего геймдизайнера.
Поднимайте пост, если уделяете внимание оптимизации и производительности своего кода и следите за нашими новостями!
P.S. Выложим прототип прям впритык со сроками, ибо не хотим спешить. Если есть время, то почему бы не использовать его впрок?
Главное что мне нравится в этой игре — в ней всё приятно и красиво. Классная отрисовка, дизайн уровней, удовлетворение от подрывов — всё это расслабляет и неслабо развлекает. Отличная работа!
• проект разрабатывается с апреля
• художник нанят на сайте фрилансеров
Почему эта игра еще участвует?
Привет! Отвечу на второе замечание как художник этого проекта во избежание дальнейших недоразумений.
Во-первых, слово «нанимать» подразумевает то, что человеку платят за работу, тут же все участники проекта делают игру на добровольной основе и ради своего интереса, я в том числе. Во-вторых — в прошлом посте было написано, что нашли меня через «Общество ленивых художников», и это не «сайт фрилансеров», а сообщество по интересам, где, в основном, люди просто собираются порисовать вместе.
Можно Вас попросить прислать пункты, которые мы нарушаем, из следующего официального документа правил проведения конкурса: https://docs.google.com/document/d/1q2apmrvPrJuMLcAMHfPDWapdKM9NMTOsB6jerDIVziU/edit?usp=sharing
Заранее, благодарим.
.