Tim Sweeney on the First Version of the Unreal Editor

Agreed, what a great interview!

I remember UnrealEd from the Unreal 1 and Unreal Tournament 1 disks. That's how it looked like: https://www.gamasutra.com/db_area/images/blog/309414/ide1.jp...

Back in the "engine war" between Quake 3 Arena and Unreal Tournament, the map community loved UnrealEd, it was definitely easier to use and was just-in-time, no seperate minute-long build-process to build the level and try it out, in UnrealEd you could just try it out. Visual Basic 4-6 were incredible RAD product (rapid application development). Before Github, before GoogleCode, before Sourceforge, there was PlanetSourceCode and it was the go to place for Visual Basic dev community. For everything you could find little programs and code. Windows 95/98 era and Visual Basic was the perfect symbiosis. Very sad when MS announced the vision of .net and stopped VB6 in 1999 (it took them until 2003 to show up with something, yet many devs faced a wall with no support, and were forced to moved on to Java/PHP/etc). Anyway when I first read about UnrealEd was coded in Visual Basic 5 or 6 I couldn't believe it, it had an outstanding performance and integrated the C++ renderer perfectly. Though it was a bit unstable (which was common also for Word 97 and Excel 97 back then), so one had to save a lot, and use "save as" to not correct files. I would say the next evolution of game editors was certainly Sandbox editor of Cryengine 1 from Far Cry 1 disk (2004). Creating tropical islands with its landscape editor was never easier. Of course other tools soon reached parity.

Huh, funny - when I was starting to design a Quake map, if I remember correctly, I would start by making a giant solid, and then carved out rooms from it. Am I remembering that incorrectly?

Going from WorldCraft (Half-Life) to DromEd (Thief, Thief 2) was a similar experience for me. No more leaks.

> left my maps with a host of problems usually related to planes not lining up correctly

