For games, you can't really go strictly MVC as there are a lot of objects that don't really fit into any of those categories. Here's a short explanation of how my game ScribBall is structured:
* Contains the root scenegraph node used to render the game
* Contains a Game Board object
* Responsible for the gameloop (input, timing, updating, drawing)
* Also responsible for scoring and special effects
* Contains a scenegraph node for drawing sub-objects
* Contains a list of Ball objects
* Contains a cpSpace to simulate the balls
* Responsible for the game rules (when balls match, etc)
* Recieves input from the Gamestate on when to update and where the mouse was clicked.
* Contains a scenegraph node to draw itself
* Contains a cpBody
* Contains a cpShape
* Not really responsible for anything, just holds the Chipmunk and graphics data really.
If you don't know what a scenegraph is, you really should. It's terribly handy. (Google is your friend) For right now you just need to know that it's a hierarchical way to store a scene and draw it.
Now, starting from the bottom and building our way back up: The ball is a controller for a ball that appears onscreen. The body is clearly a model object, it stores the information (position and rotation) that the view displays. Now the game board is also a controller, when you add a ball to the game board it adds the body and shape from the ball to the board's space and the ball's scenegraph node is added as a child of the game board's scenegraph node. When the gamestate is created, it creates a game board, and adds the board's scenegraph node as a child to it's own.
Maybe that's a bit of a long explanation, but in my eyes a cpSpace is not a model. It's also not a controller or view in the traditional sense. In ScribBall, the game board keeps it's own list of balls so that it can iterate or transform it easily. The important detail to remember is that the ball is not a cpBody, a cpShape or an image on the screen, but the union of the three.