Skip to main content
Game Development

Return to Answer

The flaws people said they found in my answer were due to clarity. So I added: asked "in a chatroom", an example "of what not to do", the reference page, and another short paragraph.
Source Link
RoboticRenaissance
RoboticRenaissance
  • 161
  • 6

Tetrad is correct that your ideas seem a bit messy at the moment. But to answer the question more directly (small picture rather than big picture) for those who come hereafter:

Typically you want a few classes with a lot of properties, rather than subclasses. Um... sorry, my history is too full to find the reference Here's a wikipedia reference someone gave me when I asked this exact same question like 4 days ago in a chatroom. (Thanks Alex, for helping me find it again).

For example, among (of what not to do): Among the entities we've got Frog, Truck, Land, Water. Land and Water are stationary, or static. Frog and Truck are moving, or dynamic. So we could make Static and Dynamic subclasses and put each one into those classes. On the other hand, both a Truck and the Water will kill you. Maybe Water is Dynamic, instead? Water and Truck are both in the Enemy class? Well... no.

It's better to use properties on the various entities. Frog and Truck have the canMove property equal to true. Truck and Water have the killOnContact property.

To Clarify and make Direct You'll find that it's easier to come up with names for the behaviors and features and what not, than it is to come up with a single category in which something should go. (The same reason each SE site has tags rather than categories).

Tetrad is correct that your ideas seem a bit messy at the moment. But to answer the question more directly (small picture rather than big picture) for those who come hereafter:

Typically you want a few classes with a lot of properties, rather than subclasses. Um... sorry, my history is too full to find the reference someone gave me when I asked this exact same question like 4 days ago.

For example, among the entities we've got Frog, Truck, Land, Water. Land and Water are stationary, or static. Frog and Truck are moving, or dynamic. So we could make Static and Dynamic subclasses and put each one into those classes. On the other hand, both a Truck and the Water will kill you. Maybe Water is Dynamic, instead? Water and Truck are both in the Enemy class? Well... no.

It's better to use properties on the various entities. Frog and Truck have the canMove property equal to true. Truck and Water have the killOnContact property.

Tetrad is correct that your ideas seem a bit messy at the moment. But to answer the question more directly (small picture rather than big picture) for those who come hereafter:

Typically you want a few classes with a lot of properties, rather than subclasses. Here's a wikipedia reference someone gave me when I asked this exact same question like 4 days ago in a chatroom. (Thanks Alex, for helping me find it again).

For example (of what not to do): Among the entities we've got Frog, Truck, Land, Water. Land and Water are stationary, or static. Frog and Truck are moving, or dynamic. So we could make Static and Dynamic subclasses and put each one into those classes. On the other hand, both a Truck and the Water will kill you. Maybe Water is Dynamic, instead? Water and Truck are both in the Enemy class? Well... no.

It's better to use properties on the various entities. Frog and Truck have the canMove property. Truck and Water have the killOnContact property.

To Clarify and make Direct You'll find that it's easier to come up with names for the behaviors and features and what not, than it is to come up with a single category in which something should go. (The same reason each SE site has tags rather than categories).

Source Link
RoboticRenaissance
RoboticRenaissance
  • 161
  • 6

Tetrad is correct that your ideas seem a bit messy at the moment. But to answer the question more directly (small picture rather than big picture) for those who come hereafter:

Typically you want a few classes with a lot of properties, rather than subclasses. Um... sorry, my history is too full to find the reference someone gave me when I asked this exact same question like 4 days ago.

For example, among the entities we've got Frog, Truck, Land, Water. Land and Water are stationary, or static. Frog and Truck are moving, or dynamic. So we could make Static and Dynamic subclasses and put each one into those classes. On the other hand, both a Truck and the Water will kill you. Maybe Water is Dynamic, instead? Water and Truck are both in the Enemy class? Well... no.

It's better to use properties on the various entities. Frog and Truck have the canMove property equal to true. Truck and Water have the killOnContact property.