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

Почніть із завершеного малого ігрового циклу

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

Оберіть одну цільову платформу та невеликий набір пристроїв введення. Додаткові рівні, мережеву гру та процедурний контент залиште на потім. Це робить невдалий прототип діагностованим: можна відрізнити зламане правило зіткнення від незавершеної функції, а не щоразу розширювати prompt.

Спочатку оберіть процес, потім рушій

Для невеликого оригінального 2D-проєкту спершу оцініть задокументовану CLI Godot для циклу перевірки, редагування й запуску. Unity є корисним стартом, коли наявний проєкт або команда вже залежить від його роботи в редакторі. Здатність підтримувати результат має впливати на вибір не менше, ніж перший прототип.

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

Відокремте доступ до моделі від інструментів рушія

Агент має два різні з’єднання: сервіс моделі, що створює міркування та редагування, і локальні інструменти, що перевіряють або запускають проєкт. Godot MCP і Unity MCP належать до сторони інструментів. Установлення будь-якого з них не обирає провайдера моделі та не доводить інтеграцію з gateway.

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

Зробіть перший brief придатним для перевірки

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

Збережіть початковий brief без змін. Нову вимогу позначайте як зміну обсягу. Пояснення помилки або самостійне редагування файла позначайте як втручання. Так зберігається різниця між одним початковим prompt і численними наступними ітераціями моделі та інструментів.

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

Працюйте зі змінами, які легко перевірити

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

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

Розглядайте ресурси й локалізацію як виробничі входи

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

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

Окремо підтверджуйте кожен стан доставки

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

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

Що приклад Playco показує про процес

Історія клієнта OpenAI від 3 вересня 2026 року описує використання Playco моделі Astra у Playbot, IDE, підключеному до ігрових рушіїв. Команда ітерувала над grey-box основою, перш ніж створити тематичні прототипи. Це опублікована провайдером історія клієнта, а не benchmark APIsRouter.

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

Перевірте локальний прототип Godot

Switchyard — невелика головоломка з електричними схемами у трьох кімнатах, створена під час локального запуску розробки Codex. Вихідний проєкт містить рух персонажа, перемикачі, двері, збирання елементів, завершення кімнати, поразку та перезапуск, налаштування і збережений прогрес. Автоматизовані перевірки рушія виконали ігровий цикл, а окремий процес знову відкрив збереження. Нижче наведено справжній знімок viewport Godot, а не концепт-арт.

У записаному запуску використано Godot 4.5.1. Ідентичність його моделі та оплату API не можна було спостерігати, тому це не benchmark продуктивності або вартості Astra. Завантажувані вихідні файли й PCK демонструють локальний проєкт; для PCK потрібен Godot. Окрема збірка Windows, експорт у браузер, ручний playtest і випуск у Steam залишаються окремою роботою. Цей приклад показує конкретні артефакти, які варто вимагати від агента до заяви про доставку.

Оберіть наступний посібник за вузьким місцем

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

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

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