З розробки Romergo
Від нескінченних правок до знімального майданчика: як я вчуся генерувати історії
У попередній статті я писав, чому між першоджерелом і готовою візуальною новелою потрібен цілий процес: зберегти факти, підготувати персонажів, зібрати сцену й подивитися, що насправді бачить гравець.
Відтоді процес ускладнився. Не тому, що хотілося вигадати ще кілька гучних назв для ШІ. Під час створення історій я постійно стикався з неприємною проблемою: хороше зображення дуже легко втратити, намагаючись зробити його трохи кращим.
Спочатку просиш виправити руку. Потім повернути частину одягу. Потім прибрати зайву ногу — так, і таке буває. Зрештою помічаєш, що за всіма правками змінилося обличчя, потемнішали тіні, а чисте тло стало каламутним.
Виправляєш одну ділянку, а змінюється вся картинка. У якийсь момент доводиться визнати: п’ять версій тому було краще.
Виправити зображення — ще не означає зберегти його
Одна з найбільших моїх проблем — накопичення змін. Беремо зображення А, робимо з нього Б, потім із Б — В і продовжуємо ще кілька спроб. Кожна нова версія успадковує і потрібну правку, і все, що непомітно змінилося раніше.
У моїх генераціях «пливли» обличчя, важчали тіні, на поверхнях з’являлися артефакти, зникали дрібні деталі. Не кожен наступний кадр обов’язково гірший. Але довгий ланцюжок правок давав надто багато можливостей відійти від початкового вигляду.
Для людини «залиш усе як є, тільки поверни голову» звучить очевидно. Ми впізнаємо персонажа, розуміємо кімнату й припускаємо, що куртка залишається на ньому, навіть якщо про неї не нагадали. З генератором про ці речі доводиться домовлятися явно. Він може створити переконливе нове зображення й водночас зламати те, що ми вважали само собою зрозумілим.
Тож так, значна частина роботи — вчитися домовлятися із ШІ. Іноді буквально пояснювати, що третя нога нам досі не потрібна.
GENERAL: точка, до якої можна повернутися
Першою відповіддю став GENERAL — погоджене еталонне зображення персонажа, місця або предмета. Якомога нейтральніше, з добре видимими постійними ознаками й мінімумом деталей конкретного епізоду.
Далі я намагаюся уникати нескінченного ланцюжка «остання правка → наступна правка». Новий стан створюється від GENERAL з урахуванням того, що має відбуватися зараз.
Під час виправлення сцени завдання може мати три опори:
- GENERAL задає вигляд персонажа або місця;
- попередній кадр допомагає зберегти потрібну позу, композицію або стан;
- повні вимоги описують бажаний результат, включно з новою правкою.
Попередня версія залишається допоміжним референсом. Вона не повинна непомітно перетворюватися на новий еталон разом з усіма накопиченими помилками.
*Це ілюстрація підходу, а не порівняння реальних генерацій. GENERAL дає сталу точку опори, але не гарантує незмінності кожного пікселя.*
Магічного способу заборонити генератору помилятися немає. Проте тепер є зрозуміла відповідь на запитання «куди повертатися, коли все почало плисти?». Змінюється й мета правки: створити потрібну сцену з тим самим персонажем, а не просто відредагувати останню невдалу версію.
Render Eye: що існує у світі й що видно в кадрі
Наступна проблема тонша. Припустімо, персонаж добре описаний: куртка, рукавички, ремінь, чоботи. Але зараз кадр по пояс, одна рука за спиною, а частину тіла затуляють двері.
Які деталі треба намалювати? Які мають бути приховані? І як відрізнити приховану рукавичку від тієї, яку генератор просто забув?
Саме для цього я розвиваю Render Eye. У нього два завдання: підготувати вимоги до генерації та перевірити отримане зображення після неї.
Спочатку він звертається до біблії історії — збережених описів персонажів, локацій, предметів та їхніх станів. Потім зіставляє їх із постановкою: положенням камери, дією та тим, на що має звернути увагу гравець.
Для кожної важливої деталі визначається: видима повністю, частково, перекрита іншим об’єктом чи поза кадром. Якщо рука за спиною, рукавичка не зникає зі світу. Її просто не можна перевірити з цього ракурсу.
Так виходить конкретне завдання для кадру. Не просто «намалюй героя в коридорі», а «цей герой, у цьому одязі, з цього ракурсу, з такими видимими деталями». Якщо предмет потрібен для розуміння сцени, він не має випадково сховатися за краєм зображення.
Після генерації Render Eye повертається до того самого завдання. Перевіряє одяг, предмети й розташування персонажів, окремо — анатомію та артефакти. Виявлена помилка або невпевненість повертає зображення на виправлення. Не можна прийняти зниклу куртку, а потім переписати опис персонажа, наче її ніколи не було.
Водночас не варто наділяти систему уявними надздібностями. Зображення розглядає ШІ, який теж може щось пропустити. Обов’язкова перевірка робить процес дисциплінованішим, але не перетворює модель зору на безпомилкового спостерігача.
Режисер: навіщо нам саме такий кадр
Можна правильно намалювати одяг, зберегти обличчя, розставити всіх персонажів — і все одно отримати прісну сцену.
Історія — це не лише присутні в ній речі. Важливо, коли гравець їх помітить, яка репліка буде першою, скільки часу отримає реакція й що в цей момент буде чути.
Так з’явилася окрема роль режисера. Він працює близько до самої сцени: порядок реплік і реакцій, присутність персонажів, освітлення, колір, музика, звуки, паузи та композиція інтерфейсу. Першоджерело залишається робочим матеріалом протягом усього процесу, а не прочитаним на початку завданням.
Візьмімо вигадану фразу: «За дверима почулися кроки».
Можна просто показати двері й вивести текст. А можна заздалегідь приглушити музику, залишити тихий фон кімнати, дати крокам прозвучати за кадром, затриматися на реакції персонажа й лише тоді продовжити розмову. Якщо першоджерело ще не розкрило, хто прийшов, камера не повинна послужливо показувати цю людину.
У детективі той самий коридор може привертати увагу до зачіпки, у романтичній сцені — до очікування зустрічі. Різниця народжується з конкретних рішень. Самого запису «настрій: жахи» в завданні недостатньо.
Режисер зберігає рішення в плані постановки. Факти твору залишаються окремо від інтерпретації: холодне світло може бути художнім вибором, а поява нового переслідувача змінює події.
В іграх є ще одна складність: люди читають у власному темпі. Пауза перед реплікою й очікування, поки її дочитають, — різні речі. Не можна спланувати красиві чотири секунди й закрити текст тому, кому потрібно шість.
І я не хочу замінювати прісну сцену механічним набором ефектів. Іноді правильне рішення — нерухомий кадр, проста склейка й відсутність музики. Прийом має бути потрібним.
Директор: чи вийшло те, що ми задумали
Назви «режисер» і «директор» можуть здаватися близькими, але я розділяю їхню відповідальність. Режисер ставить сцену. Директор перевіряє результат.
Він зіставляє першоджерело й план постановки з тим, що справді потрапило в гру. Дивиться на готову послідовність, а не тільки на окремі красиві картинки.
Чи не закрив інтерфейс важливий предмет? Чи не зник персонаж, який слухає, під час зміни репліки? Чи не грає музика з попередньої кімнати? Чи не розвалилася композиція на телефоні? Чи передає сцена той тон, заради якого добирали світло, паузи та звук?
Корисна перевірка має також розуміти, куди повернути проблему. Дефект усередині картинки — назад у генерацію. Хороше зображення персонажа невдало розміщене на екрані — треба поправити збірку. Звук починається зарано — перемальовувати тло не потрібно.
*На схемі Director — режисер постановки, а QA — директор, який перевіряє якість. Схему спрощено: під час збірки й фінальної перевірки першоджерело також залишається опорою. Зворотна стрілка означає виправлення відповідного етапу, а не обов’язковий перезапуск усієї роботи.*
Людина теж не повинна чергувати біля генератора
Навіть якщо зображення з’являються швидше, залишається інша ціна — постійне перемикання уваги. Відкрити чат, подивитися кадр, залишити коментар, повернутися до справ. За кілька хвилин повторити.
Тому ще один напрям — GENERAL пачками. Незалежні еталони можна підготувати заздалегідь і принести людині групою. Так їх можна розглянути разом, помітити неузгодженості й залишити спільні або окремі зауваження.
Потім переробляються лише потрібні кадри. Погоджені зображення не мають губитися через одну невдалу спробу. Залежності нікуди не зникають: якщо наступному зображенню потрібен ще не погоджений еталон, спочатку треба розібратися з ним.
Це не обіцянка прискорити сам генератор у кілька разів. Для мене важливіше зменшити кількість моментів, коли людині доводиться кидати свої справи заради чергової перевірки.
Маленький знімальний майданчик замість однієї великої команди
Зрештою я справді намагаюся зібрати маленький знімальний майданчик із ШІ. У ньому є описаний світ, еталони, постановка, виробництво кадрів, збірка й контроль якості.
Це зони відповідальності в робочому процесі агента. Це не означає автоматично, що за кожною роллю вже стоїть окремий ШІ, який працює постійно. Важливо, щоб рішення зберігалися, вимоги не змінювали заднім числом, а кожна правка давала зрозуміти, що треба перевірити знову.
За новими етапами вже є інструменти та збережені плани. Далі — випробування на справжніх довгих розділах: наскільки вони допомагають утримувати персонажів, настрій і увагу автора протягом історії?
Моя кінцева мета — принести велику книжку, обрати розділ і послідовно перетворити його на квест, у який можна грати. З можливістю зупинитися, подивитися результат, виправити важливе й продовжити з того місця, де завершилася робота.
Генерувати історії виявилося значно складніше, ніж «написати хороший промпт». Але тепер цю складність можна розкласти на конкретні завдання. Десь потрібен сталий еталон, десь — уважне читання, десь — тиша перед реплікою. А десь досі потрібна людина, яка подивиться на сцену й скаже: «Ні, ось тут я тобі не вірю».