Я строю игровой движок.
Но не совсем такой, каким обычно представляют движок.
Все началось с простой проблемы.
Каждый новый проект начинался одинаково.
Новая игра — и снова:
— система сохранений;
— UI;
— Object Pool;
— Event Bus;
— загрузка контента;
— аналитика;
— настройки;
— менеджеры всего подряд.
В какой-то момент я поймал себя на мысли:
Я создаю не игры.
Я снова и снова строю одну и ту же инфраструктуру.
Сначала мне казалось, что это только моя проблема.
Но чем больше я изучал тему — форумы, обсуждения разработчиков, истории небольших студий — тем больше понимал, что это системная проблема.
Потом я наткнулся на статью The Hidden Cost of Studio Engineering от Deconstructor of Fun. Та самая статья
Главная мысль была очень простой:
Игровые компании постоянно недооценивают стоимость собственной инфраструктуры.
Пока команда строит внутренние инструменты, она не строит игру.
И тогда я понял одну вещь:
Крупные игровые компании уже решили эту проблему.
У них есть внутренние платформы, которые позволяют создавать новые проекты быстрее.
Но у небольших студий и инди-разработчиков часто нет ресурсов, чтобы годами строить такие системы самостоятельно.
Именно эту проблему я хочу решить.
Я строю Enterprise Engine.
Не очередной Unity Framework.
Не набор разрозненных ассетов.
А платформу разработки игр по модели:
Engine = Console
Game = Cartridge
Движок содержит фундамент:
архитектуру, сервисы, инструменты и производственные системы.
А каждая игра становится отдельным картриджем, который подключается к этой платформе.
Удалил игру — движок остался.
Создал новый проект — тебе не нужно начинать с нуля.
Цель — сделать подход больших игровых компаний доступным для небольших команд.
Платформа должна помогать создавать игры разных жанров и для разных устройств:
WebGL, Android, iOS, Steam и других платформ.
Внутри уже есть фундаментальные системы:
• модульная архитектура на
.asmdef;• Onion Architecture с четким разделением слоев;
• ядро, независимое от Unity API;
• Dependency Injection через VContainer;
• State-driven application flow;
• событийное взаимодействие между системами;
• Object Pool;
• система сохранений с миграциями и защитой от отката;
• экономика, инвентарь и прогрессия;
• аналитическая система;
• Remote Config и настройка баланса;
• интеграции рекламы, лидербордов и платформенных сервисов.
Одна из вещей, которой я особенно горжусь — это подход Creative Mode.
Когда ты создаешь рекламные креативы или записываешь геймплей, тебе не нужно создавать отдельные сцены и вручную отключать интерфейс.
Одна настройка — и игра готова для чистой записи.
Кажется мелочью.
Но именно из таких мелочей складывается производственный процесс.
Самое важное:
Я не строю движок в вакууме.
Первый настоящий «картридж» уже существует.
Это игра в стиле Vampire Survivors, но со своей механикой жадности.
Она стала первым реальным тестом платформы.
Именно настоящая игра показывает, где архитектура удобная, а где ее нужно менять.
Каждая новая проблема превращается в улучшение движка.
Я не знаю, насколько большой получится этот проект.
Но я точно знаю одно:
Разработчики должны тратить больше времени на создание игр, а не на бесконечное восстановление одной и той же инфраструктуры.
Это первый пост из серии.
Дальше я буду рассказывать:
— как устроена архитектура внутри;
— почему выбрана модель «консоль / картридж»;
— какие решения пришлось переделывать;
— как из внутреннего инструмента постепенно рождается продукт.
#unity #gamedev
