10 ms·

Tim Sweeney on the First Version of the Unreal Editor

271 points by vesrah 9y ago

lbenes 9y ago
> "A lot of the features in Unreal arose from fallacies of what I misperceived other people did." In both the programming and business world, I've observed this trait in successful people. 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 wish there was some way I could "fix" that wiring in my own brain. On the one hand, my skepticism has saved me more times that I could count from being conned or from bad deals. But it also has held me back by focusing on the problems instead of just blazing forward.
- ericmcer 9y ago
  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.
  - hacker_9 9y ago
    This is why you write plans; you find the pain points that will occur and figure those out before committing yourself to an idea. Often I find any wild ideas I have are mostly killed off in the planning stage, but this generally also leads to new more solid ideas too.
  - hyperpallium 9y ago
    A "bias for action", according to "In Search of Excellence". Which didn't let a lack of experimental evidence stop them reporting experimental evidence. And was very successful. Which, I guess, validates it.
- hacker_9 9y ago
  Correct, hindsight is 20/20.
- thomastjeffery 9y ago
  > 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.
- doomlaser 9y ago
  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.
- taneq 9y ago
  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/ramblings-in-realtime-chapter-1-inside-quake-r981 https://www.gamedev.net/articles/programming/graphics/rambli...
- kristiandupont 9y ago
  I suppose George Dantzig is the ultimate example of such an episode https://en.wikipedia.org/wiki/George_Dantzig https://en.wikipedia.org/wiki/George_Dantzig
- z3t4 9y ago
  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.
  - WillReplyfFood 9y ago
    NP in P here i come.
- skocznymroczny 9y ago
  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-down-in-flames 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”
- WillReplyfFood 9y ago
  The ilusion of competen competitors without budget oversight - what drives a industry forwards, i can allready see the powerpoint presentation and the bookline.
- 1wd 9y ago
  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.)
  - kayamon 9y ago
    I think you're referring to this one: http://www.phatcode.net/res/224/files/html/ch64/64-01.html http://www.phatcode.net/res/224/files/html/ch64/64-01.html
    - 1wd 9y ago
      Yes, thank you! (So I indeed remembered a few things wrong: It was about a read- and write-FIFO, not about a flip-flop and latch. And the speed improvement factors were not mentioned.)
zaphar 9y ago
His comments on tooling at the end of the article apply equally to all development projects not just games. Tooling had an enormous impact on productivity for developers but far too few organizations spend enough time on it.
deleted 9y ago
[deleted]
scrumper 9y ago
I was not aware of the ZZT/Unreal connection. ZZT was one of my formative programming experiences, a lovely reminder to see it here!
mastazi 9y ago
"Also, a bunch of the former Future Crew demo-scene guys had formed a hardware company, and they had released some screenshots with incredibly realistic volumetric lighting in an indoor scene". The European demo scene was very important in the development of computer graphics (e.g. early 3d shading techniques) and music (e.g. music trackers which can be considered predecessors to modern DAWs), every now and then I go and watch those demos and I am amazed by what a bunch of teenagers was able to achieve on very limited hardware such as an Amiga 500 or an Atari ST. Many classic demos are now visible on Youtube so you don't have to go through the chore of installing emulators.
- fapjacks 9y ago
  ... But for those that do want to run them locally, DosBox will run most of them.
- dividuum 9y ago
  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 https://youtu.be/MViZocLJVcM?t=28s. That was really impressive back then. Thanks for the throwback!
  - badsectoracula 9y ago
    Another demo i always remember from the 90s is The Fulcrum by Matrix: https://www.youtube.com/watch?v=7jDzPZZaTLY https://www.youtube.com/watch?v=7jDzPZZaTLY It was released a bit later (1998) but for its time it has some very impressive lighting effects.
- CoolGuySteve 9y ago
  I remember those Glaze3D screenshots from BitBoys back in the day. They were the most awesome vaporware.
- pjmlp 9y ago
  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.
