Як я сам написав мультиплеєрний 3D-екшн на Godot, делегувавши рутину AI-агентам

Привіт, спільното! Я — соло-розробник, і сьогодні хочу розповісти, як за кілька тижнів інтенсивної роботи створив «Гномобій» (Gnome Slayer) — кооперативний 3D-екшн на Godot 4. З кросплеєм між Windows та Linux, сюжетною кампанією, мультиплеєром і 19 досягненнями.

Але найцікавіше в цій історії не сама гра, а те, як вона створювалась. Я активно використовував AI-агентів як повноцінний інструмент розробки, а не просто як автодоповнення в IDE. Основну «чорнову» та агентську роботу тягнув на собі Fable 5, а для дрібних і точкових правок я підключав Sonnet 5.

Спойлер: AI не замінив мене, але він кардинально змінив пайплайн. У цій статті я чесно поділюся архітектурою свого мультиплеєра, роботою з CC0-асетами та реальними фейлами, коли штучний інтелект робив усе технічно правильно, але логічно — абсолютно повз.

Що таке «Гномобій»

Якщо коротко, це гра, де ви б’єте гномів. Але з технічного та продуктового погляду все трохи складніше:

• Сюжетна кампанія «Осколки Серця Гори»: 6 розділів, NPC, побічні завдання та 3 різні фінали, які залежать від ваших дій.
• PvE (Хвилі): класичне виживання проти наростаючих хвиль ворогів, можна грати соло або в коопі.
• PvP-арена: дезматч до 10 вбивств на окремій локації.

У грі є дерево навичок, прокачка статів (Сила, Живучість, Спритність, Удача), збереження прогресу, 4 різні біоми (луг, осінній ліс, зимовий ліс, нічний цвинтар) з динамічною зміною дня і ночі, боси та навіть найманці-союзники.

Чому Godot, а не Unity чи Unreal?

Для соло-проєкту ключовим фактором є швидкість ітерацій та відсутність зайвого тертя. Мій вибір припав на Godot 4.7, і ось чому:

1. Сцени й вузли — це звичайні текстові файли (.tscn, .gd). Це не просто зручно для Git, це критично важливо для AI-агента. Fable 5 міг самостійно читати структуру сцени, правити її та зберігати, не клікаючи по GUI, як це довелося б робити людині.
2. Швидкість GDScript. Синтаксис, близький до Python, і відсутність довгого кроку компіляції. Написав → запустив. Для темпу «сформулював фічу агенту — перевірив за хвилину» це ідеально.
3. Мультиплеєр «з коробки». Вбудований high-level API для RPC та синхронізації дозволив швидко підняти мережевий код без милиць у вигляді сторонніх плагінів.
4. Нуль фінансового тертя. Відкритий код, безкоштовно, без роялті та сюрпризів з ліцензіями.

Архітектура мультиплеєра: як це працює під капотом

Мережева частина — це те, що зазвичай ховає амбіції інді-розробників. Я обрав модель listen-server, де хост одночасно є і сервером, і клієнтом (Гравцем 1).

Щоб гравцям не доводилося розбиратися з пробросом портів і NAT, хост відкриває один UDP-порт (7788), або ж підключення йде через Radmin VPN. Також ми додали голосовий чат (push-to-talk) з автоматичним ducking’ом (приглушенням звуків гри) та звичайний текстовий чат.

Технічні рішення:

• Авторитетний сервер (Античіт by design): Усі бойові розрахунки — шкода, критичні удари, HP, кулдауни — рахуються виключно на сервері. Клієнт лише надсилає намір: «я вдарив ціль X». Сервер вирішує, чи пройшов удар, і розсилає результат.
• Жорстка синхронізація версій: При підключенні клієнт і сервер звіряють рядок версії гри. Якщо білди різні — клієнт отримує явну помилку.
• Процедурна генерація через сид: Кожна арена генерується з певного сида (розташування будинків, дерев, скринь, точок інтересу). Мережею передається лише сид, а не геометрія.
• Динамічний NavigationMesh: Оскільки перешкоди з’являються динамічно, навігаційна сітка перебудовується асинхронно прямо на льоту, із захистом від подвійного запуску.

AI-агент у розробці: очікування vs реальність

Це найсмачніша частина. Я використовував CLI-інструмент, якому міг дати завдання природною мовою: «Зроби катсцени», «Додай точки інтересу», «Навчи гномів-найманців бігати за мною».

