Перевод интервью со Сте Пикфордом

Интервью со Сте Пикфордом, взятое для шведского документального фильма Dokument NES и проведённое в 2014 году Стефаном Ганкером посредством email-переписки.

Оригинальная статья...

Но для начала я бы хотел познакомить читателя с интервьюируемым. Сте Пикфорд вместе со своим братом Джоном начал создавать игры в 80-х. Они руководили студией Zippo Games, в рамках которой они разрабатывали игры для Rare, среди которых была также Wizards & Warriors. Впоследствии они сотрудничали с Software Creations. В последующие годы у них были только две студии — Zed2 и Zee3, — в которых только они и работали.

Теперь вернёмся к интервью. Я снимал шведский документальный фильм про NES и расспросил Сте о том, как они создавали свои игры для консоли. Мне было интересно, к помощи каких аппаратных и программных инструментов они прибегали.

Стефан: В ранние годы создания игр для Family Computer у Nintendo практически не было вменяемых инструментов разработчика. Для ввода графики они использовали некое устройство под названием «оцифровщик»; они рисовали пиксель-арт на бумаге в клетку, размещали листы на оцифровщике, представлявшем собой сетку светодиодов 8×8, зажигали светодиоды и потом указывали, какого цвета должна быть та или иная ячейка на бумаге в клетку. Вы знаете что-нибудь об этом оцифровщике кроме того, что я вам рассказал? Я в курсе, что вы начали разрабатывать игры для NES сравнительно поздно, когда уже появились более или менее человеческие инструменты. 

На изображении показано то, как Такаси Тэдзука из Nintendo в 1989 году редактирует графику Super Mario Bros 3. Что за устройство он использует?

А как вы создавали визуальное оформление для своих NES игр? Какие у вас тогда были программы и на каком «железе» они работали? Сильно ли разнились методы разработки игр в разных компаниях, или же имелся некий универсальный набор инструментов?

Сте: Впервые слышу об оцифровщике! Но звучит удручающе. Нет, таким мы точно не пользовались. И хотя мы начали работать со NES сравнительно поздно, при создании игр для других платформ нам не приходилось пользоваться чем-то настолько ужасным.

Если говорить в целом, наш рабочий процесс в те времена не отличался от того, что мы делаем сегодня. Мы создавали графику с помощью определённого инструментария на компьютере, потом использовали другой инструмент для того, чтобы конвертировать сохранённую графику в формат, который целевая платформа в состоянии переварить, и затем импортировали результат в проект, который впоследствии собирался или компилировался для требуемого устройства. В современной разработке игр описанный процесс называется «пайплайном» (pipeline — трубопровод). В стародавние времена мы его так не называли, но по сути своей он был именно таким, только более примитивным и с меньшим количеством шагов.

В поздние 80-е Rare при создании NES-графики всё ещё пользовались бумагой в клетку и вводили данные вручную, но они в принципе плохо поспевали за временем. Мы рисовали в приложении DPaint 2 сначала на Amiga, а потом и на PC. Я располагал изображения в DPaint как набор символов (таким же образом, каким они размещались в памяти NES), скорее всего, в виде LBM-файла, а потом мы написали для DOS утилиту, которая бы сканировала их в набор символов.

Говоря о спрайтах, я в те времена также прорабатывал «структуру» каждого кадра на бумаге и потом вручную прописывал координаты для каждого отдельного спрайта 8×8 пикселей, представлявшего собой «строение» каждого кадра анимации.

Что же касается задних планов, то мы, по-моему, всё ещё конструировали уровни на бумаге, а потом вручную вводили данные для блоков символов, составлявших этап.

Стефан: А как создавались музыка и звуковые эффекты? Были ли у вас какие-то отдельные инструменты для этого и что вообще из себя представлял процесс написания музыки? На изображении показан Кодзи Кондо из Nintendo, сидящий в своём офисе в 1989 году. Я вижу массу «железа», но что из всей этой кучи он реально использовал для написания музыки?

Сте: Ох, боюсь, я плохо осведомлён о музыкальной кухне, поскольку для наших игр Rare предоставляли полностью готовый звук, и программисту оставалось только зашить его в игру. Я этого процесса вообще не касался. Я предполагаю, что «звукачи», как и программисты, также писали код, с помощью которого они напрямую управляли звуковой начинкой NES, и, как мне видится, они нам передавали уже готовый алгоритм, который подключался к основному коду нашей игры, так что музыка а игре генерировалась в результате работы программы, а не просто воспроизводила записанные данные.

