Каким был первый Unreal Editor?

Статья взята с ресурса habr.com

В последнее время стали популярны ретроспективы классических игр, но очень редко вспоминают о классических инструментах разработки. Мне удалось побеседовать с Тимом Суини о первой версии 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, ко всему этому.

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

ДЛ: Отлично. Спасибо, что нашли время пообщаться со мной.

Статья взята с ресурса habr.com

Присоединяйтесь к нам в Инстаграм

October 4, 2018
by CONCEPT.ART
0
14

Дайджест разработки на Unreal Engine

Игры на Unreal Engine, разработка на Unreal Engine, туториалы для Unreal Engine и другие интересные материалы об Unreal Engine вы найдете в этом дайджесте. Самое главное – дайджест посвящен Unreal Engine.

Игры на Unreal Engine

Ремейк Final Fantasy VII на Unreal Engine 4. 

Така Кавасаки из Epic Games Japan о выходе ремейка Final Fantasy VII.

Как могла бы выглядеть The Legend of Zelda: Ocarina of Time на UE 4.

Современный вариант классической игры GoldenEye 007 на Unreal Engine 4.

Вышел ремейк Metal Gear Solid под названием Shadow Moses на движке Unreal Engine 4. 

Игра ARK: Survival Evolved от египетской студии Instinct Games. 

Новая игра от Джона Ромеро и Адриана Кармака. 

Battlefleet Gothic: Armada – успешная адаптация настольной игры.

Постмортем игры Bulletstorm Exclusive от компаний People Can Fly и Epic Games.

Реализация Castlevania на Unreal Engine 4.

Nexon делают Final Fantasy XI на Unreal Engine 4.

Очередной трейлер и новый подзаголовок Hellblade.

Crazy Killer – онлайн-экшн по мотивам игры «Мафия».

Фанатский ремейк Star Wars: Knights of the Old Republic на движке Unreal.



Обучение

Фреймворк на Unreal Engine 4 для разработки квестов на C++.

Сайт Shooter Tutorial, посвященный разработке шутера на Unreal Engine 4.

Начало работы с VR на Unreal Engine 4.

Подборка видеоуроков по созданию игр на Unreal Engine.

Кастомный SoundNode для мультиплеера.

3D Model Viewer для инвентаря.

Как открыть сайт в игре при помощи Trigger Box?

Открываем сайт в игре при помощи кнопок Unreal Motion Graphics.

Создаем искусственный интеллект, способный к восприятию.

Использование таймлайнов с помощью С++.

Использование делегатов.

Поясняем лямбда-выражения.

Construction Script, основанный на С++.

Обработка анимации в C++.

Входные данные с различными параметрами.

Actor Spawn и функция GetDefaultObject.

Использование Unreal Motion Graphics на C++.

Создание искусственного интеллекта, который может слышать.

Создаем инвентарь.

Создаем комбинации рукопашного боя на С++.

Создание базовой диалоговой системы на С++.

Реализация многопоточности на UE4.

Создаем классы интерфейсов на UE4 при помощи С++.

Создаем консольные команды.

Используем рефлексию в Unreal Engine.

Создаем различные назначения действий с параметрами.



Это интересно


Видео: как разрабатываются игры на Unreal Engine в виртуальной реальности.

Создание звуков тяжелой брони для InSomnia Project.

Доклад от Epic Games «Состояние Unreal» на GDC 2016.

BMW используют виртуальную реальность и движок Unreal Engine 4 для разработки новых транспортных средств.

Видео: как Epic Games создали свое техническое демо ProtoStar.

Впечатления от редактора Unreal Engine для VR.

«Цифровые люди»: о разработке Uncanny Valley в UE4.

The Wiz – трансформируемый беспроводной контроллер.

Архитектурная визуализация на Unreal Engine: в каких отраслях могут пригодиться игровые движки?

October 3, 2018
by CONCEPT.ART
0
50

Создаём простейшую VR-демку с Unreal Engine

По мере того, как виртуальная реальность становится мейнстримом, всё больше разработчиков игр изъявляют желание создавать новый контент для устройств вроде HTC Vive и Oculus Rift. Из доступных движков особенно выделяются два: Unreal Engine and Unity3D. В этой статье мы рассмотрим процесс разработки маленькой демки на основе Unreal Engine. Мы делаем уровень, по которому можно будет свободно перемещаться, а также брать или уничтожать объекты.

Что такое Unreal Engine?

Это игровой движок, созданный в компании Epic Games в 1998. Сначала он использовался для создания шутера Unreal, и с тех пор на базе движка был создан целый ряд больших и сложных игр (в том числе Unreal Tournament, Bioshock, Mortal Kombat X и многие другие). Unreal Engine предоставляет программистам два набора инструментов: традиционный C++ и систему визуального скриптинга Blueprints, позволяющую быстро разработать игровую логику.

Поддержка VR появилась с четвёртой версии, в 2012 году. Первое поддерживаемое устройство — Oculus Rift DK1. Сегодня движок работает уже со всеми основными устройствами.

