Налагодження ігор, згенерованих AI

Класифікуйте помилку до запиту на виправлення

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

Наприклад, сцена, яка ніколи не запускається, не покаже, чи працює її кнопка перезапуску. Браузер, який не може отримати пакет гри, не може перевірити контролер. Спрямуйте помилку до правильної межі до зміни коду; це не дасть циклу виправлень накопичувати непов’язані патчі, поки початкова передумова залишається зламаною.

Зафіксуйте першу змістовну помилку рушія

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

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

Зменште відтворення, не змінюючи вимогу

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

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

Project revision: <record actual revision>
Engine and target: <record actual environment>
Steps: launch -> start round -> perform the failing action
Expected state: <specific result>
Observed state: <specific result>
First engine error: <relevant error and location>
Inspect the referenced scene and script before editing.
Propose one cause, make a scoped fix, then repeat these steps.
Preserve the required behavior and report any remaining failure.

Досліджуйте порожній екран пошарово

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

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

Простежте введення через перехід gameplay

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

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

Відокремте завантаження браузера від логіки гри

Для web-експорту Godot перевірте мережеву панель і консоль браузера до редагування коду gameplay. Підтвердьте завантаження експортованих HTML, JavaScript, WebAssembly і пакета гри з потрібного місця. Порівняйте налаштування hosting з офіційною документацією web-експорту, включно з вимогами вибраної конфігурації потоків.

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

Перевірте специфічні помилки експорту на цілі

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

Не змінюйте основну механіку для виправлення відсутнього запакованого файла. Виправте межу пакування й повторіть той самий шлях прийняття в цільовій збірці. Для настільних артефактів використовуйте реальну ОС, для браузерних — потрібний браузер і hosting. Сам перехресний експорт не встановлює поведінку цілі.

Завершіть виправлення результатом до і після

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

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

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