Coming from website development with MVP/MVC data patterns we went through this
Over time this is what we have come up with:
Data Access tier:
Data Access Repositories
Simulation Models (models)
Simulation (think controller inherits SimulationListener with event methods)
Render Models (meshes/animations)
Renderer (think View)
For games it's more like Simulation runs as fast as you can run it... Renderer renders at a set interval reading the simulation objects to determine what to render. It is less of a linear approach then say the menu system or other applications like websites.
Simulation models contain update methods to update the physics/states based on events. For example, in Capture the Flag our flag has dropped(), reset(Vector), captured(GameMech (simulation object)), and update(). The simulation models also contain pointers to objects. Our flag has a GameMech carrier object. The update() takes into account the carrier's position and updates the flags position.
Here is the scenario: Mech runs over flag -> fires simulation listener event flag picked up (GameMech) -> Flag object carrier set -> Mech dies fires mech killed event -> flag object dropped() method invoked in the mech killed event -> Mech from flag team runs over Flag -> fires flag returned event -> flag object reset() method invoked in the mech returned event
Now the renderer/View is dumb. It just renders the objects the simulation updates and when needed brings in meshes/animations for those objects. The only action the View has is raising events in the simulation. Like when a rocket button is pushed it raises the event of launching a missile. The simulation adds the missile and position of missile. Next time the renderer renders it then can see that object and just produces the mesh at that given location.
Hope that helps.