In game development, is the controller in MVC exclusively for working with user input?

Question

I read conflicting things on this.

From Wikipedia:

controller Processes and responds to events, usually user actions, and can cause changes to the model.

This word is TYPICAL, which is confusing. If not only user input, then what else?

Answer 1

I see the controller as a coordinator, most of my code is usually in the controller. This is where most branches take place. In a view or model, most of your code will deal with itself (the data object does not know anything about the view object). However, the controller maps the data object (model) to the view object, so my thoughts are about this as a coordinator.

A general “test” can be applied to their application to see if they follow MVC enough: “Is it very easy to override your application? (Change the view without rewriting a whole bunch of code).

Do not get carried away with all the religious debates and strict "rules" surrounding MVC, a product that makes money only after 80% of the MVC rules is better than a product that has not yet been made, and also a complex for the actual launch on the right ...

Answer 2

Not. In the classic template, the controller can receive input from any source. For MVC web infrastructures such as Ruby / Rails or ASP.NET MVC, the controller receives it from the request and form parameters.

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

EDIT : when I say inputs from any source, I think of an application that can have a graphical interface and other interfaces for inputting sources, for example, a sensor subsystem that interacts with the controller to update the model.

EDIT: based on your upgrade the controller can respond to network events, if the game is a massively multiplayer online game. They will not be processed by the controller for the user input device.

Answer 3

The responsibility of the dispatcher is to control the flow of applications. It processes the requests, composes the corresponding models / views / helpers, and possibly gives an answer.

Requests can come from many different sources, such as web and local services, scheduled events, etc.

Answer 4

I invoke verification and disinfection of the user part of the view input.

I call the controller logic, the part that receives and works with verified, sanitized data. So you can write a test harness that acts like a view that passes data to the controller and validates the results.

Answer 5

No, it should not be used for ALL interactions between the model and the view (user interface screen). This includes displaying data on the user interface screen (screen update) as it is extracted from the model, as well as responding to user inputs / interactions with the user interface screen ...

it may also include updating the user interface screen as a result of changes in the model (in the data) using these user actions on the OTHER screens or (in a multi-user parallel system), other user actions on the data in the repository (database)

Answer 6

Not necessary. The controller can process user input, update your model, and possibly decide to directly return the JSON result, or even an image created using a dynamic image instead of a view page.

The controller can also decide the flow of pages. The user clicks the "My Account" link on your website, but has not logged in yet, so they get to the login page. After a successful login, the controller may decide to redirect them to the "My Account" page using the query parameter ReturnUrl or not.

You can also put validation logic in your controller, but I would not suggest this approach for larger projects. This logic belongs to your model.