I happened across this randomly on Twitch, a programmer by the name of Casey Muratori is building a 2D indie game from _scratch_. He says he's doing it to teach absolutely every low level aspect of programming involved in an entire commercial quality game, including custom graphics and sound libraries, ai, compression, pathfinding, etc with no external library calls. The guy is one of the programmers that makes the Bink video compression you always see in the splash screens for big games, and most recently worked on Jonathan Blow's The Witness.

After watching a few of the streams, he seems to be a very good programmer, is entertaining and gives detailed explanations and I'm looking forward to following along. I've always been interested in the low level stuff and have never found a good book or tutorial series on making an application or game from scratch, this looks perfect to me.

The website is at http://handmadehero.org and the stream archives are on youtube.

I'm on his day 6 stream (think he's currently on like day 18) and have learned how to build my own pixel buffer to blit to a window and do some rudimentary animation, but more interesting has been following along his thought process as he decides what feature to tackle next and how to work it in to his existing code base, and all the digging in to the visual studio debugger and Windows API internals that you generally can avoid knowing anything about.

Thanks for posting this!

I'm excited to watch the videos to catch up to the stream and follow the stream when I can.

Still going strong on day 14 and really enjoying having someone of his experience level detail his thought process for the way he structures his code. For example, he has rather unique ideas about how to structure the code so that everything ends up in one monolithic compilation unit that we compile every time as distinct from using a build system that manages only rebuilding touched source files. He claims that for any project he's ever worked on up to hundreds of thousands of lines of code that it's faster than any moderately complex build system can manage even with parallelized compilation. It certainly reduces a lot of complexity out of a project that is only going to be handled by a few people, the current build file we're using is just a .bat with a single line call to the compiler that looks like

and from there the main platform dependent file includes all of the other relevant source files.

A lot of his other practices tend to follow that principle of coding in a style relevant to your purpose. Instead of spending a lot of time up front designing APIs and defining his abstraction layers, which are more relevant in huge organizational projects that require many people to be working on different parts of the same code base at once, he just codes whatever he thinks he needs and routinely goes back and "compresses" the code, a term he uses in place of refactoring though I'm not sure I understand what difference he sees in the two. Early on he had all of his DirectSound, XInput and graphics buffer code stuffed in to the game loop in WinMain() just to get all of the pieces up and running, and over the last few days he's been pulling it out in to seperate functions that pass their values in to the abstracted platform independent game layer. Instead of designing that abstract layer first and trying to shoehorn the way we handle the windows specific operations required in to that pattern, it's been very easy to figure out all of the general things the game will need and construct the game layer in tandem with the platform specific stuff. Basically the opposite of how I'm used to programming having been fed a steady diet of UML diagramming and object orientated class design that tends to frustrate me when I actually dive down in to designing my program.

I will say that he has crashed and burned in one respect, that he spent so much time in the beginning and in the Q&A parts of each stream trying to bring beginning programmers up to speed. Even with years of programming experience I'm seeing lots of new things and having to work hard to keep up by looking things up on my own. I don't really see any way someone unfamiliar with C, bit operations, pointers and the like would not give up in frustration after the first week or two, and it's just akward seeing him devote time to explaining what a #define is or what a for() loop is before diving in to code that casts pointers of differing sizes to the same memory chunk and performing bit operations on them, or some other similarly complex operation.

Yah I've been watching his intro to C videos and the Q&As to get me back to speed because its been awhile since I coded in C++.

Everything is foggy in C land for me but wow is this guy detailed in information.
Him pulling out the assembly language in the first few videos and showing the code in actual memory was fun to watch. His talks on the era of what changed over time and him ranting at Microsoft are worth the watch alone.

That struck me at video one. He introduces the command line, and instead of saying "Look, if you never seen this before, the newb stuff is ---->>>", he introduces it in the most empathetic way possible. I haven't watched more than the first video, but I'm definitely interested in looking at more.

On day 23 now. He's almost done with the Windows layer of the game. He claims aside from a few very specific needs, we'll never need to have any cross-talk between the two layers, where the platform independant game code will call in to the platform code which passes back information, or vice-versa.

Instead of using malloc() or new to dynamically allocate memory from the heap, he just asks for a huge chunk (1GB at the moment, he mentioned going back and determining this based on the resources available to each computer the game will run on) of memory on the Windows side at startup, and passes a struct to the game layer containing several pointers to that chunk which the game layer then uses to allocate memory from. This allows him to do things like compile the game layer as a DLL and hot-compile that portion while the game is still running, and he shows how to set the game to automatically unload and reload the DLL whenever the creation time stamp has changed, immediately updating the game while it's running with the new code. As long as there are no calls to portions of the chunk allocated memory that redivide it in new ways (like redefining the layout of memory structs in new ways and trying to access it in ways don't make sense in the old memory layout), all of the game state and memory is preserved across the dll recompile and things just automatically update on the fly and use the new code.

His examples so far are pretty limited, like changing the math of some drawing and sound functions or messing around with a player jump and fiddling with the math to get the jump physics right, but he's showing how to take advantage of the memory structure and DLL hot loading to save the input state of the game and allow us to make edits to the code while an input loop controls the game flow without us ever having to pick up the controller or issue any keyboard commands, seeing the changes in real time. I'm probably doing a terrible job explaining it, but you might be able to see how useful that can be in a bunch of different situations.

It's hard to follow the guy live, he's an emacs wizzard and jumps around the code at a million miles an hour making changes, but it makes for interesting debugging and helps you take on his mindset of programming and debugging while typing it in yourself following along on the youtube archives.

First time I've looked at this thread. Very interesting and thanks. I will take a look at the videos. Hopefully we can generate some further discussion. One point about your description of his style, being the lone developer for a project does tend to simplify some things such as decision making about design and overall architecture. On building the game, yes build systems can and do get complicated. For instance at least one large software company I know of actually has FTEs assigned to build teams for their products. In the last month or so I've been looking at GNU Make and make files that use it. There is a lot of implicit commands in Make that require one to know Make somewhat in depth at least. In digging through various make files my reaction is that I would make an effort to be more explicit and straight forward. As far as one monolithic build is concerned, well high speed multi-core processors are bound to help.

On day 37 ATM. I caught up with the live stream over Christmas but found following along with him live was impossible given how fast he moves and makes edits. My interest level is still high, and hearing him talk in random places about the game design has me excited for the kinds of systems he plans on implementing - this isn't going to just be a simple game as an exercise in 2d engine design.

So far the Windows code is mostly there and he's working on how the engine handles world positioning and tiling, and just now he's starting to move in to writing bits of the renderer. It was cool seeing him go through learning the bmp file format without really reading the bmp spec by examining the debugger to look at what the memory is doing and playing around with the values and some debug graphics.

At the same time, the last few weeks have been super slow and I think he's missing the mark by attempting to constantly iterate over basic functionality to come to what he actually has in mind in an attempt to better explain how we get to where he wants to be. That would be great if he didn't move so fast, but he makes so many changes constantly that I find myself not really looking at the big picture trying to keep up with him. It's not a big problem at the moment as the code is fairly simple and obvious what we're doing, but I can see this method not working as well when we get to more advanced parts of the code.

Also the 30+ mins of Q&A at the end of each stream have been pretty useless for the most part, I wish he would have his mods cherry pick some decent questions over the course of the stream and let him go over them at the end instead of sitting through him trying to filter out all of the "How do I get a job as a game programmer" or "Why aren't you using language X?" type questions.

Anyone else still working through this?

Very excited about this. A guy at work has been way into it, and got me stoked about it. Even though the likelihood of me developing anything for Windows ever again is nil, I sounds like there is a ton to be learned.

The game is going to be made cross platform (not just windows)

Thanks for posting this. It's very enjoyable.

I'm just about to finish the refresher C for Windows course. It's been ages since I did anything in C so I'm watching it but it's a decent watch. He's a great communicator.

Can't wait to start the main videos proper. Hopefully it'll be at some stage tomorrow. If the quality of the videos maintain I hope to catch up to the live stream in about a month

Bothers me every time he takes a drink. Couldn't make it thru the first one.

Surely you'd benefit more than other by watching it?

I have notived the drink thing. Smalls nits though. He also says shenanagans too much.

If it's still around I'm absolutely going to watch it in a year or so.

