[w0utert]

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]

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]

>> 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/

[agentultra]

I think you missed the philosophical justification at the beginning of the series. This is Handmade Hero we're talking about where we build every system of the game with no help from libraries, frameworks, or engines. The whole point is to show people how it all works from soup to nuts.

Using libraries, even the STL in C++, would be cheating.

In the bigger picture of things these abstractions have costs. They're not free despite the C++ propaganda machine telling us otherwise. It's important to know what those costs are in order to make effective decisions about whether to include them in your project.

And finally the golden rule: if it looks right it is right. We're not here to write pretty, elegant code. Your pretty abstractions don't matter to the hardware. The target platform your system runs on is likely a highly-optimized piece of circuitry with real, physical constraints. Casey is the first programmer I've seen teaching people to keep the Intel manual handy and how to implement data-structures for cache-efficiency instead of pretty abstractions and virtual machines and template meta-programming.

It may not be a style of programming that agrees with you but it's one that has a growing number of proponents from Casey to Mike Acton, Jonathan Blow, and others. It's not a new idea either... but it certainly distinguishes itself as a reaction to the normative notion of programming by abstraction. It's a philosophy that proscribes programming by mechanical sympathy; using machines to manipulate data to get the results you desire.

[w0utert]

I haven't missed it, I know the idea is to do everything by hand, which I think definitely has educational value but does not necessarily lead to better or more efficient code (to the contrary, even). Not using STL or Boost on the one hand, but using many of the available OS frameworks on the other hand, seems a bit arbitrary, I don't see why 'handmade' should mean 'reinventing the wheel' even on basic tools and building blocks like data structures etc.

>> In the bigger picture of things these abstractions have costs. They're not free despite the C++ propaganda machine telling us otherwise. It's important to know what those costs are in order to make effective decisions about whether to include them in your project.

Based on years of writing all kinds of software I can only disagree with this. Even in games there's such a tiny amount of code that would really benefit from going all the way down to the bare metal to avoid some constant-factor overhead of higher-level abstractions, that it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation 'to make it faster'.

>> It may not be a style of programming that agrees with you but it's one that has a growing number of proponents from Casey to Mike Acton, Jonathan Blow, and others. It's not a new idea either... but it certainly distinguishes itself as a reaction to the normative notion of programming by abstraction. It's a philosophy that proscribes programming by mechanical sympathy; using machines to manipulate data to get the results you desire.

Philosophically, that's all nice and dandy. Practically speaking, it doesn't make much sense though, except for educational purposes (and even then, only up to the point of showing how things work, then moving on and settling on a proven, battle-tested version of the same thing that you don't need to maintain and debug yourself. At least that's my opinion...

[chipsy]

> it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation 'to make it faster'.

There is a circularity to this logic that you should address.

On the one hand, you shouldn't write your own abstractions because someone else did a good-enough one already.

On the other hand, you shouldn't try to write more appropriate abstractions because you should have working code first.

Well, which is it? If you intend to write appropriate abstractions(and that's a goal of HH), you have to start off being a bit too crude and slow so that you have a working test case; then you can gradually improve that with better algorithms as you uncover the performance profile.

Jumping to "use someone else's code" introduces a dependency and a guess about average-case behavior. That is okay if we're making "Premade Hero", but it teaches nothing about algorithm design.

And w/r to your own project, there are a lot of guesses about what will be useful or helpful - the specifications boil down to "it would be fun to add more physics and scripting to Thrust" which, as a game design goal, is quite impoverished. HH also lacks for design right now, but everything in it is built on direct experience and isn't going to box in Casey later. It is motions he is going through to show to the crowd how it all works if you were going to do it yourself.

[agentultra]

I get that... but Handmade Hero is an educational effort. It is trying to show people how to implement their own data structures. How to read the manuals for your OS and hardware and how to program that hardware.

There is no "battle-tested" single data-structure that is going to fit into every program ever written. Different data, different platform, different problem. The philosophy chosen by STL and Boost, etc, panders to the lowest-common denominator or some idealized use-case. That might be useful for certain applications but making an educated decision on whether to include it takes knowing the cost of memory access and how your cache is being utilized (or not as is often the case with STL bloat-ware). The "zero-cost abstraction" promise is a myth.

Any significant game engine or system will end up considering, carefully, it's memory allocation strategy and access patterns. You will end up writing specialized data structures for your particular data challenges to best use the hardware and operating system running your program.

The more abstractions you add the more difficult it becomes to manage the complexity in your programs and you end up writing more abstractions to solve the problems with your other abstractions. Soon your program takes tens of thousands of cycles access the data it needs in your loop and you end up cutting out all of the abstractions anyway.

And there's nothing wrong with teaching people to think this way. If we want to call ourselves engineers it's time to stop thinking that only a certain elite is allowed to write the data structures we mere mortals are blessed to use. Everything has a cost. You can't add features and incur no cost. Every instruction, memory access, page to disk -- it all takes electricity and time. We should be able to think about our systems holistically and consider each aspect of our system.

I'm not saying we should write every program from scratch every time. However we should be able to if it's required by the problem we're trying to solve. Our job is to solve data problems. We take data in and transform it to perform some task. Everything else from the bottom up introduces a cost to the system. Maybe 90% of the time you do need a garbage collector -- you've considered your access patterns and object life-times and know that the particular algorithm and its costs align with the goals of your system.