Note that this was most likely an issue with the editors people were creating at the time. AFAIK nobody has managed to build the original QuakeEd's source code and that one didn't had those issues (mainly because it didn't allow much manipulation in the first place - most brushes are axis aligned and neatly arranged on the grid).

> UnrealEd on the other hand inverted that paradigm, instead of building your level a void you carved your map out of a solid mass

Which is funny because this is also what Doom did: like Unreal, Doom had you carve up negative space in a huge solid world. This approach was also used by other engines at the time, like the Sith Engine by LucasArts which was used in Jedi Knight (in that engine all world geometry is made by sectors creating negative space pretty much the same way like in Doom).

Although personally as a programmer i tend to favor positive brushes for their simplicity. I have written a 3D world editor that has both negative and positive brushes and the code to handle the geometry generation for negative brushes is like 10 times more than the positive brushes (i don't use BSP) due to all the edge cases from floating point precision.

Minor nitpick, but Carmack didn't create the tools for id's games. Romero made most of the early tools until his depature.

I remember the revelation of realising that unreal used positive “null-space” instead of negative and being blown away... no more damned lighting leaks and placing giant boxes over everywhere I thought might have been the cause.

I think most of my love with editing as a kid was for the Build editor and Duke3D - you could make some impressive levels with a mixture of laying out walls/zones in 2D, and adjusting heights and textures in first-person 3D. Opening the existing levels was also possible and a great way to learn how they had been made. I swear I’ll remember parts of the sector ID tag list until the day I die.

It’s kind of a pity that with the increased complication of engines and design that this is a much harder process to get started on. Though perhaps I’m underestimating the wonder even now of loading up a box room and the feeling of I made this...

Most people suffer from the same problem, it is very hard not to see all the faults with an idea in its infancy. Whether these are perceived problems or real ones, and whether these problems are products of our own self-doubt or legitimate concerns is difficult to discern.

I can't decide if it is a form of stupidity or intelligence that allows people to confidently throw themselves behind their own ideas.

Correct, hindsight is 20/20.

> I know I've had ideas that were ahead of their time, but was held back by that damn voice saying it can't be done or I don't have the resources.

I think a good method would be to share that idea with others, and work on it with help.

Unfortunately, it can be difficult to find other interested people.

Bill Atkinson did the same thing with some of QuickDraw's overlapping region code on the original Macintosh. He perceived that the Xerox Alto was doing things that were more advanced than it actually was, and ended up shipping a more advanced and efficient overlapping window implementation because of it.

And then of course there's this great anecdote about VGA video card optimisations from Ramblings in Realtime: https://www.gamedev.net/articles/programming/graphics/rambli...

I suppose George Dantzig is the ultimate example of such an episode https://en.wikipedia.org/wiki/George_Dantzig

If other people say it can't be done, it means you are on the right track. If you think it can't be done it means you are side tracking.

Same story happened to Starcraft 1, in which Blizzard revamped their Warcraft-2 lookalike game to a more isometric view to match something the competition seemingly did.

https://www.codeofhonor.com/blog/starcraft-orcs-in-space-go-...

"At some point I talked with Mark and Patrick about how Dominion Storm knocked us on our heels, and they let us in on Ion Storm’s dirty little secret: the entire demo was a pre-rendered movie, and the people who showed the “demo” were just pretending to play the game! It would be an understatement to say that we were gobsmacked; we had been duped into a rebooting StarCraft, which ultimately led it to be considered “the defining game of its genre. It is the standard by which all real-time strategy games are judged”

The ilusion of competen competitors without budget oversight - what drives a industry forwards, i can allready see the powerpoint presentation and the bookline.

I remember reading a story years ago about one early VGA card company. They had somehow heard about a competitor using a flip-flop(?) to make their VGA card twice as fast. They puzzled over this idea for a long time, wondering how that competitor could have done that. It seemed impossible but because the competitor had apparently managed to do it, they kept experimenting, and ended up shipping a product inspired by this idea, but not quite achieving that factor two. Later they found out the competitor had actually done something much less impressive. (Using only a latch instead of a full flip-flop? I don't quite remember the exact details. I thought this story was in the Graphics Programming Black Book by Michael Abrash of Quake-fame, or maybe one of Jim Blinn's Corner columns, or something like that, but I can't find it.)

... But for those that do want to run them locally, DosBox will run most of them.

Holy shit. Mentioning the demo scene in an article about game engines made me remember the "Into the Shadows" demo by Triton from 1995 (one year before quake was released): https://youtu.be/MViZocLJVcM?t=28s. That was really impressive back then. Thanks for the throwback!

I remember those Glaze3D screenshots from BitBoys back in the day. They were the most awesome vaporware.

I lost countless hours in Amiga 500 meetings with a couple of friends back in the day, with them doing ProTracker sessions.

And the joy of reading electronic magazines (diskmag) like Hugi.

That skybox thing exists in other engines as well. E.g. in CSGO you can find the skybox scene somewhere in the map with noclip, usually far outside the playing area.

> There was no better feeling to me as a kid than opening up a map like DM-Deck16 in the Unreal Editor, and investigating how the genius mappers had created this or that part of the map (especially the toxic zones).

That's the thing I really liked about the game back then. You could just open the included maps in the editor and look at how they've been done. Usually the maps are either no longer in the format the editor supports and have to be decompiled (id games) or things were stuffed away in some large nonstandard archive file (I remember trying to find the Starcraft campaign maps and couldn't). Back when internet access was only sporadic and short I tended to give up where I couldn't figure things out further on my own instead of searching for tools.

Blew my mind as a kid when I didn't really understand the skybox but I think I left one of the 4 armed guys in that area on the map and when I went into the level he was towering over the level like a giant.

I didn't use QuArk, but I did use (and bought a copy of) Qoole[1]. I built several Quake2 levels some of which I released out into the wild:

http://www.jaruzel.com/apps/quake2/

I recently tried to get Qoole back up and running, but it really hasn't aged well. Making levels in it now, seems like way too much hard work.

--

[1] Qoole Screenshot: http://www.cs-h1.do.am/_ld/2/50880145.jpg

This brings back so many sweet memories. I started with QuArK, then I was introduced to UnrealEd. I remember finding UnrealEd to be more clunky than QuArK. It also took some time for me to get used to the 'inverse' editing in UnrealEd (in uED you basically start with a solid block of infinite size, and then cut out the parts you want accessible by the player).

I then went on to make multiplayer maps for half-life (can't remember which editor I used), I still play those maps with friends.

After HL1 I went to college and couldn't afford a PC capable of running the newer games/engines, and that's where my map building hobby stopped, unfortunately. Nowadays the engines and tools are so complex, that it just takes too much time to build maps for a hobby IMO.

> While I'm going all nostalgic, anyone remember playing UT on Linux?

Not the original UT, but 2004 had a Linux version. Damn, that's a long time since I tried that game the last time. Gotta get myself a real licensed one though, back when I was younger we shared a serial key and well, someone got the serial banned on most servers somehow...

What wondered young me was that UT2k4 was able to run without any compilation or whatsoever on any Linux system no matter which kernel version, distribution, driver version, xorg version, ... Older me knows it's due to static compilation, but still absolutely awesome given that the only binary that does the same is busybox in static compiled mode, everything other will break when crossing distribution boundaries.

It definitely still had BSPs. UT2003 had terrain rendering that seemed custom (not likely octrees but could have used quadtrees for all I know) and much more of the environmental detail was made up of static meshes (meshes were culled based on the bsp but didn't contribute to it) presumably because GPUs could churn through them faster. The basic BSP editing was still there though, kind of amazing how long they kept that unchanged.

No, ut was based on the unreal engine, level and data files were compatible, you could copy the unreal files over to ut and play it with all those little enhancements the engine has gotten. No octrees in ut, but good old bsp holes.

When you enter the building of a AAA game studio, the majority of Epic paying customers, it is filled with Windows computers and some macOS ones on the 3D rendering and iOS departments.

So they are paying attention to whom gives them the bucks.

I tried to use UE4 on Linux and gave up. My guess: someone on the UE team supports Linux as a pet project, and they're productive enough on other tasks that nobody tells them to stop. It's pretty clear to me that they support Linux as a runtime environment but they will never put much effort into supporting development on Linux. Most game programmers are used to Visual Studio anyway.

A layer above the actual geometry of the level.

It was too slow to calculate lighting in real-time, so a process executed at design-time in Unreal (at build-time in iD engines) that calculated how lights lit the level geometry and then baked those changes on to the textures that were applied to the geometry.

It's like painting the glow of a torch on to the wall once before playtime rather than actually doing it every frame. Lighting doesn't typically change every frame, so it works.