0

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?

Alex W
  • 101
  • 1
  • 3
    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. – Joshua Light Feb 13 '17 at 18:24
  • @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. – wondra Feb 13 '17 at 18:58
  • @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. – Joshua Light Feb 13 '17 at 19:15
  • @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. – Alex W Feb 13 '17 at 19:33
  • @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). – Alex W Feb 13 '17 at 19:34
  • @AlexW well, the really common practice is to store your model on server and view on client. So right now I don't really understand what MenuModel could be? Can you please explain so that I can help you with some advice. Or you can just look at the common MVC-framework - ASP.NET MVC and see what I did exactly mean.

    Let's look at simple example: you have a model, that handles all the business-logic of your game: stats, creatures, game states and so on. Main menu then is just a set of words, that can send commands to model e.g. "Hey, Start a game, please" (via controller).

     – Joshua Light Feb 13 '17 at 20:22
  • It's entirely for a local game, so I'm unsure on how servers come into it. Even something as simple as a chess application has a menu and a game - it is as if we wanted to write this in MVC, in my mind. – Alex W Feb 13 '17 at 20:30
  • @AlexW so what a MenuModel you will implement for chess example? – Joshua Light Feb 13 '17 at 20:35
  • @AshkarielEter If I understand your question correctly, MenuModel would contain simple things such as which option is currently selected, is the game has saves it'd contain basic information from those saves to display, it would contain options that the view may use to display things (such as colour of the menu or other graphical settings), etc. – Alex W Feb 13 '17 at 21:10
  • @AlexW you can be sure, that a common way to implement this is something like that: create class SavesModel to store saves with methods like GetSavesFor( accountID ), on ui create a graphical menu with states support (actually this is not a model from from MVC), and add click handler on button "Saves" that will go to the controller and call GetSaves(). Controller itself will check current user id, call Model.GetSavesFor ( currentUserID ) and return it to the view. This is one way to do that. Another called Stupid View but I think for example one explained way is enough. – Joshua Light Feb 13 '17 at 21:40
  • This kind of discussion is why I tend to avoid buzzwordy terms like MVC, since they fool you into wasting time on faux-problems like "are you using the terms correctly?" instead of actual problems in the application. For example, sure you could store the color of the menu in a separate place from menu "view" but how does that help you? Instead, focus on decoupling things that multiple parts of your game care about, like say what key mappings the player has chosen: the menu needs to know that information to display it, and the game needs that in order to respond to the right buttons. – jhocking Feb 14 '17 at 16:56
  • Instead of focusing on narrowly on MVC itself, focus instead on the overall separation of presentation and domains https://martinfowler.com/bliki/PresentationDomainSeparation.html MVC is really just one example of the overall idea of decoupling domain logic from its presentation. – jhocking Feb 14 '17 at 17:08

3 Answers3

1

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.

jhocking
  • 15,786
  • 2
  • 43
  • 59
  • 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?

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

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.

jzx
  • 3,805
  • 2
  • 23
  • 38
1

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.

MrCranky
  • 6,058
  • 26
  • 48