Interest In Handmade Hero

Recently my coworker and I have found great joy in following the first few episodes of Handmade Hero. While I cannot speak for anyone but myself I feel that the joy comes from feeling closer to the machine. This is the feeling Handmade Hero instills in you as Casey Muratori, a developer with 30+ years of industry experience, opens the door to a very different kind of programming in the setting of game development.

As a professional iOS Developer using Swift I feel a major disconnect between the activity I engage in daily and what the CPU actually ends up doing with my compiled application. This has bothered my subtly the minute I started writing high level code. When the programs I used to write as I was teaching myself the trade were simple they were close to the machine. I could look at the assembly produced by my little factorial program and just get a sense of what was going on.

As I have been working on the techniques introduced by Casey Muratori (the programmer behind Handmade Hero) I feel that joy of programming slowly seeping back into my sessions. I no longer am stuck in some other programmers object-oriented world. It's just me, the machine, a pixely little back-buffer and my imagination.

I was wondering if anyone else has seen or actively watches the Handmade stream and is perhaps interested in sharing their thoughts and testimonials, as it were. Perhaps, although I think this is hoping a little too high, there are even some projects out there that are a direct result of Handmade among the members of this community.

I implore you to check out the stream if you haven't already and perhaps pre-order the game (which provides you with the source code for each day so you can follow along). It's an eye opening journey that I am embarking on and I would like to make sure as many people as possible know about this. And while the stream has been running for over 4 years now I believe, I think it's not to late to start from the beginning.

See handmade hero's webpage here for more details.
Thanked by 1ladyinblack

