Archived

This topic is now archived and is closed to further replies.

Model View Controller Game Design

This topic is 5151 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am looking for some advice on game design as it relates to the separation of the model and the view. At the present time, I am working on a real time strategy game using the Model View Controller architecture. Under the architecture; the model is responsible for the game state; the view is responsible for rendering the model; and the controller is responsible for events which change the model. For example, each starship controller is responsible for the creation of a new missile when there is a missile fire event from the observed starship. As such, each game objected (starship, missile, etc.) is composed of a separate model, view, and controller object. I would be interested to hear recommendations on other ways to create a separation of the model and the view as it relates to game design. Furthermore, I could really use some advice on which creation pattern (especially a recommended implementation) would be best for the Model View Controller Architecture. The following is a link to my game in progress: http://www.freelancegames.com/demo.jpg _______________________________________ Understanding is a three edged sword...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I''ve been using MVC for awhile now. I think i can help you out.

Each major component has a reoccuring framework.

Major Components : Factory, Objects, Object Container

Factory :: is a creation factory used to create objects, using simple registeration policy. An external script registers the type of objects the game support, and points to a data file which desribes the object. The datafile is just a list of modules defining the objects capablities. The external script also binds the object to a name which is used in game to create them. This name and datafile defines an objects creation policy.

Objects :: fundemental unit representaiton within a Component (Model , View or Controller ). An object is an aggreate of modules. These modules define the objects function and capacity. When external functions or objects want something specific from the object they must bind to an interface within the object. If the binding fails, it means the object doesnt posses that functionality. If it succeedes it return the interface which is a module within the Object, which exposes a public interface. Objects are created by the factory, using a name.

Object Container :: this is usually unique to each Component. For the Model its the world object, the View its the scenegraph, and for the Controller its usualy some a UI manager. Its important to mention, becuase all Objects must eventually go into their respective containers to be useable. They do not update themselves, rather its these containers who do that. Containers are fundemetnally responsble for managing the objects ( creation, update, removal ).

So the connections between the Components should be realaitvely loose. For my design, within the Models Object datafile, it defines the external Object name associated with this Model Object. That way, when an a Modlel Object is passed into another Components Object Container, it uses this paramter to create an analog Object wihtin itself.

Well hope this helps.

Good Luck.

-ddn

Share this post


Link to post
Share on other sites
quote:

For my design, within the Models Object datafile, it defines the external Object name associated with this Model Object. That way, when an a Modlel Object is passed into another Components Object Container, it uses this paramter to create an analog Object wihtin itself.



What do you mean by the external object name? Assuming the external object name is the registration name associated with the view and the controller. That would mean that you are basically passing the name of the view and the controller to there respective containers to be created? Moreover, you are actually creating the view and the controller objects in there container; not a factory? Which would mean that you are only using a factory to create the model objects?

Can you clarify my assumptions?

quote:

For the Model its the world object, the View its the scenegraph, and for the Controller its usualy some a UI manager. Its important to mention, becuase all Objects must eventually go into their respective containers to be useable.


Within the confines of Game Design, I would agree with two thirds of the last sentence in the quote above. Why is it important for the controller to be placed in a container?

quote:

So the connections between the Components should be realaitvely loose.



Do you have a higher level controller that creates an association between the model, view, controller containers?

Thanks

_______________________________________
Understanding is a three edged sword...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The principle for MVC, is there is a one to many relationship between the Model to its Views. The model acts as the source and the various views recive that source and translate that to a approriate output. How much access you give the views depends upon you. I''ve found there are views which are so low level that they truthly require nearly full access to the model ( such as the Network component ), and on the other spectrum there are views which only perhrically access the model through interfaces (such as the Graphical component). Having a well defined interface which these external views can use, is a good way to reduce coupling. So there should be some time invested in that aspect of the design. The Controller is a bridge between the components.

I''ve found it convient to abstract the Controller in a similar fashion as i''ve done the View and Model. This is beacause i can then bind different functionality by changing the Controller Object external defintion, like how i can change the View and Model Objects. This is optional, ofcoruse. You can code the controllers objects however you wish. I''ve switch back and forth on this design aspect. Currently im using a fully event driven design, and the controllers as such, are embeded into the various modules. But in truth having more flexiblity within the Controllers would be quite useful. Thus I might switch back or atleast allow for runtime binding of the controllers to their modules. This would allow me to have access control and redirection on a per module level.

So due to the one to many relationship, the Views look at the Model or some aspect of it anyways. They then translate this into their output. The process of translation, requires them to bind a concrete Model Object into one of their Viewable Object types. Thus the statement where i noted the Model Objects defintion contains a this info which is used by external Views to bind too. For instance within the model the object "Animal_Generic" is bound to an external view object "Frog", if i wanted to have them look like rats, i can bind them instead to the View object "Rat", and if i wanted them to sound like birds i would bind their Sound View to "Bird" etc..

As you can see the View encompass many functionality other than just the visual. I have Views for networking, sound as awell as visual.

So, each View component does have a concrete view object which is bound to a concrete model object. The View objects, are functinoally seperate from the Model object. They do refer to and reflect the Model object state, but cannot and should not affect it directly. All interaction from View to Model goes through the Controllers. The importance of the controller cannot be overstated.

So its alot to take in and im sure i''ve been very vebose. So i''ll leave it at this. Hope this has helped. If you have any more question, just ask.

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
quote:
Original post by Sean Doherty
For example, each starship controller is responsible for the creation of a new missile when there is a missile fire event from the observed starship. As such, each game objected (starship, missile, etc.) is composed of a separate model, view, and controller object.



In case, starship controller is called the "Role Controller".

quote:

I would be interested to hear recommendations on other ways to create a separation of the model and the view as it relates to game design. Furthermore, I could really use some advice on which creation pattern (especially a recommended implementation) would be best for the Model View Controller Architecture.

The following is a link to my game in progress:

http://www.freelancegames.com/demo.jpg


_______________________________________
Understanding is a three edged sword...



Before writing MVC, you must read the Controller Pattern.

In other ways to separate Model and View, use the notify mechanism.

good luck ^^.

Share this post


Link to post
Share on other sites