StrangerLeks

Наковальня Пустоты

Те, кто играл (кто не играл оч рекомендую) в Dragon Age: Origins и достаточно долго шатался по гномьим подземельям, наверняка помнят Наковальню Пустоты.

Каридин создал ее для производства големов.

Инструмент получился настолько эффективным, что довольно быстро возник классический технологический вопрос:

«Если мы можем это делать - означает ли это, что мы должны это делать?»

Сначала в големов превращали добровольцев. Потом добровольцев стало не хватать. Дальше история ожидаемо пошла куда-то не туда...

Каридин попытался остановить конвейер и в итоге сам превратился в голема.

А спустя много лет уже перед игроком появляется выбор: уничтожить Наковальню или сохранить инструмент, способный дать гномам огромное преимущество (но какой ценой?).

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

С AI у меня примерно такое же отношение. Я не считаю, что нужно уничтожать Наковальню. Наоборот.

Просто не стоит забывать, кто именно кого кует. Впрочем, эта тема для отдельного разговора.

Вообще не стоит кидаться в крайности типа:

"AI - зло. Настоящий разработчик должен всё писать руками".

Если инструмент позволяет за несколько минут сделать то, на что раньше уходил час, глупо специально от него отказываться.

Но есть и другая крайность:

"Зачем вообще что-то знать? Написал промт — получил игру".

С одной стороны именно так - получить «чет работающее» действительно становится все проще.

А вот получить хороший продукт по-прежнему требует усилий, опыта и понимания того, что ты вообще делаешь.

Для себя я решил, что все же многие вещи "пока?" оставляю за собой, например такие как: архитектура проекта, геймдизайн, баланс. игровой цикл, основные механики, то какой игровой опты должен получать человек и др.

По Интеграции SDK у меня к примеру отдельная ветка. Спецом для этого сделал навыки для агентов, шаблоны. Процессы постоянно обновляются.

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

То есть я не говорю агенту: "Сделай мне такую игруху, чтобы все просто охренели и были в восторге! Чтобы я ее загрузил потом на Яндекс Игры и сразу начал грести деньги лопатой."

Задача выглядит скорее так:

вот этот модуль отвечает за сохранения;

вот контракт данных;

здесь должен быть платформенный адаптер;

игровая логика не должна напрямую обращаться к SDK;

вот сюда добавь конкретное поведение;

вот "это" не трогай, совсем... даже если будет "так" или "вот так" - не трогай!

Сначала я стараюсь прокрутить решение у себя в голове. Представить блоки. Представить как я стою в чистом поле, а вокруг мощный цветовой контраст, ветер... Связи. Где состояние. Кто кого вызывает. Что произойдёт после рекламы (Игрок закроет игру и никогда ее не откроет). Что будет, если SDK не загрузится. Что произойдёт при потере фокуса окна. И только потом отправляю конкретную работу в нашу цифровую кузницу.
По мне, это наиболее здоровый вариант использования AI агентов.

Периодически я провожу небольшие эксперименты, чтобы нащупать границы ии. Понять, на что действительно способен инструментарий. А что пока только очень убедительно делает вид.

Например, игра Astro.

Первую играбельную версию я буквально навайбкодил за пару часов.

Я специально решил сделать игру максимально AI-first: концепцию прорабатывать через GPT, реализацию отдать Codex, работать через VS Code, а графику по возможности вообще не рисовать традиционным способом.

Хотелось проверить несколько довольно простых вопросов.

Что получится?

Можно ли в это будет играть?

«Способна ли такая игра зарабатывать?

Сколько времени я реально потрачу?

Каким окажется качество?

И главное:

«Что произойдёт, если я постараюсь прикладывать к непосредственному производству как можно меньше ручного труда?»

Для эксперимента я выбрал хорошо знакомый мне жанр и механику. Намеренно простую. Тренды, популярность жанра и коммерческий потенциал я вообще не учитывал. Буквально взял первое, что пришло в голову и что было мне хорошо знакомо.

В этом и был смысл эксперимента.

Я хорошо знаю, как работают игры такого типа, поэтому мог довольно точно понимать, где ИИ делает нормально, где делает ерунду, а где делает работающую ерунду.

Последнее, кстати, отдельная категория.

За основу взял старую классику в духе «Galaxian» — fixed shooter (аркадный шутер с ограниченной зоной движения), один из ранних представителей жанра shoot 'e
m up.

Это одна из тех игрушек, с которыми я познакомился ещё во времена NES, в далеком детстве. Насколько помню одна из первых игр в которые я играл на денди.

Сама идея намеренно простая. Мне хотелось проверять не мою способность придумать невероятную концепцию, а способность GPT и Codex построить полноценную игру на хорошо понятном фундаменте.

