State-Controller-View-Model

Game Play & Game Design
#1

Hi,

I can’t figure out how these objects should interact with each other
using Active rendering

I’ll try to say what I have now:
State -> Handles one gui(MainMenu, InGame), is painted/updated every gameLoop
Controller -> a list of functions that can be applied to the model, should that contain mouseLeftClick() handles left clicks or select() handles left click logic :confused:
View -> paint/update itself, direct access to model
Model -> send notification when something changed to the view
UserInput -> Swing Actions a view invokes an Action and the action then handles the request(the actions will needs view and controller objects)

Should the State paint/update the gui? or should the state call paint/update on the controller and then paint/update the gui.

#2

Hi

I don’t use State-Controller-View-Model but only MVC. I disagree with you, the view shouldn’t access directly to the model, it is not very dangerous if your program is not online, if you have only a model per view and if you only do it to read data. On my view, a State should propagate the update through the controller to the model if concerned and then the model should use the controller to try to update the view or something like that.

#3

Take a look at http://www.puremvc.org. I don’t think PureMVC was designed with game development in mind, but they provide good diagrams and documents explaining how it works. There are many forms of the MVC pattern, and the PureMVC is just one of them. Still, you could gain something from looking at it, or you could go right ahead and implement their library.

#4

Good pointer, thanks.

#5

I’d just focus on separating the concerns and keeping things consistent. The object communication is well less important and easily fixed should it really be bad. But if you take the separating of concerns and consistency to hart it’s really hard to come up with something poor.

#6

Yeah really what matters is that you create a paradigm and you follow it.

I personally make the View the class that handles all display and absolutely no computation, the Controller the class that handles all input and turns it into a simple and useable list, and the Model takes the information from the controller, decides what to do with it, and then tells the View what to draw.

If you were doing like what I did above, then just make sure you didn’t do something like put scanning for nearby objects in the Model, that should go in the Controller because it has to do with input, even if it’s not human input… i.e. the model will decide to do something based on nearby objects.