4 ms·

Use traits and you get this for free, without implementing all the plumbing yourself. Inheritance has its place in game dev though. It's just that your hiearch

Use traits and you get this for free, without implementing all the plumbing yourself. Inheritance has its place in game dev though. It's just that your hiearchy needs to be designed in the space of what you are actually building: not vehicles, weapons, and monsters but renderers, physics, AI, GUIs, etc. And you want to figure out how that stuff is going to work before you break it up into classes.

terinjokes 15y ago
I don't come from a game development background, but I do find the realm interesting, and I'll probably have my crack at it soon enough. This post is interesting, it kinda goes against what I think of when I think of OOP. I would have modeled it with inheritance of vehicles, weapons and monsters. But after reading this post I could see how that could be a bad idea. But I'm curious in what you say. "Hierachy needs to be designed in the space of what you're actually building: renderers, physics, AI and GUIs." Do you care to explain this farther? Why those over the concrete objects? What do you even mean by it? EDIT: Specifically how what do you mean by having inheritance of physics, renderers, AIs and GUIs? EDIT II: Grammatical fixes.
- tree_of_item 15y ago
  Here are some nice comments on LTU that explain what I think the GP meant. http://lambda-the-ultimate.org/node/3265#comment-48061 http://lambda-the-ultimate.org/node/3265#comment-48061 http://lambda-the-ultimate.org/node/3265#comment-48063 http://lambda-the-ultimate.org/node/3265#comment-48063 The general idea is that your objects should model the program, not the domain. Games may blur this line since they are simulations in some respect, which is a situation where you actually do want to model the domain. That doesn't mean you need anything as unsubtle as classes with a 1:1 correspondence to domain objects, though, which is what this article is about.
  - Natsu 15y ago
    I think the problem exists because people hear "object" and they think of physical objects, when, as you say, the objects in OOP are supposed to be something more abstract: a means of gathering together common code and common data, not a means of creating digital mirrors of real objects.
  - gte910h 15y ago
    Objects when not doing a simulation are merely syntactic sugar of keeping the data and the functions that act on them very close to each other in a very tightly coupled way, while keeping other functions more loosely coupled. Trying to simulate things that don't require simulation (aka, modeling physical properties), is a bad idea. You're not really making a program then, but a very specific, complicated subset that requires way more work and doesn't get your job done.
- extension 15y ago
  I just mean that first you need to figure out how your engine is going to work -- what actual code you are going to write -- then go about organizing that code into an object model. A physics engine will have classes for the things it cares about like masses, constraints, collisions, contacts, etc. A renderer could have things like meshes, materials, particle systems, and lights. Each subsystem has a different idea of what a particular vehicle, weapon, or monster is. Two monsters might have the same physics properties but be rendered very differently. A Koopa and a Flying Koopa might look the same but behave differently. You can't start with classes for vehicles, weapons and monsters, and expect these classes to be used across all subsystems. OOP is really a way to organize your code. OOP doesn't generate solutions.