dmschulman 9y ago
The Unreal Editor was such a breath of fresh air compared to what Carmack at id had cooked up to create Quake maps. I worked in both editors as a young kid and the design paradigm with Quake, assembling a map in a void, left my maps with a host of problems usually related to planes not lining up correctly or having tiny gaps (leaks) which caused the map to not compile correctly or created an issue when actually playing the map. It drove me crazy. UnrealEd on the other hand inverted that paradigm, instead of building your level a void you carved your map out of a solid mass. The geometry was much easier to work with and led me to really embrace Unreal's engine over Quake. I still loved Quake as the better game but Unreal's technology shined brighter for me as a young map maker.
- VikingCoder 9y ago
  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?
  - Negative1 9y ago
    Nope, that was possible, but the boolean operations could lead to numerical instability if you didn't align your brushes to the grid at a reasonable granularity, which could still lead to leaks. The flooding code was generally pretty well done but developers had to bandage issues like this in every Quake-engine game. FYI Unreal still had leaks (which lead to major performance issues if uncontrolled, due to the PVS being too inclusive), but it was not as pronounced as the negative space still allowed the map to finish building the BSP (Quake just failed, sometimes without a clue as to why).
- brobinson 9y ago
  Going from WorldCraft (Half-Life) to DromEd (Thief, Thief 2) was a similar experience for me. No more leaks.
  - vvanders 9y ago
    Oh man, Half-Life is a treasure but Hammer was definitely not the most straightforward tool.
Steltek 9y ago
I recall Unreal Tournament (1999) used octrees and not BSPs. Was this changed between Unreal and UT? I recall comparisons between Quake 3 (also 1999) and UT engines noted the spatial model impacting the performance of certain map designs: indoor vs outdoor. While I'm going all nostalgic, anyone remember playing UT on Linux? There were so few good Linux games back then. I think I played it until the hard drive platter was thread-bare.
- mschuster91 9y ago
  > 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.
  - iforgotpassword 9y ago
    Ut99 also had a Linux port, made by another company though. Loki games?
    - paines 9y ago
      yup! and it worked great.
- razorunreal 9y ago
  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.
orliesaurus 9y ago
I never worked on the Quake one but the Unreal Editor is where I started getting creative with computers - both by creating maps and fiddling with Unreal Script to change behaviors and build mutators. For the mapping aspect, as a 10-something year old - it was super weird having to think in reverse at first - but then it got just natural. Think of being a huge block of clay and working from the inside. As the Unreal Editor evolved it just got better. The best part of the early Unreal editor was the "skybox" hack that you would have to create basically a small box placed somewhere in the map with the inside painted as the sky (or whatever panorama you wanted players to see when they looked at the sky). 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).
- ygra 9y ago
  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.
  - WillReplyfFood 9y ago
    The skyboxes where very cool- you could craft little spaceships battling and then set them into the skybox, where they - tall as mountains would duke it out over the mortals fighting among themselves.
- whywhywhywhy 9y ago
indescions_2018 9y ago
Great interview! I would definitely be interested in a history of Unreal in full book length form. And if anyone hasn't already perused "Masters of Doom" by David Kushner on the early days of Id Software, it is such a good read. Regarding the Haskell love. I believe Unreal contributed to the design of a research functional programming language prototype called Cayenne back in the day: Cayenne—a language with dependent types https://dl.acm.org/citation.cfm?id=289451 https://dl.acm.org/citation.cfm?id=289451 I think another historical note is how everybody developed on SGI machines in the late 1990s. Primarily, due to Maya modeling. But the 3D graphics API wars were certainly a factor: Direct 3D and OpenGL by Paul Hsieh http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html And, yeah, MSDOS ZZT from 1991 is still playable via Internet Archive ;) https://archive.org/details/msdos_ZZT_1991 https://archive.org/details/msdos_ZZT_1991
- culerawo 9y ago
  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.jpg 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.
kevindqc 9y ago
>So I figured out that I needed to compute the line integral from the eye to every point on the screen. I learned some calculus in college, so I said to myself "I should be able to do this." So I figured out the formula for it with some crazy complicated trigonometry. I implemented it, but it was 100 times too slow. Then I realized, "Oh wait, I can do this in the lightmap space”, because the lightmap is a discretization of geometry into bite-sized chunks. I did that with lightmaps, so it was real-time. What is lightmap space?
- naikrovek 9y ago
  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.
  - kevindqc 9y ago
    Oh so he just means using lightmaps. Gotcha
  - royjacobs 9y ago
    No, I think he means that he was calculating the contribution of the volumetric light per lightmap texel, instead of per screenspace pixel. If he would have "painted it on the lightmap" then the effect would not have changed based on your viewpoint, since it's just baked into the lightmap.
