Casey Muratori has been creating tools for games for well over a decade. He worked on Bink 2, the ubiquitous video compression technology, as well as The Granny Animation SDK, way back in 1999. He's also done a fair amount of work on Jonathan Blow's upcoming The Witness, rewriting the movement system and helping to extend the world editor. 

It's a surprise, then, that someone who has spent most of their career creating tools to help developers do the things they need to has decided to help people circumvent them. Handmade Hero, Muratori's latest project, is chronicling the development of a game made entirely from low-level programming.

Everything, from the basic game engine, to the rendering and audio, to the high-level game systems themselves, will be coded from scratch, and filmed while he's doing it. Muratori hosts a regular Twitch stream (weekdays, 8pm PST) of his work, explaining what he's doing as he's doing it, as well as putting the whole thing up on YouTube.

I talked to Muratori about his motivations to make Handmade Hero, as well as the state of game engines in the industry today, and what the future might look like as they become more commonly used.

Can you explain what Handmade Hero is, as well as the intent behind it?

Sure! Handmade Hero is a combination of two things I've always wanted to do: 1) record 100% of the coding for an entire game, and 2) make a game where I wrote all of the code involved. And by "all of the code" I literally mean all of it. We're going to try to have a Raspberry Pi version at some point where it boots straight into the game -- no operating system, no graphics driver -- just like the old days. 

The intent is similarly half educational and half personal. The educational part is about showing how real, low-level game programming happens, minute-to-minute, in a way that people new to the discipline can watch and learn from. it's a much more direct, in-person way to learn programming than what you get form reading a book or a blog. I feel like it's a good way to teach programming, because at least personally, I've always learned the most from programming alongside more experienced programmers. There's something about watching someone program that you can't get from a book or a lecture. 

The personal part of the intent is about recapturing a little bit of game development history that I was born too late to be part of. I got into the industry just a few years after people stopped writing games, where, you know, you booted directly off the game disk and the game was the only thing running. Those were the types of games I played as a kid, but I never got to make one like that commercially. This is also my chance to go back in time a little bit! So it's a personal goal for the project for me to make sure that, when it's done, it runs on at least one homebrew platform where we can take over the whole machine.

The amount of time you've promised to invest in the development of Handmade Hero is not insignificant, and when you see it on paper it actually seems a little insane. What made you decide to commit so much time to it?

Well, I'm not getting any younger! So I decided if I was going to finally do a project where everything was recorded, I would have to do it pretty soon. I enjoy programming and I also enjoy explaining things, so really, an extra 10 hours a week of doing those things isn't too bad. Plus, it's a project I really believe in, and it's always easier to make time for something you believe is important to do. 

It almost seems like Handmade Hero is a reaction to the ubiquity of game engines like Unity and Unreal, which have made it so easy for small developers to get a foot in the door of game development. Do you think that ubiquity is a bad thing?

No, on the whole I think it's a good thing. I think we want to have tools that allow people to make games quickly. We've undoubtedly already seen good games come about because of Unity, Unreal, Flash, Game Maker etc., that never would have happened without them. But I do think there are two downsides to this trend, and they are downsides we can (and should) be taking steps to correct. 

The first problem is that if everyone in the next generation of game developers decides to use a pre-fab engine, who will be left to make the new engines? It may sound like a silly thing to say, but I think it's a real concern. Game engines are extremely complex things that require a tremendous amount of knowledge to create and maintain. And that goes double for engines like Unity and Unreal that are meant to be generic and handle a wide variety of game types.

So if we look down the road and say, who will be making the big additions to Unity in 2030? Who will be developing Unreal Engine 12? As an industry, we'd better have a good answer to that question, because eventually all the developers who are working on them now will retire, and there will have to be talented, experienced programmers ready to step into those roles.

When creating a game required difficult programming, we naturally had a system where people who wanted to make games would have to learn engine programming and develop those skills. But the ubiquity you describe has removed that natural system, so we need to make sure we have a culture in place that will continue to cultivate engine programming excellence in its absence. 

The second problem is that we have not yet succeeded in creating game engines that truly remove the low-level programming component entirely. You cannot just arbitrarily make whatever you want with these tools and forget about the limitations of the hardware, and perhaps more commonly, the limitations of the tools themselves. You constantly bump into those limitations in a number of ways.

We see this sort of thing happen in practice all the time. To pick just one example, The Binding of Isaac -- a game I greatly enjoyed -- recently had to be re-coded in its entirety because Flash proved to be such a limitation for the developers. They couldn't add more content to it, and they couldn't get the frame rate up, they couldn't add proper joypad support -- the list goes on and on.

When I think about that, I think about how incredibly frustrating it must be for the developers to end up in this position where they literally cannot move their game forward because of the tools. They know what they want to achieve, and they are being throttled by their tools. There's a temptation to blame the developers in these scenarios, and say "you should have used X instead of Y" or "you shouldn't have coded it like that" but really the developers are doing exactly what they were supposed to do: use a game development tool to make a game! They weren't supposed to have to know about any of this stuff, right?

So I think we want to try and fix this problem culturally, too. I think we can do a lot more to provide good teaching materials for all skill levels of game developer. i think we can make it so that it's fun to learn about low-level programming. If high-level developers have easy ways to learn and understand how all the parts of an engine work, even just at a basic level, then they will be better equipped to deal with performance problems and systemic problems as they arise, because they'll have a better understanding of what's going on under the hood. And perhaps most importantly, they'll know what's possible, so they'll know what to demand from tool vendors, which will drive the tools forward in the right directions.

