In the 16 years since the release of Quake, it has become the most influential 3D game engine in the history of video games.
This is hardly an overstatement. Quake may not be the literal grandfather of all modern 3D engines, but the lessons that John Carmack discovered while created Quake have been one of the single biggest influences in game history. Take a look at this chart (pulled from the Wikipedia page on Quake)…
There are two main points to take from this graph. The first is that there are some massive commercial successes in that tree. Quake of course, which was preceded by Doom, but you also have all of Valve’s games (Half-Life, Counter-strike, Portal) as well as the Call of Duty series, and some older series like Hexen and Heretic. These are some of the most popular first person games of their days, and any engine that spawned them all should not be ignored.
The second thing to note (perhaps actually the first thing you noticed) was that the majority of the titles listed here are mods and ports of the existing Quake games. The mod community around id Software’s games is extremely healthy, and you have here almost 20 years of modding experience and history to draw from. What better way to learn about the programming and creation of 3D games than by looking at how this line of code has evolved over the years?
To that end, I have decided to work my way through the original Quake engine, take it apart and slowly rebuild it, examining each piece of code as I do so. What I hope to gain from this experience is a deeper understanding of how the engine itself operates, and how some of the biggest games in history solved the technical problems of creating enthralling three dimensional spaces.
Rebuilding a Quake Rebuild
The biggest issue that I faced initially was deciding on which version of Quake to rebuild. The purist in me wanted to build the original source code as it was released by id. However, the code they released was quite crusty even when it was released, and it took significant work to build. Today, with our 64-bit operating systems and blinding fast computer speeds, this would turn the project into a series of hacks that would much less informative and much more frustrating to deal with, and I quickly discarded it.
Instead, I have decided to rebuild the Fitzquake mod of glquake. Rebuilding this mod provides several advantages for my current interests:
- The code base runs well in Windows XP, which is the OS I will be using to rebuild it.
- Because it’s based on glquake, it uses hardware acceleration instead of the software renderer, meaning the code is much shorter and easier to understand than it would be otherwise (I will go into why I’m more interested in hardware acceleration later).
- The project has not been updated since February 2009, meaning it is stable and likely will not be updated while I’m working on this project.
Sure, there are advantages to using other versions of Quake, but I’m more interested in digging into the code and not getting into a religious war over the ‘right’ way to learn something.
Tools I’m using
Here are the more important tools I’m using for this project.
- Windows XP / Service Pack 3
- Visual Studio 2008
- Fitzquake version 0.85, updated February 12, 2009
- CLOC, to track how much code I’ve written
- DOS prompt, to type in command line arguments
- My brain, the best debugger I have on hand to do this work!
Why not Windows 7 or Visual Studio 2010? Because they aren’t on the computer I have here. Yes, I have Windows 7. Yes, I also have Linux. I’m not a purist for either operating system. I’m a game developer, and 90% of the United States uses Windows machines, so I use Windows. The industry is also in a state where developing in Windows XP makes sense, as we’re split in the number of people who still use it versus the ones that have updated to Windows 7. I haven’t even tried to compile Fitzquake in Windows 7, but maybe I’ll look into it in the future.
I’m going to start by creating a new project that has identical settings to the original Fitzquake Visual Studio project. I’ll make the directory structure the same, but I’ll strip out all the files. That way we can start fresh. I will likely leave in any Windows resource files, or any other non-source code files in, since we won’t be building those. The focus here is on code, not the environment outside of that.
Using CLOC on a completely shows the following information:
125 files consisting of 42,659 lines of code. The original Quake is much larger thanks to the software renderer. But even at this size, we have quite the project in front of us.
I’m planning on breaking this up into 100 posts. Each post therefore will cover about 425 lines of code. Probably what I’ll do is attempt to break up the functions we look at into roughly equal sets.
If you’re interested in what I’m working on, feel free to follow me on Twitter, where I’ll try to keep in touch with people. I’m excited about this, and hope it stands as a great learning experience for myself and for other people too. The end.