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

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

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

От воспоминания к собственной игре

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

Сейчас у меня более 15 лет опыта разработки на Java. За это время я успел поработать с корпоративными приложениями и высоконагруженными серверными системами, поэтому сложная архитектура или большой проект меня не пугают. Но игр за все эти годы я не делал. Android, Kotlin и Compose тоже оставались в стороне от моей обычной работы. Получалось, что программировать я умею, а для этой конкретной идеи всё равно пришлось бы начинать с незнакомой области.

«ИИ не придумал эту игру — он помог мне наконец начать её делать».

Зато в последнее время я много работаю с ИИ-инструментами и уже хорошо представляю, где они действительно экономят время. Поэтому я решил соединить накопленный опыт со старой идеей и наконец проверить, получится ли из неё игра. Хотелось как можно скорее добраться до версии, которую можно запустить и оценить самому, не тратя несколько недель только на знакомство с новым стеком. В эксперименте участвовали Claude, GPT, Kimi и только появившийся Fable.

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

Спецификация как общая точка отсчёта

Поэтому работа началась с описания правил, а не с генерации кода. Я подготовил несколько исходных тезисов и попросил Fable оформить их в Markdown-спецификацию. Так появился SPEC.md — первый документ с общей концепцией игры, устройством карты, правилами владения системами, производством сил, перемещением флотов и условиями захвата. Затем спецификацию последовательно анализировали другие модели. Они уточняли формулировки, находили неоднозначные места и предлагали дополнения, а я оставлял полезные изменения и убирал то, что уводило игру в сторону от первоначального замысла.

По мере развития идеи одного файла SPEC.md стало не хватать. Сначала рядом с ним появились VISUAL.md, где собирались решения по оформлению и анимациям, PLOT.md с сюжетом отдельных уровней и LORE.md с общим каноном игрового мира. Следующим стал CONTENT_PLAN.md: в нём сюжет и идеи для кампании превращались в более конкретный технический план уровней. Позже к этой группе добавились ECONOMY.md, посвящённый дальнейшему развитию экономики и связанных с ней механик, и OPERATORS.md с описанием героев-операторов, которыми управляет игрок, и их способностей.

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

«Когда код переходил от одной модели к другой, спецификация не давала проекту превратиться в хаос».

Эта система документов была важна не только как подробное описание будущей игры. Она отделяла уже принятые решения от предположений конкретной модели. Если ограничиться запросом в духе «сделай стратегию с точками и линиями», модель самостоятельно заполнит все пробелы: определит поведение противника, скорость движения, порядок расчёта результата и множество других деталей. Две реализации в таком случае будут различаться не только качеством кода, но и фактически окажутся разными играми.

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

Когда спецификация стала достаточно подробной, я попросил модели подготовить первые варианты игры в виде одного HTML-файла. Такой формат был выбран не ради будущей архитектуры, а ради скорости проверки. Файл можно было открыть непосредственно в браузере, без проекта, сборки, зависимостей и отдельной инфраструктуры. В нём помещались игровая логика, интерфейс и анимация, поэтому результат каждой итерации становился виден почти сразу.

Эксперимент не задумывался как строгий бенчмарк. У моделей не было полностью одинаковых запросов, фиксированных лимитов или формальной системы оценок. Первые варианты создавались независимо, а затем из-за ограничений подписок и характера задач работа всё чаще переходила от одного инструмента к другому. Одна модель могла подготовить основу, следующая — исправить обнаруженную проблему, третья — предложить развитие механики. В итоге я сравнивал не столько модели между собой, сколько способы организовать их последовательную работу над одним проектом.

Первый прототип и короткие циклы разработки

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

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

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

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

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

Переход от HTML к Android

После нескольких рабочих версий стало ясно, что идея выдержала первоначальную проверку. Одновременно возникла более сложная задача: перенести найденный процесс за пределы автономного HTML-файла. Android был мне ближе, чем iOS, поэтому следующую версию я решил делать на Kotlin и Compose. Этот переход отделил быстрый эксперимент от разработки настоящего приложения.

«HTML доказал, что идея работает; Android должен был превратить её в продукт».

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

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

Ситуация изменилась после выхода Sol. Новая модель работала заметно увереннее, чем 5.5, и сравнимо с Fable, поэтому я отменил подписку на Claude и решил продолжить разработку в Codex. К тому моменту у меня накопилось три сброса лимитов, и подписки Plus хватало, чтобы без спешки двигать проект вперёд. Основную часть Android-приложения я сделал именно в таком режиме: ставил следующую задачу, проверял результат и переходил дальше по мере освобождения лимита.

Codex, как и Claude, мог сам запустить Android-эмулятор, открыть приложение, сделать скриншоты и проверить результат изменения. Если экран отображался неправильно или какой-то сценарий не работал, модель могла увидеть проблему в эмуляторе, вернуться к коду, внести исправление и повторить проверку. Для Android-разработки это оказалось намного полезнее простой генерации файлов, потому что значительная часть цикла от изменения до визуальной проверки проходила без ручного переключения между инструментами.

Примерно в середине разработки появилась Kimi K3, и часть задач я начал передавать ей. В результате более поздняя часть Android-приложения создавалась уже совместно: что-то писал Codex с Sol, что-то — Kimi K3. Лимиты у сервисов заканчивались по очереди, и вместо того чтобы ждать, я переходил к другой модели. Заодно это стало ещё одной проверкой процесса: насколько хорошо новый инструмент сможет продолжить проект после предыдущего.

Каждая модель сначала читала и уточняла документацию, а затем меняла код. Если в ходе работы обнаруживалось новое ограничение или принималось другое решение, оно возвращалось в документы и становилось частью общего контекста. Благодаря этому передача проекта работала в обе стороны: следующая модель не только получала накопленные знания, но и оставляла после себя более точное описание для той, которая придёт за ней. Постепенно выбор одной «лучшей» модели потерял смысл. Гораздо важнее стали качество документации, размер поставленной задачи и возможность самостоятельно проверить сделанное изменение.

Как меняется роль ИИ по мере роста проекта

При создании раннего прототипа цена ошибки была невысокой. Если очередная версия работала неудачно, её можно было отбросить после одной игровой сессии. Поэтому на этом этапе моделям удавалось передавать крупные части реализации и быстро перебирать варианты. В Android-проекте тот же уровень доверия начал замедлять работу. Кодовая база росла, между компонентами появлялись связи, а исправление одной проблемы могло нарушить предположение, на котором строилась другая часть приложения.

«Чем больше становился проект, тем меньше работы можно было безоговорочно отдавать ИИ».

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

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

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

После успешного HTML-прототипа задача изменилась. Вместо сомнений в самой механике появились обычные вопросы разработки продукта: как сопровождать код, где провести границы состояния, каким образом проверять изменения и как сохранять знания о принятых решениях. Так эксперимент с несколькими моделями и автономными HTML-файлами постепенно превратился в Android-проект, а воспоминание о Flash-игре без названия — в Synaptic Front.

Попробуйте Synaptic Front

Игра уже доступна в Google Play. Там можно увидеть, во что превратилась идея из этой истории, и сыграть самому.

Продолжение следует.