Think card game …
Computer attacks human with a card. In response, player moves the card on the View to beat it.
In this scenario please confirm that:
(1) It is ok for View to know, where on screen “landing area is” without asking it’s controller
(2) It is ok for View to know where the “defender” card on screen is without asking it’s controller
If the view is aware of who both the attacker and defender is, (3) is it ok for a View to determine whether attacker can beat the defender?
If this is not ok, (4) is it ok for a View to class other then it’s controller for this information (think Utils class), or should it always be the controller?
(5) Would it be better instead to send a delegate method to the controller indicating that “attacker card landed on defender card” and expect boolean whether attack will succeed?
The view is a passive input/output device. It should not know anything about the gameplay rules, like whether the attacker can beat the defender. Even the controller should not know the gameplay rules, the model always decides that.
The view should be able to represent and handle all possible input and output states and relay the input to the controller. The controller will pass the input information to model and update the view according to new model state. In your case the view detects that card A landed on card B and passes the information to the controller. The controller passes the information to the model, the model transitions to a new game state and the controller will update the view to the new state. Sometimes the view can update automatically by observing the model directly, it depends on the situation.
A good way to think about the MVC separation rules is to imagine porting the game to a different interface (GUI/CLI) or a different skin. If you find that you would have to redo a substantial part of the code to support a different interface, that you would have to touch something besides the interface-specific stuff, that means the design is not optimal.
Another good source of design intuition is testing & simulation. If want to run some automatic tests or game simulations, you are forced to keep the game code separate from the input and output inside the model. When the logic is sprinkled over the whole MVC, testing and simulating the game hurts and reminds you that something is wrong.