Как мы с ИИ воскресили игру с кнопочных телефонов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claude vs Codex: где случился вау-эффект

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Как мы писали сетевой код мобильного PvP шутера: синхронизация игрока на клиенте

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

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

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

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

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

Выводы

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

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

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

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

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

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

• быстрыми фикcами;

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

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

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

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

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

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

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

Подписывайтесь на Телеграм-канал Alfa Digital — там рассказываем о работе в IT, делимся новостями, анонсами митапов и квартирников, рассказываем о технологиях, делимся советами наших экспертов, вакансиями и стажировками, иногда шутим.

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