Seperation of drawing and logic in games
- by BFree
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.....)
