5 ms·

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

• 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.
        • jstimpfle 8y ago
          > I dunno, maybe aim for something a little better than writing an exponential amount of functions for all of your interactions. You mean "polynomial". And you are still not acknowledging that OOP doesn't help there either. There is only one way out: You as the programmer must do the sensible thing. If you really need runtime polymorphism (which you rarely need, if you structure things correctly and keep separate things separate), then for god's sake go ahead and do it. But in my opinion it's much cleaner to do it with explicit function pointers. > Games... > the entire industry has mostly adopted it and released great games with it. I think you are at least 10 to 20 years late. The games industry, especially in the AAA sector where performance is critical, seems to long have acknowledged that OOP doesn't work out.