Seperation of drawing and logic in games
Posted
by
BFree
on Game Development
See other posts from Game Development
or by BFree
Published on 2011-02-17T14:49:11Z
Indexed on
2011/02/17
15:34 UTC
Read the original article
Hit count: 237
I'm a developer that's just now starting to mess around with game development. I'm a .Net guy, so I've messed with XNA and am now playing around with Cocos2d for the iPhone. My question really is more general though.
Let's say I'm building a simple Pong game. I'd have a Ball
class and a Paddle
class. Coming from the business world development, my first instinct is to not have any drawing or input handling code in either of these classes.
//pseudo code
class Ball
{
Vector2D position;
Vector2D velocity;
Color color;
void Move(){}
}
Nothing in the ball class handles input, or deals with drawing. I'd then have another class, my Game
class, or my Scene.m
(in Cocos2D) which would new up the Ball, and during the game loop, it would manipulate the ball as needed.
The thing is though, in many tutorials for both XNA and Cocos2D, I see a pattern like this:
//pseudo code
class Ball : SomeUpdatableComponent
{
Vector2D position;
Vector2D velocity;
Color color;
void Update(){}
void Draw(){}
void HandleInput(){}
}
My question is, is this right? Is this the pattern that people use in game development? It somehow goes against everything I'm used to, to have my Ball class do everything. Furthermore, in this second example, where my Ball
knows how to move around, how would I handle collision detection with the Paddle
? Would the Ball
need to have knowledge of the Paddle
? In my first example, the Game
class would have references to both the Ball
and the Paddle
, and then ship both of those off to some CollisionDetection
manager or something, but how do I deal with the complexity of various components, if each individual component does everything themselves? (I hope I'm making sense.....)
© Game Development or respective owner