Model updating itself in MVC?

Question

My group in school is tasked with creating an application of our own choosing which follows good object oriented design principles. The group has chosen to make a tower defense game with help of libGDX (a Java game framework) and we are currently debating whether the update loop of the game (code that is executed each frame) should be implemented in the controller with libGDX pre-existing functionality or in the model itself in the form of a custom update loop.

Is there anything that clearly goes against the model being able to update itself? Some in our group argue that having the model being updated by the controller makes it too dependent on a specific controller, while some argue that having the update loop inside the model narrows the possible usage of the model to only being used by views and controls that works correctly with the high update frequency of the model state.

Answer 1

Considering that your model is the game logic (e.g. the territories, the tower, the ennemies, the rules of the game), the game loop would works this way:

• get next input event to process (mainly user input, i.e. a controller responsibility)
• translate the event into commands for the game logic (model)
• (the view will update itself if necessary since it's an observer of the model).

Now can a MVC model change a model directly? Of course! If the user presses space bar to fire, the controller would send a "fire" command to the game. If in the model an enemy is hit, the model would chain-react and update its state and depending on the rules, the model may even decide that the enemy died and remove it from set of active enemies. There is no prohibition there.

However, the model should not start to manage itself events outside of the game loop. There are in particular timer events (e.g. that will tell ennemies to advance), which should in principle belong to the controller, since it's just another input from the game environment that will trigger change. Timers being moreover very platform dependent, this split of responsibility helps to keep the model platform independent. Which makes sense since you could play with the same game rules on a phone, on game console, a PC, or even with plain-text based legacy terminals.

By design the model receives its update commands from the controller. This doesn't makes it dependent of any specific controller. On contrary: the model does not need to know anything about the controller. The controller tells the model what to do. Any other controller is ok, provided it can tell the same things to the model. If there is a dependency in the other direction, there's something flawed in your design.

Answer 2

Whichever solution does not require getting data out of objects is probably the more object-oriented design.