Основним «робочим конем» був Fable 5 — він працював автономно: сам читав код, писав файли, запускав термінал і тестував свої ж зміни. Якщо ж треба було швидко відрефакторити конкретну функцію чи пофіксити дрібний баг, я перемикався на Sonnet 5.

Перевірка йшла через headless-тести (--test, --test-story). Godot запускався без вікна, симулював сюжет чи бій, і випльовував у консоль PASS/FAIL. Це дозволяло перевіряти регресії за секунди.

Але чи було все безхмарно? Звісно, ні:

Кейс 1. Тиха регресія, яку не спіймав жоден краш

При додаванні досягнень, агент випадково видалив виклик обробки консольних аргументів (_handle_cmdline()) з _ready(). Результат? Headless-тести просто тихо зависали. Жодної помилки. Я витратив купу часу, поки не почав розставляти дідівські print() крок за кроком.

Висновок: Тести ловлять помилки виконання, але не ловлять ситуацію, коли код просто перестав викликатися.

Кейс 2. Технічно бездоганно, естетично — вирвиоко

Коли ми робили візуал для найманців-магів, агент додав їм насичені золоті кольори, світіння (emission) і купу іскор-частинок. У коді все було ідеально. Але коли я зайшов у гру, то побачив новорічну ялинку, яка випадала зі стилістики. Довелося йти і руками притлумлювати кольори.

Висновок: AI чудово виконує ТЗ буквально, але оцінка «чи виглядає це доречно» залишається виключно за людиною.

Кейс 3. Гравці роблять те, що тести не перевіряють

Мої найманці-маги мали переслідувати ворогів. У тестах усе працювало. У реальній грі маг помічав ворога на іншому кінці карти, тікав туди і лишав мене напризволяще. Тестовий сценарій просто не перевіряв дистанцію відриву від власника.

Кейс 4. Таймінги та інфраструктурні милиці

Коли додавали ретро-субтитри в катсценах, агент зробив фіксований час показу репліки. Тест проходив, але довгі репліки фізично неможливо було встигнути прочитати. Довелося переписувати логіку під залежність від кількості символів.

Інший приклад: у headless-режимі Godot не може зробити скріншот (рендерер повертає порожню текстуру). Змусити агента візуально перевірити, чи правильно стоїть 3D-модель, було неможливо. Довелося обходити це математично, перевіряючи розміри через bounding box.

Робота з асетами: CC0 і жодної генерації голосу

Болюча тема для інді — графіка. Щоб не мати проблем з авторським правом, я використав пакети моделей з ліцензією CC0 (Creative Commons Zero) від чудового автора Kay Lousberg (KayKit). Використані набори: Character Pack (Adventurers, Skeletons), Halloween Bits, Dungeon Remastered.

Fable 5 тут приємно здивував: перш ніж тягнути щось із GitHub, він перевіряв ліцензію пакету і дивився, чи ця модель ще не використовується в проєкті.

Щодо звуків: Усі звуки (удари, вибухи, пікання тексту) синтезовані процедурно через прості Python-скрипти. Ніяких семплів, і принципово ніякої AI-генерації голосу. Локалізація (на 3 мови) перевірялася окремим скриптом-аудитом, який шукав tr() у коді та звіряв їх із CSV-файлом.

Підсумки: чи варто розробляти з AI?

Звісно, у грі все ще є баги, певні технічні шорсткості та недоліки — це не відполірований AAA-реліз. Проте, якщо подивитися на це як на результат роботи однієї людини в синергії з AI-асистентами лише за кілька тижнів, — це дивовижний показник за поточними мірками індустрії. Ще кілька років тому соло-розробник витратив би на такий об’єм систем місяці монотонної роботи.

Штучний інтелект не зробив гру за мене. Він був надшвидким мідлом, який блискавично писав шаблонний код, генерував логіку збережень чи розставляв ноди. Але геймдизайн, баланс складності, відчуття імпакту від ударів єдиною зброєю в грі — мечем, та загальна атмосфера — це речі, які неможливо делегувати. AI знімає рутину, але режисером вашої гри все одно залишаєтесь ви.

«Гномобій» (Gnome Slayer) вже доступний на itch.io — буду радий, якщо ви спробуєте пограти і поділитесь фідбеком.

Буду радий відповісти на технічні питання в коментарях! Хто з вас уже пробував інтегрувати агентні AI-інструменти у свої пайплайни розробки на постійній основі?

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев