I've built a career using game engines other people have made. Sometimes it bothers me that I do not know what's going on behind the hood because of all the layers of abstraction. It's nice to be able to make something quickly, but the programmer in me feels sad that I'd have to trust things to just work without me knowing how.
Handmade Hero showed me how things work behind the scenes and it inspired me to be more aware of the internals of what I'm using as much as possible. Now I make it into a point to delve into documentations and source codes and am now also playing around with low level languages (Like C and Rust) during my free time. Overall these have helped me a lot and I look forward to improving myself more.
So kudos and thanks to Casey for this series. It has helped me strive to become a better programmer.
This is a really good series by an experienced game developer that's basically free (or at least the Zed Shaw model of pay to download but free to view).
Every now and then I pick up the current version of the code to see what it looks like, but there's no way I'm going to follow it through to the end. But for me, it does work as a reference for the various parts of the code he happens to be working on at the moment, and sometimes he stops to give a tutorial on something like basic 2d physics.
Watching the process overall is useful but if anyone is intimidated by the length of the stream I would suggest approaching it non-linearly.
He seems to have turned off comments on his Youtube stream, which I find disappointing. A lot of the value I've gotten from the early videos came from the comments people made either agreeing with, expanding on or disputing what was discussed.
I know from my own experience, though, that it can be "fun" to explain things that you know inside out in (too much) detail because it gives you a feeling of satisfaction and appreciation of the material you're going over.
However, I can't help that for anyone to whom you have to explain high school math episode after episode, the rest of the show, i.e., actual (and sometimes rather low-level) programming would be completely over their head.
That said, I do enjoy watching the shows quite a bit and I still plan on finishing the full run. I just wish the trivial stuff wouldn't receive so much time, or that there was a good way of skipping forward without having to fear to miss something important.
One really awesome thing is that the source code is bundled up after each episode so that you can really easily get back to speed after a longer break, like in my case. What I plan to do is to find the last episode I watched, then download that episode's code, and remind myself of the current state of affairs by studying the code, rather than trying to remember the content of everything I already saw.
I think this whole series is such a cool thing to do. And you can really tell that he knows his shit.
Casey, if you hang out here on HN, two thumbs up for this awesome effort!
After watching through most of the series, and writing a 3d engine (HH style, no libraries), I have internalized an amazing amount; the vast majority of what Casey's gone over. I agree that often times he goes into more detail than necessary - even for me, who started knowing literally nothing about what he was talking about, but I would attribute the amount of learning I've gotten out of the series to exactly that. For someone that doesn't understand the difference between an Object Transform and a Camera Transform, the only way for them to actually learn what they are is to hammer it home again and again - through examples and practice. I think I am exactly his target audience - young programmers who want to learn how to make video games.
Just my 2c
Game development is a great way to either brush up on your linear algebra skillz or motivate you to develop them in the first place, so he can't assume that his audience is either fully up to speed or completely ignorant.
Streaming a coding session over a well defined feature seems like a really good idea to stay focused .. like XP except not terrible and make you want to stab your partner in the face.
I watched about a dozen Handmade Hero episodes, and I was a bit annoyed that every session resulted in a random hunt to fix a bunch of bugs because there was not sufficient abstraction. It wouldn't be so bad if the abstractions were upcoming, but Casey seems to have an aversion to abstraction and I stopped watching because I grew bored of watching him jumping around in a bunch of files trying to figure out what memory write caused an issue at run-time.
And this is especially true in games because you need to get all abstractions right otherwise the game will be limited and/or not performant enough.
In many other programming fields you don't get punished for adding a few abstractions that are not strictly necessary, so usually other programmers are used to abstracting things away fairly early (eg in OOP: properties vs public variables, ...) because they're free as long as you don't overuse them.
Also you should keep in mind that the stream is educational so Casey sometimes takes the scenic route before getting to the point, and he's both implementing the engine and designing it, so sometimes he doesn't know yet what he wants exactly.
I actually find it amazing that sometimes 400 hours of programming and 2 years later he goes back to code written in the first few weeks and is fairly easily able to modify it to work with a new system that's just been implemented.
With the same restrictions of course - relatively little dynamic memory allocation, and hitting frame rate consistently on the lowest supported platform.
You would likely still encounter bugs while building the abstractions to not have bugs. It might be neat if you could pick out a particular example and show how your approach would have avoided the problem or be quicker though.
If I wanted to follow along on a Mac instead of Windows, how different of a process am I looking at?
He likes that its configuration language is C, so he doesn't have to learn a configuration language to get things done.
Watching Casey add some fairly powerful features in the editor in an hour or two, including using Windows APIs directly, was quite illuminating.
For my personal projects I've adopted a lot of his style, which is very enjoyable to work with, and I found no downside.
I think the biggest benefits attributed to OOP are really from splitting up the namespace into more manageable pieces. This can and usually should be done in larger C and C++ projects even if you're not using an OOP approach. The defaults in this regard are a little unfortunate, but both languages provide tools to do it (internal/"static" linkage in C, namespaces and using declarations in C++).
It's a mix of livestream development and democoding (mostly Rust and C++) and super-detailed breakdowns of demos and tools he's built. He does a super good job of taking effects and tools that seem very intimidating and breaking them down into understandable parts.
Commenting to ask if anyone has additional resources / streams / guides on those topics they can recommend.
Beyond that, if you're interested in physics look up everything Erin Catto has written about the design and implementation of Box2d.
My background is in physics, that part interests me the most, I'd be happy to make a physics sandbox myself.
Casey is really well known in the gaming community - https://mollyrocket.com/casey/about.html Through Handmade Con, he's also interviewed many other creators like Jonathan Blow and Edmund Mcmillen. He also contributed to Blow's recent game, The Witness (specifically the movement system and the world editor).
I can not throw a basketball into the hoop - and if it would save my life. Now i could downplay all the NBA players, calling it a "nice hobby", a gimick to sell shoes.
Or just admit with a nod of acknowledgment- that i will never be this good. Literally cant be. And its okay.
If you want to put a bit of time in everything shown is easily attainable and that’s the point. None of this is cutting edge, it’s basic making games stuff without libraries and a fairly modest goal in terms of the actual game.
Spouse? What happened?
I don't think he's in it for the money. I think that he, and many game developers of a similar vintage, are frustrated with the direction that modern software has taken. It's slow, getting slower, and often doesn't work correctly. I think this is his way of expressing that frustration, by teaching how the machine you're programming ACTUALLY WORKS. I for one have gotten more out of Handmade Hero than any other single source of learning in my life.
Maybe the ROI is the feedback and such from the community that has popped up around the game? That, and the $15.00 per copy to get access to the source code as the series goes on. But I'd be willing to bet that the feedback and community is the driving thing for this guy.