Наверное, пора начать рассказывать про проект, над которым я работаю последние недели.
Я строю игровой движок.
Но не совсем такой, каким обычно представляют движок.
Все началось с простой проблемы.
Каждый новый проект начинался одинаково.
Новая игра — и снова:
— система сохранений;
— 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 и других платформ.
Внутри уже есть фундаментальные системы:
• модульная архитектура на
• Onion Architecture с четким разделением слоев;
• ядро, независимое от Unity API;
• Dependency Injection через VContainer;
• State-driven application flow;
• событийное взаимодействие между системами;
• Object Pool;
• система сохранений с миграциями и защитой от отката;
• экономика, инвентарь и прогрессия;
• аналитическая система;
• Remote Config и настройка баланса;
• интеграции рекламы, лидербордов и платформенных сервисов.
Одна из вещей, которой я особенно горжусь — это подход Creative Mode.
Когда ты создаешь рекламные креативы или записываешь геймплей, тебе не нужно создавать отдельные сцены и вручную отключать интерфейс.
Одна настройка — и игра готова для чистой записи.
Кажется мелочью.
Но именно из таких мелочей складывается производственный процесс.
Самое важное:
Я не строю движок в вакууме.
Первый настоящий «картридж» уже существует.
Это игра в стиле Vampire Survivors, но со своей механикой жадности.
Она стала первым реальным тестом платформы.
Именно настоящая игра показывает, где архитектура удобная, а где ее нужно менять.
Каждая новая проблема превращается в улучшение движка.
Я не знаю, насколько большой получится этот проект.
Но я точно знаю одно:
Разработчики должны тратить больше времени на создание игр, а не на бесконечное восстановление одной и той же инфраструктуры.
Это первый пост из серии.
Дальше я буду рассказывать:
— как устроена архитектура внутри;
— почему выбрана модель «консоль / картридж»;
— какие решения пришлось переделывать;
— как из внутреннего инструмента постепенно рождается продукт.
#unity #gamedev
Я строю игровой движок.
Но не совсем такой, каким обычно представляют движок.
Все началось с простой проблемы.
Каждый новый проект начинался одинаково.
Новая игра — и снова:
— система сохранений;
— 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
Deconstructor of Fun
The Hidden Cost of Studio Engineering — Deconstructor of Fun
A build-vs-buy breakdown for game studios, showing why internal engineering builds almost always cost more.
❤1
Почему я строю движок по модели «консоль / картридж»
Когда я начал проектировать Enterprise Engine, передо мной встал главный вопрос:
Что именно должен содержать движок?
И еще важнее:
Что НЕ должно находиться внутри движка?
Потому что самая частая проблема игровых проектов выглядит так:
Создается новая игра. Берется старый проект. Копируются папки.
Удаляется ненужное. Переименовываются менеджеры.
Через несколько недель получается еще один проект, где половина кода принадлежит прошлой игре, а половина — новой.
И через некоторое время уже сложно понять:
Где заканчивается движок и начинается игра?
Я хотел решить эту проблему по-другому.
Поэтому основой Enterprise Engine стала модель:
Движок — это консоль.
Игра — это картридж.
Как это работает?
Консоль содержит все, что нужно для производства игр:
— базовую архитектуру;
— систему сохранений;
— аналитику;
— экономику;
— прогрессию;
— UI-систему;
— управление;
— работу с платформами;
— инструменты разработки;
— интеграции сервисов.
Это фундамент.
То, что не должно переписываться каждый раз.
А картридж — это сама игра.
Ее жанр.
Ее механики.
Ее контент.
Ее уникальные решения.
Картридж можно заменить, удалить или создать новый.
Но консоль остается.
Именно это разделение позволяет строить платформу, а не просто очередной игровой проект.
Почему это важно?
Потому что большие игровые компании давно работают похожим образом.
Они не начинают каждый новый проект с пустого файла Unity.
У них есть внутренние технологии, инструменты и системы, которые помогают выпускать новые игры быстрее.
Проблема в том, что у маленьких студий и инди-разработчиков обычно нет ресурсов создавать такую инфраструктуру самостоятельно.
Именно этот разрыв я хочу сократить.
Но настоящая проверка этой идеи — не архитектурная схема.
А реальные игры.
Поэтому Enterprise Engine не строится в вакууме.
Первым картриджем стала игра в стиле Vampire Survivors, но с собственной механикой:
Вместо того чтобы убегать от толпы врагов, игрок получает награду за риск.
Чем дольше он остается внутри опасности — тем выше ставка.
Эта игра заставила движок пройти настоящие испытания:
— система прогрессии;
— экономика;
— баланс;
— телеметрия;
— удаленная настройка параметров;
— работа с контентом.
Но самое интересное впереди.
Сейчас на Enterprise Engine создается второй картридж.
Другой жанр.
Другой игровой цикл.
Другие задачи.
И именно это станет главным тестом:
Я хочу проверить не то, может ли движок поддерживать одну игру.
Я хочу проверить, может ли одна платформа стать фундаментом для разных игр.
Потому что хороший движок — это не тот, на котором сделана одна игра.
Хороший движок — это тот, на котором можно создавать следующую игру быстрее предыдущей.
Продолжение следует.
#unity #gamedev
Когда я начал проектировать Enterprise Engine, передо мной встал главный вопрос:
Что именно должен содержать движок?
И еще важнее:
Что НЕ должно находиться внутри движка?
Потому что самая частая проблема игровых проектов выглядит так:
Создается новая игра. Берется старый проект. Копируются папки.
Удаляется ненужное. Переименовываются менеджеры.
Через несколько недель получается еще один проект, где половина кода принадлежит прошлой игре, а половина — новой.
И через некоторое время уже сложно понять:
Где заканчивается движок и начинается игра?
Я хотел решить эту проблему по-другому.
Поэтому основой Enterprise Engine стала модель:
Движок — это консоль.
Игра — это картридж.
Как это работает?
Консоль содержит все, что нужно для производства игр:
— базовую архитектуру;
— систему сохранений;
— аналитику;
— экономику;
— прогрессию;
— UI-систему;
— управление;
— работу с платформами;
— инструменты разработки;
— интеграции сервисов.
Это фундамент.
То, что не должно переписываться каждый раз.
А картридж — это сама игра.
Ее жанр.
Ее механики.
Ее контент.
Ее уникальные решения.
Картридж можно заменить, удалить или создать новый.
Но консоль остается.
Именно это разделение позволяет строить платформу, а не просто очередной игровой проект.
Почему это важно?
Потому что большие игровые компании давно работают похожим образом.
Они не начинают каждый новый проект с пустого файла Unity.
У них есть внутренние технологии, инструменты и системы, которые помогают выпускать новые игры быстрее.
Проблема в том, что у маленьких студий и инди-разработчиков обычно нет ресурсов создавать такую инфраструктуру самостоятельно.
Именно этот разрыв я хочу сократить.
Но настоящая проверка этой идеи — не архитектурная схема.
А реальные игры.
Поэтому Enterprise Engine не строится в вакууме.
Первым картриджем стала игра в стиле Vampire Survivors, но с собственной механикой:
Вместо того чтобы убегать от толпы врагов, игрок получает награду за риск.
Чем дольше он остается внутри опасности — тем выше ставка.
Эта игра заставила движок пройти настоящие испытания:
— система прогрессии;
— экономика;
— баланс;
— телеметрия;
— удаленная настройка параметров;
— работа с контентом.
Но самое интересное впереди.
Сейчас на Enterprise Engine создается второй картридж.
Другой жанр.
Другой игровой цикл.
Другие задачи.
И именно это станет главным тестом:
Я хочу проверить не то, может ли движок поддерживать одну игру.
Я хочу проверить, может ли одна платформа стать фундаментом для разных игр.
Потому что хороший движок — это не тот, на котором сделана одна игра.
Хороший движок — это тот, на котором можно создавать следующую игру быстрее предыдущей.
Продолжение следует.
#unity #gamedev
Первый тест Enterprise Engine: одна игра построила фундамент, вторая проверила его
В предыдущем посте я рассказывал про модель Enterprise Engine:
Движок — это консоль.
Игра — это картридж.
Но любая архитектурная идея ничего не стоит без проверки реальной разработкой.
Поэтому я решил проверить главный вопрос:
А это действительно универсальная платформа?
Или я просто построил хороший фундамент под одну конкретную игру?
Первым картриджем стал проект в стиле Vampire Survivors.
И здесь важно быть честным:
Он создавался вместе с движком.
За время разработки было сделано 88 коммитов.
Но это не было ускорение.
Это была стройка.
Каждая проблема игры показывала, чего не хватает платформе:
Нужна прогрессия — появляется система прогрессии.
Нужна экономика — появляется экономика.
Нужна аналитика — появляется телеметрия.
Нужна настройка баланса — появляется система tuning.
Первый картридж не просто использовал движок.
Он помог его построить.
А потом появился второй тест.
Совершенно другой жанр. Match-3 puzzle. И вот здесь стало интересно. Эта игра уже не строила ядро. Она подключалась к существующему фундаменту.
Результат:
1 день разработки.
12 коммитов.
За это время игра получила:
— генератор уровней с обратной генерацией и проверкой решаемости через солвер;
— tutorial funnel;
— бустеры (undo, hammer, shuffle);
— адаптивную сложность с сохранением прогресса;
— настройку баланса через ассеты, без изменения кода;
— звук и game-feel через системы движка.
Самое важное:
Я не писал заново:
— сохранения;
— экономику;
— аналитику;
— Object Pool;
— систему обновления;
— базовую архитектуру.
Я просто использовал их.
Именно ради этого я и начал строить Enterprise Engine.
Конечно, обе игры еще находятся в разработке.
Vampire Survivors prototype сейчас ждет полноценный арт и полировку.
Match-3 проект проходит следующий этап — визуальная часть, UI и финальная настройка игрового опыта.
Но технически они уже доказали главное:
Два совершенно разных жанра работают на одном фундаменте.
И вот здесь проходит граница между framework и foundation.
Framework помогает написать игру.
Foundation позволяет строить следующие игры быстрее.
Продолжение следует.
#unity #gamedev
В предыдущем посте я рассказывал про модель Enterprise Engine:
Движок — это консоль.
Игра — это картридж.
Но любая архитектурная идея ничего не стоит без проверки реальной разработкой.
Поэтому я решил проверить главный вопрос:
А это действительно универсальная платформа?
Или я просто построил хороший фундамент под одну конкретную игру?
Первым картриджем стал проект в стиле Vampire Survivors.
И здесь важно быть честным:
Он создавался вместе с движком.
За время разработки было сделано 88 коммитов.
Но это не было ускорение.
Это была стройка.
Каждая проблема игры показывала, чего не хватает платформе:
Нужна прогрессия — появляется система прогрессии.
Нужна экономика — появляется экономика.
Нужна аналитика — появляется телеметрия.
Нужна настройка баланса — появляется система tuning.
Первый картридж не просто использовал движок.
Он помог его построить.
А потом появился второй тест.
Совершенно другой жанр. Match-3 puzzle. И вот здесь стало интересно. Эта игра уже не строила ядро. Она подключалась к существующему фундаменту.
Результат:
1 день разработки.
12 коммитов.
За это время игра получила:
— генератор уровней с обратной генерацией и проверкой решаемости через солвер;
— tutorial funnel;
— бустеры (undo, hammer, shuffle);
— адаптивную сложность с сохранением прогресса;
— настройку баланса через ассеты, без изменения кода;
— звук и game-feel через системы движка.
Самое важное:
Я не писал заново:
— сохранения;
— экономику;
— аналитику;
— Object Pool;
— систему обновления;
— базовую архитектуру.
Я просто использовал их.
Именно ради этого я и начал строить Enterprise Engine.
Конечно, обе игры еще находятся в разработке.
Vampire Survivors prototype сейчас ждет полноценный арт и полировку.
Match-3 проект проходит следующий этап — визуальная часть, UI и финальная настройка игрового опыта.
Но технически они уже доказали главное:
Два совершенно разных жанра работают на одном фундаменте.
И вот здесь проходит граница между framework и foundation.
Framework помогает написать игру.
Foundation позволяет строить следующие игры быстрее.
Продолжение следует.
#unity #gamedev
❤1
Forwarded from Professor Che (Professor Che)
Сегодня я стал еще на шаг ближе к своей мечте о геймдеве) на протяжении недели полной страданий и радостей я смог придумать персонажа для нашей следующей игры, которая уже будет в 3d, сделать эскиз, потом по нему создать модель, текстурировать ее, сделать риг и закинуть в движок unity, добавить анимации, накосячить в процессе везде где только можно, переделать все 10 раз и в итоге все работает🤯
Кстати наша первая игра “How high" уже полностью готова, но у нас возникли трудности с регистрацией на площадке google, очень надеюсь решить эту проблему в течении августа и если все пойдет по плану, то в сентябре вы уже сможете в нее сыграть
Кстати наша первая игра “How high" уже полностью готова, но у нас возникли трудности с регистрацией на площадке google, очень надеюсь решить эту проблему в течении августа и если все пойдет по плану, то в сентябре вы уже сможете в нее сыграть
👍1🔥1
Я не публиковал обновлений о нашем движке уже некоторое время.
И на то есть причина: сейчас движок тестируется уже на реальных играх.
В данный момент у нас в разработке несколько проектов разных жанров, и мы используем их, чтобы проверять движок в реальных production-условиях.
Сегодня хочу представить одну из этих игр — Blood Rave.
Изначально она создавалась как тестовый проект, но в какой-то момент стала одной из наших главных надежд.
Blood Rave — это bullet heaven, вдохновлённый Vampire Survivors, под жёсткое детройтское техно. Мы не пытаемся изобрести жанр заново. Вместо этого мы делаем большой упор на визуальный стиль, атмосферу и одну ключевую игровую идею — жадность.
В большинстве survival-игр ты стараешься держаться подальше от врагов.
В Blood Rave ты хочешь быть как можно ближе к ним.
Чем глубже ты заходишь в толпу, тем быстрее растёт твой множитель и тем больше денег ты зарабатываешь.
Но есть нюанс.
Чем дольше ты остаёшься, тем опаснее становится. В любой момент ты можешь зафиксировать заработанное —
И на то есть причина: сейчас движок тестируется уже на реальных играх.
В данный момент у нас в разработке несколько проектов разных жанров, и мы используем их, чтобы проверять движок в реальных production-условиях.
Сегодня хочу представить одну из этих игр — Blood Rave.
Изначально она создавалась как тестовый проект, но в какой-то момент стала одной из наших главных надежд.
Blood Rave — это bullet heaven, вдохновлённый Vampire Survivors, под жёсткое детройтское техно. Мы не пытаемся изобрести жанр заново. Вместо этого мы делаем большой упор на визуальный стиль, атмосферу и одну ключевую игровую идею — жадность.
В большинстве survival-игр ты стараешься держаться подальше от врагов.
В Blood Rave ты хочешь быть как можно ближе к ним.
Чем глубже ты заходишь в толпу, тем быстрее растёт твой множитель и тем больше денег ты зарабатываешь.
Но есть нюанс.
Чем дольше ты остаёшься, тем опаснее становится. В любой момент ты можешь зафиксировать заработанное —
🔥1
Игра моей первой команды в которой я был в роли Unity developer обрела страницу в steam. Приятно видеть,что проект начатый на энтузиазме достаточно не маленькой командой,которую собрал очень крутой Алексей Алешин планомерно идет к цели и там есть частичка моей работы.
Добавляйте в вишлисты🫶🏻
Indie dev forever✊🏻
https://store.steampowered.com/app/3220640/Synvector/
Добавляйте в вишлисты🫶🏻
Indie dev forever✊🏻
https://store.steampowered.com/app/3220640/Synvector/
Steampowered
Synvector on Steam
Real-time sci-fi action RPG with tactical pause. Command your mercenary fleet, coordinate squadrons through a command interface, and switch between squadron commanders. Four races, one spiral arm, one unstoppable swarm. Nothing personal. Just contract.
❤2