Хабрахабр

[Перевод] Киберпанк 2000: инструменты создания Deus Ex

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

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

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

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

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

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

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

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

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

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

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

У компании были потрясающие игры, но продавались они слабовато. По финансовым и иным причинам 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, но это уже другая история.

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

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

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

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

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

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

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

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

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

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

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

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

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

В то время они сосредоточились на создании сверхудобных инструментов, которых раньше никто не делал. Инструменты 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. Нам нужно было гораздо больше писать на нативном C, чем на UnrealScript. 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, сквозь которые можно провалиться, но самих дыр не видно. Выглядела она хорошо, но была поломана…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Примечание автора: 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, всё нужно было вычислять на ЦП и любыми средствами избегать вычислений с плавающей запятой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»