Sign in to follow this  
Klackon Halberdier

software architecture: model and visualization separation

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this