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 relief 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's Magic Carpet game

I said I’m writing 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 start to figure it out, I’ll just write a little texture mapping tool. Therefore, I read the articles of Michael Abrashabout the imposition of textures 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

DL: [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.



Examples of lighting from Unreal based on lighting maps

I made a screenshot and mailed a friend from Finland who worked for the company that manufactures 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]

DL: [laughs] Yeah!

[Author's note: the company Tim is talking about is the Bit Boys ]

TS: That is, the Unreal Engine turned out to be the first volumetric lighting engine in the world, I think ... and it was based on my delusion.

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.

DL: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 all 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 brought these principles to Unreal: you could simply drag an object to a 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 started 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 the meeting for a long time not seen friends].

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



Alan Cooper and Visual Basic

TS: That 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 Alan Cooper., often called "Visual Basic's father . "He is also an important figure in usability and user experience]



UnrealEd 3, in which there were elements of wxWidgets.

DL : I think that later, over time, parts of the editor began to be replaced with 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 appeared, rewriting parts of Visual Basic editor in C ++ with 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. So by the time we started the Unreal Engine 4 development cycle, we had five different UI tools ...

DL: This often happens ...

TS: ... including WPF insane pieces written in C # and integrated into Unreal Engine 4 that did not work on Mac eg. 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.


UnrealEd Screenshot 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 from Legend Entertainment.

DL: 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]

DL:[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: This is 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, which seemed annoying to everyone, because they constantly accidentally clicked and annoyed: “Aw, the browser opens again!” [Laughs]

DL: [laughs] ?

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 designated as “actors” (actors), because in the 1980s, SmallTalk , which I was in love with at the time, was offered programming principles based on actor models. 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]

DL: [laughs]

TS: We called this code "shmaltsizma". 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 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:For sure! 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. This article said that "[The Unreal Editor] is ahead of everyone in simplicity by light years" and "it’s difficult to work with Quake technology."

It also says: “Technology [Quake III: Arena] is really impressive” and “Prey and Trespasser look and work better than Unreal. But if it turns out that it’s harder to work with them, the developers will remain with Unreal. ”

That is, did you have a goal from the very beginning to create a tool whose competitive advantage is ease of use?



Maximum PC, November 1998

TS: Yes, quite right. You know, it was always the most important thing for me: write an editor that allows level designers to create amazing creations. From the very beginning it was clear that the most important aspect of this is real-time work and super-fast design iterations, the full realization of the principle “what you see is what you get” (“what-you-see-is-what-you-get”, WYSIWYG) . Then you will be limited only by your imagination and the ability to invent new ideas. For us, Epic has always been very important tools.

JL: What process did Epic use to ensure a great deal of attention, investment of time and labor in simplifying the use of tools?

TS:The development process in Epic is a combination of the engine development team, creating systems, functions and tools, and a game team that consume all of this to create games. We use an iterative process, when the engine development teams create new ideas, and then share them with the game teams and receive constant feedback on what works and what doesn't. This is how our technical process was created: the fact that the developers of the tools were supposed to help the developers of the games allowed them to be honest.

We not only wanted to create easy-to-use tools, but also make sure that they provide the right compromises that really allow you to create the content necessary for the release of the game.

This is the downside to ease of use. It is impossible to consider ease of use as a separate concept. It's bad when the tools are very easy to use when you start creating a game, but they are very difficult to complete the creation of the game because they limit the workflow or functionality.


If you look at the last five or six years of engine development, the competition between Epic and Unity is determined by the initial ease of use, what is the advantage for Unity. At the same time, Unreal has an advantage in the development cycle of the game release in terms of performance on different platforms. This is because we aim to be able to produce games of epic (epic) scale, that is, those that we do. In fact, it is much more difficult than to simplify the work of three people who quickly produce something simple.

Today, the Unreal Engine code size is about 20 more than the Unreal Engine 1 code. Tools have become ten times more complicated, and for good reason. People run Unreal and get lost because there are so many menu options. Then they switch to Unity and see that everything is nice and simple. And then they reach the stage when you need to release a product, and it turns out that you need to buy a license for the source code to add functions to the engine that are not in the menu. That such a dichotomy exists.

Source of inspiration and heritage: the influence of UnrealEd

JL: UnrealEd inspired some game developers, including me, not only to start creating games, but also to write their own tools. What do you think was the impact UnrealEd had on the industry?

TS: I think every existing game editor borrowed something from UnrealEd. It was one of the first editors, we made a lot of correct fundamental decisions, for example, how the user should work with 2D grids, placing objects and moving around the world. I think you can track the heredity transmitted from the first editor of Doom to the editor of Quake, and then to Unreal. Today, everything is based on this to some extent.

History of the FPS engines from Wikipedia. Click to open a larger version.

Some aspects were influenced by general principles, for example, Maya, but some are quite specifically related to Unreal — a way to structure class hierarchies, the implementation of an undo system, and all other serious problems of game development. Everyone who came into the industry in the early 2000s usually went through either Unreal or Quake. Even though Quake was a much bigger game, it seems to me that most of the designers came through UnrealEd, because its tools were very convenient.

Multiplication and division of performance: tips for game developers

JL: In 2011, you gave a Kotaku interview. I will read a few quotes that I think relate to our topic:

“We have always approached the development of games in terms of tools. We created the tools we needed, created a user-friendly set of tools and continued to work with it. ”

“We in Epic think far ahead. We are like Intel. We think about what we will do in five to ten years and choose the appropriate directions of development, while for most companies the limit of planning is the release of the next game. They invest all their resources in it, and then they are engaged in the next game. ”

“Big gaming companies such as EA or Activision do not invest in tools, they don’t have such long-term planning as ours and our awareness of how to make game development processes as efficient as possible.”



In my interview with John Romero, he grasped it very well, saying, "Tools live longer than games."

What advice can you give game developers to avoid this mistake and understand the long-term value of investing in tools?

TS: Well ... no need to "like" to create an engine. Or collect the engine, or do not do it. Now, so many companies cripple their production processes, creating engines with useless tools. It is the tools that kill people.

Look at all these engines created internally ... For example, Frostbite has more advanced rendering functions than we do, and in many cases it paints more beautiful pixels than we do, but Unreal developers can create content much more productively, 30-50 percent more productive. That is, the team can create a game of the same quality with half the power. It can perform more iterations and sharpen the game better than with less quality tools. Therefore, everyone needs to make a conscious decision - either to invest fully in creating excellent tools for internal use, or to use third-party engines.

JL: Because you think developers are suffering because of half measures?

TS:Yes. Somewhere inside these companies are incredibly stupid accountants who think like this: “Oh, by limiting spending on developing tools, we can save two percent of the budget.” As a result, this leads to an increase in the budget by 50 percent, because you have to invest significantly more time and labor in creating the game. Therefore, it creates such a crazy, not justifying cost savings.

I think that each company should make a decision - either to invest significantly more in the tools, or not to deal with them at all.


And this applies to everything. Not only to the 3D editor for creating levels, but also to the assembly systems, to the programming language, the technical development process, the DCC tools, to all this.

Tools need to increase productivity, and if it turns out that they reduce it, then you need to get rid of them.

JL: Great. Thank you for taking the time to chat with me.