“How High” — игра про прыжки по облакам вверх и попытки не упасть ☁️
без сложных механик, перегруженного интерфейса и лишнего шума — просто спокойное пространство, немного пустоты и маленький чувак, который хочет забраться чуть повыше.
постепенно допиливаем движение, визуал и общее ощущение от игры. оказалось, что даже самые маленькие детали сильно меняют атмосферу.

Чувак за 5 лет сделал 100 игр и рассказывает, чему это его научило:

🤔 Читать статью

GameDEV #статьи

Вчера я словил невероятный инсайт!

Невероятное везение случилось вчера, мне в руки попала полноценная игра одного из самых крупных паблишеров в мире, просто представьте это тоже самое, что получить исходники какого-нибудь uncharted или mortal kombat. И вот такая штука оказалась у меня в руках, при чем не где-то через доступ к гиту, а вот папка у меня на компе со всей бизнеслогикой со всей архитектурой проекта и я не мог сосчитать сколько испытал оргазмов пока копошился во всем этом. А сам инсайт заключается в том, что изучив и поняв все это я так сильно упроситл разработку игр. Фактически надо будет писать только код механики игры и во всей архитектуре он будет как картридж просто меняться от проекта к проекту, что позволит быстро тестировать рабочие и не рабочие механики, не надо будет каждый раз работать над связями UI, звука, рекламных SDK и прочей фигней.

Сейчас взяв за пример архитектуру этого паблишера я пишу свою собственную, в которую потом буду вгонять тестовые механики и смотреть как это работает.

Мой рекламный ролик прошел все тесты и запущен на массовую аудиторию-приятно.
Для этого ролика я сделал много прикольных штук таких как:
-генератор трассы кодом.
Он создает регулируемую во всех салонах форму трассы,можно менять материалы на стенках трэка и на самой дороги и делать вообще из него халфпайп.весь мэш создается кодом🤯 все,что тебе нужно это склеить куски трассы.

-генерируемые тем же способом порталы,на которые так же сделан код с эффектом вакуума(всасывает и выталкивает персонажа),так же кодом задается форма,кодом анимируется вращение,подставляются звуки.

-так же кодом реализована смена бэкграунда и материалов трассы.

Как же все это ускоряет работу! И в итоге все эти наработки дали отличный результат в виде метрик с хорошим удержанием.

Я недавно писал, что получил исходник игры одного крупного паблишера и смог изучить их архитектуру и безумно впечатлиться. Так вот, меня недавно перевели на новую игру и о,чудо,я получил и ее исходник и это тоже крупный паблишер.считай у меня сейчас в руках два полноценных продукта самых крупных паблишерлв мобильных игр,со всей внутренней инфраструктурой,со всеми тулзами и прочим.А самое главное-они у меня локально😅не на гите,а на моем домашнем компе. Вся бизнес логика,две полноценных игры это просто волшебно.

Так вот,после глубокого изучения я многое понял как работают крупные паблишеры,как они работают в конвейерном режиме быстро меняя игровые механики и тестируя их. Этот подход называется white label.

Суть заключается вот в чем: когда ты делаешь игру,ты под кажду игру пишешь инфраструктуру. Это UI система,аудиосистема,VFX система,аналитика,реклама,стандартные для всех игру инпуты и управление,система окон(настройки и тд),система локализации на разные языки,система билдов под необходимые платформы(webgl,android,iOS),система A/B тестрирования(когда одному игроку игра подгружается с одними характеристиками,другому с другими и смотрят,какая лучше дает метрику удержания),геймдизайн и левелдизайн конфиги. Вся эта инженерия о гигант очень много времени около 80% разработки и всего 20% остается на разработку собственно игры и игровых механик. Некоторые девелоперы вообще лепят все в одну кучу и при малейшем изменении какого либо компонента по п*зде идет вообще вся игра. По этому чистая архитектура где компоненты бизнес логики не знают об игре и все остальное должны жить обязательно ной частью.

А white label это уже готовая инфраструктура всех этих систем разделенная логика,ни каких зависимостей,а самое главное,что весь тот список сверху,который я еще не полностью озвучил у тебя всегда готов те 80% времени свободны и ты посвящаешь их разработке игры.

И я решил написать для себя такую white label платформу. Я начал писать и рассказывать об этом на LinkedIn. Оказалось это боль многих разработчиков и мой продукт вызывал интерес,что побудило меня попробовать построить вообще на этом какой-то реальный продукт для внедрения в небольшие студии,паблишерам и маркетинговым компаниям.

Многие считают, что геймдев это занятие мечты, что геймдев это создание интересных миров и персонажей с увлекательной историей.

Но…

На самом деле геймдев это самая беспощадная сфера в IT. Насколько она беспощадна настолько и многогранна.

Многие думают,что если ты идешь в геймдев,то ты либо разработчик игровых механик,либо 3d/2d artist,либо гейм/левел дизайнер. Например, если ты умеешь работать в Юнити и программировать это обязательно геймплей разработчик. На самом деле вариантов много и они абсолютно разные.

Как и все продукты в нашем мире, игры требуют маркетинга. Но маркетинг это не только метрики,работа с аудиторией и тд. Для маркетинга тоже должен быть продукт. В играх это чаще всего ролики и так как это игры,ролики геймплейные. Но так как это геймплейные ролики для маркетинга,голый геймплей он не работает каким бы крутым он не был. И вот тут то и нужен человек,который может собрать игровой прототип и адаптировать его под маркетинг. Такой специалист именуется Unity Creative Developer или Creative Developer. Это такой воистину многорукий Шива,который владеет и художественными навыками и понимает психологию рынка/игрока и аналитику знает и может в Юнити собрать игру,сам написать код,собрать все.

Это один из примеров очень ярких на мой взгляд,который для меня порвал шаблон Юнити разработчика. С этого человека не спрашивают чистоту кода,следование архитектуре и паттернам. Его цель сделать абстрактный прототип игры быстро,собрать рекламный креатив на этом прототипе основываясь на нейробиологии и психологии,выкатить на тест,посмотреть метрики,докрутить и снова посмотреть результат. Если результат хороший игру запускают в полную разработку. Чаще всего в играх происходит именно так. Вы видите не рекламу существующей реально игры.
Вы видите идею и именно то как она на вас повлияла в конечном счете влияет на то будет ли игра существовать или канет в небытие.

Для меня все это было большим открытием,так как я хотел попасть в геймдев и разрабатывать игры в какой-то команде,но оказался именно тем человеком,который делает рекламные креативы в Юнити.

Суть моего посыла в том,что граней очень много,дверей на самом деле много через которые можно зайти в индустрию,главное их увидеть и сделать шаг.

#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

Почему я строю движок по модели «консоль / картридж»
Когда я начал проектировать 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