In game development, is the controller in MVC purely for dealing with user input?

Question

I've read conflicting things on this.

From Wikipedia:

Controller Processes and responds to events, typically user actions, and may invoke changes on the model.

It's the word TYPICALLY that is confusing. If not just user input, then what else?

Answer 1

No. In the classic pattern, the controller could get inputs from any source. For web-based MVC frameworks such as Ruby/Rails or ASP.NET MVC, the controller gets it's input from query and form parameters.

More information on MVC at http://en.wikipedia.org/wiki/Model-view-controller

EDIT: when I say inputs from any source, I'm thinking of an application that may have a GUI and other interfaces to input sources, say a sensor subsystem that interacts with a controller to update the model.

EDIT: based on your update, a controller could respond to network events if the game were a multi-player internet game. These would not be handled by the controller for the user input device.

Answer 2

I call validating and sanitising user input part of the view.

I call the controller the logic behind, the part that takes the validated, sanitised data, and does work with it. That way you can write a test harness that acts as the view, that supplies data to the controller and test the outcomes.

Answer 3

No it should be used for ALL interactions between the Model and the View (the UI screen) This includes the display of data on the UI screen (updating the screen) as retrieved from the Model, as well as responding to user inputs/interactions with the UI Screen...

it might also include updating the UI screen as a result of changes in the model (in the data) by this users' actions on OTHER screens, or, (in a multi-user concurrent system), other users actions on the data in the repository (database)

Answer 4

Not necessarily. The controller can process user input, update your model and maybe decide to directly return a JSON result or even dymanically generated image instead of a view page.

The controller can also decide page flow. A user clicks a "my account" link on your website but isn't logged in yet so they get directed to a login page. After a successful login the controller can decide to redirect them back to the "my account" page via a ReturnUrl query parameter or not.

You could also put validation logic in your controller but I wouldn't suggest this approach for larger projects. That logic belongs in your model.

Answer 5

The controller's responsibility is to manage application flow. It handles requests, composites the appropriate models/views/helpers and optionally issues a response.

Requests can originate from many different sources, such as web and local services, timed events and more.

Answer 6

I view the controller as a Coordinator, most of my code is usually in the controller. This is where the most of branches happen. In a View or Model, most of your code is going to deal with itself (a data object doesn't know anything about a view object). However a controller matches a data object (model) to a view object, hence my thoughts of it as a coordinator.

A general 'test' one can apply to their application to see if they are following MVC enough: Is is very easy to re-skin your application? (Swap out the view without re-writing a whole bunch of code).

Don't get caught up in all the religious debates and rigid 'rules' surrounding MVC, a product that makes money by only following 80% of MVC 'rules' is better than a product that isn't done yet and too complex to actually run right...