Введение

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

В первых двух частях серии мы разговаривали с Джоном Ромеро (о TEd Editor) и с Тимом Суини (о Unreal Editor).

При написании третьей статьи мне выпала честь поговорить с Крисом Норденом об инструментах, которые он разрабатывал для гибрида FPS/RPG под названием Deus Ex. Я пообщался с Крисом в Сан-Франциско на GDC 2018.

До Ion Storm: Origin и Looking Glass

Дэвид Лайтбоун: Как вы начали работать над Deus Ex в Ion Storm?

Крис Норден: В 1994 я работал программистом Origin в Остине. Моим первым оплачиваемым проектом стал Jane’s Combat Simulations AD-64D Longbow компании Jane’s Combat Simulations. Изначально это была аркадная игра под названием Chopper Assault. Вместе с Энди Холлисом я работал над ней два года.



После выпуска игры последнее, чего бы мне хотелось — заняться ещё одним военным симулятором, потому что я совершенно не люблю всё военное. Время от времени я общался с Уорреном Спектором, который тоже работал в Origin. Ему очень нравились сюжетные ролевые игры. Я подумал про себя: «Мне тоже нравятся такие игры, хочу поработать над чем-то подобным!»

В 1996 году Уоррен ушёл из Origin и возглавил студию Looking Glass в Остине, о существовании которой никто тогда не знал. Эта студия делала порты игр для Mac, например Links 386 Pro. Также она находилась в процессе разработки собственной игры про гольф под названием British Open Championship Golf.

В Origin всё ещё продолжалась разработка Ultima Online. Её прозвали Multima, и в ней кажется использовался движок Ultima VII. Я немного экспериментировал с ним, пока не уволился из Origin и не присоединился к Уоррену в Looking Glass.

[Примечание автора: основная студия Looking Glass находилась в Кембридже, штат Массачусетс, рядом с Бостоном]

Уоррен написал дизайн-документ, и мы какое-то время работали над ролевой игрой с аббревиатурой AIR (от Austin Internet Role-Playing), которая должна была стать онлайн-проектом. Мы хотели сделать что-нибудь в 3D, потому что в то время как раз начали появляться 3D-ускорители. Мы получили прототип Voodoo 1 и написали на GLide небольшой движок.

Мы сотрудничали с офисом Looking Glass в Кембридже. После выпуска British Open я помогал Марку Леблану и Дугу Чёрчу с движком для Thief, который назывался Dark Engine.

По финансовым и иным причинам Looking Glass в то время чувствовала себя не очень хорошо. У компании были потрясающие игры, но продавались они слабовато. Поэтому примерно через год было принято решение о закрытии офиса в Остине.

[Примечание автора: Крис абсолютно прав насчёт игр — Ultima Underworld, System Shock и Terra Nova критики восприняли очень хорошо, они были одними из лучших игр 1990-х]

В момент закрытия офиса нас оставалось мало: Уоррен, я, Эл Яруссо, Харви Смит, Стив Пауэрс. Все мы по-прежнему хотели работать над этой ролевой игрой. После закрытия офиса мы около шести месяцев держались друг друга, надеясь, что нам удастся основать новую компанию и что-нибудь сделать. У нас был очень хороший дизайн-документ, мы начали «продавать» его издателям и общаться с разными людьми. Я даже не помню всех издателей, с которыми мы контактировали. Одними из этих людей были Джон Ромеро и Том Холл, которые вместе с Eidos работали над созданием в Далласе новой студии под названием Ion Storm.


Я знал Джона ещё с первых лет Id. В 1991 году в Далласе MTV закатила огромную вечеринку на корабле, посвящённую Wolfenstein 3D. Там было две машины VR Virtuality Arcade Machine. В то время я был ребёнком и думал «Боже, да это самая крутая вещь в мире!» Я встретился с Джоном ещё в те дни, когда он жил в стиле «я слишком богат, чтобы о чём-то волноваться».

Джон — замечательный человек, я работал с ним в Monkeystone Games, помогал в разработке игры для Gameboy Advance, но это уже другая история.

[Примечание автора: игра называлась Hyperspace Delivery Boy. Для Gameboy Advance её должен был издавать Majesco, но в последний момент компания отказалась от выпуска.]