Стефан: Сколько времени уходило на производство одной игры для NES с чистого листа? Я понимаю, что это зависит от самой игры, но было же какое-то усреднённое значение? И насколько большой тогда была обычная команда разработки?

Сте: Думаю, от полугода до года, если даже не меньше. Память меня иногда подводит! Обычно команда в те годы состояла из двух человек: программиста и художника, — которые совместными усилиями создавали графику и уровни. Был также и звук, но человек, отвечавший за него, обычно работал сразу над несколькими играми, поэтому он не считался штатным сотрудником для всего проекта.

В Zippo Games мы преимущественно ограничивались тремя людьми на команду, причём я или мой брат Джон некоторое время отвечали исключительно за игровой дизайн (в отрыве от программиста и художника), к тому же нередко я или другой художник подключался к проекту на поздних этапах, чтобы дорисовать недостающую графику.

А вот над Wizards and Warriors 3 некоторое время трудились два программиста, один из которых отвечал за весь интерфейс в интерьерных сценах, так что размеры типичной команды по мере создания игр для NES постепенно разрастались с двух человек до четырёх-пяти.

Стефан: Как происходила конверсия из PAL в NTSC и обратно? Это была программная или аппаратная модификация?

Сте: Точно не помню, да и я как художник не слишком вникал в этот процесс, но это была модификация исходного кода, которую мы обычно производили под самый конец разработки за день или около того. Мы делали игры для NTSC-региона на NTSC-железе даже несмотря на то, что сами находились в Великобритании и стандарт наших телевизоров был PAL. Нам пришлось раздобыть NTSC-телевизоры, что было непросто, — однако Rare впоследствии умудрились напасть на след «мультисистемных» телевизоров (то есть, телевизоров, исправно работающих в любом регионе) — большой редкости на то время, бывшей в офисе на вес золота!

Создание игр для NTSC означало, что мы работали с кадровой частотой, составлявшей 60 герц. Когда доходило до конверсии в PAL, частота менялась на 50 кадров в секунду, что означало отсутствие проблем со скоростью, поскольку шестидесятая доля секунды отлично укладывается в пятидесятую. Правда, в результате становилась ниже общая скорость игры и иногда возникали небольшие проблемы с таймингами, требующие ремонта, и я не уверен, возникала ли необходимость в ускорении музыки, но, если я помню всё правильно, это был тривиальный процесс, который выполнялся после завершения работы над NTSC-версией.

Стефан: Какие программы и «железо» вы использовали для написания игрового кода? И настолько сильно различалась техническая оснастка от разработчика к разработчику? На картинке показана команда программистов Nintendo EAD, отвечавшая, помимо прочего, за Super Mario Bros 3. Как я понял по фотографии 1989 года, они использовали компьютеры, начинка которых устарела на несколько лет. Было ли отсутствие топового оборудования среди игровых разработчиков обычным явлением?

Сте: Повторюсь, что я плохо осведомлён об устройстве внутренних студий Nintendo, но они были довольно-таки причудливой компанией, и использование ими странного или устаревшего аппаратного обеспечения меня нисколько бы не удивило. Nintendo не учили нас выполнять нашу работу, а нам ничего не нужно было знать о том, как работают они. От нас требовалось только предоставить завершённый ROM-файл, способный функционировать на NES, а все наши рабочие процессы были сугубо нашим делом.

Всё наше оборудование для создания игр ограничивалось простыми компьютерами. Не скажу, что оно было таким уж передовым, но оно по крайней мере было актуальным. Мы просто использовали достаточно типичные современные компьютеры для тех лет, работавшие на 286-х и 386-х процессорах (по современным меркам уже невероятно примитивные). Графика создавалась с помощью DPaint 2, но я об этом уже говорил. Кажется, первое время графику для наших ранних NES-игр мы рисовали на Амиге, но впоследствии мы переключились на IBM PC, хоть я и продолжил пользоваться теми же программами. Для непосредственно самой разработки мы использовали актуальный компилятор/редактор, а что касается NES, то Rare предоставили нам аппаратное подключение к модифицированной NES, так что мы компилировали код на компьютере, загружали его на фейковый картридж для NES, подключенной к компьютеру, и запускали игру. Мы также могли записывать последние сборки игры в EEPROM-память тестового картриджа и потом запустить его на модифицированной консоли.

