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

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

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 ^^.