Как мы с помощью ИИ воскрешали игру для кнопочных телефонов / Хабр

Привет! Меня зовут Абакар, я являюсь главным техническим лидером разработки в Альфа-Банке, а в свободное время изучаю ИИ и веду канал на YouTube 🙂 В школьные годы на переменах я увлекался простой, но невероятно затягивающей аркадой про самолётики. Почти десять лет я мечтал возродить эту старую (но любимую) Java-игру на Android: с управлением, стрельбой, игрой против бота и Bluetooth-режимом для соперничества с другим игроком.

Если вы помните времена Nokia, Siemens и Sony Ericsson, то наверняка играли в подобные игры. Два самолёта. Ограниченная арена. Бесконечные маневры и попытки перехитрить противника. Скриншот из игры ниже:

Я периодически возвращался к этой мысли, но каждый раз всё упиралось в одно и то же: чтобы сделать игру качественно, нужно было погружаться в геймдев, разбираться с графикой, игровым циклом, физикой, сетевым взаимодействием и множеством нюансов. А это уже не совсем простое вечернее занятие.

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

В этой статье расскажу о том, какие модели я использовал, где ИИ приятно удивил, где столкнулся с трудностями, почему Bluetooth оказался сложнее, чем я думал, и как проект в итоге добрался до релиза в RuStore.

Начинаем веселье

Итак, я начал с того, что использовал всё, что было под рукой: Claude с Opus, Codex с GPT, а также взял подписку на Cursor, но это уже другая история. В самом начале мне хотелось быть стильным и модным, поэтому я решил воспользоваться фичей мультиагентности, где у меня есть агент-оркестратор и несколько субагентов, выполняющих разные задачи (например, аналитик пишет требования, разработчик разрабатывает, тестировщик тестирует).

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

«Я хочу, чтобы ты создал игру, где пользователь управляет самолётиком. Игра всегда работает в ландшафтном режиме, в левой нижней части экрана будет стрелочка вверх, чтобы самолёт летел вверх, а в правой нижней части — стрелочка вниз для полёта вниз. Это будет игра-платформер с плоской проекцией самолёта. В папке raw есть примеры скриншотов похожей игры, создайте игру по образу и подобию. При нажатии на экран самолёт должен стрелять снарядом, который летит с умеренной скоростью. Нужны два режима игры: один против компьютера и другой против другого игрока по Bluetooth.

Разверни команду агентов для проектирования и реализации этой функции:

• Продакт-инженер, сфокусированный на продуктовой ценности и удовлетворении потребностей пользователя.

• Аналитик, декомпозирующий продукт на последовательность задач и описывающий функциональные требования.

• QA Engineer, валидирующий DoD и описывающий сценарии тестирования.

• Software Engineer, реализующий код и пишущий тесты (если применимо, использует TDD).

• UX Designer, валидирующий требования и дополняющий требованиями к пользовательскому опыту задачи, после разработки валидирует решение.

Твоя роль – тимлид, организующий работу команды, следящий за тем, чтобы все были сфокусированы на цели, корректирующий участников и отвечающий на вопросы, но не пишущий код самостоятельно. Строго только делегировать»

Первый провал: лимиты закончились, а игры всё нет

Я пошёл пить кофе и ждал, когда по моему «мега-точному» описанию появится игра мечты. Когда я вернулся с чашкой кофе, оказалось, что лимит токенов истёк, а рабочей игры всё ещё нет. Модель успела сделать лишь половину.

Подписка за 20 долларов на Claude оказалась недостаточной по лимиту. Но ничего страшного — у меня нет жёсткого дедлайна, я подожду до следующего вечера и продолжу, но теперь уже без модной команды агентов, а по старинке: через общение один на один и требования к реализации.

Отмечу, что лимиты у Claude истекали очень быстро, поэтому мне приходилось возвращаться к задаче несколько вечеров подряд. В итоге я добился долгожданного результата, который визуально не совсем соответствовал моим ожиданиям…

Первый рабочий билд

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

На этом этапе уже было чему радоваться: самолёты летали, стрельба работала, попадания засчитывались, в режиме «против компьютера» также наблюдался успех. Игра по Bluetooth с реальным соперником — с нулевой работы не имела. Придётся её дорабатывать, но об этом чуть позже.

