What was the first Unreal Editor

Recently, retrospectives of classic games have become popular, but they rarely recall classic development tools. I managed to talk with Tim Sweeney about the first version of the Unreal Editor , or UnrealEd .

BSP and delusions: “We need to write our own editor”

David Lightbone: Thanks for taking the time to talk to me, Tim! Let's start with the early days of the Unreal Editor. I read that James Schmalz, the creator of Epic Pinball , showed you the game he was working on, and when you saw it, you were asked to create an editor for it. All right

Tim Sweeney: Exactly! He was inspired by the game Bullfrog Magic Carpet . James is an incredibly talented developer, but he wrote code only in assembly language, he didn’t want to teach C. [laughs] Thus, he wrote this 3D engine in a clean assembler, which rendered the background of the terrain and game objects. He did not want to create an editor, so he manually made a BSP-tree and placed a capsule on this relief. When I saw this, I said, "No, no, no, James, James ... you need to do something wrong." [laughs]



James Schmalz and Bullfrog Magic Carpet

I said that I would write an editor, so I started creating the Unreal Editor user interface from the UI layout in Visual Basic, oddly enough. It had a text command interface for communicating with the C ++ engine that rendered. Then I wrote a wireframe editor, and development continued on that foundation.

That is, it was an interesting learning process. I thought I would just write this editor and integrate it into the renderer of James. Once I asked him: “Can you send me a code? I want to understand how to integrate the renderer. ” And he sent me 30 thousand lines of assembly code. [laughs] In the 3D rendering engine there were some elements of Epic Pinball and some previous assembly code that he just copy-paste. I thought, “My God, what is this chaos? I don't want to touch this! ”[Laughs]

But I told myself that before I started to figure it out, I would just write a small tool for applying textures. Therefore, I read Michael Abrash 's articles about texture mapping and studied the code shared by Billy Zielsnack. Texture mapping turned out to be a rather simple topic, so I decided: “I will try to cope with all this”.

Before I implemented lighting and the like, an important part of the magic of earlier versions of Unreal Editor was creating a BSP tree in real time. The idea was that it was possible to change the position of the brushes in 3D space, after which all the work on generating BSP was updated completely in real time.


The features provided by this function did not fit in my head, and just to show all its power, I created this tool for creating tori. I contacted James, who, I recall, built my BSP by hand and told him: "Check it out." I created two connected tori and subtracted them from the world. He said, “Wow, that can't be! This is amazing". It was a real example of programmatic obstinacy.

JL: Speaking of BSP, as I understand it, John Carmack was one of the first to start using BSP in game engines and the idea of ​​working with BSP was quite new for the gaming industry of the time.

TS: Carmack wrote a really powerful editor on NeXT . I read all the information about it and saw screenshots, but I never used it. At that time I was thinking: “Wow, Carmack wrote a real-time BSP editor!” What I didn’t understand was that it actually didn’t work in real time, there was a pre-assembly process and other operations. I did not know this and thought that he had created an editor that works completely in real time, so I also wrote the same one. [laughs]



QuakeEd on NeXT and John Carmack

JL: [laughs] You thought he was so powerful, so you accepted the challenge.

TS: Yes! Many of the possibilities of Unreal have arisen because of my misunderstanding of what other people have done.

In addition, a group of former demo-makers Future Crew created a equipment manufacturing company and released several screenshots with incredibly realistic surround lighting in an indoor scene. There were sources of illumination with large spheres around, and the volumetric illumination was clearly cut off by the whole surrounding geometry. It looked physically completely accurate. I thought, “God, I have never seen anything like this, I need to figure it out!”

Therefore, I began to understand and realized that I need to calculate the linear integral from the camera to each point on the screen. In college, I studied mathematical analysis, so I said to myself: “I have to succeed in this.” So I derived a formula for this with some incredibly complex trigonometry. I implemented it in code, but it was a hundred times slower than necessary. Then I realized: “Stop, I can do these calculations in the lightmap space,” because the lighting map is the discretization of the geometry into small fragments. I transferred the calculations to the lighting maps and realized everything in real time.



Unreal lighting examples based on lighting maps

I took a screenshot and mailed a friend from Finland who worked for the company producing the equipment. He replied: “Wow, this is amazing! But our picture is just a render from 3D Studio Max, because we could not figure out how to do it in real time. ” [laughs]

JL: [laughs] Yeah!

