5 ms·

Having watched Casey's Handmade Hero series since day-1, I've always found him to be highly skilled and insightful. While not a game developer myself, learning

Having watched Casey's Handmade Hero series since day-1, I've always found him to be highly skilled and insightful. While not a game developer myself, learning from his approach to first-principles software development and code optimization has paid dividends in my day to day work nonetheless.

Ygg2 5y ago
I've found him passionate and smart. But rarely right. Like him bashing SOLID principles. It read like a man arguing against hammers, and instead suggesting using drills (which is fine if you need to drill a hole but bad advice if you want to hammer a nail). Like yeah, SOLID is over used and over-stated, but they were invented to stop certain set of problems.
- teddyh 5y ago
  Not to mention that the “S” in SOLID is closely related to what he is talking about here, namely that a software component ought to be related to only one specific source of changes – i.e. a box in an org chart – in order to minimize the risk of it being changed badly and consequently break something. This implies that you should have a connection between the org chart and the code, in order for the changes in the code over time to not constantly break the code.
- jdougan 5y ago
  With both Casey and Jon Blow I find that if I mentally prefix what they say with "When developing AAA games..." then they are almost always right. Much of it doesn't transfer far outside that domain.
  - holyyikes 5y ago
    What are you talking about? Neither one of them has ever shipped a AAA game.
    - Ygg2 5y ago
      I think it's charitable to read that as shipped a relatively performant game.
      - holyyikes 5y ago
        Actually the funny thing is that Braid's CPU usage was always kind of high for what it was doing. Not sure about The Witness. The emperor definitely doesn't have any clothes though when it comes to either one of them.
- Sinidir 5y ago
  Yeah his claims about good and bad are too unconditional and generic. He always looks at it from his specific vantage point and then declares something categorically bad which ticks me off cause its so dogmatic and lacking of contextuality.
- ImprobableTruth 5y ago
  The most bizarre part is that he took issue which the Liskov substitution principle which is just the intuitive definition of what semantic subtyping means. This isn't some crazy clean code "functions should have less than 20 lines" dogma, subtyping without semantic subtyping is just nonsensical.
- miltondts 5y ago
  > SOLID is over used and over-stated, but they were invented to stop certain set of problems. The problem is, when was it ever shown they solve any problem? Where are the measurements showing less dev time or less bugs or better performance? Where even is an algorithm to show your software is SOLID? People can't even agree on what those mean.
  - teddyh 5y ago
    SOLID is for long-term development and use software. Games are developed during a relatively short time, and then released, and then not changed very much. The next game is developed independently, as a separate project and effort. SOLID is meant to alleviate continous development where changes and new features are constantly needed. Game development does not easily fit in this mold.
    - holyyikes 5y ago
      Tell that to World of Warcraft. Really is hilarious just how goddamned clueless most of the comments in this thread are.
      - teddyh 5y ago
        Please don’t misunderstand me; I really think that SOLID is good to follow. My comment was more meant to express understanding for people having doubts about SOLID in situations where the SOLID principles don’t give as much of an obvious benefit.
- hahamrfunnyguy 5y ago
  I would say it's more like a builder arguing against building codes. A high-quality building can certain be built without them, but sticking to some known formulas makes sure that everyone working on it is able to anticipate what others are going to do. It also makes sure that the building won't collapse, though this aspect doesn't really apply to software. Software has gotten a lot more complicated since the 1990's and from my experience, projects where design patterns are used effectively run a lot more smoothly than those where they're not used or not used effectively. It's great when you can open a project from 15 years ago and say "Actually, the code isn't too bad!" because the developers followed some rules of thumb. I agree with Casey that these rules of thumb aren't going to lead to higher-quality software from the end user's perspective. I doubt that they're going to make it worse though, unless they're blindly followed.
  - krapp 5y ago
    On the other hand, Casey's been working on Handmade Hero for almost a decade, and has what amounts to an overengineered debug room with less actual gameplay complexity than you'd find in any framework tutorial. Meanwhile actual game developers would pick up a framework, use all those abstractions and libraries Casey finds unnecessary and surpass Handmade Hero in an afternoon. There's something to be said for not wasting time on things that don't matter to anyone but yourself, and code aesthetics is often one of those things.
    - leoncaet 5y ago
      He works on HH for about 2 hours per week.
      - krapp 5y ago
        That's still far too much time for far too little progress. Six hundred videos and counting, each over an hour in length. What is there to learn except how not to develop a game, much less (as I recall him claiming) a AAA quality game.
      - holyyikes 5y ago
- 3np 5y ago
  I have no opinion on them as this is the first time I see them but their misrepresentation of Amdahl's law bothered me as their version makes it incorrect to the point of being useless. Here's how they present it: T(n) = b + (T(1)-b)/n T(n): Time to run task for n parallel threads (workers) b: Time it takes to run part of task that can not be parallelized Therefore: T(inf) = b This misses the cost of coordinating between workers. It also removes the key part of it being a theoretical limit of the speedup as resources increase. Their attempt to simplify it makes the new version dangerously wrong if you take their word for it. Less wrong: T(n) >= b + (T(1)-b)/n Or even (but now it's not really Amdahl's again): T(n) >= b + (T(1)-b)/n + C(n) In fact, for many problems T(n) > T(n-1) for some n, as at some point C(n) > (T(1)-b)/n This is not really "a more subtle improvement", "new version", or "refinement". It was known in the field in the 70s. That is, Brook's Law can apply to parallelized computation, not just to teamwork. Which OP observes but still doesn't make them see the errors in their previous assertion.

