4 ms·

>And this one line is why you're willing to setup all these crap boilerplate supporter classes and take a huge hit in runtime performance? Hits don't usually h

>And this one line is why you're willing to setup all these crap boilerplate supporter classes and take a huge hit in runtime performance? Hits don't usually happen that often in games relative to everything else the engine is doing unless you're writing something like MMO server code that processes hits from thousands players. Yours is a classic case of over-optimizing, I think.

jstimpfle 8y ago
Over-optimizing as in, write the one obvious line instead of 15 lines of crap that are also slower?
- Novashi 8y ago
  Until you get a decent combat system in and now your hit has to go through 30+ calculations. It's almost never as simple as "monster.HP - damage". Besides, if we really want to be snarky, why haven't you wrote it in assembly for performance?
  - jstimpfle 8y ago
    No, I'm not talking about one arithmetic CPU operation. I'm talking about simple, procedural hit(monster, weapon, damage). Why not in assembly? Because it's not worth the effort. You won't notice any difference in speed. Be pragmatic.
    - Novashi 8y ago
      >I'm talking about simple, procedural hit(monster, weapon, damage). The moment your game needs to know anything else about that hit event, you're going to start creating side effects from that procedure and that QUICKLY snowballs into spaghetti code. Not to mention, just from the signature, that's going to be an absolutely huge procedure. >Because it's not worth the effort. You won't notice any difference in speed. Be pragmatic. That's the exact same case I'm making. A hit object every so often will have no impact on performance (certainly not a huge impact) like you originally said and you gain developer productivity.
      - jstimpfle 8y ago
        (monster, weapon, damage) is "the object". And yes, the procedure probably has "side effects". Because that's the point. > Not to mention, just from the signature, that's going to be an absolutely huge procedure. How do you intend to write less code with OOP?
        Novashi 8y ago
        >(monster, weapon, damage) is "the object". Now an environment flag causes fire damage to deal +10% more. You're either going to have to extend the hit method again (further complicating it), or just pull that flag from the environment class in the procedure body itself (undeclared dependency). When something else outside monster/weapon/damage/environment has to change the hit calculations, you'll have to extend it again and again. >And yes, the procedure probably has "side effects". Because that's the point. Side effects are terrible for maintenance and debugging, you shouldn't be using that to defend your argument here -- unless you don't know what side effects are which is why it's in scare quotes? >How do you intend to write less code with OOP? The point is for it to be more human readable because it's unlikely there's performance impact in this case. You don't want to count code quality by lines/characters of code.
        jstimpfle 8y ago
        > When something else outside monster/weapon/damage/environment has to change the hit calculations When something should change, you edit the freakin' code. There is no way around it. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). > Side effects are terrible for maintenance and debugging FP apologetists want to make you believe that, but side effects are the actual point of the program. > The point is for it to be more human readable hit(player, weapon, monster) Player.hits(Monster).with(Weapon) I mean at least acknowledge that that's a highly subjective statement...
        Novashi 8y ago
        >When something should change, you edit the freakin' code. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). I dunno, maybe aim for something a little better than writing an exponential amount of functions for all of your interactions. >FP apologetists want to make you believe that, but side effects are the actual point of the program. If you want to make all of your co-workers hate you because randomProcedure changes shared state when it shouldn't, go right ahead. If you want to stop that, you're like two steps away from OOP's dependency injection when you write validator functions on the shared state object. >I mean at least acknowledge that that's a highly subjective statement... Games are about the worst choice for criticizing OOP because OOP is so useful for describing games. Procedural style is fine for Pong or Sudoku or really simple games, I guess. It's highly subjective in-so-far as the entire industry has mostly adopted it and released great games with it.
- jryan49 8y ago
  These examples are supposed to be examples, not what we would actually do in this specific case. In a huge enterprise system that has 500 different ways something could be done, in which your function would have 30 million if statements, all which is dependent on runtime behavior, polymorphism can help solve that problem. Imagine there are hundreds of ways Hit can be implemented and used in different situations. That's the reason for breaking out this type of abstraction. I agree this example the author used isn't probably a clear one in which one should use OOP.
  - jstimpfle 8y ago
    > Imagine there are hundreds of ways Hit can be implemented and used in different situations. This is the typical argument you get to hear from OOP apologetists. And the codebase is rotting, just for concerns about hypothetical problems... I remember one time when I was criticized for putting in too much global data and not enough classes "because what if we have two GUI instances?". The guy of course had no idea why he would want that, and how it should work.

