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
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.
No comments:
Post a Comment