[Author's Note: The company Tim talks about is the Bit Boys ]

TS: So the Unreal Engine turned out to be the first engine with surround lighting in the world, as I think ... and it was based on my mistake.

It was a terrific time in the early history of the gaming industry, because 3D was just beginning to become possible. Several software renderers have already been written, but no one was able to solve large-scale problems: how to make lighting work in a big world, how to make real-time geometry work in a big world. This development process was moving in huge leaps: Carmack implemented new crazy ideas, I implemented new crazy ideas, and we constantly released screenshots of what we are capable of.

If you look at it now, in just four years we have recreated about 20 years of rendering research in the 1980s and 1990s, which were previously possible only through preliminary calculations, and not in real time.

JL: Yes, as the BSP idea was based on an article written in 1969.

TS: Exactly before my birth!

TurboPascal and Maya: UnrealEd Sources of Inspiration

JL: What sources of inspiration have you used when developing the Unreal Editor design philosophy?

TS: There were only a few sources of inspiration.

If you look at the game ZZT , released in 1991, you will see the basic set of features of the Unreal Engine. In essence, this is a game engine with a game built into it. The game has a small scripting language, which, despite its simplicity, was a fully scripting language that allowed writing small game scripts.

[Author's note: read more about ZZT in the book Anna Anthropy , published by Boss Fight Books]

The game had a real-time interactive WYSIWYG editor for creating levels. Pressing a few keys could move, add levels and check them in the game, and then recycle them. Such an interactive workflow was a key feature of the game.



ZZT, game mode and editor mode

Another source of inspiration was Turbo Pascal , which was the first development tool I really loved. It was a very easy to use editor for creating code and compiling. You simply entered the code, then after a few seconds it was already compiled and you ran it. The iterative process of creating programs was amazing compared to what I was used to at the time. If you look at the ZZT implementation, then it really looks like the text version of the Unreal Engine. The whole Unreal model was inspired by her.

There is another serious source of inspiration, which led to the creation of a variety of engine design elements: Visual Basic, similar to Microsoft's Delphi clone, that is, the version of Object Pascal for Windows with editing in the Borland visual interface. But I never used Delphi, I only worked in Visual Basic.

The idea was that the user has a form editor, he draws form elements in it, fields and everything like that, and then clicks on them and opens the code. The code appears immediately and the user simply continues to enter it and continues to work.



Borland's TurboPascal

I transferred these principles to Unreal: you could simply drag the object to the level, double-click on it to open the script editor, then enter the script and save it. To start writing code, create three-dimensional objects and do everything in real time, just a few mouse clicks are enough.

Another important aspect in the development of Unreal was that Epic bought several Silicon Graphics workstations, where the first version of Maya was launched. At that time, Maya was completely sucked, but it had an interactive 3D mode with a blue-red-black background space in which objects and frames were rendered in real time. No PC program could do this; they are all stuck in legacy code and outdated UI templates.



So, the first thing I did when I started working on the Unreal Editor was to create a black background with blue and red lines, copying Maya. I wrote a procedure for drawing lines and created three-dimensional frame contours of all objects. Such was the example that inspired me, which proved that it was possible.

From Visual Basic to Slate: UnrealEd Interface Evolution

[Author's note: at the beginning of the interview, I launched in a virtual machine on my laptop UnrealEd 1. I gave Tim a mouse so that he could work in it.]

TS: Wow, great, you already launched it!

JL: Yes! I imagined that the version we see here is Visual Basic.

TS: Yes, yes!

[Author's note: creating a level from scratch, Tim was happy. From the outside, it seemed like a meeting of friends who had not seen each other for a long time.

JL: What led you to use Visual Basic to develop the interface of the first version of UnrealEd and what other options did you have?



Alan Cooper and Visual Basic

TS: It was in 1995. At that moment, the user interface frameworks for C ++ were just awful. There was a Microsoft Foundation Classes, which was the most miserable piece of API you can imagine. The user started drawing window controls and the framework created huge amounts of C ++ code with lots of comments like: “here we create a control for you!” If the user moved an object, the framework updated part of the code, but not other parts, and it constantly broke, so I said to myself: "I will not touch this again."

Visual Basic was a terrific user interface design tool in which all the controls, menu items, and parts of the UI could be very productive. It was the most productive toolset for UI that I’ve ever seen, mainly because it was a very clear and interconnected program: you drew the UI, clicked on it and added simple code for its interaction. I realized that it’s so much easier to create a UI, and then pass it to C ++ through the command line interface, sending text back and forth as a way to serialize data. I think the situation has not changed for about a dozen years, until in the early 2000s decent UI-tools for C ++ began to appear, such as Qt and the like.

[Author's Note: The first version of Visual Basic was developed by Alan Cooper , who is often called the " father of Visual Basic ." He is also an important figure in usability and user experience]



UnrealEd 3 with wxWidgets elements

JL : I think that later, over time, parts of the editor began to be replaced by other parts. How did this evolution happen?

TS: After completing Unreal Editor 1, I calmed down and was engaged in a whole bunch of research of the new generation, which generally didn’t bear fruit until Warren Marshall showed up, rewrote parts of Visual Basic editor in C ++ using wxWidgets . wxWidgets which at the time was the best toolkit. This became the foundation for the UI framework in Unreal Editor 2.

By the middle of the Unreal Engine 2 development process, the Visual Basic code completely disappeared from the engine. We had a more convenient and clean C ++ framework. Thus, we got almost the same UI, but without language difficulties. But the real problem was that wxWidgets did not evolve and other UI toolkits came out, so we continued to integrate them for special tools. Therefore, by the time the Unreal Engine 4 development cycle began, we had five different UI-tools ...

JL: This often happens ...

TS: ... including crazy WPF chunks written in C # and integrated into Unreal Engine 4 that didn't work on a Mac, for example. Therefore, at that moment we had a huge chaos in the code.

At the same time, Nick Atamas created the prototype of a new UI layer in C ++, and over time we decided to use it. So he turned into a Slate. So we rewrote 100 percent of the Unreal Engine user interface, got rid of all the connected UI toolkits and redid it in the same style. This allowed us to scale up the editor and come to what we have today.


Screenshot UnrealEd with Slate UI

But we still could not achieve the convenience that existed during the days of Visual Basic. Even the C # user interface framework was just a huge jumble of XML and other unnecessary madness. It seems that each new generation implements the UI in an increasingly sophisticated way and gets worse.

Screenshots and XCopy: the importance of licensing

JL: Which companies were the first to use the Unreal Editor?

TS: In the early stages, two years before the release, we already had two license buyers: the Unreal Engine used Microprose, and then Legend Entertainment used it for its Wheel of Time, and we provided them with support.



Wheel of Time by Legend Entertainment

JL: They helped you too, right? Working together was part of that relationship.

TS: Yes, their license payment supported Epic afloat during the Unreal development process.

At that time, I took licensing very seriously, because it allowed us to pay bills, which led us to the engine licensing model, which was completely different from the Id model. At that time there was a joke that Id licensing the engine was like buying a XCopy for a quarter of a million dollars: you pay a quarter of a million, and they enter the DOS XCopy command to give you a copy of the source ... and that's it. [laughs]

JL: [laughs] Well, so what led to the sale of the Unreal Engine license to Microprose and Legend Entertainment even before the release of Unreal 1?

TS: I think it happened because we were still in the early stages, around 1995, producing amazing screenshots of not only our game, but also screenshots of our editor. This made the company contact us. We received a call from Microprose and said: “We want to license your engine!”, And we are: “Engine? What engine? Oh, our engine! It will cost you dearly. ” [laughs] That was literally the conversation.



Some of the very first Unreal Editor and Unreal screenshots

Dinosaurs and lizards: terminology and iconography UnrealEd

DL: Speaking of screenshots: here is one of them, published in Blue's News in the late 90s. There are some minor differences from the version that is running in my virtual machine: for example, in the upper left corner there are the Play, Help and Epic buttons that are not in the final version.

Can you tell us a little about it?


Screenshot UnrealEd, published on Blues News in 1998

TS: It's definitely Unreal Engine 1, around 1998, because it contains the code of Steve Paulge, who at the time was coordinating a multiplayer game.

The “Epic” button was just a link to a web page that seemed annoying to everyone, because they constantly accidentally clicked and annoyed: “Aw, the browser opens again!” [Laughs]

JL: [laughs] Well, can you talk a little about iconography?

TS: For all the UI elements, I drew absolutely horrible icons, and then sent them to Dan Cook, an artist who was engaged in graphics for our early shooter Tyrian .

He needed to draw an icon for the Pawn element, so he created a chess piece. I said, “No, no, no, no,” and he said, “Well, then tell me what a pawn is.” I said that it was something like a monster, something very cool, so he painted the head of a creature incomprehensible to anyone: they said it was a dinosaur, a lizard, or something else ... but these icons remained with us for about ten years.



Daniel Cook and the icons he created for UnrealEd. The “Add Pawn” icon is below, the third on the right.

JL: We already talked about the word "pawn". Did we invent it ourselves, or saw it somewhere?

TS: I think Steve Poldj or James Schmalz suggested it.

JL: What about "actor"?

TS: Carmack came up with his own terminology, he called objects "entities", and I thought, "No, we need something unique."

JL: [laughs]

TS: We decided that we would have objects referred to as “actors” (actors), because in the 1980s, SmallTalk , which I was in love with at the time, proposed programming principles based on the model of actors . The model was object-oriented and seemed like a good start to us. Therefore, we came up with the idea of ​​pawns and instigators, defining the launch of a series of events and to all other terminology.

Schmalzysm and brain voodoo virus: the creation of UnrealScript

JL: Tell us more about how James and Steve participated in the use and creation of UnrealScript.

TS: James Schmalz was a unique diamond, a jack of all trades. He was the best artist of the team, a terrific level designer, and could also program in UnrealScript and assembler.

JL: In the Unreal credits, his name appears in a pair of completely different categories.

TS: There are extremely few people of this level of talent in the entire gaming industry, and it deserves all the success it has received.

But he switched from assembler to UnrealScript and wrote insane UnrealScript code, in which he simply hammered the lines as they continued to work, and in the evenings I approached him and simplified his code. He had multi-line expressions like "something instigator dot dot blah blah", and I replaced them with something like ... "self". [laughs]

JL: [laughs]

TS: We called this code "Schmalzim". And in Poldzh in the code there were magic numbers like "walk speed = run speed x 3.072". I asked him: “Is there really a 3.072 constant in physics that I don’t know about?” [Laughs]



TS: UnrealScript was inspired by Java; at the time, this language seemed to be a C ++ heir. The creators of the language copied many constructive solutions, and on top added many new concepts. In UnrealScript, there were rudiments of base containers that appeared in Java only a few generations later.

I always thought that when developing the C # language, the authors followed UnrealScript, because I saw some features of UnrealScript that surfaced in C #. I always hoped they would borrow some of these ideas.

But the more I dig into object-oriented programming and in SmallTalk, I studied the most up-to-date research of metaclasses, the more I realized that it was a kind of brain-voodoo-virus that did not have any real theoretical rationale. In turn, if we look at Haskell and the Curry-Howard line , as well as other modern programming principles, we will see the source and structure for inspiration.

SoftDisk, Id and millions of dollars checks

JL: Did Jay Wilbur and Mark Raine, with their business orientation and shareware experience, influence the engine, tools, editor, or resources they were provided with?

TS: In the early stages, Epic worked because I was involved in the technical side, and Mark worked in the business. Mark flew around the world, made insane business deals that brought us cash. It was very important, if not for him, we would not have survived in these early stages.



Mark Raine and Jay Wilbur

At some point we were stranded and all our expenses were financed from the American Express Mark, which he was canceled as a result.

JL: [laughs]

TS: Then he flew into a meeting with TG Interactive and returned from there with a million dollar check. It saved us. And so repeated several times in our history. It is very important to have excellent businessmen who can negotiate. He was the first president of Id, and after Mark Jay became the first CEO of Id.

JL: And before that, he was in SoftDisk with Carmack, right?

TS: Right! And it's funny, because in fact I sold my first ZZT game to SoftDisk. It was Jay Wilbur who dealt with my contract with SoftDisk. As a result of these negotiations, I received three thousand dollars from SoftDisk, so I knew Jay for a very long time.


Early Days Id Software. Jay Wilbur on the right.

Working with the guys from Id inspired me from the very beginning. I went to some stupid shareware conference and Id appeared there. At the time, they were industry favorites because they released Wolfenstein 3D, which was the biggest success story in shareware. They chatted with us, and then they invited us to dinner. It was so cool to see that the superstar industry turned out to be simple, modest guys. John Romero is the cutest game developer in the world.

[Author's note: I agree. John Romero spent a lot of his time on our TEd interview.]

WYSIWYG and ease of use: the most important is the outlook for the tool

DL: So, in November 1998, the Maximum PC edition appeared, in which there was an interview with you, where you also talked about the different technologies that existed at that time. В этой статье говорилось, что "[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, ко всему этому.

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

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