jstimpfle 8y ago

Over-optimizing as in, write the one obvious line instead of 15 lines of crap that are also slower?

Novashi 8y ago
Until you get a decent combat system in and now your hit has to go through 30+ calculations. It's almost never as simple as "monster.HP - damage". Besides, if we really want to be snarky, why haven't you wrote it in assembly for performance?
- jstimpfle 8y ago
  No, I'm not talking about one arithmetic CPU operation. I'm talking about simple, procedural hit(monster, weapon, damage). Why not in assembly? Because it's not worth the effort. You won't notice any difference in speed. Be pragmatic.
  - Novashi 8y ago
    >I'm talking about simple, procedural hit(monster, weapon, damage). The moment your game needs to know anything else about that hit event, you're going to start creating side effects from that procedure and that QUICKLY snowballs into spaghetti code. Not to mention, just from the signature, that's going to be an absolutely huge procedure. >Because it's not worth the effort. You won't notice any difference in speed. Be pragmatic. That's the exact same case I'm making. A hit object every so often will have no impact on performance (certainly not a huge impact) like you originally said and you gain developer productivity.
    - jstimpfle 8y ago
      (monster, weapon, damage) is "the object". And yes, the procedure probably has "side effects". Because that's the point. > Not to mention, just from the signature, that's going to be an absolutely huge procedure. How do you intend to write less code with OOP?
      - Novashi 8y ago
        >(monster, weapon, damage) is "the object". Now an environment flag causes fire damage to deal +10% more. You're either going to have to extend the hit method again (further complicating it), or just pull that flag from the environment class in the procedure body itself (undeclared dependency). When something else outside monster/weapon/damage/environment has to change the hit calculations, you'll have to extend it again and again. >And yes, the procedure probably has "side effects". Because that's the point. Side effects are terrible for maintenance and debugging, you shouldn't be using that to defend your argument here -- unless you don't know what side effects are which is why it's in scare quotes? >How do you intend to write less code with OOP? The point is for it to be more human readable because it's unlikely there's performance impact in this case. You don't want to count code quality by lines/characters of code.
        jstimpfle 8y ago
        > When something else outside monster/weapon/damage/environment has to change the hit calculations When something should change, you edit the freakin' code. There is no way around it. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). > Side effects are terrible for maintenance and debugging FP apologetists want to make you believe that, but side effects are the actual point of the program. > The point is for it to be more human readable hit(player, weapon, monster) Player.hits(Monster).with(Weapon) I mean at least acknowledge that that's a highly subjective statement...
        Novashi 8y ago
        >When something should change, you edit the freakin' code. If you have different kinds of hits then you make different procedures. e.g. magicPixieDustHit(monster, pixieDust, weapon, damage). I dunno, maybe aim for something a little better than writing an exponential amount of functions for all of your interactions. >FP apologetists want to make you believe that, but side effects are the actual point of the program. If you want to make all of your co-workers hate you because randomProcedure changes shared state when it shouldn't, go right ahead. If you want to stop that, you're like two steps away from OOP's dependency injection when you write validator functions on the shared state object. >I mean at least acknowledge that that's a highly subjective statement... Games are about the worst choice for criticizing OOP because OOP is so useful for describing games. Procedural style is fine for Pong or Sudoku or really simple games, I guess. It's highly subjective in-so-far as the entire industry has mostly adopted it and released great games with it.
jryan49 8y ago
These examples are supposed to be examples, not what we would actually do in this specific case. In a huge enterprise system that has 500 different ways something could be done, in which your function would have 30 million if statements, all which is dependent on runtime behavior, polymorphism can help solve that problem. Imagine there are hundreds of ways Hit can be implemented and used in different situations. That's the reason for breaking out this type of abstraction. I agree this example the author used isn't probably a clear one in which one should use OOP.
- jstimpfle 8y ago
  > Imagine there are hundreds of ways Hit can be implemented and used in different situations. This is the typical argument you get to hear from OOP apologetists. And the codebase is rotting, just for concerns about hypothetical problems... I remember one time when I was criticized for putting in too much global data and not enough classes "because what if we have two GUI instances?". The guy of course had no idea why he would want that, and how it should work.