Мы поговорили с Ромеро и Томом Холлом, и они такие: «Уоррен, ты крут, давайте сделаем эту игру!». А Уоррен ответил: «Тут есть загвоздка. Мы не переедем в Даллас. Мы не переедем в Калифорнию. Мы вообще никуда не будем переезжать. Мы сохраним студию в Остине. Так мы останемся совершенно автономными. Вы дадите мне полный контроль над всем. Вы мне дадите денег, и всё будет отлично». Они ответили: «Ладно, нас устраивает. Решено.»

[Примечание автора: очевидно, это слишком упрощённая версия переговоров, но она даёт представление о произошедшем]

В то время у Уоррена был отличный дизайн-документ для игры «Troubleshooter», который постепенно превратился в дизайн-документ Deus Ex.

Итак, мы вшестером основали студию Ion Storm Austin. В то время я был техническим директором, главой ИТ-отдела, «эйч-аром», службой безопасности и ведущим инженером. У нас не хватало людей, чтобы заниматься всеми этими делами. Поэтому нужно было быстро проводить собеседования и набирать персонал.

Команда была крошечной. У нас было три инженера: я сам, Скотт Мартин и Эл Яруссо. Сценаристом наняли Шелдона Пакотти. У нас было две дизайн-группы по три человека. Одну возглавлял Роберт Уайт, вторую Харви. Кажется, ещё было шесть художников, которыми руководил Джей Ли.

А, да, и ещё я нанял Алекса Брэндона, потому что был большим фанатом его музыки для Unreal. Сейчас мы с ним большие друзья. Я познакомил его с его будущей женой, потому что мы дружили в старшей школе. Он отличный парень: превосходный музыкант и хорошо разбирается в технических подробностях.

Затем мы наняли администратора, и на этом всё. А потом нам предстояла адская работа в течение двух с половиной лет! [смеётся]

Выбор между движками Unreal и Quake

ДЛ: итак, в то время как остальная часть Ion Storm работала с движком Quake, вы выбрали Unreal. Можете объяснить, как вы пришли к такому решению?

КН: Как бы я ни уважал движок Quake, я знал, что в то время нам бы не было поддержки. Мы создавали очень специфичную игру, в которой мы хотели иметь возможность делать всё, что угодно. Quake был шутером, и ничем бОльшим. Если бы мы попытались делать на нём что-то кроме FPS, то потребовалось бы много труда, а поддержки от Id мы бы не получили. Они просто записывали CD с кодом, давали его разработчикам, и оставляли их в одиночестве.

ДЛ: В моём интервью с Тимом Суини он назвал модель лицензирования движка Quake того времени «операцией xcopy за четверть миллиона долларов».

КН: Да, совершенно верно! Согласен, движок был потрясающим. В то время он произвёл революцию, но мы знали, что команда из трёх инженеров не сможет переписать движок и не сможет написать собственный. У нас просто не хватило бы времени.

В своё время я был большим фанатом демосцены Amiga, C64 и PC. Я начал смотреть видео игры под названием Unreal и подумал «Боже мой, да тут RGB-освещение и полное 3D. Движок использует MMX, SSE и 3DNow. Он выглядит очень круто!» Но нам не удавалось найти о нём подробной информации, поэтому мы запланировали поездку в компанию Digital Extremes в Лондоне (Канада). Мы встретились с Тимом и его командой, они показали нам все возможности движка. Ещё я встретился с Карло Фогельсангом, с которым сейчас работаю в Sony — он в отделе Playstation. Он написал Galaxy Audio Engine: почти всё на ассемблере, суперхардкорный парень. В движке была система частиц под названием Fire. Всё это было внутри движка. Я подумал: «Ребята, мне нравится ваш подход».


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

Поэтому мы решили: «У этих ребят хорошие инструменты, все очень нам помогают, тут есть куча олдскульных ребят, которые в 80-х писали хардкорные штуки. А как у вас устроено лицензирование?» Они ответили: «Мы раньше этим никогда не занимались, для нас это что-то новое». Думаю, что в то время они не понимали, как создать модель лицензирования. Мы сказали: «У нас есть Уоррен Спектор, и он хочет создать на вашем движке игру». Когда они это услышали, то стало ясно, что им очень захотелось поработать с нами.

Честно говоря, я не помню подробностей нашего лицензионного соглашения. Вероятно, Тим помнит. Я не помню, сколько мы заплатили, но не думаю, что очень много".