Ygg2 5y ago

I've found him passionate and smart. But rarely right. Like him bashing SOLID principles. It read like a man arguing against hammers, and instead suggesting using drills (which is fine if you need to drill a hole but bad advice if you want to hammer a nail). Like yeah, SOLID is over used and over-stated, but they were invented to stop certain set of problems.

teddyh 5y ago
Not to mention that the “S” in SOLID is closely related to what he is talking about here, namely that a software component ought to be related to only one specific source of changes – i.e. a box in an org chart – in order to minimize the risk of it being changed badly and consequently break something. This implies that you should have a connection between the org chart and the code, in order for the changes in the code over time to not constantly break the code.
jdougan 5y ago
With both Casey and Jon Blow I find that if I mentally prefix what they say with "When developing AAA games..." then they are almost always right. Much of it doesn't transfer far outside that domain.
- holyyikes 5y ago
  What are you talking about? Neither one of them has ever shipped a AAA game.
  - Ygg2 5y ago
    I think it's charitable to read that as shipped a relatively performant game.
    - holyyikes 5y ago
      Actually the funny thing is that Braid's CPU usage was always kind of high for what it was doing. Not sure about The Witness. The emperor definitely doesn't have any clothes though when it comes to either one of them.
Sinidir 5y ago
Yeah his claims about good and bad are too unconditional and generic. He always looks at it from his specific vantage point and then declares something categorically bad which ticks me off cause its so dogmatic and lacking of contextuality.
ImprobableTruth 5y ago
The most bizarre part is that he took issue which the Liskov substitution principle which is just the intuitive definition of what semantic subtyping means. This isn't some crazy clean code "functions should have less than 20 lines" dogma, subtyping without semantic subtyping is just nonsensical.
miltondts 5y ago
> SOLID is over used and over-stated, but they were invented to stop certain set of problems. The problem is, when was it ever shown they solve any problem? Where are the measurements showing less dev time or less bugs or better performance? Where even is an algorithm to show your software is SOLID? People can't even agree on what those mean.
- teddyh 5y ago
  SOLID is for long-term development and use software. Games are developed during a relatively short time, and then released, and then not changed very much. The next game is developed independently, as a separate project and effort. SOLID is meant to alleviate continous development where changes and new features are constantly needed. Game development does not easily fit in this mold.
  - holyyikes 5y ago
    Tell that to World of Warcraft. Really is hilarious just how goddamned clueless most of the comments in this thread are.
    - teddyh 5y ago
      Please don’t misunderstand me; I really think that SOLID is good to follow. My comment was more meant to express understanding for people having doubts about SOLID in situations where the SOLID principles don’t give as much of an obvious benefit.
hahamrfunnyguy 5y ago
I would say it's more like a builder arguing against building codes. A high-quality building can certain be built without them, but sticking to some known formulas makes sure that everyone working on it is able to anticipate what others are going to do. It also makes sure that the building won't collapse, though this aspect doesn't really apply to software. Software has gotten a lot more complicated since the 1990's and from my experience, projects where design patterns are used effectively run a lot more smoothly than those where they're not used or not used effectively. It's great when you can open a project from 15 years ago and say "Actually, the code isn't too bad!" because the developers followed some rules of thumb. I agree with Casey that these rules of thumb aren't going to lead to higher-quality software from the end user's perspective. I doubt that they're going to make it worse though, unless they're blindly followed.
- krapp 5y ago
  On the other hand, Casey's been working on Handmade Hero for almost a decade, and has what amounts to an overengineered debug room with less actual gameplay complexity than you'd find in any framework tutorial. Meanwhile actual game developers would pick up a framework, use all those abstractions and libraries Casey finds unnecessary and surpass Handmade Hero in an afternoon. There's something to be said for not wasting time on things that don't matter to anyone but yourself, and code aesthetics is often one of those things.
  - leoncaet 5y ago
    He works on HH for about 2 hours per week.
    - krapp 5y ago
      That's still far too much time for far too little progress. Six hundred videos and counting, each over an hour in length. What is there to learn except how not to develop a game, much less (as I recall him claiming) a AAA quality game.
    - holyyikes 5y ago
3np 5y ago
I have no opinion on them as this is the first time I see them but their misrepresentation of Amdahl's law bothered me as their version makes it incorrect to the point of being useless. Here's how they present it: T(n) = b + (T(1)-b)/n T(n): Time to run task for n parallel threads (workers) b: Time it takes to run part of task that can not be parallelized Therefore: T(inf) = b This misses the cost of coordinating between workers. It also removes the key part of it being a theoretical limit of the speedup as resources increase. Their attempt to simplify it makes the new version dangerously wrong if you take their word for it. Less wrong: T(n) >= b + (T(1)-b)/n Or even (but now it's not really Amdahl's again): T(n) >= b + (T(1)-b)/n + C(n) In fact, for many problems T(n) > T(n-1) for some n, as at some point C(n) > (T(1)-b)/n This is not really "a more subtle improvement", "new version", or "refinement". It was known in the field in the 70s. That is, Brook's Law can apply to parallelized computation, not just to teamwork. Which OP observes but still doesn't make them see the errors in their previous assertion.