- Lazare 15y ago
  Not everyone agrees with this, but, here goes: When I was in college, I was taught OOP in Java via the obligatory inheritance examples: "So we have an Mammal class which has a 'walk' method, and then we have Cat and Dog classes which inherit from Animal, and have 'meow' and 'bark' methods." This is a sadly ubiquitous anti-pattern which will cripple your ability to do OOP until you unlearn it. Never model the actual domain. Doesn't matter if it's a game ("okay, so the PlateArmor class inherits from the Armor class") or a CRM ("okay, so the Comment class will inherit from the FormattedContent class"). Instead, model how the program should work. How to do that is a bit beyond the scope of a comment, but a good start is to think about behaviours and interfaces that logically fit together. (And, again, this tends to be a divisive issue. But I - and a lot of very good programmers whom I respect - strongly feel that the "Cat inherits from Mammal" example is exactly and precisely what you should never do. Despite the fact that it's how OOP is taught in most courses and books, seemingly.)
  - meric 15y ago
    At least in that example the Cat is everything the Animal is. Some examples go as bad as: Square inherit Rectangle inherit Shape because "all squares are rectangles and all rectangles are shapes"......
    - Deestan 15y ago
      For completeness, Square inheriting from Rectangle is horrible for at least the following reasons: 1. Inheritance is IS-A. A Square ISN'T-A Rectangle because it breaks Rectangle's contract. If I give you a Rectangle object, you know that you can change the width without affecting the height. If I give you a Rectangle reference which happens to be a Square instance, setting different width and height will either cause a crash/exception, which is not what a Rectangle should do, or ignore one of the values and set the height equal to the width, which is also not what a Rectangle should do. 2. A bit subtle, maybe, but important. While your renderer probably has a method taking Shape objects, it is very unlikely that you have an interface somewhere that takes Rectangle objects. In that case, what you actually need out of this is some code reuse between Rectangle and Square, not type inheritance.
tree_of_item 15y ago
Languages with traits may not allow them to be changed at runtime, which may be a useful behavior to have in a game.
- yvdriess 15y ago
  Composition may be done at runtime, but indeed changing the behavior of an existing object at runtime is not something trait systems provide. Cloning into a new object with different traits is perhaps an option.

terinjokes 15y ago

I don't come from a game development background, but I do find the realm interesting, and I'll probably have my crack at it soon enough. This post is interesting, it kinda goes against what I think of when I think of OOP. I would have modeled it with inheritance of vehicles, weapons and monsters. But after reading this post I could see how that could be a bad idea. But I'm curious in what you say. "Hierachy needs to be designed in the space of what you're actually building: renderers, physics, AI and GUIs." Do you care to explain this farther? Why those over the concrete objects? What do you even mean by it? EDIT: Specifically how what do you mean by having inheritance of physics, renderers, AIs and GUIs? EDIT II: Grammatical fixes.

tree_of_item 15y ago
Here are some nice comments on LTU that explain what I think the GP meant. http://lambda-the-ultimate.org/node/3265#comment-48061 http://lambda-the-ultimate.org/node/3265#comment-48061 http://lambda-the-ultimate.org/node/3265#comment-48063 http://lambda-the-ultimate.org/node/3265#comment-48063 The general idea is that your objects should model the program, not the domain. Games may blur this line since they are simulations in some respect, which is a situation where you actually do want to model the domain. That doesn't mean you need anything as unsubtle as classes with a 1:1 correspondence to domain objects, though, which is what this article is about.
- Natsu 15y ago
  I think the problem exists because people hear "object" and they think of physical objects, when, as you say, the objects in OOP are supposed to be something more abstract: a means of gathering together common code and common data, not a means of creating digital mirrors of real objects.
- gte910h 15y ago
  Objects when not doing a simulation are merely syntactic sugar of keeping the data and the functions that act on them very close to each other in a very tightly coupled way, while keeping other functions more loosely coupled. Trying to simulate things that don't require simulation (aka, modeling physical properties), is a bad idea. You're not really making a program then, but a very specific, complicated subset that requires way more work and doesn't get your job done.
extension 15y ago
I just mean that first you need to figure out how your engine is going to work -- what actual code you are going to write -- then go about organizing that code into an object model. A physics engine will have classes for the things it cares about like masses, constraints, collisions, contacts, etc. A renderer could have things like meshes, materials, particle systems, and lights. Each subsystem has a different idea of what a particular vehicle, weapon, or monster is. Two monsters might have the same physics properties but be rendered very differently. A Koopa and a Flying Koopa might look the same but behave differently. You can't start with classes for vehicles, weapons and monsters, and expect these classes to be used across all subsystems. OOP is really a way to organize your code. OOP doesn't generate solutions.
Lazare 15y ago
Not everyone agrees with this, but, here goes: When I was in college, I was taught OOP in Java via the obligatory inheritance examples: "So we have an Mammal class which has a 'walk' method, and then we have Cat and Dog classes which inherit from Animal, and have 'meow' and 'bark' methods." This is a sadly ubiquitous anti-pattern which will cripple your ability to do OOP until you unlearn it. Never model the actual domain. Doesn't matter if it's a game ("okay, so the PlateArmor class inherits from the Armor class") or a CRM ("okay, so the Comment class will inherit from the FormattedContent class"). Instead, model how the program should work. How to do that is a bit beyond the scope of a comment, but a good start is to think about behaviours and interfaces that logically fit together. (And, again, this tends to be a divisive issue. But I - and a lot of very good programmers whom I respect - strongly feel that the "Cat inherits from Mammal" example is exactly and precisely what you should never do. Despite the fact that it's how OOP is taught in most courses and books, seemingly.)
- meric 15y ago
  At least in that example the Cat is everything the Animal is. Some examples go as bad as: Square inherit Rectangle inherit Shape because "all squares are rectangles and all rectangles are shapes"......
  - Deestan 15y ago
    For completeness, Square inheriting from Rectangle is horrible for at least the following reasons: 1. Inheritance is IS-A. A Square ISN'T-A Rectangle because it breaks Rectangle's contract. If I give you a Rectangle object, you know that you can change the width without affecting the height. If I give you a Rectangle reference which happens to be a Square instance, setting different width and height will either cause a crash/exception, which is not what a Rectangle should do, or ignore one of the values and set the height equal to the width, which is also not what a Rectangle should do. 2. A bit subtle, maybe, but important. While your renderer probably has a method taking Shape objects, it is very unlikely that you have an interface somewhere that takes Rectangle objects. In that case, what you actually need out of this is some code reuse between Rectangle and Square, not type inheritance.

tree_of_item 15y ago

Languages with traits may not allow them to be changed at runtime, which may be a useful behavior to have in a game.

yvdriess 15y ago
Composition may be done at runtime, but indeed changing the behavior of an existing object at runtime is not something trait systems provide. Cloning into a new object with different traits is perhaps an option.