arca_vorago 9y ago
As I sit here fighting to get 4.18 to compile I just want to say epic has really left the gnu/linux community floating in the wind and it makes me sad. 'make CXX=g++ -k' for any other linux ue4 users I'm considering switching to pure blender/godot even though it's not even close to feature parity with ue4, at least it's a gpl license and linux is a first class client.
- pjmlp 9y ago
  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.
  - deleted 9y ago
    [deleted]
- blt 9y ago
  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.
iforgotpassword 9y ago
Anyone remember bsp holes? I never found a definitive answer where they came from. Was the algorithm technically flawed? Was the implementation buggy? Was it some shortcuts taken to speed up things, knowingly causing these glitches? Also There were so many pieces of advice out there on how to prevent them or if they occur, how to get rid of them that I was convinced at some point that half of that must have been cargo cult like.
Jur 9y ago
I remember working with QuArK to build Half-Life levels which must have been somewhere in `98-`00. I loved building the levels and triggers for opening doors and moving elevators. I remember at the time being impressed with the sculpting from UnrealEd when it was introduced, but I don't recall it being more intuitive. Anyone else who used QuArK who has an opinion? Seeing the screenshot with the gridview from QuArK brings back nice memories in any case: https://en.wikipedia.org/wiki/Quake_Army_Knife https://en.wikipedia.org/wiki/Quake_Army_Knife
- Jaruzel 9y ago
  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/ 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 http://www.cs-h1.do.am/_ld/2/50880145.jpg
  - heeen 9y ago
    GtkRadiant and Trenchbroom are modern brush editors
- LeonM 9y ago
  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.
  - 9y ago
barrkel 9y ago
I think tools and toolmakers don't always get the credit they deserve. Tools are the other way of increasing the leverage of a team of developers (the first being increasing the level of the team through knowledge and upskilling). It's sometimes hard to get businesses to see the benefit of building tooling, though, because it seems like a yak-shaving exercise (and can be if it's not scoped correctly). I think if you have people who are naturally inclined to be toolmakers, and they've got a problem which can be solved in two ways - repetitively, or with tooling - the deciding factor on whether they build a tool or not will be how much autonomy of decision-making they have. Tightly focused "agile" sprints will result in small packets of work, no one of which will be big enough to justify any tool building, so there won't be any space for introspection and planning, and it probably won't happen. Tooling tends not to evolve from refactoring. It has a similar genesis - seeing repetitive work - but the approach requires a couple more clicks up the abstraction stack to plan out.
bluedino 9y ago
This was the biggest takeaway from the article, for me: I thought to myself "Holy shit, Carmack wrote a real-time BSP editor!" What I didn't realize was that it wasn't actually real-time, there was this re-build process and all this other offline stuff. I didn't know that, and so I thought I had to create a completely real-time thing, and so I did. It basically goes to show you nothing's impossible until someone says it is. Had Tim thought, "There's no way you can write a real-time BSP editor on current hardware", he would have never done it.
talmand 9y ago
Billy Zelsnack Now that's a name I haven't thought about for a long time. The gamer in me wishes Rebel Boat Rocker had worked out because their game had some promise. I only talked with Billy a couple of times and he seemed a good guy. I met John Romero once in the Ion Storm tower, I would agree with the interview as he seemed a nice guy. Although there's a bit of a rep there. Shame Ion Storm was such a mess. Met Jay Wilbur as well. Seems I've met quite a number of people in the industry during that time, wish I had capitalized on that a bit better. Never did meet Carmack or Sweeney, that would have been nice to add to the collection. Personally, I actually preferred Half-Life level development for a long while simply because the output was so nice. It was all about the lighting for me. Once the level building tools evolved a bit from the first crude Quake1 tools, dealing with them wasn't as bad as people seem to remember. It was those tools that instilled in me that the concept of making things more efficient and to look for more efficiency was well worth the effort. Eventually a common thing for Unreal, probably UT, level development was to start with one large empty space and then fill it as necessary. As I remember it anyway. Especially with the usage of meshes and instances, it was simply more efficient. My favorite editor was always DromEd for the Dark Engine used for Thief. The concept of designing levels with real-world units, that lighting had serious gameplay implications, and having to consider sound throughout the level was a nice change of pace.
1wd 9y ago
Another fascinating short question answered by Tim Sweeney about a neat hack / feature of the excellent Unreal 1 software rasterizer: http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtm...
vcool07 9y ago
Very engaging read. Any other such interesting interviews of retro game dev ?

271 points by vesrah 9y ago

> "A lot of the features in Unreal arose from fallacies of what I misperceived other people did." In both the programming and business world, I've observed this trait in successful people. 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 wish there was some way I could "fix" that wiring in my own brain. On the one hand, my skepticism has saved me more times that I could count from being conned or from bad deals. But it also has held me back by focusing on the problems instead of just blazing forward.

ericmcer 9y ago
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.
- hacker_9 9y ago
  This is why you write plans; you find the pain points that will occur and figure those out before committing yourself to an idea. Often I find any wild ideas I have are mostly killed off in the planning stage, but this generally also leads to new more solid ideas too.
- hyperpallium 9y ago
  A "bias for action", according to "In Search of Excellence". Which didn't let a lack of experimental evidence stop them reporting experimental evidence. And was very successful. Which, I guess, validates it.
hacker_9 9y ago
Correct, hindsight is 20/20.
thomastjeffery 9y ago
> 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.
doomlaser 9y ago
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.
taneq 9y ago
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/ramblings-in-realtime-chapter-1-inside-quake-r981 https://www.gamedev.net/articles/programming/graphics/rambli...
kristiandupont 9y ago
I suppose George Dantzig is the ultimate example of such an episode https://en.wikipedia.org/wiki/George_Dantzig https://en.wikipedia.org/wiki/George_Dantzig
z3t4 9y ago
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.
- WillReplyfFood 9y ago
  NP in P here i come.
skocznymroczny 9y ago
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-down-in-flames 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”
WillReplyfFood 9y ago
The ilusion of competen competitors without budget oversight - what drives a industry forwards, i can allready see the powerpoint presentation and the bookline.
1wd 9y ago
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.)
- kayamon 9y ago
  I think you're referring to this one: http://www.phatcode.net/res/224/files/html/ch64/64-01.html http://www.phatcode.net/res/224/files/html/ch64/64-01.html
  - 1wd 9y ago
    Yes, thank you! (So I indeed remembered a few things wrong: It was about a read- and write-FIFO, not about a flip-flop and latch. And the speed improvement factors were not mentioned.)

