Timeline for Applying MVC in Game Development
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 14, 2017 at 16:41 | comment | added | jhocking | eg. Maybe the main menu shows a list of all the missions, while the game shows you info about the current mission you are playing. The mission data model doesn't need to be (and thus shouldn't be) repeated between game and menu; both menu and game controllers request data from the same mission data model. | |
| Feb 14, 2017 at 16:37 | comment | added | jhocking | Those diagrams still show "menu model" and "game model" as separate things; my point was that you really shouldn't have the model layer split up with any relation to the view or controller layers. Any state for the game is really just a part of the controller logic; the model shouldn't (or rather doesn't need to) know or care if data about, say, missions is being requested by the menu or the game. | |
| Feb 13, 2017 at 19:25 | comment | added | Alex W | My menu refers only to the main startup menu as opposed to a paused-game menu, I did not make this clear. Am I correct in thinking that this (which I believe to be close to the second example) is better than this (which I believe to be close to the first example? If so, how would one deal with changing state - supposing the player has quit the main game, how should the program deal with entering the state of the main game? | |
| Feb 13, 2017 at 18:25 | history | answered | jhocking | CC BY-SA 3.0 |