Suppose you have a scene composed of a world, a player, and a boss. Oh, and this is a third person game, so you also have a camera.
So your scene looks like this:
class Scene {
World* world
Player* player
Enemy* boss
Camera* camera
}
(At least, that's the basic data. How you contain the data, is up to you.)
You only want to update and render the scene when you are playing the game, not when paused, or in the main menu... so you attach it to the game state!
State* gameState = new State();
gameState->addScene(scene);
Now your game state has a scene. Next, you want to run the logic on the scene, and render the scene. For the logic, you just run an update function.
State::update(double delta) {
scene->update(delta);
}
That way you can keep all the game logic in the Scene
class. And just for the sake of reference, an entity component system might do it like this instead:
State::update(double delta) {
physicsSystem->applyPhysics(scene);
}
Anyways, you've now managed to update your scene. Now you want to display it! For which we do something similar to the above:
State::render() {
renderSystem->render(scene);
}
There you go. The renderSystem reads the information from the scene, and displays the appropriate image. Simplified, the method for rendering the scene might look like this:
RenderSystem::renderScene(Scene* scene) {
Camera* camera = scene->camera;
lookAt(camera); // Set up the appropriate viewing matrices based on
// the camera location and direction
renderHeightmap(scene->getWorld()->getHeightMap()); // Just as an example, you might
// use a height map as your world
// representation.
renderModel(scene->getPlayer()->getType()); // getType() will return, for example "orc"
// or "human"
renderModel(scene->getBoss()->getType());
}
Really simplified, you'd still need to, for example, apply a rotation and translation based on where your player is and where he's looking. (My example is a 3D game, if you go with 2D, it'll be a walk in the park).
I hope this is what you were looking for? As you can hopefully recollect from the above, the render system doesn't care about the game's logic. It only uses the scene's current state to render, i.e. it pulls the necessary information from it, in order to render. And the game logic? It doesn't care what the renderer does. Heck, it doesn't care if it's displayed at all!
And you don't need to attach rendering information to the scene either. It should be enough that the renderer knows it needs to render an orc. You'll have loaded an orc model already, which the renderer then knows to display.
This should satisfy your requirements. The graphic representation and logic are coupled, because they both use the same data. Yet they are separate, because neither relies on the other!
EDIT: And just to answer why one would do it like this? Because it's easier is the simplest reason. You don't need to think about "such and such happened, I should now update the graphics". Instead you make stuff happen, and each frame the game looks at what's currently happening, and interprets it in some way, giving you an on-screen result.