zaphar 9y ago

His comments on tooling at the end of the article apply equally to all development projects not just games. Tooling had an enormous impact on productivity for developers but far too few organizations spend enough time on it.

deleted 9y ago

[deleted]

scrumper 9y ago

I was not aware of the ZZT/Unreal connection. ZZT was one of my formative programming experiences, a lovely reminder to see it here!

mastazi 9y ago

"Also, a bunch of the former Future Crew demo-scene guys had formed a hardware company, and they had released some screenshots with incredibly realistic volumetric lighting in an indoor scene". The European demo scene was very important in the development of computer graphics (e.g. early 3d shading techniques) and music (e.g. music trackers which can be considered predecessors to modern DAWs), every now and then I go and watch those demos and I am amazed by what a bunch of teenagers was able to achieve on very limited hardware such as an Amiga 500 or an Atari ST. Many classic demos are now visible on Youtube so you don't have to go through the chore of installing emulators.

fapjacks 9y ago
... But for those that do want to run them locally, DosBox will run most of them.
dividuum 9y ago
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 https://youtu.be/MViZocLJVcM?t=28s. That was really impressive back then. Thanks for the throwback!
- badsectoracula 9y ago
  Another demo i always remember from the 90s is The Fulcrum by Matrix: https://www.youtube.com/watch?v=7jDzPZZaTLY https://www.youtube.com/watch?v=7jDzPZZaTLY It was released a bit later (1998) but for its time it has some very impressive lighting effects.
CoolGuySteve 9y ago
I remember those Glaze3D screenshots from BitBoys back in the day. They were the most awesome vaporware.
pjmlp 9y ago
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.

dmschulman 9y ago

The Unreal Editor was such a breath of fresh air compared to what Carmack at id had cooked up to create Quake maps. I worked in both editors as a young kid and the design paradigm with Quake, assembling a map in a void, left my maps with a host of problems usually related to planes not lining up correctly or having tiny gaps (leaks) which caused the map to not compile correctly or created an issue when actually playing the map. It drove me crazy. UnrealEd on the other hand inverted that paradigm, instead of building your level a void you carved your map out of a solid mass. The geometry was much easier to work with and led me to really embrace Unreal's engine over Quake. I still loved Quake as the better game but Unreal's technology shined brighter for me as a young map maker.

