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
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
And, yeah, MSDOS ZZT from 1991 is still playable via Internet Archive ;)
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.
> "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.
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.
"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.
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.
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.
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).
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
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.
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.
I was not aware of the ZZT/Unreal connection. ZZT was one of my formative programming experiences, a lovely reminder to see it here!
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.
Another fascinating short question answered by Tim Sweeney about a neat hack / feature of the excellent Unreal 1 software rasterizer:
>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?
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.