4 ms·

This looks to be similar to the Handmade Hero project (https://handmadehero.org/ https://handmadehero.org/) which I love, but rather than building a modern RPG

This looks to be similar to the Handmade Hero project (https://handmadehero.org/ https://handmadehero.org/) which I love, but rather than building a modern RPG in the case of HH, Handmade Quake seems to be focused on rebuilding that familiar classic shoot-em-up, step-by-step, one line of code (and presumably one concept) at a time. I'm sure the folks at id would be pleased, as they routinely opensource their games to share knowledge with others. These two projects are as close to a game development masterclass as one can get.

stagger87 11y ago
If your goal is to learn about game development, I would avoid Handmade Hero. Over 200+ days into the project, and he still has a rats nest of a 90's era style Windows code base. It's clear he didn't put any pedagogical thought into the project. Masterclass is the wrong word to describe HH.
- AlexeyBrin 11y ago
  You are as wrong as you could get, the Handmade Hero project has about 200 hours and not 200 days as in 200 working days. Everything is coded live and recorded, so for 200 hours of work he is doing quite well. The Windows specific code is localized in the platform code and this could be swapped with something Linux or OS X specific at any time.
  - User0124 11y ago
    Come one, don't do a strawman. Parent is factually correct that HH project has been going on for 200 days. Nowhere was even implied that 200 working days were put into the project.
    - AlexeyBrin 11y ago
      All it matters is the actual time spent coding, 200+ hours of coding is well reflected in the actual code size and game development.
      - User0124 11y ago
        All it matters is the actual time spent coding False dichotomy. If that were true, skill and knowledge wouldn't matter.
      - w0utert 11y ago
        It's not exactly 200 hours as Casey regularly goes well into the Q&A session and adds things past the first hour. But that's not really the point the OP was making, I guess. I really enjoy watching HH and I have nothing but respect for Casey and the way he's doing these videos, but you can't possibly maintain that the code he's writing should be taken as an example by anyone. The HH code is just plain bad, dangerous, unnecessarily 'optimized' (read: taking ugly shortcuts or incomplete simplifications) in places where it doesn't matter, while super-inefficient in places where it does, it's untested, full of TODO's, does not use any modern language/compile features, it's basically just a lot of lines of code thrown together with minimal design (I do like his seperation between the platform layer and the game layer though). I've watched and enjoyed over 100 hours of HH, and the process the game is going through is very interesting, but in terms of code quality and suitability to 'learn game programming' I would not recommend it.
        AlexeyBrin 11y ago
        While I don't 100% agree with how Casey codes I wouldn't get as far as saying that The HH code is just plain bad, dangerous. He defined a problem space (implement a game like in the 90's with a software renderer) and decided to use the common parts of C and C++ for the actual implementation. You made me curious, what do you consider a good programming style for game programming ?
        w0utert 11y ago
        >> While I don't 100% agree with how Casey codes I wouldn't get as far as saying that The HH code is just plain bad, dangerous. He defined a problem space (implement a game like in the 90's with a software renderer) and decided to use the common parts of C and C++ for the actual implementation. Well, I would ;-). I think the quality of the code he writes for the game scores low on almost any objective measure of quality except pragmatism. >> You made me curious, what do you consider a good programming style for game programming ? I don't think there is a single 'good programming style' for games, it all depends on the game, the development environment (language, tools) the third-party components you use, the target platform, etc. I think there's a lot of best practices you could apply to any game though. Applying abstraction in those parts where it matters and doesn't negatively impact performance, for example. Defining the components of your game and keeping clear boundaries between them. Making good use of the language features at your disposal. Not obsessing over constant factor performance 'optimisations' before you know where the bottlenecks are. Thinking about and preferring efficient algorithms and data structures, over quick & dirty 'handmade' data structures, just because you feel STL or boost are 'not efficient' (it doesn't matter for 99% of your game code, especially not for something simple as HH). Not passing around naked pointers everywhere. I could go on for a while... If you watch Casey work on HH, most of the time he's fiddling with and rewriting the same things over and over again, because he feels that he always needs to program everything 'in the simplest possible way' first, and then rewrite when necessary. I don't disagree with throwaway code at all, and not everything always needs to be 'designed upfront', but he's taking these things to the extreme, which results in an entangled mess of spaghetti code full of bugs (which you'll have seen he runs into in almost every episode of his stream). He basically disregards all the advances we've had in programming since the 90's, and keeps hammering in C-style code that happens to be compiled by a C++ compiler, but doesn't use any of the advantages C++ provides. I still like to watch him do it though because there's definitely educational value to his videos, and he does solve some interesting problems along the way. And because I've been working on a simple game myself for a while. In my earlier comment I refrained from plugging my own little side-project but now you've asked you could take a look here [1] if you wanted to see how I like to program games. It's about an equal amount of hours in as HH but it already has some actual gameplay, is fully scriptable using Lua, Box2D physics, a sprite-based OpenGL rendering backend, persistency (freeze/unfreeze), action replays with live code updates (inspired by HH, but done 'the right way'), texture-mapped truetype font rendering, some interesting 'handmade' algorithms (complex polygon triangulation, sprite packing), motion controls, etc. I realise it's not the same thing as HH as I prefer not to re-invent the wheel for everything and use libraries and frameworks, but I still feel it's much closer to how you would program a 'real' game using modern technologies. [1] http://www.wouterbijlsma.nl/blog/ http://www.wouterbijlsma.nl/blog/
- User0124 11y ago
  Has the refactoring of the code to separate files been done yet? The last time I saw it, it was one big file.
- krapp 11y ago
  I've learned a lot of useful stuff watching the Handmade Hero feed on Youtube - but I stopped trying to follow along directly after the second week or so. Casey seems to harbor grudges against C++ and object oriented programming (both of which he will expound upon at length) that lead him to pile obfuscations and abstractions into his code that make it difficult to approach as a student, and difficult to separate what should be best practice from "stuff Casey does because anything other than raw C is a big dumb stupid." And now that the series is 200~ days in, I know it would be futile to start again from the beginning (assuming I only do one "day" per day) because by the end of the year I still wouldn't know how to make a basic game. So I've gotten into the habit of just watching the particular parts i'm interested in (such as tiling, or fonts) and implementing them with SDL so maybe I can finish something decent within my lifetime (although I should probably just use Unity.) That said, it is still a very good series, as long as you accept that Casey Muratori and his methods are very opinionated.
  - nulltype 11y ago
    If you think his abstractions are bad, you should see object oriented programming.
  - agentultra 11y ago
    Yeah... if you disagree with his objections to object-oriented programming and design-by-abstraction you're going to have a hard time getting through the series. If design patterns are comfortable and understandable for you then check out Game Programming Patterns[0]. It's a decent book. However I agree with Casey's philosophy and the wider data-oriented design approach to programming. C++ is not a great language. Zero-cost abstractions are a myth. We should be thinking about the data and not about how to write clever, abstract code. [0] http://gameprogrammingpatterns.com/ http://gameprogrammingpatterns.com/
jupiter90000 11y ago
I really think it's great that experienced game devs are willing to put so much effort into these things. I loved the idea behind the Handmade Hero series. Do you know anyone who has the time to step through all the lessons for such a thing though? It's a great resource to have out there, I'm just doubtful all but a few dedicated individuals will have the patience and commitment to go through something like Handmade Hero fully, spending many many hours and days essentially making what someone else made. Speaking for myself, I would find more motivation in learning how to build something I wanted to make, with guidance from a master of the trade. I couldn't see myself spending a year of evenings after work building what someone else already made to try to learn the skill. Some degree of synthesis should be included. Perhaps some will use the information as a template to build what they really would love to create. If that's the case, I think these resources are even more awesome.

stagger87 11y ago

If your goal is to learn about game development, I would avoid Handmade Hero. Over 200+ days into the project, and he still has a rats nest of a 90's era style Windows code base. It's clear he didn't put any pedagogical thought into the project. Masterclass is the wrong word to describe HH.

AlexeyBrin 11y ago
You are as wrong as you could get, the Handmade Hero project has about 200 hours and not 200 days as in 200 working days. Everything is coded live and recorded, so for 200 hours of work he is doing quite well. The Windows specific code is localized in the platform code and this could be swapped with something Linux or OS X specific at any time.
- User0124 11y ago
  Come one, don't do a strawman. Parent is factually correct that HH project has been going on for 200 days. Nowhere was even implied that 200 working days were put into the project.
  - AlexeyBrin 11y ago
    All it matters is the actual time spent coding, 200+ hours of coding is well reflected in the actual code size and game development.
    - User0124 11y ago
      All it matters is the actual time spent coding False dichotomy. If that were true, skill and knowledge wouldn't matter.
    - w0utert 11y ago
      It's not exactly 200 hours as Casey regularly goes well into the Q&A session and adds things past the first hour. But that's not really the point the OP was making, I guess. I really enjoy watching HH and I have nothing but respect for Casey and the way he's doing these videos, but you can't possibly maintain that the code he's writing should be taken as an example by anyone. The HH code is just plain bad, dangerous, unnecessarily 'optimized' (read: taking ugly shortcuts or incomplete simplifications) in places where it doesn't matter, while super-inefficient in places where it does, it's untested, full of TODO's, does not use any modern language/compile features, it's basically just a lot of lines of code thrown together with minimal design (I do like his seperation between the platform layer and the game layer though). I've watched and enjoyed over 100 hours of HH, and the process the game is going through is very interesting, but in terms of code quality and suitability to 'learn game programming' I would not recommend it.
      - AlexeyBrin 11y ago
        While I don't 100% agree with how Casey codes I wouldn't get as far as saying that The HH code is just plain bad, dangerous. He defined a problem space (implement a game like in the 90's with a software renderer) and decided to use the common parts of C and C++ for the actual implementation. You made me curious, what do you consider a good programming style for game programming ?
        w0utert 11y ago
        >> While I don't 100% agree with how Casey codes I wouldn't get as far as saying that The HH code is just plain bad, dangerous. He defined a problem space (implement a game like in the 90's with a software renderer) and decided to use the common parts of C and C++ for the actual implementation. Well, I would ;-). I think the quality of the code he writes for the game scores low on almost any objective measure of quality except pragmatism. >> You made me curious, what do you consider a good programming style for game programming ? I don't think there is a single 'good programming style' for games, it all depends on the game, the development environment (language, tools) the third-party components you use, the target platform, etc. I think there's a lot of best practices you could apply to any game though. Applying abstraction in those parts where it matters and doesn't negatively impact performance, for example. Defining the components of your game and keeping clear boundaries between them. Making good use of the language features at your disposal. Not obsessing over constant factor performance 'optimisations' before you know where the bottlenecks are. Thinking about and preferring efficient algorithms and data structures, over quick & dirty 'handmade' data structures, just because you feel STL or boost are 'not efficient' (it doesn't matter for 99% of your game code, especially not for something simple as HH). Not passing around naked pointers everywhere. I could go on for a while... If you watch Casey work on HH, most of the time he's fiddling with and rewriting the same things over and over again, because he feels that he always needs to program everything 'in the simplest possible way' first, and then rewrite when necessary. I don't disagree with throwaway code at all, and not everything always needs to be 'designed upfront', but he's taking these things to the extreme, which results in an entangled mess of spaghetti code full of bugs (which you'll have seen he runs into in almost every episode of his stream). He basically disregards all the advances we've had in programming since the 90's, and keeps hammering in C-style code that happens to be compiled by a C++ compiler, but doesn't use any of the advantages C++ provides. I still like to watch him do it though because there's definitely educational value to his videos, and he does solve some interesting problems along the way. And because I've been working on a simple game myself for a while. In my earlier comment I refrained from plugging my own little side-project but now you've asked you could take a look here [1] if you wanted to see how I like to program games. It's about an equal amount of hours in as HH but it already has some actual gameplay, is fully scriptable using Lua, Box2D physics, a sprite-based OpenGL rendering backend, persistency (freeze/unfreeze), action replays with live code updates (inspired by HH, but done 'the right way'), texture-mapped truetype font rendering, some interesting 'handmade' algorithms (complex polygon triangulation, sprite packing), motion controls, etc. I realise it's not the same thing as HH as I prefer not to re-invent the wheel for everything and use libraries and frameworks, but I still feel it's much closer to how you would program a 'real' game using modern technologies. [1] http://www.wouterbijlsma.nl/blog/ http://www.wouterbijlsma.nl/blog/
User0124 11y ago
Has the refactoring of the code to separate files been done yet? The last time I saw it, it was one big file.
krapp 11y ago
I've learned a lot of useful stuff watching the Handmade Hero feed on Youtube - but I stopped trying to follow along directly after the second week or so. Casey seems to harbor grudges against C++ and object oriented programming (both of which he will expound upon at length) that lead him to pile obfuscations and abstractions into his code that make it difficult to approach as a student, and difficult to separate what should be best practice from "stuff Casey does because anything other than raw C is a big dumb stupid." And now that the series is 200~ days in, I know it would be futile to start again from the beginning (assuming I only do one "day" per day) because by the end of the year I still wouldn't know how to make a basic game. So I've gotten into the habit of just watching the particular parts i'm interested in (such as tiling, or fonts) and implementing them with SDL so maybe I can finish something decent within my lifetime (although I should probably just use Unity.) That said, it is still a very good series, as long as you accept that Casey Muratori and his methods are very opinionated.
- nulltype 11y ago
  If you think his abstractions are bad, you should see object oriented programming.
- agentultra 11y ago
  Yeah... if you disagree with his objections to object-oriented programming and design-by-abstraction you're going to have a hard time getting through the series. If design patterns are comfortable and understandable for you then check out Game Programming Patterns[0]. It's a decent book. However I agree with Casey's philosophy and the wider data-oriented design approach to programming. C++ is not a great language. Zero-cost abstractions are a myth. We should be thinking about the data and not about how to write clever, abstract code. [0] http://gameprogrammingpatterns.com/ http://gameprogrammingpatterns.com/

jupiter90000 11y ago

I really think it's great that experienced game devs are willing to put so much effort into these things. I loved the idea behind the Handmade Hero series. Do you know anyone who has the time to step through all the lessons for such a thing though? It's a great resource to have out there, I'm just doubtful all but a few dedicated individuals will have the patience and commitment to go through something like Handmade Hero fully, spending many many hours and days essentially making what someone else made. Speaking for myself, I would find more motivation in learning how to build something I wanted to make, with guidance from a master of the trade. I couldn't see myself spending a year of evenings after work building what someone else already made to try to learn the skill. Some degree of synthesis should be included. Perhaps some will use the information as a template to build what they really would love to create. If that's the case, I think these resources are even more awesome.