Стефан: NES разрешала использовать в картридже различные дополнительные чипы, позволявшие расширить границы того, что можно реализовать в игре. Как это влияло на процесс разработки? Вы перед началом разработки решали, какими чипами будете оснащать картридж, или планы могли поменяться прямо по ходу создания игры?

Сте: Да, начинка у картриджей была весьма крутой. Я знаю, что в Mario 3 такое обилие классных эффектов анимации достигалось благодаря особому «железу» на картридже, которое умело мгновенно переключать банки памяти и позволяло «свободно» анимировать блоки символов (например, танцующие растения и деревья на экране карты) без потребления процессорного времени.

Впрочем, обычно это не от нас зависело. У Rare был свой собственный дизайн картриджей, и мы делали игры с расчётом на то, что они будут работать на картриджах от Rare.

Другим важным моментом был объём памяти на картридже. Количество доступной памяти варьировалось от игры к игре и обычно определялось на старте проекта (поскольку от этого зависела стоимость производства), однако нередко объём доступной памяти возрастал посреди рабочего процесса. В некоторых случаях такая ситуация возникала вследствие того, что мы кровь из носу нуждались в дополнительной памяти, без которой наша игра попросту не помещалась на картридж, а иногда место на картридже увеличивалось прямо по ходу разработки из-за падения цен на память, благодаря чему мы бесплатно получали запасное место под данные. 

Стефан: EPROM и EEPROM — это же ведь одно и то же? Во время изучения этой темы я обнаружил, что использовалась EPROM-память, но никак не EEPROM.

Сте: Я сам плохо понимаю разницу между ними. Я просто помню, что в студии их называли EEPROM'ами. Думаю, в рамках вашего исследования можно сказать, что это почти одно и то же.