Просто клонировать Galaxian мне было неинтересно.

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

Например, убрал необходимость постоянно нажимать кнопку выстрела. Стрельба стала автоматической. Добавил простую прогрессию. Валюту. Разные корабли. Разные типы оружия. Паттерны поведения противников. Боссов.

При этом я не стал полностью идти за современной коммерческой моделью и превращать игру в бесконечный забег с максимально агрессивной монетизацией.

Мне хотелось, чтобы у игры был конец. Лично меня в старых бесконечных аркадах всегда немного раздражало отсутствие финальной точки. Поэтому после 100 уровней в Astro появляется финальный очень жирный босс.

У него несколько систем вооружения, собственное движение, призыв противников, лазер, самонаводящиеся снаряды, несколько фаз и изменение поведения по мере получения урона.

Часть идей для его поведения я вообще достал из каких-то своих старых наработок. Уже даже не вспомню, какой давности. Было интересно посмотреть, как ИИ реализует знакомые мне игровые паттерны. И реализовал он их именно так как и планировалось.

Я сделаю игру с одного промта!

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

Да, можно написать:

Сделай Galaxian, только современный.

Через некоторое время на экране действительно что-то полетит.

Но между:

«что-то полетело» и «в это можно нормально играть» находится небольшая такая пропасть. И вот там начинается работа.

У меня уже был собственный HTML5-шаблон, который когда-то делался руками. Адаптация под разные экраны, базовые подходы к интеграции SDK и некоторые другие решения не рождались в Astro с нуля.

Было понимание платформы. Ну и самое главное - я знал, как подобная игра должна работать.

Поэтому весь эксперимент нельзя честно описать как: написал предложение - получил коммерческую игру. Так пока не работает.

Скорее: «поставил ИИ практически на все производственные позиции под тщательным наблюдением.»

Самая большая проблема оказалась вообще не в коде

Баланс. ИИ его не чувствует.

Он прекрасно может написать:

damage = 4;

fireRate = 1.2;

enemyHp = 15

Но почему здесь должно быть `4`, а не `2.7`?

Почему скорострельность должна расти именно так?

Когда игрок начнёт чувствовать усиление?

Когда прокачка сломает сложность?

Сколько противников одновременно могут атаковать, чтобы игроку было сложно, но у него при этом оставалось пространство для манёвра?

Вот здесь магия внезапно заканчивается.

Приходилось самому задавать:

характеристики кораблей;

порядок их силы;

прирост урона;

скорострельность;

стоимость;

количество рикошетов;

количество траекторий;

здоровье;

частоту атак;

ограничения на одновременно атакующих врагов;

поведение босса;

интервалы между атаками;

награды;

темп прогрессии.

Причем быстрее было бы просто открыть игровой движок и передвинуть три значения руками. Серьезно. Я дольше объяснять и описывать это буду...

Пока сформулируешь промт. Пока объяснишь контекст. Пока агент изменит. Пока проверишь. Потом выясняется, что "немного увеличить скорострельность" он понял несколько иначе, чем ты. Пишешь еще один промт. Потом ещё один.

В какой-то момент сидишь и думаешь:

«я сейчас автоматизирую работу или очень медленно редактирую переменную через посредника?»

Но кое-где ИИ оказался чертовски хорош

Я специально открыл финальную сборку Astro и посмотрел на неё не как автор игры, а как программист.

Некоторые решения там хорошие. Прям действительно хорошие. Например, интеграция Яндекс SDK вынесена в отдельный адаптер. Игровая логика не разбросана прямыми вызовами `YaGames` по всему проекту. Есть отдельный слой `yandex-sdk-adapter.js`, который занимается авторизацией, рекламой, облачными сохранениями, таблицами лидеров и событиями платформы. Это правильное решение. Хранилище тоже сделано довольно аккуратно.

Есть нормализация данных, локальные сохранения, объединение локального и облачного прогресса, версия настроек, обработка старых сохранений.

Для браузерной игры такого уровня - вполне здраво.

Есть отдельные модули:

`config.js`;

`storage.js`;

`audio.js`;

`i18n.js`;

`yandex-sdk-adapter.js`;

`ui.js`;

`game.js`;

`main.js`.

Без npm. Без фреймворка. Без игрового движка. HTML5/JS/Canvas. В целом эта "портянка" оказалась вполне читаемой.

На оптимизацию тоже пришлось потратить время. Я наивно полагал, что ИИ сам учтёт этот момент. Увы. Когда в игре стало много объектов, появились просадки производительности. И пришлось уже напрямую ставить конкретные задачи.

Например, пришлось указывать чтобы он сделал:

Object Pooling — объекты пуль и частиц не создаются заново каждый раз, а переиспользуются.

