Наверное, пора начать рассказывать про проект, над которым я работаю… — Львиная доля — TG.ME

Наверное, пора начать рассказывать про проект, над которым я работаю последние недели. Я строю игровой движок. Но не совсем такой, каким обычно представляют движок. Все началось с простой проблемы. Каждый новый проект начинался одинаково. Новая игра — и снова: — система сохранений; — 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