0
\$\begingroup\$

Suppose one is working on a game which has more than one component of code where the data, view, and logic is disjoint from the workings of another component of code (i.e. all games have a main menu and the game itself, with their looks, logic, and data being independent). How best should one lay an application out?

I see at least two options:

  1. Top-level code creates model, view, and controller objects which then each have fields of each area of the application. For example, the model object may have a menuData field and a gameData field. Each of the view and controller would also have something similar. Additionally, the main controller would have access to the main view and main model.
  2. Top-level code creates an object for each area of the code (i.e. menu and game), and then each of these has their own model, view, and controller.

Are either of these the best way to go about this? Is there a more common approach than MVC?

\$\endgroup\$
  • 3
    \$\begingroup\$ The main purpose of MVC is to decrease the complexity of the program by splitting logic onto layers with easily managed dependencies. There are a few implementations, each can be used aswell, but I've not heard about something like your first point. The second point seems better, but, as I've said before, you should program your layers independently, so that changes in the view will not affect the model. You can build model as you like and then connect it through controller (or observer) to the view. So the whole model should not know that there is a menu at all. \$\endgroup\$ – Ashkariel Eter Feb 13 '17 at 18:24
  • \$\begingroup\$ @AshkarielEter isnt it the functionality mvc/DI frameworks usually handle for you? Resolution and instantiation of dependencies to be injected. Since game engines arent usually build around mvc I can imagine there might need to build similar framework functionality for your(or existing) game engine. \$\endgroup\$ – wondra Feb 13 '17 at 18:58
  • \$\begingroup\$ @wondra well, you're actually right, but I've talked about the whole conception of MVC, and the author of a question maybe misunderstood some aspects of the pattern. \$\endgroup\$ – Ashkariel Eter Feb 13 '17 at 19:15
  • \$\begingroup\$ @AshkarielEter I have commented on jhocking's answer with a picture of the second point, however here the concept of the "whole model" doesn't make sense, and I, in fact, have a model specifically for the menu. I therefore am not sure what you mean by your last point. \$\endgroup\$ – Alex W Feb 13 '17 at 19:33
  • \$\begingroup\$ @wondra I am not sure I understand, could you expand on this? If it is relevant, I have been using a Java binding of OpenGL (called Slick2D, based upon the LWJGL). \$\endgroup\$ – Alex W Feb 13 '17 at 19:34
1
\$\begingroup\$

Sounds like semantic noodling to me. I guess I tend more towards your option 2 in that I have lots of different model objects for different aspects of the game instead of just one monolithic model object that handles everything, but I don't keep "menu" and "game" areas strictly separate. After all, what if you want to be able to access the main menu every time the game is paused, so that the player can save/load games at any time, and then the main menu has options that affect the game?

Instead, I tend to break up my model and controller objects with little relation to each other and instead think of all the model objects as the model "layer" of the application. Unless my "layer" notion is what you meant by the model object in option 1, in which case, like I said semantic noodling.

Anyway, any controller can access any model object in the model layer, rather than only menu controller accesses menu model etc. Meanwhile the model objects are split up into areas of responsibility like missions, enemies, etc rather than menu, game, etc. The menu controller can access the mission model if the player hits "Cancel Mission" in the menu view, that sort of thing.

\$\endgroup\$
  • \$\begingroup\$ 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? \$\endgroup\$ – Alex W Feb 13 '17 at 19:25
  • \$\begingroup\$ 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. \$\endgroup\$ – jhocking Feb 14 '17 at 16:37
  • \$\begingroup\$ 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. \$\endgroup\$ – jhocking Feb 14 '17 at 16:41
1
\$\begingroup\$

Separating model from view and controller is invaluable in one very specific aspect of game development often overlooked when not developing at scale: testing. Develop your game simulation as a model, and you can swap out a user input device controller for an automated, repeatable testing harness. This allows for incredible leaps forward in testability, allowing for automation frameworks to handle large swathes of regression testing without requiring legions of testers to replay the same levels over and over again just to find out if a systemic change has broken previously working assets.

This really comes into its own when you are suffering from a hard to reproduce problem, you can record simulation inputs and save them to allow automated tests to continually play through your game, over and over, exercising all those same parts that the user does.

It also allows you to measure metrics associated with your game - memory usage, framerate, etc. in a repeatable and methodical way. It better allows you to alter your View code, safe in the knowledge that changing the rendering timings probably won't lead to gameplay changes.

\$\endgroup\$
  • 1
    \$\begingroup\$ Although this highlights advantages of MVC in game development, I don't see how it answers the question. \$\endgroup\$ – Vaillancourt Aug 7 '17 at 10:07
1
\$\begingroup\$

First, a quick review of MVC as it pertains to OOP:

  • Model - objects that store and maintain data consistency with respect to the problem at hand, in our case simulation.
  • View - objects that translate output to the user.
  • Controller - objects that translate input into commands that alter the model.

In its purest form, we should be able to save a game's state using only the model and a different view. Or possibly change the type of game being played by swapping in different views and/or controllers.

Audio options, for example, could be seen two ways. On the one hand you could take it to be configuring how the view works (the audio portion of the user interface) and nothing to do with the model (the game state irrespective of user settings). Or, you could see it as configuring the model (the program state, including user settings and game state) and the view simply reflecting that.

My own preference is to have the model represent just the game state, because the view is supposed to be separable from the model. You could imagine changing the view to make the game work for deaf people, at which point it wouldn't make sense to incorporate audio options in the game state.

The usefulness of this modularity can be felt when swapping the controller to port a game to another platform. This often means literal controllers (mouse and keyboard for gamepad) as well as operating system input (checking whether the user alt+tabbed out of the game doesn't make sense on a console).

Finally, to address your question directly, having each layer in every component is probably going to mean that the view and controller layers too closely parallel the model, thereby making them less separable. They should be basically independent from each other, except where they must join together.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.