A typical implementation of a Model-View-Controller system starts with designing the model, which is generally the game world, and an update function which simulates the model's evolution. As usual, the world contains exactly zero view-related information. Pseudocode:

while true
  world = update(world)

Then comes the view. The most elementary solution would be to generate a brand new view based on the current state of the model. Pseudocode:

while true
  world = update(world)
  graphics = extract(world)
  render(graphics)

This solution is good enough for most business applications, where the view is intended to represent a snapshot of the data along with methods for interacting with that data. As such, generating a brand new snapshot from scratch is sufficient. In the game development world, this isn't enough. First, there is the question of efficiency: extracting a completely new graphical representation of the game world every frame completely ignores the existence of spatial and temporal locality in the game world—even though a given object will have the same aspect and be in the same position from one frame to the other, its aspect and position will be computed every frame. Then, there is the issue of cosmetic time-dependent effects, such as animation or sound: given a snapshot of the world state, what frame of a given animation should be displayed, and what portion of a sound file should be played? Since in almost all cases the world has no reason to store cosmetic information about animations or sounds, these cannot be used in this simple implementation. An improved solution consists in giving the view the possibility to persist some data in-between frames. Pseudocode:

while true
  world = update(world)
  if graphics
    graphics = evolve(world, graphics)
  else
    graphics = extract(world)
  render(graphics)

If no data exists yet, extract creates a reasonable approximation of what the view should look like if it had been present for a short while, based on the world's state. This should generally be a good guess. Then, evolve ensures that the view on a given frame is consistent with the previous frames (animations play the right way, objects don't jump around without interpolation, sounds actually play all the way, and so on). In turn, the evolve function should give results that are close to the guess that would have been made by extract in the same situation, in order to keep the view in sync with the model. While a good improvement (the view now takes advantage of spatial and temporal locality), there are still a few issues to iron out. First, there are the efficiency issues: the evolve function must remove objects which are not there anymore, update those objects that are present, and create avatars for the objects which appears. This means that all objects will be examined (though not necessarily recomputed) even if they haven't changed since the previous step. Then, there are the functionality issues: suppose that, during the update step, a character shot another character. The existence of that shot is not apparent in the world state: the first character's ammo count went down, and the second character's life went down as well. How can the view display the muzzle flash and play the gunshot sound? The evolve function can keep a copy of those variables and perform an educated guess about what happened, but it could be wrong. Or the model could keep a flag about whether the gun was fired, or a list of events which may cause sounds to be played and animations to be played, but this would violate the separation of the model and the view. The problem here belongs with the interaction between the view and the model. Assuming that the model code remained exactly the same, but that in addition of updating the world state, it constructed a diff (a list of differences between the old state and the new state) that the graphics system could examine in addition to the final state, all these problems would be gone. And, looking back from that point, it is fairly obvious that giving the view access to only static snapshots of the model was fairly limiting. Pseudocode:

while true
  world, diff = update(world)
  if graphics
    graphics = evolve(world, diff, graphics)
  else
    graphics = extract(world)
  render(graphics)

However, an issue remains. Here is an example event pseudocode, such as firing a gun:

// Before
fire_gun(args,world):
  world = apply(FIRE_GUN, args, world)
  return world

// After
fire_gun(args,world,diff):
  diff << (FIRE_GUN, args, world)
  world = apply(FIRE_GUN, args, world)
  return (world, diff)

In addition to applying the gun event to the world (something which also happened in the previous version), the event logs itself to the difference list. However, in order for the view to react correctly to this event, it must be aware of the state of the world at the moment when the gun fire occured. Thus, the old world state is attached to the event inside the difference list. Alternately, the view has its own copy of the world state and has it evolve using the received events. Either way, the processing and memory overhead are unnecessarily high. Instead, the system can be reduced to a listener approach, which also serves a nice purpose in the case of networking. Pseudocode:

while true:
  if !graphics 
    graphics = extract(world)
  world, graphics = update(world, graphics)
  render(graphics)

This is not a violation of view-model separation, because update does not know that graphics represents the view: it is just a listener object which will be notified of all events which happen inside the world during the update using a forwarding system:

fire_gun(args,world,listener):
  listener = send(FIRE_GUN, args, world, listener) 
  world = apply(FIRE_GUN, args, world)
  return (world,listener)

By implementing a listener system to extract information from all the events which occur inside the world during an update, a diff-based communication channel from the model to the view appears, and can be used to improve performance and expressiveness of the system. Are there any opinions you wish to share about the above? Past experiences with improving the performance of the model-view-controller approach? Other solutions you may have found to these problems?