Это снижает давление на Garbage Collector (сборщик мусора).

Пространственная сетка для противников. Вместо того чтобы каждая пуля проверяла столкновение со всеми врагами, она проверяет только ближайшие ячейки.

Закешировать Canvas-спрайты.

То, что раньше перерисовывалось сложными Canvas-path каждый кадр, в ряде мест предварительно собирается в offscreen canvas (скрытый холст), а затем используется повторно.

Закешировать: противники; снаряды; некоторые эффекты; полосы HP; бонусы и т.д.

Появились короткие simulation substeps (подшаги симуляции), чтобы при просадке FPS быстрые снаряды не начинали пролетать сквозь цели.

Обновления HUD ограничить по частоте, чтобы выполнялись только при изменении значений.

Удалить части временных объектов без "дорогого" сдвига массивов. до этого он его двигал.

Уменьшить количество ненужных `atan2`, Canvas transforms и пересозданий объектов.

То есть если поставить перед ИИ конкретную задачу:

Вот узкое место. Вот ограничения. Поведение игры менять нельзя.

Найди способы уменьшить allocation и количество операций на кадр. То ИИ работает очень достойно. И вот это для меня один из главных выводов всего эксперимента.

**Чем точнее я сам понимал проблему, тем полезнее становился ИИ. **Как-то подозрительно.

А теперь посмотрим внутрь голема

Есть и другая сторона. Основной `game.js` в текущей версии - примерно «2200 строк».

Один класс управляет почти всем игровым миром: игроком, стрельбой, врагами, дайверами, боссами, пули. столкновения, бонусы, частицы, прогрессия, игровой цикл, рендеринг и т.д.

Работает?

Да.

Хотел бы я добровольно построить архитектуру нового проекта именно так? Хотел бы я далее работать с этим проектом? Нет, нет, нет.

В коде хватает hardcode (жёстко прописанных значений).
Есть некоторые формулы, которые фактически продублированы между игровой логикой и UI.
Например, визуальное описание усиления оружия рассчитывается отдельно от самой механики оружия.
Это потенциальная точка рассинхронизации.
Проект использует общий глобальный namespace `window.GameTemplate`.

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

Также нет нормального автоматизированного набора unit-тестов.
Зато есть большой `QUALITY_GATE.md`, чек-листы и проверки синтаксиса - это полезно. Но чек-лист не заменяет тесты. Тесты есть тесты.
Есть довольно агрессивное восстановление после runtime-ошибок непосредственно в игровом цикле.

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

Ну и главное.

Архитектура появилась «эволюционно».

Не: «сначала определили систему, затем реализовали».

А: «сделали - добавили - починили - расширили - оптимизировали - еще добавили - теперь это трогать нельзя, оно держит потолок».

Знакомо?
Мне тоже…

Только человеку для выращивания подобной портянки обычно требуется заметно больше времени. ИИ справился намного быстрее. Прогресс.

С графикой Наковальня экономит огромное количество времени

В игре практически нет традиционного набора игровых изображений.

Корабли, враги, боссы, снаряды, эффекты и значительная часть визуала рисуются непосредственно через Canvas. То есть ассет фактически является кодом.

Для эксперимента как по мне - отличный вариант.

Мне не пришлось:

• рисовать десятки спрайтов;

• экспортировать их;

• собирать атласы;

• постоянно перекидывать новые версии;

• следить за разрешениями каждого изображения.

Поменял параметры - получил другой силуэт. Попросил переработать визуальный язык - изменился весь набор. По скорости проверки гипотез это очень мощно.

Что касается уникальности... тут без чудес, получите очередной конвейерный ИИ продукт.
То же самое со звуком: часть звукового оформления генерируется через WebAudio.

Для прототипирования и небольших HTML5-проектов ИИ здесь действительно может резко сократить производственный цикл.
Хотя есть обратная сторона.
Когда все генерируется одним инструментом и примерно одним способом... Начинаешь это видеть.

Итог

В игру можно играть. Более того, в целом она получилась примерно такой, какой я ее и представлял. Можно считать что ИИ справился.

Но все равно, сколько я ни пытался потом добавить ей характера...

Нет авторской мелочи, странности, неправильности, решения из серии "я художник я так вижу".

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

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

Получится конвейерный очередной голем.

Сэкономил ли я время?

Вот тут ответ получился скорее неожиданным.

И да и нет.

Огромное количество времени сэкономлено на:

• первичной реализации;

• рутинном коде;

• Canvas-графике;

• локализации;

• документации;

• поиске очевидных ошибок;

• рефакторинге отдельных участков;

• оптимизации;

• создании однотипных систем;

• проверке технических гипотез.

Но когда дело доходило до:

• баланса;