What are the advantages of coding your own engine?

The most obvious advantage is that your only limitations are the physical limitations of the hardware, and that can be very empowering, certainly. You know what game you're making, and so you don't have to pay the cost for the generic nature of a licensed, one-size-fits-all game engine. You can tune everything to be in line with the needs of the game, which allows you to be more efficient than an engine that was written without having any idea what kind of game would be built on top of it. 

But there are other advantages, such as the psychological benefit of everything working the way you think is most natural, so that you don't feel like you are fighting the engine architecture all the time. Sometimes it's easy to underestimate the degree to which that wears programmers out and makes them unproductive. Feeling like you're spending all your time learning and working around someone else's code can be very demoralizing, and it can take all the fun out of programming. 

That being said, the reason to make an engine from scratch for Handmade Hero was not because I want to encourage everyone to make their own engine. We're making an engine because it is educational to do so and is an important part of the learning process for future game engine developers. Yes, we will get benefits from making our own engine -- in fact, we already have looped live code editing, a feature I don't think exists in any commercial engine right now -- but that is not the primary reason for doing it on this project. 

In your mission statement for Handmade Hero you've said that you're aiming to have it be as complex, systems wise, as you can manage, to properly demonstrate how to code those systems. That seems like a pretty daunting task, with a lot of moving parts potentially colliding. Do you worry that you've bitten off more than you can chew?

From the perspective of how long it will take to explain everything on the livestream, it's actually not the game systems that scare me. They are often straightforward to explain, even when they get complicated, because people can directly relate the operations back to things they already understand. If you've ever played Magic: The Gathering with a rules lawyer, you understand the basic process that a complex game system goes through to compute what happens on every event, because you've lived it!

So honestly, I'm more worried about explaining some aspects of the renderer, like pixel centers and fill rules, barycentric coordinates and interpolated values, or the lighting equation. Sometimes it's hard to bring those to life in an understandable way because they are so abstract and are very different from anything that people have experienced before if they're not graphics programmers.

And it's definitely the case that I have good days and bad days in terms of my ability to explain things on the stream. Sometimes I feel like I did a good job putting something out there, and other days I finish the stream and just think, "that was absolutely terrible, nobody is ever going to understand that!" But I do the best I can, and my hope is that for the times when I fail to explain things in a coherent way, we can make supplemental materials to the stream that will pick up the slack.

What has the reaction to Handmade Hero been like so far? Do you have a dialog with your audience?

The reaction has been way, way beyond what I ever could have predicted. I figured this would be a niche project for a long time. My hope was that once I got to the point where there was a renderer and a sound system and a little character walking around levels with monsters -- you know, 10 months into the project or something -- people would see the game in that alpha state and think it looked interesting, then go back and look at the video series to learn how it was made. But much to my surprise, it turned out that there was a huge audience for the project right from day one. 

There's also tons of people who have been contributing to the project in a number of ways beyond just watching the show. People have created an online episode guide with time-based links to each segment of the videos. People have ported the game to Mac. They've ported it to Linux. They've ported it to Qt and Swift, even! Somebody even said they were working on a compiler -- from scratch -- to compile Handmade Hero! It's fantastic.

I'm so happy to see all these people getting excited about low-level programming. For some, it's their first introduction to low-level programming, and I am delighted that they're finding it so rewarding. For other people, they already knew how to do low-level programming, but they just didn't have a rallying point for it. These are people who work in other industries, perhaps, who use Java and other high-level languages in their daily work, and Handmade Hero is this nice excuse for them to start doing some fun low-level stuff. And that's just plain great. I never anticipated that part of it, but it's possibly one of the best aspects of the project so far.

I can't tell you how many people have written in to me and said something along the lines of "this makes programming fun again!" And that's exactly how low-level programming feels to me, too. It's just a ton of fun! And it's been tremendously rewarding sharing that experience with other people. 

You've been supplying tools to the games industry for over a decade now. It Handmade Hero a reaction to a specific problem you've observed in that time?

No, I've never really observed any specific problems as a tools author. I always worked on pretty low-level tools, so anyone who was using the tools I was writing was usually also a low-level coder like me. 

Since you've started, have you found the development of Handmade Hero has taught you anything you didn't know before?

In the large, perhaps not yet, but in the small, definitely. One of the surprising things about Handmade Hero is that there are a lot of experts who watch the show just because they enjoying having a show about the kind of programming they do. So every now and then I'll get clarifications from an expert during the Q&A. If I muse about something on the stream like "I don't know how wide the SIMD instructions are on the Playstation 4 CPU but..." it's often the case that during the Q&A an expert will write in and answer. It's pretty great!

Do you have a pre-planned "lesson play" for the things you want to teach?

I have a plan for what I want in the game, but I don't have a lesson plan. I think programming should be very fluid, and that's one of the things I constantly emphasize on the stream. Programming can, and should, be fun. A lot of time the best code is the code that you enjoyed writing. And there's no question that you get a lot more code done when you're having fun than when it feels like a grind. So I try not to make things overly formal, or force what we code to fit into some Procrustean bed like a lot of programming methodologies encourage today. We don't have a schedule, just a feature list, really, and we start each day by figuring out what we can do to drive us forwards.