Розробка ігор з AI у Godot

Визначте межі проєкту до редагування

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

Оберіть помірний ігровий зріз із явними переходами. Наприклад, титульний екран, що веде до однієї кімнати й назад через перемогу або поразку, дає повторюваний тест. Визначте, хто перевірятиме візуальну композицію та керування, адже ані успішний parser, ані повідомлення моделі про завершення не доводять цілісності досвіду.

Визначте виконуваний файл і підтримувані аргументи

Стабільна документація CLI Godot містить наведені нижче команди. GODOT_BIN і PROJECT — змінні shell для цього прикладу, а не налаштування Godot; замініть шляхи-заповнювачі на наявний виконуваний файл і проєкт. Шлях до проєкту має містити project.godot.

До написання сценаріїв із додатковими прапорцями зафіксуйте версію та вивід довідки. Так ви не припустите, що команда з поточної онлайн-документації існує у встановленій збірці. Запишіть ідентичність бінарного файла разом із подальшими результатами тестів і не змінюйте її під час дослідження помилки. Ці ілюстративні команди використовують документовані форми CLI.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

Відокремте імпорт, парсинг і справжню гру

Безголовий імпорт перевіряє межу обробки ресурсів. Перевірка parser досліджує скрипт. Звичайний запуск доходить до гри й може виявити проблеми зв’язування сцен та виконання. Зберігайте ці результати окремо в записі огляду, а не підсумовуйте всі три як пройдені тести.

Наведений нижче шлях до скрипта вже має існувати у вашому проєкті. Перевірка parser навмисно вузька: вона не доводить працездатність зіткнень, реакцію на введення чи правильне збереження. Після зміни повторіть поведінку, яку вона змінює, а також перехід безпосередньо до і після неї. Це часто інформативніше за численні ізольовані перевірки згенерованих допоміжних функцій.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

Свідомо обирайте інструменти CLI або MCP

Агент із доступом до shell може виконувати перевірену послідовність CLI. Godot MCP — додатковий інтерфейс інструментів, який підтримує проєкт; його налаштування описано на окремій сторінці. В обох випадках оператор має знати цільовий проєкт до схвалення запису або запуску процесу.

Тримайте налаштування провайдера моделі агента окремо від інструментів рушія. Робоче локальне з’єднання не доводить доступність певної моделі або підтримку всіх функцій сумісного gateway. Спочатку встановіть найменший дозволений read, потім оборотну зміну сцени і лише після цього повний цикл gameplay у схваленому експерименті.

Дайте помилкам достатній контекст сцени

Коли взаємодія не працює, зафіксуйте відповідне дерево сцени, скрипт, дію введення та першу змістовну помилку виконання. Поясніть очікуваний перехід і спостережуваний стан. У звіті про неможливість руху гравця вкажіть, чи має гра фокус, чи виявлено введення та чи змінюється позиція гравця.

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

Явно підготуйте передумови експорту

Експорт потребує відповідного preset і встановлених шаблонів експорту. Перед збіркою перегляньте export_presets.cfg та включення ресурсів. Зберігайте облікові дані експорту приватними. Назва preset у прикладі ілюстративна й має відповідати вашому проєкту; каталог виводу вже має існувати.

Розглядайте відсутній шаблон або preset як проблему середовища, а не доказ помилки в логіці згенерованої гри. Збережіть логи експорту й хеш артефакту, щоб висновки про цільову платформу стосувалися конкретної збірки. Успішний експорт — важлива контрольна точка, але він не доводить, що доставлений player запуститься або завершить раунд.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

Запустіть miniflow доставки на цільовій платформі

Запустіть експортовану гру в операційній системі, яку плануєте підтримувати. Перевірте старт, введення, повний раунд, перезапуск, налаштування та збереження після повторного запуску. Для кожного результату збережіть ідентичність артефакту, контекст пристрою та спостережуваний результат. Експорт, створений у macOS, сам по собі не перевіряє поведінку у Windows.

Для web-цілі також перевірте завантаження браузера й помилки виконання та випробуйте canvas справжнім введенням. Перевірте потрібну конфігурацію hosting, а не припускайте, що локальний запуск у редакторі охоплює завантаження ресурсів браузером і платформні обмеження.

Проєкт джерела та нативний знімок для перевірки

Локальний приклад Switchyard містить головоломку Godot із трьома кімнатами, автоматизовані перевірки gameplay, перевірки збереження й повторного відкриття, необроблені логи, ZIP джерела та PCK Godot. Його нативні знімки показують фактично запущений проєкт у двох розмірах viewport. Повторення документованих команд є сильнішою перевіркою, ніж оцінювання проєкту за одним знімком.

У проєкті використовувався Godot 4.5.1 у запуску Codex, точну модель генерації якого не перевірено. Тому він демонструє локальний процес рушія, а не benchmark Astra. Експорт у браузер було заблоковано відсутністю шаблонів експорту, а PCK не є окремим виконуваним файлом Windows. Ці межі записано разом із джерелом, щоб наступний розробник знав, що ще потрібно перевірити.

Завершіть цикл передачею, яку можна перевірити

Передача має називати ігровий обсяг, ідентичність джерела, версії рушія та шаблонів, інструкції збірки, прийняті результати й невирішені дефекти. Додайте автентичні знімки перевіреного артефакту та походження доставлених ресурсів. Зберігайте спроби виправлень і ручні втручання, а не лише фінальний дамп згенерованого коду.

Коли базовий цикл прийнято, додайте ресурси й локалізацію через власні перевірки імпорту та gameplay, перш ніж розглядати відправлення на платформу. Цей огляд спирається на документацію рушія; застосуйте його до встановленої версії та збережіть реальні результати. Ведіть короткий список невирішених проблем із кроками відтворення, щоб наступний сеанс починався з того самого відомого стану.

Поширені запитання