[Перевод] Каким был первый Unreal Editor
В последнее время стали популярны ретроспективы классических игр, но очень редко вспоминают о классических инструментах разработки. Мне удалось побеседовать с Тимом Суини о первой версии Unreal Editor, или UnrealEd.
BSP и заблуждения: «Нам нужно написать свой редактор»
Дэвид Лайтбоун: Спасибо, что нашли время поговорить со мной, Тим! Давайте начнём с ранних дней Unreal Editor. Я читал, что Джеймс Шмальц, создатель Epic Pinball, показал вам игру, над которой работал, и когда вы увидели её, то предложили создать для неё редактор. Всё верно?
Тим Суини: Точно! Его вдохновила игра Bullfrog Magic Carpet. Джеймс — безумно талантливый разработчик, но он писал код только на языке ассемблера, он не хотел учить C. [смеётся] Таким образом, он написал на чистом ассемблере этот 3D-движок, который рендерил фон рельефа и игровые объекты. Он не хотел создавать редактор, поэтому вручную изготовил BSP-дерево и поместил на этот рельеф капсулу. Когда я увидел это, я сказал: «Нет-нет-нет, Джеймс, Джеймс… нужно делать совсем не так». [смеётся]
Джеймс Шмальц и игра Magic Carpet компании Bullfrog
Я сказал, что напишу редактор, поэтому приступил к созданию интерфейса пользователя Unreal Editor с макета UI в Visual Basic, как ни странно. У него был текстовый командный интерфейс для общения с движком на C++, который выполнял рендеринг. Затем я написал wireframe-редактор, и на этом фундаменте продолжилось развитие.
То есть это был интересный процесс изучения. Я думал, что просто напишу этот редактор и интегрирую его в рендерер Джеймса. Однажды я спросил его: «Можешь прислать мне код? Я хочу понять, как интегрировать рендерер». И он выслал мне 30 тысяч строк ассемблерного кода. [смеётся] В движке 3D-рендеринга были некоторые элементы Epic Pinball и какой-то предыдущий ассемблерный код, который он просто копипастил. Я подумал: «Боже мой, что это за хаос? Я не хочу к этому прикасаться!» [смеётся]
Но я сказал себе, что прежде чем начну разбираться, я просто напишу небольшой инструмент для наложения текстур. Поэтому я прочитал статьи Майкла Абраша о наложении текстур и изучил код, которым поделился Билли Зелснэк. Наложение текстур оказалось довольно простой темой, поэтому я решил: «Попробую со всём этим справиться».
До того, как я реализовал освещение и тому подобное, важной частью магии ранних версий Unreal Editor было создание BSP-дерева в реальном времени. Идея заключалась в том, что можно было менять положение кистей в 3D-пространстве, после чего вся работа по генерации BSP обновлялась полностью в реальном времени.
Предоставляемые этой функцией возможности не укладывались в голове, и просто чтобы показать всю её мощь, я создал этот инструмент для создания торов. Я связался с Джеймсом, который, напомню, строил свои BSP вручную и сказал ему: «Зацени это». Я создал два соединённых тора и вычел их из мира. Он сказал: «Ого, быть того не может! Это потрясающе». Это был настоящий пример программерской упёртости.
ДЛ: Кстати о BSP, насколько я понимаю, Джон Кармак был одним из первых, кто начал использовать BSP в игровых движках и идея работы с BSP была довольно новой для игровой индустрии того времени.
ТС: Кармак написал по-настоящему мощный редактор на NeXT. Я прочитал о нём всю информацию и видел скриншоты, но никогда им не пользовался. В то время я думал: «Ничего себе, Кармак написал BSP-редактор реального времени!» Чего я не понимал, так это что на самом деле он не работал в реальном времени, там существовал процесс предварительной сборки и другие операции. Я этого не знал и думал, что он создал редактор, полностью работающий в реальном времени, поэтому тоже написал такой же. [смеётся]
QuakeEd на NeXT и Джон Кармак
ДЛ: [смеётся] Вы подумали, что он такой мощный, поэтому приняли вызов.
ТС: Да! Многие возможности Unreal возникли из-за недопонимания мной того, что сделали другие люди.
Кроме того, группа бывших демомейкеров Future Crew создали компанию по производству оборудования и выпустили несколько скриншотов с невероятно реалистичным объёмным освещением в сцене внутри помещения. Там были источники освещения с большими сферами вокруг, а объёмное освещение чётко обрезалось всей окружавшей его геометрией. Оно выглядело физически совершенно точной. Я подумал: «Боже, я никогда ничего подобного не видел, мне нужно в этом разобраться!»
Поэтому я начал разбираться и понял, что мне нужно вычислять линейный интеграл от камеры до каждой точки на экране. В колледже я изучал матанализ, поэтому сказал себе: «У меня должно это получиться». Так я вывел формулу для этого с какой-то безумно сложной тригонометрией. Я реализовал её в коде, но она была в сто раз медленнее необходимого. Потом я осознал: «Стоп, я же могу делать эти вычисления в пространстве карты освещения», потому что карта освещения — это дискретизация геометрии на небольшие фрагменты. Я перенёс расчёты в карты освещения и реализовал всё в реальном времени.
Примеры освещения из Unreal на основе карт освещения
Я сделал скриншот и отправил по почте знакомому из Финляндии, который работал в той компании, производящей оборудование. Он ответил: «Ого, это потрясающе! Но наша картинка — это просто рендер из 3D Studio Max, потому что мы не смогли понять, как это сделать в реальном времени». [смеётся]
ДЛ: [смеётся] Да уж!
[Примечание автора: компания, о которой говорит Тим — это Bit Boys]
ТС: То есть Unreal Engine оказался первым движком с объёмным освещением в мире, как я думаю… и он был основан на моём заблуждении.
Это было потрясающее время в ранней истории игровой индустрии, потому что 3D только начинало становиться возможным. Уже было написано несколько программных рендереров, но никто не смог решить крупномасштабные проблемы: как заставить освещение работать в большом мире, как заставить работать геометрию реального времени в большом мире. Этот процесс развития двигался огромными скачками: Кармак реализовывал новые безумные идеи, я реализовывал новые безумные идеи, и мы постоянно выпускали скриншоты того, на что мы способны.
Если взглянуть на это сейчас, то всего за четыре года мы воссоздали примерно 20 лет исследований рендеринга 1980-х и 1990-х, которые раньше были возможны только через предварительные расчёты, а не в реальном времени.
ДЛ: Да, как идея BSP была основана на статье, написанной в 1969 году.
ТС: Именно, ещё до моего рождения!
TurboPascal и Maya: источники вдохновения UnrealEd
ДЛ: Какие источники вдохновения вы использовали при разработке философии дизайна Unreal Editor?
ТС: Было всего несколько источников вдохновения.
Если вы посмотрите на игру ZZT, выпущенную в 1991 году, то увидите базовый набор функций Unreal Engine. В сущности, это игровой движок со встроенной в него игрой. В игре есть небольшой скриптовый язык, который, несмотря на свою простоту, был полностью скриптовым языком, позволявшим писать небольшие игровые скрипты.
[Примечание автора: подробнее о ZZT можно прочитать в книге Anna Anthropy, опубликованной Boss Fight Books]
В игре был интерактивный WYSIWYG-редактор реального времени для создания уровней. Нажатиями нескольких клавиш можно было перемещаться, добавлять уровни и проверять их в игре, а потом перерабатывать их. Такой интерактивный рабочий процесс был ключевой особенностью игры.
ZZT, режим игры и режим редактора
Другим источником вдохновения был Turbo Pascal, ставший первым инструментом разработки, который я по-настоящему полюбил. Это был очень простой в использовании редактор для создания кода и компилирования. Вы просто вводили код, затем через несколько секунд он уже компилировался и вы его запускали. Итеративный процесс создания программ был потрясающим по сравнению с тем, к чему я привык в то время. Если вы посмотрите на реализацию ZZT, то она действительно выглядит как текстовая версия Unreal Engine. Вся модель Unreal была вдохновлена ею.
Существует и ещё один серьёзный источник вдохновения, который привёл к созданию множества элементов дизайна движка: Visual Basic, похожий на написанный компанией Microsoft клон Delphi, то есть версии Object Pascal for Windows с редактированием в визуальном интерфейсе компании Borland. Но я никогда не пользовался Delphi, я работал только в Visual Basic.
Идея заключалась в том, что у пользователя есть редактор форм, он рисует в нём элементы форм, поля и всё подобное, а затем нажимает на них и открывает код. Код появляется сразу же и пользователь просто продолжает вводить его и продолжает работу.
TurboPascal компании Borland
Я перенёс эти принципы в Unreal: можно было просто перетащить объект на уровень, дважды щёлкнуть на него, чтобы открыть редактор скриптов, после чего вводить скрипт и сохранять его. Чтобы начать писать код, создавать трёхмерные объекты и делать всё в реальном времени, достаточно всего нескольких нажатий мышью.
Ещё одним важным аспектом в разработке Unreal стало то, что Epic купила несколько рабочих станций Silicon Graphics, на которых запускалась первая версия Maya. В то время Maya была полным отстоем, но в ней существовал интерактивный 3D-режим с сине-красно-чёрным фоновым пространством, на котором объекты и каркасы отрисовывались в реальном времени. Этого не могла делать ни одна программа на PC; все они застряли в legacy-коде и устаревших шаблонах UI.
Итак, первое, что я сделал, когда начал работать над Unreal Editor — создал чёрный фон с сине-красными линиями, скопировав Maya. Я написал процедуру отрисовки линий и создал трёхмерные каркасные контуры всех объектов. Таким был вдохновивший меня пример, доказавший, что это возможно.
От Visual Basic до Slate: эволюция интерфейса UnrealEd
[Примечание автора: в начале интервью я запустил в виртуальной машине на своём ноутбуке UnrealEd 1. Я дал Тиму мышь, чтобы он смог поработать в нём.]
ТС: Ого, здорово, вы его уже запустили!
ДЛ: Да! Я представил, что версия, которую мы здесь видим, это Visual Basic.
TS: Да, да!
[Примечание автора: создавая уровень с нуля, Тим радовался. Со стороны это казалось встречей давно не видевшихся друзей.]
ДЛ: Что привело вас к использованию Visual Basic для разработки интерфейса первой версии UnrealEd и какие другие варианты у вас были?
Алан Купер и Visual Basic
ТС: Это было в 1995 году. В тот момент фрейворки пользовательских интерфейсов для C++ были просто ужасными. Существовал Microsoft Foundation Classes, который был самым жалким куском API, который можно себе представить. Пользователь начинал рисовать элементы управления окна и фреймворк создавал огромные объёмы кода на C++ с кучами комментариев типа: «здесь мы создаём для вас элемент управления!» Если пользователь перемещал объект, то фреймворк обновлял часть кода, но не другие части, и он постоянно ломался, поэтому я сказал себе: «Больше я к этому не прикоснусь».
Visual Basic был потрясающим средством разработки интерфейса пользователя, в котором можно было очень продуктивно располагать все элементы управления, пункты меню и части UI. Это был самый продуктивный набор инструментов для UI, который я когда-либо видел, в основном потому, что это была очень чёткая взаимосвязанная программа: ты рисовал UI, нажимал на него и добавлял простой код его взаимодействия. Я понял, что так гораздо проще создавать UI, а потом передавать его C++ через интерфейс командной строки, отправляя текст туда и обратно, как способ сериализации данных. Думаю, ситуация не менялась около десятка лет, пока в начале 2000-х не стали появляться достойные UI-тулкиты для C++, такие как Qt и подобные ему.
[Примечание автора: первая версия Visual Basic была разработана Аланом Купером, которого часто называют «отцом Visual Basic». Он также является важной фигурой в области юзабилити и user experience]
UnrealEd 3, в котором присутствовали элементы wxWidgets
ДЛ: Я думаю, что потом, со временем, части редактора стали заменяться другими частями. Как происходила эта эволюция?
ТС: Завершив Unreal Editor 1, я успокоился и занимался целой кучей исследований нового поколения, которые в целом не принесли плодов, пока не появился Уоррен Маршалл, переписавший с помощью wxWidgets части кода Visual Basic редактора Unreal Editor на C++. wxWidgets который в то время был лучшим тулкитом. Это стало фундаментом для фреймворка UI в Unreal Editor 2.
К середине процесса разработки Unreal Engine 2 код Visual Basic совершенно пропал из движка. У нас был более удобный и чистый фреймворк на C++. Таким образом мы получили практически тот же UI, но без языковых сложностей. Но настоящей проблемой стало то, что wxWidgets не развивался и выходили другие UI-тулкиты, поэтому мы продолжали интегрировать их для специальных инструментов. Поэтому ко времени начала цикла разработки Unreal Engine 4 у нас было пять разных UI-тулкитов…
ДЛ: Такое часто случается…
ТС: … в том числе безумные куски WPF, написанные на C# и интегрированные в Unreal Engine 4, которые не работали на Mac, например. Поэтому в тот момент у нас в коде был огромный хаос.
В то же время Ник Атамас создавал прототип нового слоя UI в C++ и со временем мы решили использовать его. Так он превратился в Slate. Так что мы переписали 100 процентов интерфейса пользователя Unreal Engine, избавились от всех подключаемых UI-тулкитов и переделали его в едином стиле. Это позволило нам увеличить масштаб редактора и прийти к тому, что у нас есть сегодня.
Скриншот UnrealEd со Slate UI
Но нам всё равно не удалось достичь того удобства, которое существовало во времена Visual Basic. Даже фреймворк интерфейса пользователя C# был просто огромным нагромождением XML и другого ненужного безумия. Похоже, что каждое новое поколение реализует UI всё более изощрённым способом и становится всё хуже.
Скриншоты и XCopy: важность лицензирования
ДЛ: Какие компании первыми использовали Unreal Editor?
ТС: На ранних этапах, ещё за два года до выпуска у нас уже было два покупателя лицензии: Unreal Engine применяла Microprose, а потом его использовала Legend Entertainment для своего Wheel of Time, а мы обеспечивали им поддержку.
Wheel of Time компании Legend Entertainment
ДЛ: Они тоже помогали вам, правда? Совместная работа была частью этих взаимоотношений.
ТС: Да, их оплата лицензии поддерживала Epic на плаву в процессе разработки Unreal.
В то время я очень серьёзно воспринимал лицензирование, потому что оно позволяло нам оплачивать счета, что привело нас к модели лицензирования движка, совершенно отличавшейся от модели Id. В то время ходила шутка, что лицензирование движка у Id походило на покупку XCopy за четверть миллиона долларов: вы платите четверть миллиона, а они вводят команду DOS XCopy, чтобы передать вам копию исходников… и на этом всё. [смеётся]
ДЛ: [смеётся] Хорошо, так что же привело к продаже лицензии на Unreal Engine компаниям Microprose и Legend Entertainment даже ещё до выпуска Unreal 1?
ТС: Думаю, так произошло потому, что мы ещё на ранних этапах, примерно в 1995 году, выпускали потрясающие скриншоты не только нашей игры, но и скриншоты нашего редактора. Это заставило компании связаться с нами. Нам позвонили из Microprose и сказали: «Мы хотим лицензировать ваш движок!», а мы такие: «Движок? Какой движок? А, наш движок! Он обойдётся вам очень дорого». [смеётся] Вот буквально таким и был разговор.
Одни из самых первых скриншотов Unreal Editor и Unreal
Динозавры и ящерицы: терминология и иконография UnrealEd
ДЛ: К слову о скриншотах: вот один из них, опубликованный в Blue’s News в конце 90-х. Тут заметны незначительные отличия от версии, которая запущена в моей виртуальной машине: например, в верхнем левом углу есть кнопки Play, Help и Epic, которых нет в финальной версии.
Можете рассказать немного об этом?
Скриншот UnrealEd, опубликованный на Blues News в 1998 году
ТС: Это совершенно точно Unreal Engine 1, примерно 1998 года, потому что в нём есть код Стива Полджа, в то время координировавший многопользовательскую игру.
Кнопка «Epic» была просто ссылкой на веб-страницу, которая всем казалась раздражающей, потому что постоянно случайно нажимали и досадовали: «Ай, опять браузер открывается!» [смеётся]
ДЛ: [смеётся] Ну ладно, а можете немного рассказать об иконографии?
ТС: Для всех элементов UI я нарисовал совершенно ужасные иконки, а потом отправил их Дэну Куку, художнику, который занимался графикой для нашего раннего шутера Tyrian.
Ему нужно было нарисовать иконку для элемента Pawn, поэтому он создал шахматную фигуру. Я сказал: «Нет-нет-нет», а он ответил: «Ну ладно, тогда расскажи мне, что такое pawn». Я сказал, что это что-то вроде монстра, что-то очень крутое, поэтому он нарисовал голову непонятного никому существа: говорили, что это динозавр, ящерица, или ещё что-то…, но эти иконки оставалась у нас около десяти лет.
Дэниел Кук и созданные им иконки для UnrealEd. Иконка «Add Pawn» внизу, третья справа.
ДЛ: Мы уже говорили о слове «pawn». Мы сами придумали его, или увидели где-то?
ТС: Думаю, его предложил Стив Полдж или Джеймс Шмальц.
ДЛ: А как насчёт «actor»?
ТС: Кармак придумал свою терминологию, он называл объекты «сущностями» (entities), и я подумал: «Нет, нам нужно что-то уникальное».
ДЛ: [смеётся]
ТС: Мы решили, что у нас будут объекты, обозначаемые как «акторы» (actors), потому что в 1980-х годах в SmallTalk, в который я в то время был влюблён, были предложены принципы программирования на основе модели акторов. Модель была объектно-ориентированной и показалась для нас хорошим началом. Поэтому мы пришли к идее pawns и instigators, определяющих запуск серий событий и ко всей прочей терминологии.
Шмальцизмы и мозговой вуду-вирус: создание UnrealScript
ДЛ: Расскажите подробнее о том, как Джеймс и Стив участвовали в использовании и создании UnrealScript.
ТС: Джеймс Шмальц был уникальным бриллиантом, мастером на все руки. Он был лучшим художником команды, потрясающим дизайнером уровней, а также мог программировать на UnrealScript и ассемблере.
ДЛ: В титрах Unreal его имя встречается в паре совершенно разных категорий.
ТС: Во всей игровой индустрии чрезвычайно мало людей такого уровня таланта и он заслуживает всего полученного успеха.
Но он перешёл от ассемблера к UnrealScript и писал безумный код UnrealScript, в котором просто вбивал строки, пока они продолжали работать, а по вечерам я подходил к нему и упрощал его код. У него были многострочные выражения типа «что-то точка instigator точка бла-бла», а я заменял их на что-то типа… «self». [смеётся]
ДЛ: [смеётся]
ТС: Мы называли такой код «шмальцизмами». А у Полджа в коде встречались магические числа типа «walk speed = run speed x 3.072». Я спрашивал его: «Неужели в физике есть константа 3.072, о которой я не знаю?» [смеётся]
ТС: UnrealScript вдохновлялся Java; в то время этот язык казался наследником C++. Создатели языка скопировали множество конструктивных решений, а поверх добавили множество новых концепций. В UnrealScript существовали зачатки базовых контейнеров, которые появились в Java только несколько поколений спустя.
Я всегда думал, что при разработке языка C# авторы следили за UnrealScript, потому что я увидел некоторые особенности UnrealScript, которые всплыли в C#. Я всегда надеялся на то, чтобы они позаимствовали некоторые из этих идей.
Но чем больше я закапывался в объектно-ориентированное программирование и в SmallTalk, изучал самые современные исследования метаклассов, тем больше я осознавал, что это был своего рода мозговой вуду-вирус, который не имел под собой никаких настоящих теорических обоснований. В свою очередь, если мы посмотрим на Haskell и соответствие Карри-Ховарда, а также другие современные принципы программирования, то увидим источник и структуру для вдохновения.
SoftDisk, Id и чеки на миллионы долларов
ДЛ: Повлияли ли Джей Уилбур и Марк Рейн, с их ориентацией на бизнес и опытом работы с shareware, на движок, инструменты, редактор или ресурсы, которые им были предоставлены?
ТС: На ранних этапах Epic работала благодаря тому, что я занимался технической стороной, а Марк — бизнесом. Марк летал по миру, заключал безумные бизнес-сделки, приносившие нам наличку. Это было очень важно, если бы не он, мы не выжили бы на этих ранних этапах.
Марк Рейн и Джей Уилбур
В какой-то момент мы оказались на мели и все наши траты финансировались с карты American Express Марка, которую у него в результате аннулировали.
ДЛ: [смеётся]
ТС: Тогда он полетел на встречу с TG Interactive и вернулся оттуда с чеком на миллион долларов. Это нас спасло. И так повторялось несколько раз в нашей истории. Очень важно иметь отличных бизнесменов, умеющих договариваться. Он был первым президентом Id, а после Марка Джей стал первым генеральным директором Id.
ДЛ: А до этого он вместе с Кармаком был в SoftDisk, верно?
ТС: Точно! И это забавно, потому что на самом деле свою первую игру ZZT я продал SoftDisk. Именно Джей Уилбур занимался моим договором с SoftDisk. В результате этих переговоров я получил от SoftDisk три тысячи долларов, так что знал Джея очень давно.
Ранние дни Id Software. Джей Уилбур справа.
Работа с ребятами из Id вдохновляла меня с самого начала. Я отправился на какую-то дурацкую shareware-конференцию и там появилась Id. В то время они были любимчиками индустрии, потому что выпустили Wolfenstein 3D, который стал крупнейшим успехом в истории shareware. Они болтали с нами, а потом пригласили на ужин. Было так здорово видеть, что суперзвёзды индустрии оказались простыми скромными ребятами. Джон Ромеро — милейший разработчик игр в мире.
[Примечание автора: Соглашусь. Джон Ромеро потратил очень много своего времени на наше интервью на TEd.]
WYSIWYG и простота использования: самое важное — перспективы инструмента
ДЛ: Итак, в ноябре 1998 года появился выпуск Maximum PC, в котором было интервью с вами, где вы также говорили о разных технологиях, существовавших в то время. В этой статье говорилось, что »[Unreal Editor] на световые годы опережает всех по простоте» и «с технологией Quake сложно работать».
Также там написано: «Технология [Quake III: Arena] на самом деле впечатляет» и «Prey и Trespasser выглядят и работают лучше, чем Unreal. Но если окажется, что с ними сложнее работать, то разработчики останутся с Unreal».
То есть была ли у вас цель с самого начала создать инструмент, конкурентное преимущество которого — простота использования?
Maximum PC, ноябрь 1998 года
ТС: Да, совершенно верно. Знаете, это всегда было для меня важнее всего: написать редактор, позволяющий дизайнерам уровней создавать потрясающие творения. С самого начала было понятно, что важнейшим аспектом этого является работа в реальном времени и сверхбыстрые итерации дизайна, полная реализация принципа «что видишь, то и получаешь» («what-you-see-is-what-you-get», WYSIWYG). Тогда ты будешь ограничен только своим воображением и способностью придумывать новые идеи. Для нас, компании Epic всегда были очень важны инструменты.
ДЛ: Какой процесс использовался Epic, чтобы обеспечить большое внимание, вложения времени и труда в упрощение использования инструментов?
ТС: Процесс разработки в Epic — это сочетание команды разработчиков движка, создающей системы, функции и инструменты, и игровой команды, потребляющих всё это для создания игр. У нас используется итеративный процесс, когда команды разработки движка создают новые идеи, а затем делятся ими с игровыми командами и получают постоянную обратную связь о том, что работает, а что нет. Именно так создавался наш техпроцесс: то, что разработчики инструментов должны были помогать разработчикам игр, позволяло им быть честными.
Мы не только хотели создавать простые в использовании инструменты, но и убедиться, что они обеспечивают правильные компромиссы, которые действительно позволяют создавать контент, необходимый для выпуска игры.
Это оборотная сторона простоты использования. Невозможно считать простоту использования отдельной концепцией. Плохо, когда инструменты очень просты в использовании, когда вы начинаете создавать игру, но ими очень сложно завершить создание игры, потому что они ограничивают рабочий процесс или функционал.
Если посмотреть на последние пять-шесть лет развития движков, то конкуренция между Epic и Unity определяется первоначальной простотой использования, в чём у Unity есть преимущество. В то же время в цикле разработки выпуска игры с точки зрения производительности на разных платформах преимущество имеет Unreal. Так происходит потому, что мы нацелены на то, чтобы иметь возможность выпускать игры эпического (epic) масштаба, то есть такие, какие делаем мы. На самом деле это намного сложнее, чем упростить работу трёх человек, быстро выпускающих что-то простое.
Сегодня размер кода Unreal Engine примерно в 20 превышает код Unreal Engine 1. Инструменты стали раз в десять сложнее, и на то есть причины. Люди запускают Unreal и теряются, потому что опций меню так много. Тогда они переходят на Unity и видят, что всё мило и просто. А потом они доходят до этапа, когда нужно выпускать продукт, и оказывается, что нужно покупать лицензию на исходный код, чтобы добавить в движок функции, которых нет в меню. Вот такая существует дихотомия.
Источник вдохновения и наследие: влияние UnrealEd
ДЛ: UnrealEd вдохновил некоторых разработчиков игр, в том числе и меня, не только начать создавать игры, но и писать собственные инструменты. Как вы считаете, какое влияние UnrealEd оказал на индустрию?
ТС: Думаю, каждый существующий сегодня редактор игр позаимствовал что-то от UnrealEd. Это был один из первых редакторов, мы приняли множество правильных фундаментальных решений, например то, как пользователь должен работать с 2D-сетками, размещением объектов и перемещением по миру. Думаю, можно отследить наследственность, передаваемую от первого редактора Doom к редактору Quake, а потом и к Unreal. Сегодня всё в какой-то степени основано на этом.
Схема истории движков FPS из Wikipedia. Нажмите, чтобы открыть более крупную версию.
На некоторые аспекты повлияли общие принципы, например, Maya, но некоторые достаточно конкретно связаны с Unreal — способ структурирования иерархий классов, реализация системы отмены (undo) и все другие серьёзные проблемы разработки игр. Все, кто пришёл в индустрию в начале 2000-х, обычно проходили или через Unreal, или через Quake. Даже несмотря на то, что Quake была гораздо более крупной игрой, мне кажется, что большинство дизайнеров пришло через UnrealEd, потому что его инструменты были очень удобными.
Умножение и деление производительности: советы разработчикам игр
ДЛ: В 2011 году вы дали Kotaku интервью. Я зачитаю несколько цитат, которые, как мне кажется, относятся к нашей теме:
«Мы всегда подходили к разработке игр с точки зрения инструментов. Мы создавали нужные нам инструменты, создавали дружественный к пользователю набор инструментов и продолжали работу с ним».
«Мы в Epic думаем далеко вперёд. Мы как Intel. Мы думаем над тем, что будем делать через пять-десять лет и выбираем соответствующие направления развития, в то время как для большинства компаний предел планирования — выпуск следующей игры. Они вкладывают все свои ресурсы в это, а потом занимаются следующей игрой».
«Большие игровые компании, такие как EA или Activision не вкладываются в инструменты, у них нет такого долгосрочного планирования, как у нас, и нашего осознания того, что нужно сделать процессы разработки игр как можно более эффективными».
В моём интервью с Джоном Ромеро он очень хорошо ухватил это, сказав: «Инструменты живут дольше, чем игры».
Какой совет вы можете дать разработчикам игр, чтобы они могли избежать этой ошибки и поняли долгосрочную ценность вложений в инструменты?
ТС: Ну… не нужно «вроде бы» создавать движок. Или собирайте движок, или не делайте этого. Сейчас так много компаний калечат свои процессы производства, создавая движки с никуда не годными инструментами. Именно инструменты убивают людей.
Посмотрите на все эти движки, создаваемые внутри компаний… Например, у Frostbite есть более продвинутые функции рендеринга, чем у нас, и во многих случаях он рисует более красивые пиксели, чем у нас, но Unreal-разработчики могут создавать контент гораздо более продуктивно, примерно на 30–50 процентов продуктивнее. То есть команда может вдвое меньшими силами создать игру такого же качества. Она может совершать больше итераций и оттачивать игру лучше, чем с помощью менее качественных инструментов. Поэтому всем нужно принять осознанное решение — или полностью инвестировать в создание отличных инструментов для внутреннего использования, или использовать сторонние движки.
ДЛ: Потому что вы считаете, что из-за полумер страдают разработчики?
ТС: Да. Где-то внутри этих компаний сидят невероятно тупые бухгалтеры, думающие так: «О, ограничив траты на разработку инструментов, мы сможем сэкономить два процента бюджета». В результате это приводит к увеличению бюджета на 50 процентов, потому что в создание игры приходится вкладывать значительно больше времени и труда. Поэтому это создаёт такую безумную, не оправдывающую средств экономию.
Я думаю, что каждая компания должна принять решение — или вкладывать значительно больше в инструменты, или вообще не заниматься ими.
И это относится ко всему. Не только к 3D-редактору для создания уровней, но и к системам сборки, к языку программирования, техпроцессу разработки, инструментам DCC, ко всему этому.
Инструменты должны увеличивать производительность, и если оказывается, что они её снижают, то от них нужно избавляться.
ДЛ: Отлично. Спасибо, что нашли время пообщаться со мной.
