Best way to divide data and view?

[Randomaniac]

I'm not quite sure if this question belongs in the SFML forums, but I'll try it out anyway.

I'm a 19 year old student writing a small game for a long term project. Since I've used SFML before (for visual train simulation with my own graphics engine) I immediately decided it would be my graphics library for this project.

The problem is now: how do I go about dividing data and view in an orderly fashion? I want the blueprints to be just right from the start so I won't have to make any major changes later on. An older colleague has adviced me to use the MVC (Model-View-Controller) model but I haven't found a way just right to implement it.

Just to sketch you some context: The game will be 2D topview. I've got a couple of base classes: graphs and nodes and an abstract factory. All entities or game tiles will be nodes, which the graph will hold. The abstract factories will take care of producing these when asked. The derived class from the graph you can call the PlayField as it will hold the obstacles on the screen and generally decide what the screen should look like as it also holds all entities.

Now.. Just to repeat that tiny, simple-looking question. How best to set up my graphics? One single graphics object that communicates with the playfield to communicate through changes, both ways? One graphical representation object for each entity in the game?

Any help would be greatly appreciated. Same goes for sharing experience: I've got few but I'm determined. Share what you can!

[eigenbom]

Hi, thats a big question, and the best approach really depends on many things within your game. For example, if you have millions of entities, many of which are not visible at any one time, then you probably only want to create their graphical representations when they come into view, so a 1-to-1 graphics entity to game entity may not be appropriate.

Personally I would start off with a single graphics class/module that communicates with the Playfield, as you mentioned. That way you can change up its internals as you develop further. As the requirements change (and they will!) you might need to spatially partition the graphics objects for quicker collision detection, rendering, picking, etc ..

I really have no idea about your game, but for instance, if your AI controller adds a new enemy to a game, you might have some logic like..

Code: [Select]

// aiController
void decision(){
  ...
  playField.addEntity(ENEMY,...);
}

// playField
void addEntity(...){
  ...
  graphicsSystem.entityAdded(...); // might load and create the sf::Sprite and add it to an internal tree of some sort
  physicsSystem.entityAdded(...); // e.g., might create a box2d body
}

In this case playField is acting like a main controller AND model, who knows about the other systems.

When some input comes in, e.g., a mouse click, your main system would first pass it to the UI layer, then might ask graphicsSystem (or physicsSystem) if the click intersects an entity. If so, you might then ...

Code: [Select]

playField.entitySelected(...);


which would then tell the graphics system in order to provide a highlighted rectangle around the object etc..

HTH