4 ms·

Because the camera was using velocity and acceleration and was collidable, I derived it from our PhysicalObject class, which had those characteristics. It also

by Dove 15y ago

Because the camera was using velocity and acceleration and was collidable, I derived it from our PhysicalObject class, which had those characteristics. It also had another characteristic: PhysicalObjects could take damage. The air strikes did enough damage in a large enough radius that they were quite literally "killing" the camera. This is what's wrong with inheritance.

SamReidHughes 15y ago
Um, no? If their camera wasn't a PhysicalObject, they'd have had to write custom code for handling the camera case for anything that handles PhysicalObjects. All this means is that perhaps a PhysicalObject shouldn't be the thing that takes damage.
- ZenPsycho 15y ago
  That's why you use delegation and traits instead of inheritance. sometimes the alternative to a bad idea isn't the even stupider thing you did before you found out about it.
- Jare 15y ago
  The reason is that inheritance is too coarse-grained and promotes bundling together lots of unrelated concepts. So it's likely that with a finer grained system, they would have separated physics and damage in different classes. They might have still made the mistake of not separating them, or of copy-pasting the damage object into the camera anyway, so the point and punchline of the story still stands.
  - fruchtose 15y ago
    They might have still made the mistake of not separating them, or of copy-pasting the damage object into the camera anyway, so the point and punchline of the story still stands. The possibility that a programmer could make a mistake in the implementation of a paradigm is not an argument against that paradigm. The first part of your comment is very real and very valid, but copy-pasting is a potential issue regardless of your programming language.
    - deleted 15y ago
      [deleted]
    - Dove 15y ago
      I am convinced that this is not just a programmer's mistake. This is an illustration of the problem with the paradigm itself. Inheritance makes you want to glue unrelated things together. Inheritance views the world as fundamentally hierarchical; you can divide things up into branches of a tree. A node on the tree either has all of a set of functions or none of them. Any code you put into Reptile will never be needed by a Mammal, and will never be inappropriate for an object that needs other things in Reptile. But of course, that's unrealistic. Where would you put swim()? Where would you put fly()? Code reuse can't always be decomposed into a tree. And in an inheritance paradigm, you get ugly workarounds in that case -- cut and pasted code, nasty multiple inheritance hacks, or util classes. All bad things. What you want are things coupled, not by convenient proximity in current function, but by logical relationship. You want a class that has swimming-related code and nothing else, that any swimmer can use without preconceptions about whether it's a Reptile or a Mammal. You want, in short, Traits.
      - zoul 15y ago
        Inheritance is not a design methodology, it’s a tool. As a tool it does not “view the world”, unless it’s meant in the sense that when you only have a hammer, every problem looks like a nail to you. When you only have inheritance in your toolbox, things are going to end badly indeed. But that does not mean that inheritance is a bad tool.
      - tomjen3 15y ago
        Actually I want multiple inheritance. That way I can write that a crocodile is a reptile and a swimmer or that camera is a game object and it is collidable but not damageable. Yes it can make your code more complex, but you can also use it to make the game more clean.
    - ZenPsycho 15y ago
      I think you should be very careful about using this kind of argument. This is the mindset of a cult. Why didn't X work? well you just didn't use enough X! . I have kind of a visceral reaction of disgust when this is used, because it encourages the retention of silly ideas without really using reason, logic or evidence to defend them.
- ZenPsycho 15y ago
  Game Development Essentials: Don't use inheritance in your game http://unlikekinds.com/post/17192015158 http://unlikekinds.com/post/17192015158
damian2000 15y ago
FYI, the game was 'Force 21', "a Real-time Strategy game made by Red Storm Entertainment in 1999 that features a storyline which has US forces fighting PRC (Chinese) forces in the year 2015." From the review here: http://au.pc.ign.com/articles/161/161030p1.html http://au.pc.ign.com/articles/161/161030p1.html "You view the game mainly from the Tactical 3D window. The camera is, sadly, always situated just above the lead vehicle in the selected platoon. A free roaming camera would have been better as it would have given you more opportunities to view the action. Still, the camera is very useful and really succeeds at drawing you into the action. The camera is very, very easy to use--just bump the edges of your screen with the mouse...well, the mouse cursor, not the actual mouse itself. The camera then spins around the lead unit of the platoon. Vertical movement isn't as good. The angle of the camera doesn't allow you to look straight down on your units or get down on the ground beside them. Oh well, c'est la guerre. There's also a Strategic view that's better for getting an overall impression of the terrain elevation, but it's no good for seeing the action. For the overall impression of the battle, I preferred to use the tiny strategic window in the corner of the screen."