ДЛ: Вероятно, сравнимо с тем, сколько Id в то время запрашивала за Quake?

КН: Думаю, меньше! И это был ещё один плюс. Их движок был относительно новым, но мы не были первыми лицензиатами. Одними из первых были Wheel of Time и Klingon Honor Guard.

[Примечание автора: подробнее об истории лицензирования Unreal Engine можно прочитать в моём интервью с Тимом Суини об Unreal Editor]

Поэтому мы решили выбрать его. Разработчики дали нам исходный код и сказали: «Мы будем поддерживать вас, как только сможем». Мы всегда общались один на один. Если у нас появлялся вопрос, мы отправляли электронное письмо: не было никакой системы техподдержки.

У нас возникало множество проблем, потому что раньше они никогда таким не занимались. Мы отправляли им очень много кода и вопросов, вели долгую переписку и получали обновления. Но я считаю, что это было верное решение. Думаю, если бы мы выбрали Quake, то игру было бы создать гораздо сложнее.

Кроме того, я стал членом консультативной группы Unreal Tech Advisory Group. Мы пришли к идее первого технического совещания, на котором руководители всех компаний, ставших лицензиатами (в то время их было четверо), собрались все вместе, обсуждали способы усовершенствования движка, ругали Тима за неудобные аспекты, перебрали с алкоголем и едой, ну, всё как обычно. Я до сих пор держу связь со всеми этими людьми.

ДЛ: Делились ли вы чем-то с другими членами Unreal Tech Advisory Group?

КН: Думаю, в основном мы делились усовершенствованиями Unreal Editor. Движок был отличный, но ему предстоял ещё долгий путь. Потом, когда мы смогли нанять ещё больше дизайнеров и художников, они тоже начали вносить предложения по улучшению рабочих процессов. Мы или реализовывали их сами, или отправляли их команде Unreal, или спрашивали у команды Unreal, смогут ли они сделать это быстрее, чем мы.

Мы внесли множество изменений в основной редактор, но большинство из них относилось только к нашей игре. Мы поделились частью усовершенствований, но большинство других разработчиков занималось совершенно другими играми.

Мне пришлось написать кучу систем, которые, как мне кажется, были первыми в своём роде. По крайней мере, я никогда их не видел. Например, систему смешения анимации; по сути это то, что сегодня называют morph targets или blend shapes. Не припомню, чтобы в то время кто-то делал такое в играх. Возможно, где-то это уже было реализовано, но до широкого распространения Интернета обмениваться информацией было очень сложно.

ДЛ: Можете рассказать об изменениях, которые вы внесли в Unreal Editor?

КН: Одна из систем, которой по непонятным причинам в то время в редакторе не было — это визуализация сплайнов камеры.

В первых версиях UnrealEd нужно было перетаскивать камеру и задавать точки её пути. При этом можно было видеть точки, но не соединения между ними, определявшие путь движения камеры.


ДЛ: Это как игра «соедини точки», но без чисел!

КН: Именно! У сплайна были контрольные точки и дизайнеры не всегда могли понять, как будет выглядеть путь. Они хотели очень точно знать, как камера будет двигаться по пути. Поэтому я добавил эту систему, и она им понравилась.

Это было очень просто. Я имею в виду простоту кода: отрисовать оси координат в каждой основной контрольной точке, а затем отрисовать контрольную точку, чтобы на самом деле видеть, куда она подевалась. Это очень помогло дизайнером, а сделать такую систему было очень просто. Не знаю, почему её пришлось добавлять нам. Наверно, Тим не думал, что она действительно будет нужна.

ДЛ: Это забавно, потому что если вспомнить первую демонстрацию игры Unreal публике, то первое, что видели люди — камеру, летающую вокруг замка, то есть непохоже было, что Epic не создала никаких путей камеры.


КН: Думаю, причина была в том, что многие из их дизайнеров уровней были супертехнарями и они привыкли моделировать подобные вещи в голове. Но индустрия видеоигр постепенно взрослела, поэтому нужно было создавать инструменты для людей с разным уровнем опыта. Не каждый дизайнер был инженером, а уж сегодня и подавно! Это было скорее исключением, чем правилом. Поэтому инструмент должен был стать удобным и простым.

Кстати, я до сих пор не знаю, почему Pawn обозначается головой динозавра.

ДЛ: [смеётся] Да, мы с Тимом обсуждали это в интервью! К слову, пожалели ли вы о каких-то принятых вами технологических решениях?

КН: Мы слишком активно использовали UnrealScript. Это было одной из ошибок. UnrealScript был очень гибким, но уж слишком тормозным. Нам нужно было гораздо больше писать на нативном C, чем на UnrealScript.

Истинный север и фальшивые сбои

[Примечание автора: на этом этапе интервью я открыл Deus Ex Editor (версию для UnrealEd), а также документацию Deus Ex SDK]

ДЛ: В установщике Deus Ex SDK есть папка Docs с парой файлов документации, авторами которых значитесь вы, Роберт Уайт, Шелдон Пакотти, Эл Яруссо и Скотт Мартин. Можете рассказать, кем были эти люди, и над чем они работали?

КН: Эл занимался редактором диалогов. Скотт работал над ИИ. Я занимался… всем. [смеётся] Кроме всего прочего, я был помощником директора и ведущим программистом. Но мы по немногу занимались всем, потому что во всём проекте от начала до конца было всего три инженера.


Крис Норден (внизу слева), Эл Яруссо (справа и вверху от Криса, с часами на руке), Роберт Уайт (в среднем ряду, немного правее центра, в солнцезащитных очках), Шелдон Пакотти (внизу справа) и Скотт Мартин (во втором ряду, крайний справа, тоже в солнцезащитных очках)

ДЛ: В документации к редактору есть раздел, в котором написано «В Unreal нет нативной поддержки вертикальных лестниц, но они добавлены в Deus Ex». Можете рассказать об этом подробнее?

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

В одном из указов Уоррена (потому что дизайн — это закон!) говорилось, что игрок должен иметь возможность выполнить любую миссию любым образом. Ключевой идеей игры было то, что при желании можно пройти её целиком, ни разу не выстрелив. На самом деле у нас это не совсем получилось — есть несколько зон, где нужно пару раз выстрелить, но мы были очень близки.

ДЛ: Думаю, в сиквелах разработчикам это всё-таки удалось.

КН: Да, наверно.

Итак, игрок должен был иметь возможность пройти всю игру, ни разу не выстрелив. Кроме того, он мог пройти всю игру, не занимаясь ничем, кроме как стрельбой. Игрок мог пройти всю игру так, чтобы его ни разу не обнаружил враг. Можно было проходить её совершенно разными способами.

ДЛ: Была ли нехватка вертикальных лестниц одной из тех тем, которые вы обсуждали с Тимом на совещаниях Unreal Tech Advisory Group?

КН: Чтобы ответить, мне нужно найти и посмотреть в коде скриптов, написано ли там «Fuck you, Tim!» [смеётся], потому что именно так мы делали, когда злились — записывали комментарии, чтобы вспомнить об этом позже.

Когда мы начали думать о том, как добавить поддержку вертикальных лестниц, то поначалу рассуждали «давайте создадим геометрию, а потом, возможно, получится проделать хитрые физические трюки, чтобы игрок мог хвататься за перекладины с синхронизированной анимацией». Но после мы решили — ну это всё к чёрту, слишком сложно.

ДЛ: [смеётся]

КН: Нам нужно было сделать это очень быстро, потому что дизайнеры требовали создать эту механику.

Поэтому в результате мне пришлось пойти на адские хаки. В движке была концепция «групп текстур». По сути, это строковая метка, назначаемая определённым типам текстур, чтобы их было проще сортировать. Мы могли запрашивать их в коде. Поэтому мы подумали: «почему бы художникам просто не сделать некоторые текстуры такими, что по ним можно взбираться?». После чего мы просто добавили их в группу текстур, выполняли raycast, чтобы распознавать их, а потом просто с некоторыми ограничениями приклеивали к ним игрока в направлении его движения. Это сработало хорошо, но не всегда идеально, потому что когда игрок забирался на вершину текстуры, в неё больше не испускался луч, и нам нужно было подталкивать игрока вверх и на платформу. То есть решение неидеально, но в результате оно сработало. Это был дешёвый и простой хак.

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


ДЛ: В UnrealEd был очень классный генератор спиральных ступеней [смеётся], а вертикальных лестниц не было.

КН: Да, верно… Кажется, мы ругали дизайнеров за его использование, потому что он создавал дыры в BSP. Лестница выглядела красиво, если ничего не было рядом. Но как только ты начинает делать угловые срезы в BSP, то можешь получить небольшие дыры в BSP, сквозь которые можно провалиться, но самих дыр не видно. Эта функция причиняла много боли и мы запрещали её использовать. Выглядела она хорошо, но была поломана…

ДЛ: В документации также описывается класс под названием DeusExLevelInfo, содержащий информацию о карте (например, является ли она многопользовательской), имя автора карты, место выполнения миссии, номер миссии, и так далее. Но я бы хотел спросить вас о TrueNorth.

КН: [laugh] Это был тип BAM движка Unreal: Binary Angle Measurement (двоичного измерения углов)!

ДЛ: Что это за безумные числа?!

КН: В те времена выполнение операций с плавающей запятой было очень затратным. Железо было слабым, а памяти не хватало. 360 градусов описывались не 8-битным числом, которое бы позволило обеспечить 255 единиц точности, то есть около 1,4 градуса на единицу, чего было бы недостаточно. Тим использовал для ориентаций 16-битное число, что давало большую точность.

Для программиста все эти числа достаточно просты. Это всего лишь степени двойки, никаких проблем, можно вычислять их все в голове. Но у дизайнеров и художников возникали затруднения. Поэтому мы придумали небольшие упрощения, помогающие разработчикам их запомнить.

[Пока мы работали с редактором, Крис добрался до класса Decorations]



КН: Decorations тоже был огромным классом. Все меши, с которыми можно взаимодействовать, являлись decoration. То есть практически всё в игре!

ДЛ: В разделе Decorations документации написано «Предупреждаем, что при изменении некоторых из полей, не указанных ниже, может произойти сбой редактора». Не помните, почему так случилось?

КН: [смеётся] Честно говоря, не помню. Думаю, потому, что Decoration был таким большим классом, и в нём было так много функций Epic, которые взаимодействовали с движком странным образом, что вместо того, чтобы объяснять не понимающему технических тонкостей дизайнеру, почему определённое поле может привести к неожиданному поведению, мы просто говорили «не используй его, иначе редактор крашнется».

ДЛ: [смеётся]

КН: Что-то вроде тактики запугивания. На совещаниях программистов мы задавались вопросом: как объяснить пользователям, что это приведёт к повреждению цепочки BSP, и нужно делать вот это и это? Давайте просто скажем им, что в редакторе случится сбой.

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

ДЛ: Пойдём дальше. В разделе ParticleGenerator написано «Одна из основных функций заключается в том, что его можно включать и выключать с помощью triggers и unTriggers». То есть в версии движка Unreal, с которой вы работали, нельзя было включать и отключать частицы?

КН: В то время нет. Если вы вставляли систему частиц, то она присутствовала постоянно и никогда не отключалась. Мне кажется, что это странный недосмотр.

Во всём остальном система частиц Unreal была потрясающей. Большая часть была написана на ассемблере. Она была процедурной, и написана очень хорошо по сравнению со всем остальным. Дизайнеры её любили. На самом деле, даже чересчур. Можно было убить всю частоту кадров, а они сходили с ума, добавляя всё новые и новые прозрачные слои.

В то время мы всё ещё должны были поддерживать программный рендеринг, тогда аппаратный рендеринг ещё не был широко распространён. Тим обладал потрясающими навыками программирования и написал отличный программный рендерер, он был великолепен.

[Рассматривая разные объекты в игре, я заметил в панели Properties категорию с необычным названием]

ДЛ: Что это за свойство Smell?

КН: Нюх нужен был животным, чтобы брать след. По сути, собаки могут отслеживать узлы запаха. Если я правильно помню, то двигаясь по уровням, игрок мог оставлять узлы запаха, действовавшие в течение определённого времени. Поэтому мы сделали так, чтобы собаки могли его унюхать.

ДЛ: То есть если спрятаться за ящиком, то люди вас не найдут, а собаки смогут...

КН: Именно, потому что так и происходит в реальности, и мы думали, что это будет интересный геймплейный аспект. Однако, кажется, в конце концов его вырезали. Так как не было графической обратной связи, эту концепцию оказалось сложно объяснить игроку.



