У старших класах у мене вдома з’явився досить швидкий як на той час інтернет. Разом із ним у повсякденне життя ввійшли браузерні ігри: їх не потрібно було встановлювати, вони швидко завантажувалися й добре заповнювали короткі паузи. Поки на комп’ютері розпаковувався архів або встановлювалася програма, можна було відкрити нову вкладку, зіграти коротку партію і за кілька хвилин повернутися до своїх справ. Серед безлічі 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. Там можна побачити, на що перетворилася ідея з цієї історії, і пограти самому.
Далі буде.