MVC pattern for games

[Greg]

Hi All,

Can someone please explain how the MVC pattern is used for a game.

I understand the basic idea behind it and how I could use it to build say an address book but I really struggle to implement it for something like a game. Maybe MVC isn't the pattern I should be using...?

As a simple example how would I structure a space invaders game.

- Controller, captures accelerometer and touches and passes them to the model to update user spaceship position etc. Also contains the main loop to trigger updates in the model (to move enemys across/down screen, do collision detection).

- Model, holds data on all objects. spaceship/enemy position, rotation, health, score.
Shouldn't this also hold info on how to draw the objects. ie. enemy1 = blue, enemy2 = green, battlement shape after being hit.

- View, redraws the screen with info from the model... but wouldn't it be easier to ask each object to draw itself in a given context/view?

Which class deals with the sounds? the model?

Thanks for any help/direction.

Greg

[smasher]

I'll give my philosophy - it may not be textbook correct.

Originally Posted by Greg

- Model, holds data on all objects. spaceship/enemy position, rotation, health, score.
Shouldn't this also hold info on how to draw the objects. ie. enemy1 = blue, enemy2 = green, battlement shape after being hit.

Sure, the model can know things like "I am green" or "I look like enemy.png". No problem.

Originally Posted by Greg

- View, redraws the screen with info from the model... but wouldn't it be easier to ask each object to draw itself in a given context/view?

Many books for object-oriented languages start with the example of "shapes who know how to draw themselves" , and it may be very OOP, but it's not very MCV. In my game the model knows each object's position (in map squares, not pixels!) but the view loops through them and draws them.

You get a nice separation of code this way - if I wanted to change my view from layers to OpenGL, there's nothing to change in the model. If I change the camera view or the screen size, those changes are just in the view, not the model. I could go from 2d to 3d with very few changes in the model (replace the pngs with 3d chars).

Plus the code in the model stays very clean - I can move a player by one square by saying player.x +=1 instead of player.x+=MAP_SQUARE_WIDTH.

[Greg]

thanks Smasher,

I have a feeling MVC might not be the best approach for game I have in mind... a large scrolling world.

I'll have a play it with and see how I get on.

thanks again
Greg

[smasher]

Originally Posted by Greg

thanks Smasher,

I have a feeling MVC might not be the best approach for game I have in mind... a large scrolling world.

I'll have a play it with and see how I get on.

thanks again
Greg

I dunno - if every tree, rock, and orc knows how to draw itself, then you have a lot of classes to modify code in if you make changes to the display (sprite size, orientation, etc.)

[Greg]

Yeah I'm starting to agree with you, but for some reason my gut still says otherwise.
I think it's just because it's a different approach and I'm new to Objective-C so I'm a little out of my comfort zone...

However, what I've implementing so far is working well