Game Design MVC - Controller Architecture

Question

Reading an artile on gamasutra had me thinking of how should the controller in an MVC game be designed as:

Option 1: The controller should act on the model,

Eg: whenever a key is pressed controller calls model:

On KeyPress Left
 SuperMario.StartWalking(Left)

On KeyRelease -Left or Right-
 SuperMario.StopWalking()

Option 2 : The model queries the controller about what to do

Eg: each update tick model calls GetDesiredXSpeed():

On KeyPress Left
  speedX = -SuperMario.MaxSpeed();

On KeyRelease -Left or Right-
  speedX = 0;

int GetDesiredXSpeed()
    return speedX;

Which of the two designs for controller provides the most benefits in terms of being able to change the controller to support for alternative input methods Eg, Joystick or mouse, network player or even AI? What should I preffer over the other. If you have personal expirience in game design please give me your 2 cents on this.

Answer 1

There's a more game-focused breakdown at http://www.koonsolo.com/news/model-view-controller-for-games/

The basic idea is to divide up the model, the rendering of the model by the view, and the control of the model (by the user and/or other entities). The means, for example, that your model code - the representation of the world internally, doesn't specifically know how it'll be displayed by the view. Hence, the entire graphics engine could be swapped out without touching any of the core model code. The controller is the portion of your code that deals with user input and then calls into the model to have it do something. The controller code is also pretty thoroughly separated from the model code, and could be swapped out for different control devices without needing to change the model.

Generally one is trying to minimize function calls by the model to anything else. The controller generally uses the model's function calls to change it, and the view uses different model calls to access what is needed to build the (user-visible) representation of the model.

This gets more involved when one starts trying to make a formal division between the domain objects and the object control code in the model, and it can be hard to place some code specifically in the model, in the business logic (in applications which formalize it), or in the controller code. However, for smaller games, this isn't as critical.

The short answer to the question is that generally the model will NOT query controllers, nor the view generation code.