Как завайбкодить качественную игру с нуля? Раскрываю все секреты

Всем привет! Меня зовут Саша, я работаю в сфере AI около 5 лет. А еще мне очень нравится вайбкодить) Некоторое время назад я решил проверить, получится ли у меня сделать что-то приличное в области, где у меня ровно ноль опыта ^[1], и выбрал для этого разработку игр. Получился хоррор, и он даже играбелен!

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

“а давай теперь то же самое, но с техническими деталями и лайфхаками”

Справедливо, держите!

Коротко напомню суть игры. Это психологический хоррор, где игрок участвует в эксперименте. Задача – сохранять спокойствие несмотря ни на что (а смотреть там действительно есть на что). Основная игровая механика – это паника. Ее уровень меняется при взаимодействии с триггерными объектами, монстрами, а иногда просто так (желание побесить игрока никто не отменял). Иными словами, твоя задача – не бояться, а сделать так, чтобы игра сама тебя боялась. За последние пару месяцев проект заметно вырос: было пять уровней, стало девять, а качество первоначальных уровней сильно улучшилось. По итогу имеем 150+ тысяч строк кода, из которых половина – это код игры, а другая половина – тесты. Несмотря на обилие тестов, чуть дальше я расскажу, почему это все равно не спасает.

Во время разработки я сделал ряд ошибок, набил шишки, чуть не стал седым, преисполнился, и понял, как именно нужно делать игры. Сейчас я хочу поделиться советами и мыслями, к которым я пришел на личном опыте, и которые мне сильно помогли (I wish I knew it earlier).

Креатив все еще твоя работа

Искусственный интеллект ^[2] отлично кодит по техзаданию, но в роли креативного дизайнера все еще должен выступать естественный. В моем случае это я) Все, что делает языковая модель – генерирует правдоподобный текст. Не потому, что она плохая, а потому, что именно на такую задачу ее обучают талантливые инженеры и ученые за ляям двееести баксов в год. Именно поэтому мы так часто слышим, что ИИшка генерирует что-то усредненное, что-то медианное, и настоящего креатива там не особо много. Так как страшное по определению неожиданно, именно недостаток уникальных идей со стороны модели и стал основной проблемой. Например, на запрос “сделай страшный уровень” ты получаешь классику: темный коридор, мигающая лампа, скример из-за угла. Так что если ты увидишь такой паттерн в современной навайбкоженной игре – ты знаешь, в чем дело)

Помимо этого, модель не может измерить, насколько страшный уровень получился у нее самой. Человек переживает игру целиком – визуалом, звуками, и собственным пульсом. Модель же видит код, картинки, децибелы и мои комментарии в духе “Клод, все не то, давай по новой”. Яркость панели в кадре измеряется. Время, за которое бот доходит до двери, измеряется. Страх ^[3] не измеряется ничем, кроме человека, который закричал от испуга.

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

Модель действительно решает

Все, что описано выше (брейншторм, ресерч, разбор чужих игр), стоит времени. А взять его можно ровно в одном месте: перестать смотреть шортсы с котами делать руками то, что можно делегировать LLM.

Безусловно, разработчику, который не понимает чего хочет, никакая модель (за исключением GPT-6 Astra и Opus 5.5 как же быстро они обновляются) не поможет, а опытный геймдевер справится даже с инвентарем из палеозойской эры в виде обычного браузера. Так что исход в первую очередь зависит от тебя. Но модель определяет, сколько минут твоей жизни стоит один инкремент – пофикшенный баг, новая фича, или улучшение геймплея.

Модели я отдаю рутину: код, автотесты, базовую генерацию текстур. При этом флагманские модели понимают тебя с полуслова. Отчетливее всего я это увидел, когда переключился на Fable 5.1, GPT-6 Astra, и буквально только что вышедший Opus 5.5. Задача, которая еще вчера съедала три захода и полдня объяснений, сегодня проходит с первого раза с более крутым результатом на выходе. А себе я оставляю идеи, креатив, и правила игры.

Разработка должна вестись по строгой методологии, или твой репозиторий превратится в свалку

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

1. Документация начала врать. В главном файле проекта (CLAUDE.md) было написано, что в игре нет врагов, которые охотятся за игроком. Потом такая тварина появилась, а строчку никто не поправил. Модель не спорит с тем, что ты дал ей как данность, поэтому каждая новая сессия послушно принимала устаревшую информацию за истину.

2. CLAUDE.md ^[4] разросся до неприличных размеров. И целиком грузился в каждую сессию. Агенту, которого просили поправить какую-то мелочь, приходилось читать подробности всех уровней сразу (любой каприз за ваши токены). Возможно, с какой-то такой проблемой сталкиваются разработчики, у которых недельные лимиты на самых мощных подписках заканчиваются за выходные)

Для достижения максимального удобства и структурированности пайплайна разработки, я перешел на методологию Spec-Driven Development (SDD), и логика ^[5] сводилась к трем вещам:

1. Общие правила проекта плюс отдельная спека на каждый уровень. Главный файл больше ничего не объясняет, он только подсказывает дорогу: вот общие правила проекта, вот где лежит описание каждой локации. Когда агенту дают задачу по конкретному уровню, он читает только его спеку, а остальное не трогает.

2. Записал, сделал, зафиксировал. Любое изменение начинается с записи в спеке и заканчивается тем, что спека перечитывается целиком. Таким образом мы блокируем противоречия в логике уровней. Изменение не будет считаться законченным, если документация говорит об обратном.

3. Файл разобранных багов. Каждый баг записывается в формате: симптом – причина – фикс – почему тесты это пропустили – о чем ты вообще думал когда рассчитывал что такое прокатит. Агент читает этот файл перед тем как разгребать очередную порцию браться за новый фикс. Удивительно часто новый баг оказывается хорошо забытым старым, и второй раз он чинится за минуты вместо часов.

Мой кодинг-агент перестал наступать на одни и те же грабли (неужели), научился находить свои ошибки ^[6] и грамотно тестировать значительную долю того, что он реализовал.

Как правильно тестировать то, чего модель не видит

Автотест проверяет точечно: одну дверь, одну стену, один звук. А игра работает целиком: на игрока одновременно действуют геометрия, свет, и звук. Поэтому уровень, в котором каждая деталь по отдельности исправна, в общем и целом может оказаться неиграбельным. Например, на одном из уровней живут монстры, и тесты были полностью зелеными: существо появляется, двигается, паника растет, когда на него смотришь. Захожу в игру, а мой монстр стоит с раскинутыми руками, как пугало на огороде) Это та самая T-поза, в которой 3D-модель стоит, пока ей не дали анимацию. Ни один тест не спрашивал, как существо выглядит, а мне хватило одной секунды. Поэтому игра тестируется в три этапа: сначала автотесты, потом самостоятельно играющий агент, и в конце уже подключаюсь я.

• Автотесты. Автотесты сильны там, где нужно много безобразных единообразных повторений. Например, подземелье в моей игре генерируется заново при каждом запуске, и в нем нужно зажечь семь подсвечников. Сам я могу пройти его от силы несколько раз иначе меня схватит инсульт ^[7], а бездушный тест за пару секунд строит двести разных подземелий и в каждом проверяет, можно ли там найти все свечки.

• Агент играет сам. Вот это действительно перевернуло разработку. Я настроил Claude так, что во время тестирования игры он имитирует живого игрока: сам запускает игру, ходит по уровню так же, как ходил бы человек, собирает логи и делает скриншоты. А потом сверяет код с тем, что получилось на экране. Именно это комбо позволяет тестировать игру корректно: вот что написано, а вот что из этого вышло на самом деле. Но и этого мало (и причина глубже, чем кажется)

• Играю я. Агент не чувствует страх. Не тупит. Не задается вопросами, куда идти и что делать дальше. Не понимает, легкий ли этот уровень, или тяжелый. Поэтому я настроил все так, чтобы агент сам запускал игру из моего терминала, а я играл и фиксировал все специальной кнопкой: скриншот плюс заметка к нему. Дальше агент разбирает логи игры, мои скриншоты и заметки разом. Это ускоряет фикс багов, разработку новых фичей, и улучшение уровней.

Дай поиграть живым людям

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

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

Решение уместилось в одно правило – теперь вход в укрытие стирает монстру память ^[8] о том, где он видел тебя в последний раз, и отправляет его бродить дальше. Реальный игрок за пять минут найдет то, чего агент не найдет за ляям двееести долларов в месяц. Поэтому чтобы ответить на вопрос, работает ли твоя игра, дай ее протестировать хотя бы десяти людям. Кстати, мой друг регулярно участвовал в тестировании и признался, что похудел на несколько килограммов. Эффективнее любой диеты)

Заключение

Если резюмировать одним абзацем: вайбкодинг большого проекта – это не про то, что модель сделает все за тебя. Это обычная инженерная работа, где модель берет на себя реализацию, а на тебе остается то, чего она пока не умеет (пожалуйста, научись, я так больше не могу): придумать, что именно делать, посмотреть на результат своими глазами и внятно сказать, что не так.

Спасибо, что дочитали. Я веду телеграм-канал ^[9], где пишу про AI, вайбкодинг и свои проекты, в том числе про эту игру. Всех буду ждать: https://t.me/krasnorechivyy_ch ^[9]

Ну и напоследок. В комментариях к прошлой статье мне написали, что я поручил написание статьи ИИшке, и что на написание промпта у меня ушел где-то час. Ребята, вы меня недооцениваете! За час надо пытаться написать полноценную игру, а не какой-то там промпт. При этом все не так просто, как кажется, и подробнее об этом я рассказал в своей предыдущей статье ^[10]