VikingCoder 9y ago
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?
- Negative1 9y ago
  Nope, that was possible, but the boolean operations could lead to numerical instability if you didn't align your brushes to the grid at a reasonable granularity, which could still lead to leaks. The flooding code was generally pretty well done but developers had to bandage issues like this in every Quake-engine game. FYI Unreal still had leaks (which lead to major performance issues if uncontrolled, due to the PVS being too inclusive), but it was not as pronounced as the negative space still allowed the map to finish building the BSP (Quake just failed, sometimes without a clue as to why).
brobinson 9y ago
Going from WorldCraft (Half-Life) to DromEd (Thief, Thief 2) was a similar experience for me. No more leaks.
- vvanders 9y ago
  Oh man, Half-Life is a treasure but Hammer was definitely not the most straightforward tool.

Steltek 9y ago

I recall Unreal Tournament (1999) used octrees and not BSPs. Was this changed between Unreal and UT? I recall comparisons between Quake 3 (also 1999) and UT engines noted the spatial model impacting the performance of certain map designs: indoor vs outdoor. While I'm going all nostalgic, anyone remember playing UT on Linux? There were so few good Linux games back then. I think I played it until the hard drive platter was thread-bare.

mschuster91 9y ago
> 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.
- iforgotpassword 9y ago
  Ut99 also had a Linux port, made by another company though. Loki games?
  - paines 9y ago
    yup! and it worked great.
razorunreal 9y ago
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.

orliesaurus 9y ago

I never worked on the Quake one but the Unreal Editor is where I started getting creative with computers - both by creating maps and fiddling with Unreal Script to change behaviors and build mutators. For the mapping aspect, as a 10-something year old - it was super weird having to think in reverse at first - but then it got just natural. Think of being a huge block of clay and working from the inside. As the Unreal Editor evolved it just got better. The best part of the early Unreal editor was the "skybox" hack that you would have to create basically a small box placed somewhere in the map with the inside painted as the sky (or whatever panorama you wanted players to see when they looked at the sky). 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).

ygra 9y ago
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.
- WillReplyfFood 9y ago
  The skyboxes where very cool- you could craft little spaceships battling and then set them into the skybox, where they - tall as mountains would duke it out over the mortals fighting among themselves.
whywhywhywhy 9y ago

indescions_2018 9y ago

Great interview! I would definitely be interested in a history of Unreal in full book length form. And if anyone hasn't already perused "Masters of Doom" by David Kushner on the early days of Id Software, it is such a good read. Regarding the Haskell love. I believe Unreal contributed to the design of a research functional programming language prototype called Cayenne back in the day: Cayenne—a language with dependent types https://dl.acm.org/citation.cfm?id=289451 https://dl.acm.org/citation.cfm?id=289451 I think another historical note is how everybody developed on SGI machines in the late 1990s. Primarily, due to Maya modeling. But the 3D graphics API wars were certainly a factor: Direct 3D and OpenGL by Paul Hsieh http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html And, yeah, MSDOS ZZT from 1991 is still playable via Internet Archive ;) https://archive.org/details/msdos_ZZT_1991 https://archive.org/details/msdos_ZZT_1991

culerawo 9y ago
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.jpg 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.

kevindqc 9y ago

>So I figured out that I needed to compute the line integral from the eye to every point on the screen. I learned some calculus in college, so I said to myself "I should be able to do this." So I figured out the formula for it with some crazy complicated trigonometry. I implemented it, but it was 100 times too slow. Then I realized, "Oh wait, I can do this in the lightmap space”, because the lightmap is a discretization of geometry into bite-sized chunks. I did that with lightmaps, so it was real-time. What is lightmap space?

naikrovek 9y ago
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.
- kevindqc 9y ago
  Oh so he just means using lightmaps. Gotcha
- royjacobs 9y ago
  No, I think he means that he was calculating the contribution of the volumetric light per lightmap texel, instead of per screenspace pixel. If he would have "painted it on the lightmap" then the effect would not have changed based on your viewpoint, since it's just baked into the lightmap.

arca_vorago 9y ago