(Впоследствии, опубликовав материал на форуме Famicomworld, я получил ответ на свой вопрос.
Infinest: «а их названий недостаточно для понимания разницы? EPROM: стираемое перепрограммируемое ПЗУ. EEPROM: электрически стираемое перепрограммируемое ПЗУ. Данные с EEPROM могут быть стёрты программно, в то время как содержимое EPROM'ов стирается с помощью ультрафиолета, для чего у них и есть специальные окошки.»)

Стефан: Насколько тщательно вы продумывали сюжет, геймплей и так далее перед началом разработки игры?

Сте: Как много мы планировали наперёд? Всё зависело от игры. Как правило, перед заключением контракта мы сначала определяли масштабы игры путём написания дизайн-документа, в который мы сгружали сценарий игры, её локации, тип геймплея, какой-нибудь концепт-арт и так далее. Он становился частью плана по получению контракта. Как только разработка игры начиналась, мы погружались во всевозможные детали: продумывали и оформляли уровни, писали сценарий и диалоги, если таковые подразумевались, и прочее, прочее, прочее...

Перед созданием, допустим, большой игры наподобие Wizards and Warriors 3 мы знали, что в ней будут три класса (вор, воин, чародей), доступные только определённым классам регионы города, разный геймплей для каждого класса и всё в таком же духе, а вот реализовывать геймплей для каждого класса, планировать карту города, прорабатывать головоломки и так далее мы начинали только после того, как открывалась разработка игры. Основная часть работы выполнялась во время разработки. Пока нет контракта, не стоит очень тщательно всё продумывать. Помимо этого я не советую слишком углубляться в детали (с точки зрения сюжета, локаций и всего такого) до появления рабочего прототипа, поскольку многие нюансы сценария и локаций естественным образом вытекают из того, как работает игровой процесс, а чтобы иметь о нём реальное представление, его сначала нужно сделать.

Стефан: Сейчас с помощью редакторов NES-графики можно вытаскивать изображения непосредственно из ROM-файлов. Я отправил вам пример такого изображения. 

Получается, вам приходилось делить крупные спрайты на несколько квадратов 8×8 пикселей, а потом в таком построчном виде располагать их в редакторе? 

Я правильно понимаю, что для бэкграундов вы создавали тайлы 8×8 и на бумаге зарисовывали их структуру подобно тому, как в Nintendo в незапамятные времена поступали со спрайтами, только каждый отдельно взятый квадрат на бумаге в клетку представлял собой не пиксель, а тайл 8×8? Что же касается музыки и звуков, то я догадывался, что вы вряд ли сможете много рассказать. Я пытался связаться с Дэвидом Уайзом по электронной почте, указанной на его домашней странице, чтобы взять у него интервью, но так и не смог до него достучаться.

Сте: Пример с Кирби, который вы мне показали, являет собой весьма примитивный подход, свойственный многим играм компании (в продвинутости Nintendo NES'овской эпохи по части создания игровой графики я несколько сомневаюсь). Они использовали сетку спрайтов 8×8, причём для каждого кадра анимации использовалась новая сетка. Получается так, что первый кадр Кирби использует 4 спрайта (то бишь, 16 пикселей), второй кадр использует ещё 4 спрайта (и ещё 16 пикселей). Такой метод был прост в понимании и лёгок в реализации, но выжать максимум производительности из консоли он не позволял. Каждый следующий кадр анимации нуждался в новом наборе спрайтов. Если бы вы создавали крупных персонажей с габаритами, скажем, 24×32 пикселей, то понадобилось бы создать для каждого кадра анимации по 12 спрайтов размером в 8×8 пикселей, на что вам не хватит ни памяти, выделенной под спрайты, ни лимита одновременного отображения спрайтов на экране.

Мы же поступали иначе: сначала выводили отдельные кадры анимации на экран (в DPaint), а потом вручную и очень аккуратно вырезали из каждого кадра уникальные спрайты 8×8, находя повторяющиеся сегменты (допустим, голова персонажа, находящегося в движении, может выглядеть одинаково во всех кадрах анимации ходьбы, лишь слегка меняя своё положение в пространстве), и формировали «набор» спрайтов (прямо как на правой стороне той картинки с Кирби), а потом аккуратно зарисовывали «строение» для каждого кадра анимации на бумаге в клетку, отмечая расположение пикселей и нумерацию для каждого использованного 8×8 спрайта.

Чтобы проиллюстрировать свои слова, я приложил скан одной из многочисленных страниц с наборами спрайтов для Wizards and Warriors 3.

У такого подхода было два достоинства. Для начала, мы могли переиспользовать уникальные спрайты 8×8 для разных кадров анимации (что можно увидеть на моём изображении, где все кадры City Dweller с нулевого по третий используют один и тот же спрайт 9D несмотря на то, что голова меняет своё положение каждый кадр), а также нам никогда не приходилось задействовать спрайты пустых зон на экране. Если персонаж передвигался гуськом, мы просто выводили на экран меньше спрайтов. Сеточный метод Nintendo приводил к тому, что, если персонаж пригнулся, пустая верхняя половина фрейма всё равно должна быть отображена, хотя там ничего нет. Также этот метод ограничивал внешний вид и форму персонажей, вынуждая их соответствовать сетке. Из-за этого Кирби никогда не смог бы вырасти за пределы 16×16 пикселей. В нашем же случае, если персонаж в одном кадре анимации выходил за границы сетки, мы могли просто дорисовать недостающие спрайты специально для этого кадра.

Недостаток же этого метода заключался в исключительной трудоёмкости, к тому же для него требовался богатый опыт и развитое чутьё. И мы не могли хоть как-то оптимизировать этот процесс. Впоследствии, работая уже со SNES, мы немного автоматизировали рутину, чуть-чуть пожертвовав качеством, благо SNES обладала куда более мощной начинкой, и для того, чтобы добиться от неё хорошего результата, нам больше не приходилось работать до седьмого пота.

Вот ещё один пример нашего метода в нашем блоге.

На нём изображены спрайты летящего орла из Ironsword. Можно увидеть, что мы вырезали 8×8 спрайты каждого кадра так, чтобы в эффективной области оставались только крылья орла, а не просто взяли всю квадратную сетку с кучей пустого пространства, как бы вам пришлось поступить по методу Nintendo.

В случае с фонами у нас появлялся промежуточный этап, где мы создавали блоки, скажем, 4×4 символов. А «блок» в свою очередь состоял из сетки 4×4 символов (то есть, 16 символов), и потом мы формировали карты из блоков, и карта, состоящая из блоков 10×10, визуально отображалась бы на экране как 40×40 символов, что заняло бы в памяти только 100 байт. Именно по этой причине в таких играх как Ironsword, Wizards and Warriors 3 и так далее на фоне можно увидеть повторяющиеся фрагменты, будь то стены, платформы и спуски, которые всегда выглядят одинаково.

Надеюсь, я смог внятно объяснить!

Стефан: Я хотел бы попросить Вас взглянуть на эту веб-страницу и прокомментировать некоторые упомянутые моменты. (Ссылка сдохла. На странице рассказывалось о некоторых странностях, связанных с Equinox для SNES — игрой, над которой трудились Пикфорды. Далее Сте отвечал на вопросы по игре, имевшиеся на сайте.)

Flyingomelettes: Перемены в персонаже по ходу разработки игры.

«Можно отчётливо видеть, что в игре изначально был другой протагонист. Он худее, в другой одежде и с головой в форме яблока то ли с шипом, то ли с могавком на макушке. Также на этих скриншотах заметны и другие различия между ранним прототипом и финальной версией. Спрайты призраков выглядят чуть иначе (в релизной версии в первом подземелье нет белых привидений, а их накидки немного круглее и шире). Порядок комнат (речь, вестимо, о Galadonia) также, мягко говоря, немного отличается от того, что можно увидеть в финальной версии. Более того, в верхней части экрана с обеих сторон от слова «SHAPIRO» можно найти японскую кану. Это очень странно, ведь игра разрабатывалась не японской компанией, а Software Creations, базирующейся в Великобритании (хотя в титрах и можно встретить несколько японских имён). Я уж хотел было подумать, что это кто-то из редакции японского журнала поместил текст поверх скриншота, однако этот текст написан игровым шрифтом...

Возможно, это просто совпадение, но мне кажется, что протагонист из прототипа очень похож на Monster Max из игры от Titus с тем же названием, имевшей схожие с Equinox и Solstice геймплейную стилистику и графику.

Сте: Что касается главного героя, то его оригинальный дизайн был нарисован мной. Однако он не понравился японскому издателю, и они предложили своими силами нарисовать для нас главного героя, который — по их заверениям — будет смотреться лучше. Я посчитал, что это полный бред, и у них ни за что не получится сделать лучше, чем у меня (всё-таки создавать анимацию в изометрической перспективе сложно), но когда японцы прислали нам своего нового персонажа, мне пришлось признать, что он несравнимо лучше того, что получилось у меня. Впоследствии мы заменили нашу графику на присланную, что произошло уже на поздних этапах разработки. Никакой связи с Monster Max нет. Я никогда не слышал об этой игре, никогда в неё не играл и никак не был связан с Titus.

Flyingomelettes: Дело об пропавшем режиссёре

Equinox — шикарная адвенчура для SNES и одна из моих самых любимых игр. Но, видимо, не все со мной солидарны. Обратите внимание на имя режиссёра Equinox из финальных титров.

Сте: С Аланом Смити дела обстояли вообще забавно. Изначально мы разрабатывали игру с оглядкой на стилистику жанра jRPG, и каждый «горшок» на вращающейся карте мира был на самом деле деревней. Внутри таких поселений вы бы могли исследовать лачуги местных аборигенов, общаться с неиграбельными персонажами и искать скрытые пути в подземелья. Мы прописали для NPC целый арсенал головоломок и планировали реализовать целое приключение по карте мира с постепенно раскрывающейся сюжетной линией, а с каждой решённой головоломкой вы бы получали доступ к дополнительному входу в подземелье. Мы полностью продумали и прописали в диздоках всё вышеперечисленное, сочинили загадки, написали диалоги и перевели их на японский. В планах у нас были очень прикольные головоломки. А потом, когда устаканился график, выяснилось, что релиз опоздает на пару-тройку месяцев. Издатель запаниковал и настоял, чтобы мы сократили игру и успели закончить её вовремя. Единственным возможным в такой ситуации решением нам виделось полное удаление «приключенческой» составляющей (поскольку, хотя часть графики для неё уже была на то время готова, она оставалась последней частью игры, до которой программисты не успели добраться), и превращение «горшков» с деревнями в обычные проходы в подземелья. В общей сложности игра была урезана наполовину: все приключения, сюжет и персонажи ушли под нож, оставив только 8 подземелий. Мы с Джоном были просто уничтожены; нам казалось, что нашу потенциально отличную игру взяли и выпотрошили. По этой причине мы и подписались в титрах именем «Алан Смити».

Больше на странице я не вижу ничего особенно примечательного. В игре могли быть какие-нибудь баги и графические глитчи, но я не помню точно. Разрабатывали игру мы с Джоном, однако мы никак не были связаны с созданием Solstice, автор которого покинул компанию ещё до нас. Я не уверен, что вообще играл в Solstice более пяти минут. Мне достаточно было узнать об игровом сюжете, чтобы иметь возможность создать внятное продолжение, но меня самого мало интересовал ни сценарий Solstice, ни её геймплей, я лишь пытался создать свою собственную игру. И любая возможная непоследовательность в сюжете и истории вызвана лишь моей некомпетентностью.

Надеюсь, что смог прояснить некоторые нюансы!