[Мы открываем уровень Intro, в котором присутствует один из самых знаковых объектов в игре — большой пугающий зал со статуей огромной руки, держащей вращающийся глобус. Её показывают во вступительном ролике игры]

ДЛ: У меня вопрос. Я не вижу зеркала этой геометрии под полом. В других играх зеркала имитировались размещением дублирующей геометрии на обратной стороне пола...



КН: Нет, зеркала были настоящими! Они были очень медленными, поэтому мы просили дизайнеров использовать их редко, тем не менее, это настоящие зеркала.

На самом деле, когда я писал код лазера… [смеётся]

ДЛ: [смеётся] Я вижу, к чему вы клоните...

КН:… мне на самом деле приходилось проверять наличие зеркал. У меня был тестовый уровень, где я тестировал код для всех устройств. Когда я писал код лазерного указателя, то создал отражающий зеркальный дискошар, а затем построил зал с зеркалами по обоим концам. Я взял лазерный указатель, направил его на дискошар, и всё сработало!

Разумеется, частота кадров упала ниже некуда, потому что приходилось выполнять трассировку всех прямых…

Увидеть световую волну: инструмент командной строки LWO23D

[Примечание автора: LWO расшифровывается как Lightwave Object. Это формат 3D-геометрии программного пакета Lightwave 3D компании Newtek, тоже находившейся в Техасе, как и команда Deus Ex в то время]



Скриншот из Tack's Deus Ex Lab

ДЛ: Почему ваша команда решила использовать Lightwave?

КН: Его хорошо знали наши художники. Поэтому нам пришлось приспосабливаться.

ДЛ: Расскажите подробнее, почему вы написали экспортёр как инструмент командной строки

КН: В то время, да и сейчас я часто пишу небольшие инструменты командной строки для автоматизации задач. Я олдскульный программист и не люблю ненужные усложнения. Мне по большей части не нравится C++. Мне не нравятся шаблоны. Мне не нравится всё то, что тратит время.

Когда я пишу инструменты командной строки, то создаю командный файл Win32, избавляюсь от всего встроенного, начинаю с пустого файла, с int main(), и просто двигаюсь дальше. Это быстрое и портируемое решение, которое не доставляет проблем.

ДЛ: Думаю, что экспорт статических мешей был довольно стандартным процессом. Но расскажите о том, как вы экспортировали анимацию.



Скриншот из Tack's Deus Ex Lab

КН: В игре не было скелетной анимации. Я не знаю ни одного движка той эпохи, в которой она реализована. Поэтому всё выполнялось смешением вершин. В то время скиннинг был очень затратным. Никаких GPU, всё нужно было вычислять на ЦП и любыми средствами избегать вычислений с плавающей запятой.

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

ДЛ: То есть в игре Unreal всё делалось так же?

КН: Наверно да. Не думаю, что Тим добавил скелетную анимацию до следующей версии.

Говорящие головы: ConvEdit и липсинк

[Теперь мы открываем папку ConvEdit]


ДЛ: Расскажите о ConvEdit

КН: Это было детище Эла, он написал его на Visual Basic.

ДЛ: Как и UnrealEd в то время.

Да, в те времена было не так много возможностей простой реализации интерфейса. Был Delphi и несколько других UI-фреймворков. Если не использовать их, то приходилось писать это всё нативно, например на Win32 API, GDI, и всём подобном. Это была огромная проблема.

То есть Visual Basic, который сегодня кажется довольно примитивным, в то время был очень хорош — простой визуальный фреймворк с собственным языком программирования, похожим на Basic, предшественником C#. Он позволял нам очень быстро прототипировать функции и писать инструменты.

[Примечание: Если вас интересует, как Visual Basic использовался в инструментах для разработки игр той эпохи, то прочитайте моё интервью с Тимом Суини об Unreal Editor]

В основном его использовал Шелдон. Ему нужны были инструменты для управления камерой, инструменты для управления звуками. Он хотел использовать множество кинематографических инструментов, которые до него никто не применял. Я впервые узнал, что такое rostrum zoom, работая над этой игрой с Шелдоном.

Думаю, даже сегодня этот инструмент по-прежнему используется.

