Hi Very well I realy gave a lot of thought before posting this. The thing is that I am much more competent in graphics than in game programing as I discovered not a long time ago. It all started when I wanted to create my own little framework than I can reuse over and over for games. Until now what I was doing was to plan on paper the game I want to do, then I map the keyboard and mouse into actions then those actions change the game state and I render those state. It was fine because I don't do big games and also because I always work on the same platform and for other reason that you will guess. But recently I wanted to do something "proper" if I can say that. So I looked at game architecture in some books like Game coding complete, the code is really good, concept are well explained but to be honest I don't know why I'm just not attracted to this design of course I learned a lot of concept (I know I'm such a girl) so I kept digging and found this. I really like the idea of it so I say let's get started and then it occured to me than applying MVC to game is kind of hard for me.I filled the blanks but there are still stuff I doin't get... Especially regarding the controller. First: The controller map the input into game command. I got that, but is it really okay for the model (entity) to poll every functions of its controller? Do you think the controller should have some game logic implemented ? I also was thinking that the controller could receive inputs and then "fires" game event for the model to do its job, does it not break the MVC pattern ? In a game where the player can use different objects, should I create a different controller for each one ? and also would it be efficient for the player model to contains model of its "equipment" ? Do I still need a game logic module for the game itself since every entity handles itself ? I might not be really clear please don't hesitate to insult me to do so :) Thanks

No ideas anyone ?

Quote:Original post by lollan
The controller map the input into game command. I got that, but is it really okay for the model (entity) to poll every functions of its controller?

I don't think that's happening in the document you linked. I think the controller alters the entities through an abstract interface.

Quote:Do you think the controller should have some game logic implemented ?

No, unless you want an anemic domain model (which isn't always bad).

Quote:I also was thinking that the controller could receive inputs and then "fires" game event for the model to do its job, does it not break the MVC pattern ?

That would just be abstracting controller input events into 'game events' which shouldn't break the pattern.

Quote:In a game where the player can use different objects, should I create a different controller for each one ?

I wouldn't think so. The controller handling player input should cater for the player's actions, you shouldn't need a different controller for different player states.

Quote: and also would it be efficient for the player model to contains model of its "equipment" ?

The complexity of your model is entirely up to you. You're modelling equipment in any case - whether the equipment is a separate object or not really depends on whether this makes things easier for you.

Quote:Do I still need a game logic module for the game itself since every entity handles itself ?

That might be part of the abstraction from controller to model. You could add something similar as an entity in your model if you need to.

One thing you really need to understand is that all of these patterns and guidelines are aimed at reducing the complexity of large-scale implementations. It's almost always a good idea to keeping things as simple as possible to start, and then refactoring later on if you need to.

Thanks for your advices, reading them made me think that I was way to litteral with this code design.

Can I say that the controller is the one which polls the entity at a particular event ?

Quote:Original post by lollan
Can I say that the controller is the one which polls the entity at a particular event ?

You can say that the controller provides the mapping from application input to actions in your model. "Polling" is the action of periodically checking for interesting changes, so I can't see why the controller would need to poll entities for information. The controller just provides the model with the actions that have been requested, and doesn't care about what actually happens in the model. The view does care about what happens in the model, but polling the model for updates is unlikely to be an ideal solution.

Hi,

Okay I got your point.

I decided that the controller will call the interface of the entity when a certain action occurs. Polling it like you said doesn't make sense.

However the View I think needs to poll the model before renderig itself.

What I am going to do now is kind of like this (for the human player):

InputHandler:
Will translate input into events and fires them

Controller:
Is being call when certain events occurs
Will call the right method of the interface of the model to execute the action

Model:
Will change state
Will also execute some game Logic
Will also call other model if it needs to

View:
Will check model state and render itself accordingly


I think that by using this I can as well get the AI to use the same controller.
Of course there is a lot more than that to do for a game but do you think I have the theory right ?

Thanks

Quote:Original post by lollan
I decided that the controller will call the interface of the entity when a certain action occurs. Polling it like you said doesn't make sense.

However the View I think needs to poll the model before renderig itself.

What I am going to do now is kind of like this (for the human player):

InputHandler:
Will translate input into events and fires them

Controller:
Is being call when certain events occurs
Will call the right method of the interface of the model to execute the action

Model:
Will change state
Will also execute some game Logic
Will also call other model if it needs to

View:
Will check model state and render itself accordingly


I think that by using this I can as well get the AI to use the same controller.
Of course there is a lot more than that to do for a game but do you think I have the theory right ?

I think that's good enough to start with. You'll probably have to adjust some aspects of it, but that's stuff you learn while implementing a pattern. If you really just want to create a game, don't be too rigorous with sticking to MVC - most indie games that get made ignore model-view separation from what I can tell.

There are a number of other posts on the subject on this forum by the way. You might want to look for one by ToorHyVyk (I probably spelled that incorrectly), which covers some of the deficiencies of basic MVC as applied to games (and a possible solution).

Yeah I was kind of guessing that,
I'm designing a small chess game right now and more and more I'm thinking of allowing the entity to check on his controller. I also realised that not all entity needs a controller, or maybe should I create a controller and let on entity communicate to an other through it.

I'm going to look to the other post but I've looked a while for other post on the subject chances are I already saw it.

Thanks you've helped me a lot anyway, I'll figure out the rest while doing it I think.

Thanks again