До марта 2015 года разработчикам нужно было покупать лицензию, но затем движок стал бесплатным. Единственное условие — если прибыль от игры, созданной на Unreal Engine, превысит $3000, нужно отчислять 5% роялти.

Альтернатива

В качестве альтернативы, для создания VR-игр можно использовать движок Unity3D. Он более молодой и изначально затачивался под мобильные игры, хотя и 2D-функциональность в нём очень развита. А благодаря своей популярности и гибкости, движок активно используется для создания десктопных игр и VR-контента. Создавать игры в Unity3D можно с помощью C#JavaScript или Boo. Как в случае с Unreal, движок бесплатен.

Для этой статьи я выбрал Unreal Engine, чтобы показать процесс создания десктопной игры, которая будет работать на наиболее продвинутых VR-устройствах. Также этот движок позволяет очень быстро делать прототипы.

Почему стоит разрабатывать VR-продукты?

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

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

Выбор устройства

Я выбрал HTC Vive, потому что:

  • Мы создаём демку для десктопов (это автоматически исключает из рассмотрения мобильные устройства вроде Samsung Gear VR, Google Daydream и так далее).
  • HTC Vive позволяет использовать roomscale (Oculus Rift тоже скоро обзаведётся такой возможностью).
  • HTC Vive уже имеет два контроллера перемещения (Oculus Rift Touch нужно покупать отдельно)

Поскольку мы хотим использовать контроллеры для взаимодействия с объектами, выбор HTC Vive очевиден.

Настройка VR

Берём очки HTC Vive, мощный компьютер и проходим по чек-листу:

  1. Проверить, что всё правильно подключено. Инструкция.
  2. Установить Steam и SteamVR.
  3. Проверить, чтобы были обновлены прошивки на очках и всех контроллерах.
  4. Запустить “Room setup” и “Tutorial” для настройки roomscale. Проверить, что всё работает корректно.
  5. Скачать и установить Unreal Engine (версия 4.13.2).

Теперь можно приступать к демке.

Реализация демки

Перед началом разработки нужно вооружиться знаниями о том, как работать с Blueprint’ами. Мы по шагам разберём процесс создания нового проекта, настройки уровня и создания простой игровой логики, чтобы можно было указать на объект, нажать на спуск и уничтожить его.

Запускаем Unreal Engine и переходим на закладку New project. В разделе Blueprint выбираем Virtual Reality. В настройках проекта (Project setup) выбираем Desktop/consoleMaximum Quality(максимальное качество) and No starter content (без начальных данных), а в Location (расположение) прописываем путь к файлам проекта.

Переходим в меню плагинов, и подтверждаем в Virtual Reality, что у нас включён плагин “SteamVR”.

В браузере данных (content browser) переходим в папку VirtualRealityBP/maps и открываем “MotionControllerMap”.

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

Для этого в VirtualRealityBP/Blueprints откроем Blueprint “MotionControllerPawn”.

Вызовем событие “MotionController ® Trigger” для правой руки и зададим булево значение (true/false) для нажатия и отпускания кнопки спуска:

Для события Tick создадим линию прицеливания (linetrace), чтобы знать, на какой объект мы наводимся. Для этого нужно задать начальную и конечную точки. Для начальной точки мы связываем Right ControllerMotion Controller и получаем GetWorldLocation.

Также с Motion Controller связываем Get Forward Vector. Таким образом мы будем получать направление прицеливания контроллером. Умножаем этот вектор на необходимую дистанцию (скажем, на 1000 = 10 метров) и добавляем к начальному местоположению, тем самым получив конечную точку.

Добавляем модуль LineTraceByChannel, соединяем начальную и конечную точки, во вкладке Draw Debug Type выбираем One Frame. Этот параметр означает отрисовку линии между начальной и конечной точками.

Далее переходим к выходным данным Break Hit Result, для Hit Actor делаем переход Cast to BP_PickupCube. Это означает, что на уровне мы можем выбирать только синие кубы.

Теперь кидаем ветку и проверяем булево значение для ранее созданного Can Destroy. Если оно равно false, то мы ничего не делаем. Если true, то вызываем модуль DestroyActor для уничтожения выбранного объекта.

Готово. Можно нажать кнопку Play, выбрать VRpreview и испытать своё творение.

Заключительное слово

Как видите, всё просто. Движок предлагает нам заготовки контента, которые сильно облегчают новичкам первые шаги. Более того, Unreal позволяет нам дистанцироваться от оборудования (например, нам не нужно думать об отслеживании устройств или о том, как рендерить изображение в очках). Это позволяет сосредоточиться на самом контенте.

По моему опыту, Blueprint’ы — прекрасный способ создания игровой механики в несколько кликов. На основе созданной нами демки вы можете легко разобраться в процессе VR-разработки на движке Unreal, осваивая всё более сложные схемы и игровые активности. Пришло время создавать будущее виртуальной реальности.

October 3, 2018
by CONCEPT.ART
0
17
Show more