What is the correct object-orientated approach to class design in game development?

Question

I'm in the midst of developing a 2D sprite-based game for Windows 7 Phone, using XNA. The training and tutorials available for it are pretty helpful, but the problem I face is that each of them approaches their class design differently, and the code is not particularly well-factored. As a result, it has been difficult for me to gain a good understanding of which responsibilities I should give to a particular class.

For example, I could have a base sprite class BaseSprite that knows how to draw itself, check for collisions, etc. I could then have an AnimatedSprite class that would know how to navigate its sprite sheet, an ExplodingSprite class, and so on. This technique is demonstrated in the Space Invaders example in the Windows 7 Phone Jumpstart Session 2 materials.

Alternatively, I could instead place the bulk of rendering and running the game responsibility in a GameScreen class; that class and its derived classes behave more like forms or web pages in terms of their responsibilities. Sprite classes are more simple containers with much less logic.

This is the technique used in the Windows 7 Phone Training Kit's Alien Sprite game and other game state manager examples.

What is the correct object-orientated approach to class design in game development?

Answer 1

I do use a more component-oriented approach, where you would have a Sprite class which has components like Visual, Collision, Animation, Input, etc. With this approach I don't end up having a deep class hierarchy (which is good).

For some info on Component Oriented Design see here.

Answer 2

In games, the Component pattern is a common solution.

Answer 3

The SOLID Principles apply as much to game code design as to any other profession - at least until you come to optimise, so I'd use your first example as a starting point.

I'd go further though, because BaseSprite sounds like it has the tendency to become a megaclass. The Single Responsibility Principle dictates that collision, rendering and navigation should all be handled by components, rather than individual entries in a class hierarchy. The holding class of all these components should only handle pushing world positions between them.

Answer 4

For the last few projects I have leaned more towards an MVC style approach.

At first we weren't sure if this would work, but it worked perfectly.

Model

The data objects. Just the pure data. No behaviour, no rendering.

Data manager. Just handling "lists" of data objects. (Can also be enhanced to support pooling.)

View

We call them renderers. For every data object type there is a renderer. When called with a manager it will render all objects in that list.

Controller

Same as the renderers, but controls the behaviour.

Example

The ShipManager has a list of Ships. The ShipController will move the Ships according to their state. The ShipRenderer will render the Ships according to their state.

Why

This way the view and the logic are strictly seperated. It makes porting to a new platform pretty easy. Optimizing the data layout inside the XxxManager is also very easy.