6 ms·

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 p

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/

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/