As I sit here fighting to get 4.18 to compile I just want to say epic has really left the gnu/linux community floating in the wind and it makes me sad. 'make CXX=g++ -k' for any other linux ue4 users I'm considering switching to pure blender/godot even though it's not even close to feature parity with ue4, at least it's a gpl license and linux is a first class client.

pjmlp 9y ago
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.
- deleted 9y ago
  [deleted]
blt 9y ago
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.

iforgotpassword 9y ago

Anyone remember bsp holes? I never found a definitive answer where they came from. Was the algorithm technically flawed? Was the implementation buggy? Was it some shortcuts taken to speed up things, knowingly causing these glitches? Also There were so many pieces of advice out there on how to prevent them or if they occur, how to get rid of them that I was convinced at some point that half of that must have been cargo cult like.

Jur 9y ago

I remember working with QuArK to build Half-Life levels which must have been somewhere in `98-`00. I loved building the levels and triggers for opening doors and moving elevators. I remember at the time being impressed with the sculpting from UnrealEd when it was introduced, but I don't recall it being more intuitive. Anyone else who used QuArK who has an opinion? Seeing the screenshot with the gridview from QuArK brings back nice memories in any case: https://en.wikipedia.org/wiki/Quake_Army_Knife https://en.wikipedia.org/wiki/Quake_Army_Knife

Jaruzel 9y ago
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/ 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 http://www.cs-h1.do.am/_ld/2/50880145.jpg
- heeen 9y ago
  GtkRadiant and Trenchbroom are modern brush editors
LeonM 9y ago
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.
- 9y ago

barrkel 9y ago

I think tools and toolmakers don't always get the credit they deserve. Tools are the other way of increasing the leverage of a team of developers (the first being increasing the level of the team through knowledge and upskilling). It's sometimes hard to get businesses to see the benefit of building tooling, though, because it seems like a yak-shaving exercise (and can be if it's not scoped correctly). I think if you have people who are naturally inclined to be toolmakers, and they've got a problem which can be solved in two ways - repetitively, or with tooling - the deciding factor on whether they build a tool or not will be how much autonomy of decision-making they have. Tightly focused "agile" sprints will result in small packets of work, no one of which will be big enough to justify any tool building, so there won't be any space for introspection and planning, and it probably won't happen. Tooling tends not to evolve from refactoring. It has a similar genesis - seeing repetitive work - but the approach requires a couple more clicks up the abstraction stack to plan out.

bluedino 9y ago

This was the biggest takeaway from the article, for me: I thought to myself "Holy shit, Carmack wrote a real-time BSP editor!" What I didn't realize was that it wasn't actually real-time, there was this re-build process and all this other offline stuff. I didn't know that, and so I thought I had to create a completely real-time thing, and so I did. It basically goes to show you nothing's impossible until someone says it is. Had Tim thought, "There's no way you can write a real-time BSP editor on current hardware", he would have never done it.

talmand 9y ago

Billy Zelsnack Now that's a name I haven't thought about for a long time. The gamer in me wishes Rebel Boat Rocker had worked out because their game had some promise. I only talked with Billy a couple of times and he seemed a good guy. I met John Romero once in the Ion Storm tower, I would agree with the interview as he seemed a nice guy. Although there's a bit of a rep there. Shame Ion Storm was such a mess. Met Jay Wilbur as well. Seems I've met quite a number of people in the industry during that time, wish I had capitalized on that a bit better. Never did meet Carmack or Sweeney, that would have been nice to add to the collection. Personally, I actually preferred Half-Life level development for a long while simply because the output was so nice. It was all about the lighting for me. Once the level building tools evolved a bit from the first crude Quake1 tools, dealing with them wasn't as bad as people seem to remember. It was those tools that instilled in me that the concept of making things more efficient and to look for more efficiency was well worth the effort. Eventually a common thing for Unreal, probably UT, level development was to start with one large empty space and then fill it as necessary. As I remember it anyway. Especially with the usage of meshes and instances, it was simply more efficient. My favorite editor was always DromEd for the Dark Engine used for Thief. The concept of designing levels with real-world units, that lighting had serious gameplay implications, and having to consider sound throughout the level was a nice change of pace.

1wd 9y ago

Another fascinating short question answered by Tim Sweeney about a neat hack / feature of the excellent Unreal 1 software rasterizer: http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtm...

vcool07 9y ago

Very engaging read. Any other such interesting interviews of retro game dev ?