Comments

  • YMMV, but personally I think Handmade Hero is a great example of why we don't do things that way any more. Kudos to the team for making this series and documenting it all, I think it's great that it exists, but it's 100% not what I want to be doing day to day with my time.

    Why? It seems like >80% of the streams are just re-implementing existing stuff and almost no time is spend on things like game design. At day 327 the episode is titled "Parsing Printf Format Strings"! And there are many other examples of stuff like that. Why do we need to keep re-inventing the wheel?!

    Personally I'd much rather be spending my time on solving new novel problems on a much higher level. Enough low level problems come up anyway. Even if that's not what I wanted, at the end of the day people don't care how you made your game - they only really care about the resultant product and their interaction with it - so that also means nobody is going to pay you to make games like this because it's super inefficient (with the one exception being niche performances like Handmade Hero).

    Sorry to be negative, but I do worry that stuff like Handmade Hero can give the impression that you need to know how to write every iota of your game in some low level language to be successful or a "proper" game developer, and that's not only plain wrong, but actively scares away wonderful people with super creative ideas that I would love to see making games and expressing their voice through games. It's 2019 and this sentiment is unfortunately all too common in the industry, especially if you listen to some famous game devs on social media (which is often one way people try get into the industry).

    Want to watch Handmade Hero for the educational, historical or entertainment value? Awesome, enjoy it! But just realise that it's super disconnected from the reality of game development, for very good reasons!
    Thanked by 2ashashza Ross
  • edited
    @Firguy, so do you enjoy Handmade Hero and writing low level stuff just for doing it? As in like making something not because you want to make a game, but for making something? I get that sometimes, and for some things. Like I enjoy playing Beat Saber for playing it, not for reaching some sort of high score, although passing harder and harder songs do give me enjoyment too. But if I never pass the song I'd been working on, that's fine too, mostly.

    I can't really think of many other things where I do a thing not for the purpose of finishing it and getting value out of the finished thing. Maybe sewing? Though I also would still use a sewing machine over hand sewing if I had the option for the thing I was making.

    So what I'm trying to say is that it sounds like you enjoy doing the thing for doing it, as opposed to enjoying the end results - and that's cool, so long as that's what you've identified that you like. @francoisvn said what he did because we've seen a lot of people who venture down the road of working in low-level stuff with the goal not of working with low-level stuff, but to build a game. That's like wanting to build a house by baking your own bricks from mud you harvest from the Vaal river, or something. It's cool, but if the goal is a house, Builder's Warehouse or whatever is where one should be looking.

    I hope you find other people who enjoy that sort of doing, if that's indeed what you're looking for. Not many people here has put time into low-level stuff, because we're too busy trying to figure out game design things...

    To be clear, not saying one thing is "better" than another at all, they're just different goals.
  • edited
    I have thought about this often. I have wondered perhaps if I really want to create a game I should just use a game engine. Perhaps that's the real economic solution... But then you have people like Jonothan Blow. Who almost single-handedly programmed Braid from a game engine he built himself. He then went on to create the even more ambitious game The Witness. If you were to ask the question: "Is Jonothan Blow's design abilities limited by the fact that he has to deal with a slew of low-level programming problems?", I just don't think you would come to the answer "yes". And so while when I first think of the scenario of building a small game engine from scratch to facilitate the specific game I want to create sounds like a lot of re-inventing the wheel then how can we explain a game design giant like Blow? He does after all think of himself primarily as a game designer not a programmer -- at least according to an interview. Now that's purely anecdotal, of course.

    The second thing I think of when I think about the impracticality of building things without a game engine is that I don't want the game's design and feel to be effected by the underlying system. I can't help the uncomfortable idea that if I sit down to learn a game engine and make a game in that engine I will be making a game who's identity will be inextricably linked to that game engine and in order to attempt to break that connection I will have to work against whatever underlying system I am using instead of with it. I have never shipped a game. So I don't really know what I am talking about here but I feel that when I see a Unity game I see that it's a Unity game before any explicit mention of Unity. An you might say "Well I could make a game and you wouldn't be able to recognize if I use engine A; library B or renderer C" and you may be very capable of doing such a thing but that almost doesn't matter because due to some mysterious factors the actual games produced are immediately familiar and have the feel of entity X where X is Unity, Unreal Engine or the like. So while this may have started out as a pure programming exercise I now feel that there is some reward in design to create things more fundamentally different due to the fact that when you start from scratch the notion of 3D geometry is not even necessarily a given and that additional-nothiness may be a more interesting place to start a game purely from the perspective of design.

    These are all just a bunch of ideas though. The may be wildly impractical. Only time will tell I suppose. Thanks @Tusim for commenting. Writing this reply helped me develop a few ideas that weren't yet articulated.

    The notion that "it's super disconnected from the reality of game development, for very good reasons!" is one I have to disagree with. If at least a few game developers were not good at the kinds of things taught within those streams higher level game developers would not be able to think at a high level because the low-level problems would not be solved. And low-level problems will continue to come up because technology will never stop advancing. While I think that the discouragement of potentially great (and even not so great) game designers from being creative is an evil thing to do to creative people in general, you should not discourage people from the potentially excellent low-level programmer that could lurk within them either. If someone came a long, some young programmer and did a bunch of low-level magic that meant that the large majority of designers who weren't willing to delve that deep were able to express high-level things much better we'd all agree that that's indeed a good thing. And therefore I think it has a large place in game design. Because the system you are designing your game in is tied ultimately to the lowest level of the computer. For game tech to continue to advance we as high level developers are going to have to rely on people like Casey and their willingness to delve deep. I believe the stream is seeking to preserve something more fundamental that particulars. It's meant to familiarize one with what it takes to build a game in general through a practical example of a professional game. In summary, if all programmers decided to be high-level then the fundamental tech which those high-level programmers relied on would stagnate, meaning that low-level programming (of the sort taught on Handmade Hero) is immediately relevant to high-level programmers and therefore in the design to modern games.

    It's too easy to just disregard the thing which is not immediately in front of your eyes. I believe a more balanced view should be taken. Handmade Hero is not dangerous or disconnected but it is not vital or even relevant, perhaps even for the large majority of game designers. As an aside, to say that low level programming is disconnected is to say that the very platform you are realizing high-level thoughts in is disconnected because those platforms are not realized themselves without low-level programming. Which is a tad ironic. The development community like to reflexively throw out the reinvention of the wheel thing but most of the time they are using it completely wrong. Most of the time programmers aren't reinventing anything at all. They are taking some well established idea and tuning an implementation to suit their needs. Adapting one of Jonothan Blows examples. Imagine someone who did not invent the wheel and was not in general a designer of wheels asked the person designing tank tracks why he was reinventing the wheel. There more I face these the notions the more they seem to crumble. Perhaps a rebuttal is in order? Thanks @francoisvn for prompting these thought and discussing this has also articulated a lot of vague thoughts for me.
  • Are you referring to this?

  • edited
    Like, reading through what you're saying, it sounds like your goals for your case you're building are:
    - To create things that don't look like other Unity games (If you just googled "games made with Unity", you'll see a hell of a lot of diversity and really great games. If you claim that you could tell them all as Unity games... I would say, hey I really don't care.
    - To advance game tech, which someone (a lot of someones) are already doing so I don't need to be doing that since I'm not interested in that.

    Mine are:
    - To make games.
    - As quickly as possible cos I don't have endless time/resource. In the time I might take to make an engine and learn to use it and fix it and use it and fix it, I could have built and refined 50 game prototypes. No jokes. Unity wasn't built overnight, nor was any of the other engines, Game Maker, Unreal, Pico8, etc.

    So it all depends on what your goals are.
    Thanked by 2francoisvn Gazza_N
  • Tuism said:
    Not many people here has put time into low-level stuff, because we're too busy trying to figure out game design things...
    Actually I've spent a bunch of time working on quite low level stuff (games in C/C++ and SDL, writing my own engines many times, water physics simulations, ...), and I know a quite few others here and elsewhere that have also gone down a similar route, but 99.9% of the time it's been a programmer's trap. Procedural generation is another popular programmer trap I've fallen into many times myself. It's super fun to work on, and it feels like you're making progress, but comparatively it takes ages to make something playable, never mind actually fun. When I compare the time I spent on systems like that, I realise I was just wasting my time and should have been following a different approach then (for example, first make some hand-crafted levels and then add proc gen later if it's really needed). The reason I wrote what I did and have written this reply is because I earnestly believe I could have made better use of my time and I don't want to see others repeat my mistakes.
    firguy said:
    I have thought about this often. I have wondered perhaps if I really want to create a game I should just use a game engine. Perhaps that's the real economic solution... But then you have people like Jonothan Blow. Who almost single-handedly programmed Braid from a game engine he built himself. He then went on to create the even more ambitious game The Witness. If you were to ask the question: "Is Jonothan Blow's design abilities limited by the fact that he has to deal with a slew of low-level programming problems?", I just don't think you would come to the answer "yes". And so while when I first think of the scenario of building a small game engine from scratch to facilitate the specific game I want to create sounds like a lot of re-inventing the wheel then how can we explain a game design giant like Blow? He does after all think of himself primarily as a game designer not a programmer -- at least according to an interview. Now that's purely anecdotal, of course.
    I think that's the wrong question to ask, and Jon Blow is frankly a terrible example to compare yourself to. You can't repeat his path to success, the circumstances are entirely different. Braid wasn't his first rodeo, it launched at a great time, and he had loads of money to hire an entire team for the Witness. It's also telling that while Jon is very vocal about a lot of stuff, he's not telling folks to write their own engines, especially not for their first game. In fact, I challenge you to show me successful game developers that are recommending that (successful = released a game and working full-time in the industry today), and I'll show you 5x as many that recommend you don't.

    Also, comparing yourself to just one outlier is the quintessential example of survivorship bias. What about the hundreds of other developers that have gone down a similar path, some of them much better coders than Jon Blow, and failed catastrophically? There's a very good reason that the overwhelming vast majority of the industry uses pre-made engines to make their games. Heck, even exceptions like Cliff Harris re-use large parts of their previous games when they make a new game.
    firguy said:
    The second thing I think of when I think about the impracticality of building things without a game engine is that I don't want the game's design and feel to be effected by the underlying system. I can't help the uncomfortable idea that if I sit down to learn a game engine and make a game in that engine I will be making a game who's identity will be inextricably linked to that game engine and in order to attempt to break that connection I will have to work against whatever underlying system I am using instead of with it. I have never shipped a game. So I don't really know what I am talking about here but I feel that when I see a Unity game I see that it's a Unity game before any explicit mention of Unity. An you might say "Well I could make a game and you wouldn't be able to recognize if I use engine A; library B or renderer C" and you may be very capable of doing such a thing but that almost doesn't matter because due to some mysterious factors the actual games produced are immediately familiar and have the feel of entity X where X is Unity, Unreal Engine or the like. So while this may have started out as a pure programming exercise I now feel that there is some reward in design to create things more fundamentally different due to the fact that when you start from scratch the notion of 3D geometry is not even necessarily a given and that additional-nothiness may be a more interesting place to start a game purely from the perspective of design.
    The idea that the engine will somehow limit your creativity is not really true. If you make your own engine, you'll just be constraining your creativity a lot more overall. Did you choose to use C++ instead of some other language? You're already adding constraints and affecting the kind of game you could make, but ones that you can't make an informed decision about yet! Going to choose DirectX/OpenGL/Vulkan/Metal/...? Yet another choice you don't really understand yet! How do you get to understand choices like that? By making games. And the quickest way to do that is without a doubt by using a pre-built engine.
    firguy said:
    The notion that "it's super disconnected from the reality of game development, for very good reasons!" is one I have to disagree with. If at least a few game developers were not good at the kinds of things taught within those streams higher level game developers would not be able to think at a high level because the low-level problems would not be solved. And low-level problems will continue to come up because technology will never stop advancing.
    I stand by my statement as someone that has actually shipped games and is working full time as a game developer. I think that writing your own game engine is a bad idea and is disconnected from the reality of how games are made nowadays. The reality of game development is indeed that developers are almost all working with pre-built game engines and that is just how games are made nowadays. This crosses the spectrum, from indie to AAA. Why? Because if they weren't then games would cost an order of magnitude more to make.

    It's also inaccurate to assume that if you use a pre-built engine you won't have low-level problems to work on. It's just that you'll have different problems, and many of those problems will actually be at the cutting edge of where technology is now. My day job is working on an MMO, and let me tell you about some of the low level problems we face on a regular basis, jeepers! Yip, we're using a pre-built engine, but these problems still come up all the time, it's just that they're actually new problems, not stuff solved by others years ago. We're also watching talks and reading articles by other developers to stay on the cutting edge - all of whom are also using pre-built engines.
    firguy said:
    For game tech to continue to advance we as high level developers are going to have to rely on people like Casey and their willingness to delve deep. I believe the stream is seeking to preserve something more fundamental that particulars. It's meant to familiarize one with what it takes to build a game in general through a practical example of a professional game.
    I honestly don't agree here. Casey isn't breaking new ground with his stream, he's documenting historical aspects that have been internalized by pre-built engines and older developers. I agree that the streams hold value, both in documenting and educating, but not in pushing any new barriers. It's also not actually how professional games are made nowadays, so it can't really expect to push new barriers. Even AAA companies don't make games like that these days, and goodness knows they have the workforce to attempt something like that

    ----

    I think you said it yourself with "I have never shipped a game," and "I don't really know what I am talking about here". I think it might be prudent to listen to those that have shipped games. Not just me, look at what others say and do actual research that isn't just trying to affirm what you already believe.

    I can pick apart your argument more, but it doesn't really seem worthwhile. There's so much evidence that writing your own engine for your first game is a bad idea. As @Tuism has pointed out, it's clear that you have different goals. We can't force you to change your mind if you want to go down that route. Your desire to be "unburdened" by the "shackles" of game engines is not new. I've experienced it, and so have many other game developers, but I don't think I've ever met a developer that has actually shipped a game and recommends writing your own engine, especially not for your first game.

    ----

    So what are your options here? No offence, but it seems unlikely you'll listen to advice and actually use a pre-built engine of your own accord, so here's an experiment you can try to prove me wrong:

    1. Spend a day/weekend re-making a really simple game (like minesweeper, tetris, or breakout) with a pre-built engine of your choosing. You can probably find a tutorial that'll take you a couple hours if you're already a good programmer, but it's a new tool so no worries if it takes you longer.

    2. Re-make that game in your own engine and see how long it takes. Days? Weeks? Months? If you can abandon if you think it's taking too long.

    3. Repeat 1 and 2 with a slightly bigger game or two that seems more like the kind of thing you'd want to make. Maybe a 3D shooty thing or a puzzle game or anything else - whatever you think will be fun. However, limit yourself to whatever you can make in 1-3 days (these are experiments and not meant to take long!)

    4. Write down a game concept or few. Try to think of the most creative ideas you can. Now that you have some experience with game dev from steps 1-3, spend some time thinking about how you can make those concepts in a pre-built engine or your own. What sort of actual limitations would the choice of engine place on your ideas? Time taken? Something that's not possible in one engine?

    Report back as you go and we can discuss the results. Either way you come out better informed and better able to make game stuff, be that with your own engine or not. In one case maybe you've demonstrated your aptitude for this and you can convince others to join you and make more awesome stuff, or maybe you'll start to see what I've been talking about. BTW, I've done a similar experiment before myself ;)
    Thanked by 3Tuism firguy Gazza_N
  • edited
    You know what. I should probably listen to people who claim they made the same mistakes. When I have a weekend free I will sit down to make a game in some high-level framework then rinse repeat using whatever was taught in Handmade Hero. Thanks for the reply @francoisvn.

    Edit:

    Will try get to it (at least some of it) next weekend. So I will post here when I start I guess.
    Thanked by 2francoisvn Tuism
  • edited
    @firguy Just regarding success stories with custom engines: I can think of a few companies that make their own engines and also make excellently designed games, Klei is probably the most successful of these.

    Also this guy's work is incredible:

    Also, Noita is one of my favourite games:

    I like Klei as an example because it isn't a savant super designer/programmer one manned team situation (like Jonothan Blow). There are brilliant programmers at Klei and brilliant designers at Klei and together they make brilliant games. One guy didn't need to become both.

    I think a lot of @francoisvn and @Tuism's concern stems from them being concerned that learning to be both a brilliant designer and at the same time build your own engine is too big of a task. Jonothan Blow actually has a talk where he mentions that he already had 10 years experience before starting Braid and he cautions against trying to do anything creative when you haven't mastered the technical challenges in front of you (i.e. innovation is difficult when implementation is beyond your current skills).

    But I'm not sure that you are excited about Handmade Hero because it seems like an efficient way to make excellent games. It seems to me you are talking about getting joy out of coding by doing the lower level stuff. Which is great. And you shouldn't be discouraged from seeking out joy in your life (obviously).

    And if this is the kind of thing that makes you (or anyone else reading this) happy, there are technically challenging game coding jobs in South Africa for someone with the right skillset. For instance, I know 24Bit do do some phenomenal work (though in Unity) writing code I don't always understand that does things I seldom knew were possible.

    I mention technical jobs because that's the sort of path than Jonathan Blow himself took to get to the point of building Braid. So that by the time he set out to build Braid he'd already become a damn skillful programmer.
  • All the points raised are excellent. Ultimately, the question is this: as a hobbyist, do you want to spend your limited free time creating fully playable games, or do you want to create tech? Neither is a "wrong" choice. In fact I'd argue from my (extremely biased) perspective that a baseline understanding of the tech will help you make better games. Just be aware that time and energy are limited resources (especially for long-term hobby projects), and it really helps to decide what you want to accomplish more so you don't waste either and lose motivation and momentum. I look forward to seeing what you cook up either way!
  • FWIW I agree that having an understanding of the tech can help you make better games. Although to some (small) degree it can also be a two-edged sword, because you can be tempted to do stuff the "right" way when the quick-n-dirty way would be better. I know I've had to try actively ignore that part of my brain trying to tell me to do stuff properly and just hack something together to see if it's actually fun. 9 out of 10 times it turns out the cheap way works just fine, or it's not actually fun and I've saved myself a bunch of time! In those cases, knowing how the tech works can be helpful cause you know your 5 FPS solution can be optimized later, it'll just take some time you can save upfront.

    OTOH if your aim is to create tech for games, IMHO you also won't be able to effectively create that tech if you haven't made a game before. Mostly because you don't have a solid grasp of the needs of game developers or those that might be using your tech. If making tech is your thing, then even making a couple of quick prototypes will get you a lot of helpful domain knowledge. You can then ask yourself questions like: What tools or libraries can you make to speed up your next prototype?
    Thanked by 1Gazza_N
  • edited
    Agreed fully! There's a give and take that needs to happen between robustness and just getting some code running to see whether it's even worth putting proper engineering time into at all. That's especially hard to do when you're not altogether sure what it is you're making in the first place. I also struggle with it, which is why I'm a dismal failure at game jams. I'm trying to get better. :P

    I agree wholeheartedly that using an existing engine is hands-down the best way to get started with this gig, but I'd not discourage people from digging deeper into the technology if they feel they want to, as long as they're having fun and feel they're making progress. I believe a knowledge of the tech to be valuable, but not if it actively impedes someone's goal of learning the overall craft of game development. Building a game and building a game engine are two very different animals, as everyone has been at pains to point out in this thread.
Sign In or Register to comment.