Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

(note - I don't have the reputation to create new tags, so mod action may be needed to re-tag)

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 darn good IMO, 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 on 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.

So, how do you approach the class design for your games?

share|improve this question
add comment

4 Answers

up vote 24 down vote accepted

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.

share|improve this answer
2  
+1 the article you linked to was fantastic. I was so focused on pure OO design, I completely overlooked the component/decorator type model. –  Josh E Jul 27 '10 at 13:51
1  
The component pattern isn't really "less pure" OO :) –  Srekel Jul 27 '10 at 15:40
2  
Indeed. OO is often equated with inheritance. But inheritance is only one tool OO offers, composition is another. –  haffax Jul 27 '10 at 19:37
    
Just so. I should have been more precise in my wording; what I meant is that I focused to much on the inheritance side of OO instead of thinking of OO design patterns / other OO aspects that could help me achieve what I wanted. –  Josh E Jul 31 '10 at 23:55
    
While a comoposition based approach is pretty obvious and used frequently, I have yet to see a solution to keeping the rendering component portable. Any hints would be great. –  Andreas Aug 6 '10 at 6:45
show 1 more comment

In games, the Component pattern is a common solution.

share|improve this answer
    
that's another fantastic article - well worth the read. –  Josh E Aug 1 '10 at 0:21
1  
Great, great, great article! –  Kevin Dec 19 '10 at 20:13
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
I'm voting you down because I'm sick of seeing more-or-less bare "Use MVC" as an acceptable answer. If you are developing on any modern platform, you're already using MVC at multiple levels. It's not a specific answer, and it's not a good answer, because it doesn't actually tell people how to structure classes, which is task/domain-specific. You just end up with a lot of people writing "class Modal...; class View...; class Controller..." MVC is a pattern with a lot of good high-level explanatory power when talking about existing code. It is not a pattern with a lot of good planning power. –  user744 Jul 27 '10 at 20:31
4  
@Joe I get your point, but find your choice of words unnecessary rude. I just explained how we do it. Since the higher level architecture choice makes the lower level design choice obsolete, I consider it a valid answer. –  Andreas Jul 28 '10 at 9:09
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.