How should I design my classes in a game?

Question

I'm stuck for ideas on classes in game programming. This is probably more of an opinion based question. I'm looking for information that is proving hard to find on the internet.

Say I have a class called Bullet or Mob, the name doesn't really matter it's just an example. With this, there are two options I can think of.

1. Have the class purely as a way of storing data and nothing else. So I could have, for example, properties such as EntityID, Velocity, HealthPoints, NumberOfAttacks. I would then have some other part of the game which iterates through every instance of every object and update the properties from there.

   Example: During the iteration, it checks what type of object it is, such as Bullet etc. Once it has checked this, it will calculate where the bullet should move to next based upon the Velocity property.

2. Or, have the same properties within the class, but also have all the code for updating it's own properties in there too. Example: The bullet has some kind of Update() method which get's called periodically by the game engine. This Update method would then take it upon itself to calculate the new Velocity and update it's position etc.

3. Some combination of the both? Something else I haven't thought of?

Which of these options is the more commonly used approach in game programming? What are the benefits or disadvantages of these different methods?

Have I got it all completely wrong?

Answer 1

Keep Bullet functionality in the Bullet class.

This just sounded like nails against a chalkboard to me:

During the iteration, it checks what type of object it is, such as Bullet etc. Once it has checked this, it will calculate where the bullet should move to next based upon the Velocity property.

Aaagh. D:

It's not the base Entity class' responsibility to check if it's a Bullet -- that's what method overriding is for!

I like to do this (and I know many other developers who do):

Have a base Entity class that defines properties like speed, position and id that all entities will need anyway, along with an Update(dt) method that computes its position in the next step. All entities (such as Bullet or Player) then inherit from Entity. If necessary, they override Update(dt) to add functionality such as consider keyboard input or resolve collisions, then probably call super to do the actual movement, so there's no code duplication.

Your Method 2 sounds just like this. I'd go with that.

Whether each entity should render itself or whether rendering should be done globally is a related consideration that has been discussed at length. The answers there might be helpful too.

Answer 2

In my case, I went about a lot of this through composition (more precisely through the Strategy Pattern). I built an interface, and made LinearMovement and CircularMovement classes. My friend later added a ParabolicMovement class. Any of these can be provided to a game object at will; you can swap them out at any time. The result is that the function that does the moving changes, and may have different values for speed, acceleration, angle, etc without requiring a separate concrete class.

We aren't very far along, but the flexibility of this approach is very noticeable. Done right, a player character could be of the same type as a bullet, but with different values. Going that far may not be worth it, depending on your situation, but it should be worth considering. That it helps with movement, I have no doubt. Note that the properties you've mentioned often get split off between the strategy classes in this case.