• feel (ощущения управления);

• сложности;

• игровой экономики;

• поведения врагов;

• темпа прогрессии;

• архитектурных решений;

• требований платформы;

экономия становилась гораздо менее очевидной.

Многие вещи я действительно сделал бы быстрее руками. Особенно если речь шла о системе, которую я уже хорошо знаю. Получается довольно интересная штука.

«Чем меньше я знаю о задаче - тем волшебнее выглядит ИИ.»

«Чем лучше я знаю задачу - тем отчетливее вижу, где он действительно экономит время, а где просто переносит работу из кода в промты»

И второй вариант мне нравится гораздо больше. Потому что тогда ИИ перестает быть магией. Он становится инструментом.

Что дальше будет делать Darles Games

Наковальню мы уничтожать не будем. Слишком полезная.

ИИ уже хорошо работает как:

• ускоритель прототипирования;

• дополнительный программист;

• инструмент анализа;

• генератор технических вариантов;

• помощник при оптимизации;

• средство автоматизации рутины;

• быстрый способ проверить идею;

• помощник при работе с незнакомым API.

И дальше его роль будет только увеличиваться. Но все же многие задачи и решения я оставлю за собой.

Особо важным считаю умение отсекать и выбрасывать предложенные решения ИИ. Потому что человек, который уже не способен сказать агенту: "Нет. Это плохое решение. Переделывай вот так." - не управляет Наковальней.

И в какой-то момент его самого может ждать судьба Каридина.

Может ли ИИ сделать коммерческий продукт?

Результатом эксперимента стала Astro - браузерная аркада на Яндекс Играх.

Это не попытка показать: "Смотрите, ИИ уже заменил разработчиков".

Наоборот…

Мне было интересно проверить предел инструмента, который все плотнее становится частью нашей профессии.

Способен ли ИИ помочь создать готовый коммерческий продукт?
Да.
Но за качество, идею, исполнение, баланс и конечный игровой опыт по-прежнему отвечаете вы.

Я довольно давно использую ИИ, и сделал определенные выводы. За это время:

Где-то ИИ меня удивил.
Где-то не оправдал ожиданий.
Где-то сэкономил часы.
Где-то заставил потратить час на то, что руками заняло бы десять минут.

Прогресс ИИ определенно напоминает снежный ком. Куда он в итоге врежется и какие будут последствия - тема для отдельного разговора...

---

Наковальня вайбкодинга продолжит работать.

Darles Games продолжит выпускать из нее новых големов.

Просто Астерон Кодосвет постарается сам не повторить судьбу Каридина и однажды не обнаружить, что кузнец тоже стал частью производственного процесса.

Ну и живых дварфов, пожалуй, будем использовать пореже. Хотя бы до следующего обновления...

Великолепный финал? Почти. Запускаю игру — она не работает. Совсем. Но у меня был план "Б": заранее залитая ранняя версия, где кроме стартового меню, перемещения звездолета и стрельбы не было ничего. Зато она хоть запускалась!

В итоге я доволен. Да, игра получилась скорее минималистичной демоверсией, чем полноценной аркадой, но я успел загрузить хоть что-то. А значит, первый этап завершён. Теперь идём дальше — баги ждать не будут! 😄

Привет! Меня зовут Лёха. Я давно в IT, но разработкой игр занимаюсь сравнительно недавно — всего около двух лет. Как я пришёл в геймдев — это отдельная история, которую я как-нибудь расскажу. Но сегодня не об этом.

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

Так что участие в джеме для меня — это возможность переключиться, хотя недосып уже даёт о себе знать. К слову, я создаю игры из дома, работая в одиночку, и, как дополнительный челлендж, совмещаю это с семейной жизнью: у меня есть жена и маленький ребёнок.

Почему я решил писать дневники разработчика? Давно хотел начать делиться своим опытом, а гейм джем кажется для этого отличным поводом. Здесь приветствуются заметки о процессе, поэтому я решил, что это будет моя точка отсчёта.

Что у меня есть на старте:

• Я работаю один, без команды.

• Мой выбор движка — Construct 3. Никаких заготовок или наработок у меня нет.

• Тематика джема: "В поисках золотого плюсика".

• Полтора месяца недосыпа (зато входить в рабочий ритм не придётся).

• Желание и амбиции.

• Буря идей в голове, пока без четкого плана.

Честно признаюсь, за три дня я ещё ни разу не делал полноценную игру. Это будет мой первый такой опыт. Сегодня я планирую работать над общей концепцией: определюсь с механиками, жанром, сеттингом и дизайном. Если останется время, попробую продумать UX/UI для меню игры.

Посмотрим, что из этого получится. Надеюсь, мои дневники будут интересны и полезны человекам, котикам и печенькам)