Playco вдвічі скоротила ручні правки в прототипах
Playco використала GPT‑6 Astra у Playbot — ШІ-середовищі, що працює з Unity і Godot: редагує сцени, тестує ігри та перевіряє зміни. З однієї grey box-заготовки команда створила три тематичні прототипи за один прохід; більшість запрацювала з першої спроби. Лише кіберпанкова версія потребувала виправлення продуктивності.
Порівняно з попередньою моделлю ручних правок стало на 50% менше. Playco також відзначила краще просторове мислення, відтворення референсів та адаптивність інтерфейсу в Unity. Це дає змогу швидше перетворювати ідеї на ігрові версії й порівнювати їх на практиці.
Як побудувати перевірку не навколо коду, а навколо результату
У цьому кейсі модель працює безпосередньо в ігровому рушії: змінює сцени, запускає гру, тестує її та перевіряє власні правки. Це інший робочий контур, ніж генерація коду з подальшою ручною перевіркою. Завдання вважається виконаним не тоді, коли з’явився код, а коли зміну можна запустити й оцінити під час гри.
Послідовність роботи можна відтворити так:
- зібрати нетематизований grey box із простих примітивів;
- кількома ітераціями уточнити ігрову механіку та творчі деталі;
- використати спільну основу для кількох тематичних версій;
- запустити кожну версію в рушії, знайти помилки та перевірити зміни;
- відокремити технічні дефекти від правок, що залежать від уподобань команди щодо ігрового процесу.
Робоче формулювання має вимагати не лише створення, а й перевірки: Побудуй версію на спільній grey box-основі, запусти її в рушії, протестуй зміни, знайди помилки та запропонуй поліпшення досвіду гравця.
Ще дві робочі ситуації, де видно різницю
Відтворення візуального референсу. Тут недостатньо написати правильні компоненти: модель має розташувати елементи у просторі так, щоб композиція відповідала зразку. Команда відзначила краще просторове мислення та точніше відтворення референсних зображень. Для перевірки варто зіставити референс і результат у рушії та оцінити позиціонування елементів, а не покладатися на те, що проєкт просто запускається.
Адаптивний інтерфейс у Unity. Інша ситуація — перевірка поведінки інтерфейсу. Playco побачила поліпшення його адаптивності всередині рушія. Практичне завдання тут має поєднувати зміну інтерфейсу із запуском і тестом: Внеси зміни в інтерфейс у Unity, запусти сцену та перевір, чи інтерфейс реагує належним чином. Такий цикл дає моделі можливість не лише побудувати елемент, а й виявити місця, де досвід гравця можна поліпшити.
Де підхід дає збій
Автоматична повторна генерація не завжди краща за втручання інженера. У попередньої моделі початковий grey box був менш відшліфованим, а подальші запити на виправлення зрештою стали контрпродуктивними. Після цього команді довелося виправляти гру вручну. Отже, якщо наступні ітерації не покращують робочий результат, продовжувати той самий цикл підказок немає сенсу.
Працездатність із першої спроби також не означає відсутність контролю. Кіберпанкова версія потребувала виправлення продуктивності, а сильний перший прототип усе одно коригували відповідно до уподобань команди щодо ігрового процесу. Модель може перевірити технічну зміну, але вибір того, як гра має відчуватися, залишається окремим рішенням розробників.
Що перевірити перед прийманням
Результат треба оцінювати в тому самому середовищі, де ним користуватимуться. Для кожного прототипу команда може пройти короткий контрольний список:
- чи запускається версія та чи працюють внесені зміни;
- чи не з’явилися помилки, які модель пропустила під час власної перевірки;
- чи відповідає розташування об’єктів просторовій логіці та візуальному референсу;
- чи залишається інтерфейс адаптивним у Unity;
- чи немає проблем із продуктивністю;
- чи відповідає ігровий процес уподобанням команди, а не лише технічним критеріям;
- чи справді нова ітерація краща за попередню, перш ніж просити модель виправляти далі.
Сильна сторона такого процесу — можливість перетворити більше задумів на версії, у які можна зіграти й порівняти. Рішення тоді приймають не за описом ідеї, а після практичного тесту кількох варіантів.