Не передать словами, насколько я был счастлив, ведь не пришлось писать ни единой строчки кода. Однако, когда я запустил это чудо на своём телефоне, чтобы погрузиться в ностальгические воспоминания, вот что я увидел:

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

Claude против Codex: момент вау-эффекта

И тут в игру вступил Codex с моделью GPT 5.4. Я описал проблему точно так же, как и в случае с Opus 4.6 у Claude. GPT сразу инициировал сборку на эмуляторе, снял скриншот, разобрался с сутью проблемы и исправил её с первого раза!

Моё удивление в этот момент трудно передать словами.

Конечно, я понимаю, что Claude тоже мог бы запустить сборку и выполнить те же шаги, которые сделал Codex… Однако суть в том, что Codex не требовал никаких дополнительных настроек, и с точки зрения пользователя это произвело настоящий вау-эффект. И о лимитах я вообще молчу: с этого момента я переключил разработку игры на Codex, и за те же 20 долларов ни разу не наткнулся на лимит.

А мы тем временем переходим к следующей главе, где обсудим момент, на котором буксовали как Opus, так и GPT.

Bluetooth и сетевой код: момент, когда магия закончилась

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

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

У нас есть Host — тот, кто создаёт игру, и Client — тот, кто её подключает. Мы можем выбрать простую стратегию — отрисовывать интерфейс на Client исключительно по данным с Host. В этом случае интерфейс на Client будет дёргаться, так как для плавного FPS мы должны успевать отрисовать кадр за 16 мс (а иногда и меньше, в зависимости от частоты обновления экрана). Мы, несомненно, не сможем этого добиться, если будем ждать актуальные данные, которые Host передаст Client по Bluetooth.

GPT (так же как и Opus) принял именно такую стратегию, и я получил дёргающийся интерфейс. Как только я попросил ИИ решить эту проблему, он переключился на модель взаимодействия через предсказания. Это схема, при которой Client предсказывает будущее состояние мира и отрисовку, не дожидаясь подтверждения от Host, а затем корректирует мир Client в соответствии с полученными данными от Host.

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

Также была необходимость убрать связь Client -> Host. Host должен создавать виртуальный сервер, к которому обращаются как Host, так и Client. Это поможет уравновесить возможности по отрисовке и обработке пакетов между Host и Client. Чтобы мощный девайс Host не создавал дополнительных проблем, если к нему подключается более слабый Client (с менее мощным Bluetooth модулем).

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

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

Завершаем игру

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

Но результат меня обрадовал — я смог поиграть в самолётики по Bluetooth и вернуться в те времена, когда мы с друзьями играли на переменах на кнопочных телефонах:

Был момент, когда мне пришлось столкнуться с интересным запросом. Мой хороший друг, с которым мы выступаем на конференциях, Саша, попросил поддержать Android 12, чтобы он мог поиграть с дочкой в этот «AAA» проект. Хорошо, сделано. Всего за одну команду GPT понизил минимально поддерживаемую версию с 13 до 12, и всё прекрасно заработало. Вот так быстро расширилась пользовательская база 🙂

Если проект вас заинтересовал — ознакомиться с кодом можно на GitHub, на 76% это C++.
Также, если хотите запустить игру на Android, можно скачать её с RuStore или просто APK с Google Диска.

Выводы

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

Самое ценное в этом проекте даже не то, что игра вышла в RuStore, а то, что идея, которая почти 10 лет оставалась в категории «когда-нибудь», внезапно стала проектом, который можно открыть на телефоне и запустить. Почти на 90% проект выполнил ИИ через мои требования. В 10% мне пришлось направлять ИИ, но это абсолютно не было проблемой.

Я не написал ни одной строчки кода самостоятельно (и такой задачи не было) и достиг результата, а большего мне и не нужно было 🙂

ИИ хорошо справился с:

• базовой игровой механикой;

• генерацией кода;

• быстрыми исправлениями;

• рутинной доработкой.

ИИ плохо справился с:

• архитектурой сетевого взаимодействия;

• пониманием скрытых требований;

• выбором правильной стратегии без подсказок.

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

А если вы уже пробовали реализовывать подобные проекты с ИИ — расскажите в комментариях, где он вас удивил и где заставил страдать 🙂

Читайте также: