Цей допис був написаний мовою оригіналу — італійською — Паоло Гамбарделлою. Його перекладено агентом штучного інтелекту, і він може містити неточності.
Da quanto riesco a capire, Miyamoto non ha mai scritto una riga di codice nei suoi giochi. In una vecchia Iwata Asks, Toshihiko Nakago, il programmatore principale, racconta come funzionava. Miyamoto e Takashi Tezuka disegnavano i livelli a matita su enormi fogli di carta millimetrata. Il team di Nakago inseriva i dati a mano, blocco per blocco. La sera masterizzavano tutto su una ROM e i due designer giocavano il livello. Le correzioni tornavano come appunti a matita sul foglio. “Riuscivamo a malapena a stare in un ciclo di modifiche al giorno”, dice Nakago.
Наскільки я можу зрозуміти, Міямото не написав жодного рядка коду у своїх іграх. В одному старому Iwata Asks Тосіхіко Накаґо, головний програміст, розповідає, як це працювало. Міямото і Такаші Тедзука малювали рівні олівцем на величезних аркушах міліметрівки. Команда Накаґо вносила дані вручну, блок за блоком. Увечері все це записувалося на ROM, і обидва дизайнери грали рівень. Правки поверталися у вигляді олівцевих позначок на аркуші. «Нам ледве вдавалося вкладатися в один цикл змін на день», — каже Накаґо.
Один прохід на день. Сьогодні, маючи поруч мовну модель відкритою поряд з редактором, я можу робити по одному кожні дві хвилини.
Я вже писав, що геній-одинак — це міф, і досі так думаю: без Накаґо не було б Super Mario. Сьогодні частину того діалогу між дизайнером і програмістом бере на себе модель. Але діалог нікуди не дівся, і те, як Міямото в ньому існував, говорить дуже багато про те, чим стає наша професія.
Дизайнер як режисер
Мені подобається уявляти Міямото як людину, яка знала, чого хоче, і вміла це пояснити. Його робота полягала в описі: де стоїть блок, як високо злітає стрибок, що робить Гумба, врізавшись у трубу. Переклад на асемблер — це вже чужа справа.
З AI відбувається щось схоже. Я можу описати механіку, стани персонажа, крайні випадки — і отримати скрипт для Godot або Unity, який їх реалізує. Якість результату залежить від того, наскільки чітко я уявляю собі задачу; токенів витрачу більше або менше залежно від точності опису.
Дизайнер вирішує, що має відбуватися, чому і яке відчуття це має давати. Написання коду стає частиною процесу, яку можна делегувати. Я говорив про це нещодавно у контексті джуніорів: завдання завжди було одне — пояснити машині, що від неї хочуть, щоб вийшла гра.
Обмеження сьогодні
NES мав 2 КБ оперативної пам’яті. Накаґо розповідає, що вони буквально полювали за вільною пам’яттю: маючи двадцять байт, можна було додати десять блоків до рівня. Саме з цих обмежень народилися рішення, які ввійшли в історію, — наприклад, хмари і кущі в Super Mario Bros., які є одним і тим же малюнком, просто різного кольору.
Міямото не програмував, але ці обмеження знав досконало. Тому і просив те, що реально можна було зробити.
AI теж має свої обмеження, і той, хто його використовує, має знати їх так само добре. Модель забуває все, що виходить за межі контекстного вікна. На одне й те саме питання вона може відповісти по-різному. Якщо вона працює в реальному часі всередині гри, кожен виклик має час відповіді і вартість. Хто розуміє ці обмеження, може проектувати з урахуванням їх — а іноді й перетворювати їх на механіки: персонаж із поганою пам’яттю, непередбачуваний оракул, світ, який змінюється щоразу, коли ти його відвідуєш.
Десять проходів на день, потім сто
У тій самій розмові Накаґо каже, що з новими інструментами вони могли змінювати рівень десять-двадцять разів на день. Сьогодні цикл між ідеєю, реалізацією і перевіркою скорочується майже до нуля. Змінюю гравітацію, переграю, змінюю знову.
Це зміщує вузьке місце. Раніше обмеженням була швидкість, з якою хтось міг реалізувати зміну. Тепер обмеженням є те, наскільки швидко я можу зрозуміти, чи ця зміна працює. А щоб зрозуміти — треба грати, відчувати, порівнювати. Відчуття стрибка знайдеш тільки з геймпадом у руках.
Те, чого AI не знає
AI пише код, набрасовує діалоги, генерує ассети за лічені секунди. Але вона не знає, коли рівень задовгий, коли ворог з’являється в невдалий момент, коли стрибок починає дратувати. Вона не відчуває ні радості, ні нудьги, ні напруги. Вона добре імітує рішення, які вже хтось знайшов; вибирати, яке залишити, — завдання того, хто грає.
Тому я думаю, що цінність гейм-дизайнера все більше зміщується у бік смаку, ритму і розуміння психології гравця. Саме ці якості зробили роботу Міямото позачасовою — і він їх відточував олівцем і аркушем у клітинку.
Три речі, які варто тренувати вже з завтра
- Пиши специфікації так, щоб їх міг виконати хтось інший. Візьми механіку, яку добре знаєш, — наприклад, стрибок Маріо — і опиши її в десяти рядках. Потім дай це моделі і подивися, що вийде. Кожна розбіжність між тим, що ти мав на увазі, і тим, що бачиш, — це місце, де твій опис був нечітким.
- Вивчи обмеження свого інструменту. Міямото знав пам’ять NES; ти дізнайся, де модель плутається, що забуває, коли вигадує. Це дизайнерська інформація.
- Грай більше, ніж генеруєш. Якщо одна ітерація коштує дві хвилини, легко зробити п’ятдесят — і жодну з них толком не зіграти. Виділяй час, коли берешь геймпад і робиш висновки, — і записуй, що відчув, перш ніж просити наступну зміну.