by Dove 15y ago

SamReidHughes 15y ago

Um, no? If their camera wasn't a PhysicalObject, they'd have had to write custom code for handling the camera case for anything that handles PhysicalObjects. All this means is that perhaps a PhysicalObject shouldn't be the thing that takes damage.

ZenPsycho 15y ago
That's why you use delegation and traits instead of inheritance. sometimes the alternative to a bad idea isn't the even stupider thing you did before you found out about it.
Jare 15y ago
The reason is that inheritance is too coarse-grained and promotes bundling together lots of unrelated concepts. So it's likely that with a finer grained system, they would have separated physics and damage in different classes. They might have still made the mistake of not separating them, or of copy-pasting the damage object into the camera anyway, so the point and punchline of the story still stands.
- fruchtose 15y ago
  They might have still made the mistake of not separating them, or of copy-pasting the damage object into the camera anyway, so the point and punchline of the story still stands. The possibility that a programmer could make a mistake in the implementation of a paradigm is not an argument against that paradigm. The first part of your comment is very real and very valid, but copy-pasting is a potential issue regardless of your programming language.
  - deleted 15y ago
    [deleted]
  - Dove 15y ago
    I am convinced that this is not just a programmer's mistake. This is an illustration of the problem with the paradigm itself. Inheritance makes you want to glue unrelated things together. Inheritance views the world as fundamentally hierarchical; you can divide things up into branches of a tree. A node on the tree either has all of a set of functions or none of them. Any code you put into Reptile will never be needed by a Mammal, and will never be inappropriate for an object that needs other things in Reptile. But of course, that's unrealistic. Where would you put swim()? Where would you put fly()? Code reuse can't always be decomposed into a tree. And in an inheritance paradigm, you get ugly workarounds in that case -- cut and pasted code, nasty multiple inheritance hacks, or util classes. All bad things. What you want are things coupled, not by convenient proximity in current function, but by logical relationship. You want a class that has swimming-related code and nothing else, that any swimmer can use without preconceptions about whether it's a Reptile or a Mammal. You want, in short, Traits.
    - zoul 15y ago
      Inheritance is not a design methodology, it’s a tool. As a tool it does not “view the world”, unless it’s meant in the sense that when you only have a hammer, every problem looks like a nail to you. When you only have inheritance in your toolbox, things are going to end badly indeed. But that does not mean that inheritance is a bad tool.
    - tomjen3 15y ago
      Actually I want multiple inheritance. That way I can write that a crocodile is a reptile and a swimmer or that camera is a game object and it is collidable but not damageable. Yes it can make your code more complex, but you can also use it to make the game more clean.
  - ZenPsycho 15y ago
    I think you should be very careful about using this kind of argument. This is the mindset of a cult. Why didn't X work? well you just didn't use enough X! . I have kind of a visceral reaction of disgust when this is used, because it encourages the retention of silly ideas without really using reason, logic or evidence to defend them.
ZenPsycho 15y ago
Game Development Essentials: Don't use inheritance in your game http://unlikekinds.com/post/17192015158 http://unlikekinds.com/post/17192015158

damian2000 15y ago

FYI, the game was 'Force 21', "a Real-time Strategy game made by Red Storm Entertainment in 1999 that features a storyline which has US forces fighting PRC (Chinese) forces in the year 2015." From the review here: http://au.pc.ign.com/articles/161/161030p1.html http://au.pc.ign.com/articles/161/161030p1.html "You view the game mainly from the Tactical 3D window. The camera is, sadly, always situated just above the lead vehicle in the selected platoon. A free roaming camera would have been better as it would have given you more opportunities to view the action. Still, the camera is very useful and really succeeds at drawing you into the action. The camera is very, very easy to use--just bump the edges of your screen with the mouse...well, the mouse cursor, not the actual mouse itself. The camera then spins around the lead unit of the platoon. Vertical movement isn't as good. The angle of the camera doesn't allow you to look straight down on your units or get down on the ground beside them. Oh well, c'est la guerre. There's also a Strategic view that's better for getting an overall impression of the terrain elevation, but it's no good for seeing the action. For the overall impression of the battle, I preferred to use the tiny strategic window in the corner of the screen."