Кстати, у Шелдона был туннельный синдром запястья (RSI, Repetitive Strain Injury), поэтому печать стала для него пыткой. Он почти полностью работал над Deus Ex с помощью транскрипции голоса в пакете Dragon Dictate, который в то время был гораздо хуже сегодняшнего. Шелдону даже приходилось носить ортезы, потому что синдром был очень сильным.




ДЛ: Ого! Я и не знал. В игре было множество диалогов и куча ветвлений...

КН: Огромный объём данных даже для одной миссии.

Шелдон хотел иметь сильный контроль над игрой и множество интерактивных диалогов. Он хотел, чтобы игрок совершал значимый выбор. Они с Уорреном ненавидели, когда нужно было прощёлкивать диалоги, не имея возможности выбора. Они хотели, чтобы игрок взаимодействовал с персонажами и выбирал значимые вещи, чтобы игра проставляла флаги и запоминала, как он общался с персонажами и вёл себя при прохождении.

ДЛ: Из первого прохождения Deus Ex я помню брифинг Анны Наварре в её офисе. Как и обычно в любой видеоигре, я начал бегать по офису, занимаясь всякой ерундой, пока NPC закончат свой диалог. Внезапно она прекратила свой диалог, повернулась ко мне и спросила: «Какого чёрта ты делаешь?»

КН: [смеётся]

ДЛ: На секунду я замер, и спросил себя: «Это что, на самом деле случилось?» Это было такое значимое для меня с точки зрения погружения в игру событие. Ни в одной игре до этой такого не встречалось. Подозреваю, отчасти это заслуга Conversation Editor.

КН: Одна из заповедей Уоррена гласила: «Если игрок находится в чьём-то офисе, ведёт себя по-скотски и разбивает вещи, то персонаж должен что-то сказать! Он не должен игнорировать игрока, потому что это нереалистично».

ДЛ: Были ли какие-нибудь связанные с катсценами аспекты, для которых оказалось особенно сложно создать инструменты?

КН: У нас было много диалогов, и все они были озвучены. Мы потратили недели в звукозаписывающей студии, записывая диалоги с актёрами. Это означало, что нам нужно задуматься о синхронизации движения губ (липсинке). Я подумал: «Как создать липсинк для такого количества диалогов?» У нас ведь была не только куча фраз, но и несколько языков.

В то время было не так много инструментов, помогающих в липсинке. Большинство разработчиков выполняли предварительную обработку: прогоняли диалог в инструменте, выводили файл с данными, а потом воспроизводили его. Но я решил: «У нас на это не будет времени, а если придётся перезаписывать голос, то нужно будет снова всё перерабатывать».

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

ДЛ: [смеётся]

КН: Я подумал: «Посмотрим, смогу ли я сделать это и всех удивить». Опять же, я не думаю, что кто-то делал нечто подобное раньше, но сегодня эта техника встречается повсюду.

В то время из всего, что я видел, самым близким к такой системе был Half-Life. Разработчики использовали технику Envelope Following, которая в буквальном смысле была такой: открывать и закрывать рот в зависимости от громкости звука. Система работала, но выглядело это не особо реалистично.

ДЛ: По сути, это было «дёрганье челюстью».

КН: Да, точно, именно так.

Помню, я как-то обсуждал с Гейбом Ньюэллом то, как они справились этой задачей, и он сказал: «Ой, да просто используйте Envelope Following, и этого будет достаточно. Всё остальное будет слишком сложным».

Тогда я вернулся домой и начал прикидывать математические вычисления, а потом написал систему, которая выполняла БПФ (быстрое преобразование Фурье). Повторюсь, в то время вычисления с плавающей запятой были очень затратными, и наверно я написал имитирующую их целочисленную аппроксимацию.

Она анализировала в реальном времени короткий отрывок аудиозаписи и извлекала основные частотные составляющие, а потом привязывала их к шести-семи разным фонемам.

Я втихомолку попросил одного из художников смоделировать несколько форм смешивания (blend shapes): мне нужны были «о», «а», закрытые губы и тому подобное. Он спросил, зачем, и я ответил, чтобы он просто сделал это и дал мне данные.



Быстрое преобразование Фурье (изображение из Википедии) и серия фонем Престона Блэра

ДЛ: [смеётся] Похоже, это решение идеально подошло к смешению анимаций, которое вы использовали в Deus Ex.

КН: Да, именно, идеально.

