🔒 Locked

software architecture: model and visualization separation

Started by Klackon Halberdier Aug 3, 2007 at 7:14 AM 1 replies 600+ views

Original Post

Aug 3, 2007 at 7:14 AM

I'm making a artificial life ecosystem simulation game that has plants and creatures that die and born all the time. There are classes for the "model" part of the game: world, objects etc. and then there is a visualization class "worldgraphics" that draws everything and a top level worldGUI from top level simulation/game control. I am using C++. I want to preserve the model/GUI separation. There are a lot of stuff to visualize (world contains objects. objects has many attributes (and are draw differently!) and many derives classes with their own attributes. How are those games generally done when visualization part need to know almost everything because it draws everything. At the same time good practice is to provide the data from well-defined interface to not allow everyone to access everything wildly. I have some options: - make huge amount of get/set-methods for the objects --> seems too heavy - make every attribute public and include all classes to graphics class --> seems "unorthodox" method - in object side, make graphics as friend of the object class (base and derived classes) - in object side, make graphics as friend of the object class (base and derived classes) - define some other interface/pattern/architecture..???

UriKiller

Aug 3, 2007 at 7:55 AM

As far as I know, the design that should be used for this situation is called MVC (Model-View-Controller). This seperates the program mainly into 3 parts:

1) Model - As you said: World, Objects, Etc.. This is your main data of the game. It should provide methods (to be used by the Controller) for manipulating the data of the game. The Model shouldn't know about the 2 other parts (view, controller) at all. It is used by them, but it has absolutly no access to them.

2) View - This part presents the model on the screen (I suppose that presenting audio to the user would be considered as the 'view' part as well, but that's irrelevant for now). This part gets its data from the Model and uses that data for presenting it in some way to the user. It should not have any access to the 'Controller' part.

3) Controller - This is what manipulates the Model according to inputs from various events: User Input, Timers, Network, Some Triggers, etc... This part also contains the physics engine, which is usually the part that eventually accesses the Model and changes it.

For more info, Wikipedia's article about MVC

d000hg

Aug 3, 2007 at 8:41 AM

Quote:
Original post by UriKiller
As far as I know, the design that should be used for this situation is called MVC (Model-View-Controller).

Yes that's right. This is a often-used approach in all kinds of software and there is no reason why is should not be applicable to games. If you're into doing things "properly" check out a book on software design perhaps (assuming you're not already a CS graduate).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.