Всем привет! Меня зовут Саша, я работаю в сфере AI около 5 лет. А еще мне очень нравится вайбкодить) Некоторое время назад я решил проверить, получится ли у меня сделать что-то приличное в области, где у меня ровно ноль опыта, и выбрал для этого разработку игр. Получился хоррор, и он даже играбелен!
Пару месяцев назад я написал первую статью, где разбирался, почему завайбкодить игру за час не выйдет. Главное пожелание со стороны читателей можно охарактеризовать как
“а давай теперь то же самое, но с техническими деталями и лайфхаками”
Справедливо, держите!
Коротко напомню суть игры. Это психологический хоррор, где игрок участвует в эксперименте. Задача – сохранять спокойствие несмотря ни на что (а смотреть там действительно есть на что). Основная игровая механика – это паника. Ее уровень меняется при взаимодействии с триггерными объектами, монстрами, а иногда просто так (желание побесить игрока никто не отменял). Иными словами, твоя задача – не бояться, а сделать так, чтобы игра сама тебя боялась. За последние пару месяцев проект заметно вырос: было пять уровней, стало девять, а качество первоначальных уровней сильно улучшилось. По итогу имеем 150+ тысяч строк кода, из которых половина – это код игры, а другая половина – тесты. Несмотря на обилие тестов, чуть дальше я расскажу, почему это все равно не спасает.
Во время разработки я сделал ряд ошибок, набил шишки, чуть не стал седым, преисполнился, и понял, как именно нужно делать игры. Сейчас я хочу поделиться советами и мыслями, к которым я пришел на личном опыте, и которые мне сильно помогли (I wish I knew it earlier).
Креатив все еще твоя работа
Искусственный интеллект отлично кодит по техзаданию, но в роли креативного дизайнера все еще должен выступать естественный. В моем случае это я) Все, что делает языковая модель – генерирует правдоподобный текст. Не потому, что она плохая, а потому, что именно на такую задачу ее обучают талантливые инженеры и ученые за ляям двееести баксов в год. Именно поэтому мы так часто слышим, что ИИшка генерирует что-то усредненное, что-то медианное, и настоящего креатива там не особо много. Так как страшное по определению неожиданно, именно недостаток уникальных идей со стороны модели и стал основной проблемой. Например, на запрос “сделай страшный уровень” ты получаешь классику: темный коридор, мигающая лампа, скример из-за угла. Так что если ты увидишь такой паттерн в современной навайбкоженной игре – ты знаешь, в чем дело)
Помимо этого, модель не может измерить, насколько страшный уровень получился у нее самой. Человек переживает игру целиком – визуалом, звуками, и собственным пульсом. Модель же видит код, картинки, децибелы и мои комментарии в духе “Клод, все не то, давай по новой”. Яркость панели в кадре измеряется. Время, за которое бот доходит до двери, измеряется. Страх не измеряется ничем, кроме человека, который закричал от испуга.
Думать придется самому, и много. У меня на брейншторм и ресерч уходит больше времени, нежели на тест и написание промптов. Я регулярно смотрю, как устроены другие хорроры, разбираю, за счет чего они пугают, и гоняю субагентов собирать материал параллельно. Все это фиксируется в отдельный документ идей, и там же лежит информация о предложениях, которые мы отклонили. Без этой компоненты каждая новая вайбкодинг сессия предлагает то, что вы уже обсудили и отклонили несколько недель назад.
Модель действительно решает
Все, что описано выше (брейншторм, ресерч, разбор чужих игр), стоит времени. А взять его можно ровно в одном месте: перестать смотреть шортсы с котами делать руками то, что можно делегировать LLM.
Безусловно, разработчику, который не понимает чего хочет, никакая модель (за исключением GPT-6 Astra и Opus 5.5 как же быстро они обновляются) не поможет, а опытный геймдевер справится даже с инвентарем из палеозойской эры в виде обычного браузера. Так что исход в первую очередь зависит от тебя. Но модель определяет, сколько минут твоей жизни стоит один инкремент – пофикшенный баг, новая фича, или улучшение геймплея.
Модели я отдаю рутину: код, автотесты, базовую генерацию текстур. При этом флагманские модели понимают тебя с полуслова. Отчетливее всего я это увидел, когда переключился на Fable 5.1, GPT-6 Astra, и буквально только что вышедший Opus 5.5. Задача, которая еще вчера съедала три захода и полдня объяснений, сегодня проходит с первого раза с более крутым результатом на выходе. А себе я оставляю идеи, креатив, и правила игры.
Разработка должна вестись по строгой методологии, или твой репозиторий превратится в свалку
Когда все делегируется агенту, а проверить написанное ты либо не хочешь, либо не можешь, репозиторий начинает жить своей жизнью. Документы потихоньку расходятся с кодом, а каждая новая сессия тратит токены на то, чтобы заново разобраться в том, что уже давно решено. У меня это проявилось двумя способами:
-
Документация начала врать. В главном файле проекта (CLAUDE.md) было написано, что в игре нет врагов, которые охотятся за игроком. Потом такая тварина появилась, а строчку никто не поправил. Модель не спорит с тем, что ты дал ей как данность, поэтому каждая новая сессия послушно принимала устаревшую информацию за истину.
-
CLAUDE.md разросся до неприличных размеров. И целиком грузился в каждую сессию. Агенту, которого просили поправить какую-то мелочь, приходилось читать подробности всех уровней сразу (любой каприз за ваши токены). Возможно, с какой-то такой проблемой сталкиваются разработчики, у которых недельные лимиты на самых мощных подписках заканчиваются за выходные)
Для достижения максимального удобства и структурированности пайплайна разработки, я перешел на методологию Spec-Driven Development (SDD), и логика сводилась к трем вещам:
-
Общие правила проекта плюс отдельная спека на каждый уровень. Главный файл больше ничего не объясняет, он только подсказывает дорогу: вот общие правила проекта, вот где лежит описание каждой локации. Когда агенту дают задачу по конкретному уровню, он читает только его спеку, а остальное не трогает.
-
Записал, сделал, зафиксировал. Любое изменение начинается с записи в спеке и заканчивается тем, что спека перечитывается целиком. Таким образом мы блокируем противоречия в логике уровней. Изменение не будет считаться законченным, если документация говорит об обратном.
-
Файл разобранных багов. Каждый баг записывается в формате: симптом – причина – фикс – почему тесты это пропустили – о чем ты вообще думал когда рассчитывал что такое прокатит. Агент читает этот файл перед тем как
разгребать очередную порциюбраться за новый фикс. Удивительно часто новый баг оказывается хорошо забытым старым, и второй раз он чинится за минуты вместо часов.
Мой кодинг-агент перестал наступать на одни и те же грабли (неужели), научился находить свои ошибки и грамотно тестировать значительную долю того, что он реализовал.
Как правильно тестировать то, чего модель не видит
Автотест проверяет точечно: одну дверь, одну стену, один звук. А игра работает целиком: на игрока одновременно действуют геометрия, свет, и звук. Поэтому уровень, в котором каждая деталь по отдельности исправна, в общем и целом может оказаться неиграбельным. Например, на одном из уровней живут монстры, и тесты были полностью зелеными: существо появляется, двигается, паника растет, когда на него смотришь. Захожу в игру, а мой монстр стоит с раскинутыми руками, как пугало на огороде) Это та самая T-поза, в которой 3D-модель стоит, пока ей не дали анимацию. Ни один тест не спрашивал, как существо выглядит, а мне хватило одной секунды. Поэтому игра тестируется в три этапа: сначала автотесты, потом самостоятельно играющий агент, и в конце уже подключаюсь я.
-
Автотесты. Автотесты сильны там, где нужно много безобразных единообразных повторений. Например, подземелье в моей игре генерируется заново при каждом запуске, и в нем нужно зажечь семь подсвечников. Сам я могу пройти его от силы несколько раз иначе меня схватит инсульт, а бездушный тест за пару секунд строит двести разных подземелий и в каждом проверяет, можно ли там найти все свечки.
-
Агент играет сам. Вот это действительно перевернуло разработку. Я настроил Claude так, что во время тестирования игры он имитирует живого игрока: сам запускает игру, ходит по уровню так же, как ходил бы человек, собирает логи и делает скриншоты. А потом сверяет код с тем, что получилось на экране. Именно это комбо позволяет тестировать игру корректно: вот что написано, а вот что из этого вышло на самом деле. Но и этого мало (и причина глубже, чем кажется)
-
Играю я. Агент не чувствует страх. Не тупит. Не задается вопросами, куда идти и что делать дальше. Не понимает, легкий ли этот уровень, или тяжелый. Поэтому я настроил все так, чтобы агент сам запускал игру из моего терминала, а я играл и фиксировал все специальной кнопкой: скриншот плюс заметка к нему. Дальше агент разбирает логи игры, мои скриншоты и заметки разом. Это ускоряет фикс багов, разработку новых фичей, и улучшение уровней.
Дай поиграть живым людям
Человек, который заходит в игру впервые, смотрит на нее и играет в нее совсем не так, как это делает разработчик. Сразу вспоминается анекдот про тестировщика и бар, где я и мои агенты выступаем в роли того самого тестировщика)
Приведу реальный пример из уровня, где нужно победить монстра. На уровне есть шкафы, которые можно использовать в качестве места для пряток. При этом я никогда в них не прятался, так как предпочитал смотреть опасности в лицо. Первое, что сделал коллега, которому я дал протестировать игру – залез в шкаф. Монстр встал рядом со шкафом и до последнего отказывался уходить. Уровень в этот момент буквально стал непроходимым: выйти нельзя, ждать бесполезно.
Решение уместилось в одно правило – теперь вход в укрытие стирает монстру память о том, где он видел тебя в последний раз, и отправляет его бродить дальше. Реальный игрок за пять минут найдет то, чего агент не найдет за ляям двееести долларов в месяц. Поэтому чтобы ответить на вопрос, работает ли твоя игра, дай ее протестировать хотя бы десяти людям. Кстати, мой друг регулярно участвовал в тестировании и признался, что похудел на несколько килограммов. Эффективнее любой диеты)
Заключение
Если резюмировать одним абзацем: вайбкодинг большого проекта – это не про то, что модель сделает все за тебя. Это обычная инженерная работа, где модель берет на себя реализацию, а на тебе остается то, чего она пока не умеет (пожалуйста, научись, я так больше не могу): придумать, что именно делать, посмотреть на результат своими глазами и внятно сказать, что не так.
Спасибо, что дочитали. Я веду телеграм-канал, где пишу про AI, вайбкодинг и свои проекты, в том числе про эту игру. Всех буду ждать: https://t.me/krasnorechivyy_ch
Ну и напоследок. В комментариях к прошлой статье мне написали, что я поручил написание статьи ИИшке, и что на написание промпта у меня ушел где-то час. Ребята, вы меня недооцениваете! За час надо пытаться написать полноценную игру, а не какой-то там промпт. При этом все не так просто, как кажется, и подробнее об этом я рассказал в своей предыдущей статье
Автор: aleksandralgazinov
