Announcing Handmade Quake!

I am proud to announce Handmade Quake, a series dedicated to the art and engineering of 3D video game programming.

Handmade Quake will be a series of videos and blogs where I rebuild the original Quake from scratch, line by line, system by system. It is named Handmade Quake thanks to the inspiration of the Handmade Dev community, and following the spirit of their manifesto, we will be starting with a blank Visual Studio project, nothing pre-written at all, and file by file, will turn it into the source code that id Software released to the world in late 1999.

The main goal for this project is to show you how full video games are actually built. As I was working towards my master’s degree in video game technology, I was surprised at the lack of high-quality materials, either in book form or online. Books tended to be light on info, usually teaching a language at the same time as discussing games, so they weren’t able to go into detail in either topic. Others talk exclusively about game development, but either provide no source code or basic demos that just don’t get into much depth at all, and are not intended to be played as games themselves. Basically – I want to learn about games, so show me a game!

Quake is a landmark in video game history. It practically defined the first person shooter genre on its own. It made a fully 3D real-time world possible on a 486 processor almost 20 years ago. It was cool, it was exciting, it was scary (depending on who you talk to). id Software then went on to license the engine to other companies – one of which, Valve, used it to make Half-Life, Half-Life 2, and then the Source engine. So it’s quite likely you’re playing games today that are direct descendents of Quake. There may even be some original lines of code still in there!

As a AAA title, Quake needed to solve a ton of problems. Software rendering, raw audio, memory management, networking, file I/O, input, map loading, and then running the entire simulation while you’re playing – these are all difficult challenges that are rarely addressed in detail. I want to provide you with a framework for looking at it through this classic gaming lens.

So, how will Handmade Quake work? The aim of this series is to be modular rather than linear. I say this because it’s quite possible this could stretch into hundreds of videos before it’s all said and done. If you’re curious about a system discussed in video #100, it seems unreasonable to tell you that the only way to truly understand it is to go through videos #1-99. That’s not a realistic request. It probably won’t be 100% possible to follow this exactly, but here is my three step plan for each system.

Step 1 will be the theoretical foundation for each system. We will discuss the problem that Quake faced, the part it needed to do its job, and about how that problem would be solved in a general sense. We will then “plan out” an API to solve this problem for us. I use quotes because we’re not actually creating anything, we’re using the solution Quake provides. But by looking at the problem, we can understand why they went the way they did, and how their solution is good – and to be frank, sometimes their solutions are messy too, and that’s a conversation we can have too.

Step 2 is implementation of the API we designed. To assist in keeping the videos modular, and to make them a more educational process, we will not put the implementation directly into Quake. Instead, we will implement it in its own project, so we can see it running on its own. This will make it even easier to examine the system on its own, and to be even more objective about what’s good and bad about it. This is where things may be tricky – I can’t very well render a scene without a window, as an example – but it will be much more beneficial still.

Step 3 is integration into Quake itself. We plug it into the source code, we attach it to the existing code, and we see it running in the main game. We admire the handiwork that has gone into everything – and then we move on to the next system.

The end goal should be a series that is relatively easy for you to skip around in. We’ll end up with dozens of systems, certainly, but they’ll be separate systems that you can hold onto as inspiration for your own projects down the road.

If you’re looking for some action steps on how to prepare for the series, let me give you a few.

First, subscribe to my YouTube channel so that you don’t miss anything. I’m aiming at a couple videos a week, but I don’t have a set schedule just yet. This way you’ll keep up to speed on where we are in the process. I’ve just put up a shorter preview series showing how to build the Quake source code once you download it from id’s Github account. This is not a necessary step for the main series – we’re starting from scratch, remember – but it’s pretty cool to know how to build the game yourself. Here’s the playlist for that series: Building Quake from source code.

Second, sign up to my email list. This will give you direct access to me. If many people are having similar problems, I’ll address those problems through here. If you have a question, you’ll have my email address. Email me – I promise to read every email I get, and unless I’m getting hundreds of emails a day, I’ll do my best to respond as well. The signup is on the left side of the screen, and here it is as well:

The series will likely be starting right around the beginning of 2016. With that being the 20 year anniversary of the release of Quake, and a busy Christmas ahead of me, that seems like a great time to get going. So sign up on YouTube and by email, and get ready. This is going to be the year that we all get serious about our engine programming skills!