Итак, он дал мне данные, я написал математические вычисления и как смог, вручную, привязал формы. Я не проводил серьёзных исследований, и система была довольно затратной с точки зрения производительности.

Я создал тестовый уровень с огромной головой посередине, и скормил ей пару строк. Я проверил фразу на немецком, на английском, на французском, и всё синхронизировалось идеально. Я подумал: «Чёрт возьми, это потрясающе! На самом деле сработало!»

Я нашёл Уоррена и сказал ему: «Хочу показать тебе кое-что крутое». Похоже, он был ошарашен. [Смеётся] Он спрашивал меня: «Какого чёрта, мы можем вставить это в игру? Это просто потрясающе!»

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

Возможно, стоило её запатентовать. Но я не верю в патенты на ПО, потому что думаю, что это порочная практика…

Ещё у меня вышел большой спор с одним из художественных директоров в Далласе, который хотел использовать эту систему в Anacronox. Она должна была выйти раньше нашей игры. Я сказал: «Я буду не против поделиться, но хочу, чтобы Deus Ex была первой игрой, в которой она появится». Он сказал: «Нет, вы должны отдать её нам!» Он практически орал на нас в зале. Я ответил: «Нет, не должен», и Уоррен меня поддержал. Получилось так, что мы выпустили игру первыми, поэтому это в любом случае было неважно. На самом деле, я думаю, что в результате они самостоятельно реализовали собственную версию системы, потому что мы не захотели её отдавать. Возможно, это было эгоистично, но я хотел, чтобы мы выпустились первыми, чтобы могли демонстрировать эту функцию.

Всё остальное, выпускавшееся Ion Storm, разрабатывалось в Далласе: Dominion: Storm Over Gift 3, Daikatana, Anacronox — всё сделано в Далласе. В Остине создавался только Deus Ex, и там была только наша команда, больше никого. Мы находились в пузыре, довольно сильно изолированы от офиса в Далласе, и это было сделано намеренно. Мы не хотели связываться с кучей… буду откровенным, с кучей всей их фигни. Такое разделение было совершенно намеренным и очень важным для нас. Наша команда и их команды не обменивались технологиями, никаких реальных контактов.

Заключение

ДЛ: Итак, чтобы подвести итог, я хочу спросить: если бы вы могли дать советы читающим эту статью разработчикам инструментов, то что бы сказали?

КН: Прислушивайтесь к своему заказчику. Никогда не пишите инструменты «в вакууме». Как инженер, вы можете думать: «Я могу использовать этот инструмент таким образом, и этот способ наиболее эффективен, поэтому так я его и напишу».

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

ДЛ: Встречались ли вы когда-нибудь с такой ментальностью в командах, с которыми работали? И как вы с этим справлялись?

КН: Нужно просто сказать программистам: «Как вы думаете, почему у пользователя возникает эта проблема? Как считаете, проблема в коде? Или может быть, проблема в структуре экрана? Может быть, шрифт слишком маленький? Неправильный цвет кнопки? Возможно, вы делаете что-то нестандартное?»

Потому что если вы посмотрите на большинство инструментов с профессиональным дизайном, то обычно они достаточно согласованные. Существуют дизайн-руководства по тому, как всё должно работать.

Творческая команда должна иметь возможность использовать эти инструменты. Не должно быть так, чтобы им приходилось читать документацию. В идеальном мире всё должно быть очевидно.

Сегодня существуют дизайнеры UX/UI, но в то время их не было, поэтому нам приходилось создавать дизайн интерфейса самим, но с обратной связью от пользователей.

Поэтому сядьте рядом с пользователями и посмотрите, как они пользуются инструментом. Мы смотрели, как они работают в Lightwave. Когда мы писали первую версию инструмента, то сидели рядом, не подсказывая, что нужно делать, и смотрели на них, делая заметки, типа «возникли трудности с этим» или «им постоянно приходится залезать в меню, чтобы найти то», или «возможно, стоит сделать это горячей клавишей». Просто смотрите на них, учитесь и приспосабливайтесь.

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

Не нужно попадать в классическую ловушку для инженеров: «Мне лучше знать, я записал инструмент, я знаю, как он работает. Если ты не можешь его использовать, то ты просто идиот». Это худшее, что может быть при разработке инструмента.

ДЛ: Превосходный совет. Большое спасибо, Крис!