But I don't understand most of what he's saying at this point.

I'm on day 58, things are definitely starting to drag a bit. The last week or so has mostly been restructuring code around introducing entities and changing the tile map scheme.

It's also starting to wear on me how haphazard his changes are. For example, he'll introduce rather major structural changes to his code very quickly, then just run the compiler and make the necessary changes on the lines that are erroring. It's been working for the most part, but he leaves spaghetti code all over the place with multiple definitions of the same variables or using different names and ignoring the ones he could use that already exist, long sections of commented out code, and long rambling functions. The program logic is also a bit messy, with changes in one place requiring edits to a large portion of the code base.

He's addressed these criticisms a few times. He seems to alternate between getting a little annoyed and asking what exactly is incorrect or messy, or claiming it's just boiler plate code while he's exploring how he wants the engine to be structured, and it'll all either be removed or reworked eventually. This seems to work for him as he appears able to hold most of the program logic in his head and can made all those edits very quickly and precisely. But it makes understanding the code for people following along harder, and doesn't give me any confidence that he'll ever go back and clean it up.

Obviously it works for him as he's 20 years into a very successful career, and does appear to know his stuff. I've learned a lot so far, and been introduced to a style of programming I had almost entirely dismissed.

I will confess I have not had a chance to look at it yet. I will take a look though, should be interesting. I have a tendency to "wing it from the keyboard" but that isn't always the best way to go because often with a little thought a better solution becomes apparent.

I think what he is doing is the only right way. This is how you learn to do stuff. What you see in the result of our Cepheus poker bot is only a very small fraction of things that I and other people have tried. It's not a magic equation.

Very interesting and educational. I am slowing working through the series myself. I agree it's kind of funny he will stop and explain very basic programming concepts (this is how a switch statement works) and then dive into ridiculously advanced concepts. Kind of interesting he does not use source control. Does not need to be very frequent commits, but it seems like he would like to take snapshots of his code every once in a while when it is in a known (mostly) working state. You never know when you're going to have that one tiny mistake that you spend hours tracking down...sometimes it is better to be able to just revert to a known good state!

Does anyone know of any similar series to this? Hopefully at a level a little higher than c? Java/C#? Would be interesting to see someone fire up a web server and build a web site from scratch or something along those lines.

As far as source control, he just zips his entire project source up every night. If you preorder the game you get a link to a file that contains the source for each night, along with any art or sound assets he uses. I've had to roll back my code a few times after missing some of his super fast edits and not being able to debug what I missed.

Also I think he'd take offense at the notion that someone could achieve the goal he's aiming for with his series by showing how to code a web app or the like But I get your meaning, and I hope this style of long form video tutorial takes off. It would be cool to be exposed to different programmers and their styles and ways of thinking while designing something complete from the ground up, while also learning something new like database backends, web site design, 3D modeling (there's actually a fair amount of this content out there, but most of it behind a pay wall), game music and effects and the like.

I think I'm on day 72 at the moment, been stuck there for a week or two. You have to admire his consistency, although I think he's making more than $2k/mo from his Patreon along with sales of the game, so he must feel some financial obligation to stream even when he's not feeling up for it.

I haven't really messed with this in over two years, I got sidetracked around day 80 and never got back in to it or really anything programming related since other than Zachtronics games. I still see him in my Twitch dashboard though not as frequently, it looks like he's on day 390 now and his Patreon has gone down to $1k/mo from over $2k/mo and only doing a few videos a week. It's a bit shocking how little obvious progress he has made, somewhere along the line he worked OpenGL rendering in and now he's working on lighting, so I suppose most of that time was spent on getting the engine architecture and debugging tools all squared away.

Anyone still sticking with this? I think I'm going to dive back in, but try to pace myself so I don't burn out like I did before, maybe do 2-3 a week.

If only it were the Android OS, then I'd be watching every day.

Never watched any of this, but:

Maybe the operative lesson here is "making game engines by yourself is really hard".

It is extremely easy to get caught in opengl hell. Tweaking shaders for ****ing ever. It's also pretty hard to debug. I don't do game stuff but I've used openGL a lot for 3d visualization of stuff. I've put a lot of effort into it and I'm still probably 5 years behind state of the art.

That's my take away.