I’m working on a game, and without getting into any details I am using MVC “patterns”, “rules” or whatever you want to call it to make the game.
The view includes everything needed to draw things on the screen, the controller passes input to the model. And the Model contains game logic.
Here’s my problem, the game is being made for mobile devices that vary in screen sizes. I feel my model needs to know the view size so it can appropriately adjust for it.
I’ve thought about it for a while I could put all the adjustments in the view, but it just seems inefficient to translate the model positioning to the view’s needed positioning every time. If the model knows the size it only needed to adjust itself once.
So my question is can I pass the view size to the model without ‘breaking’ MVC? I feel personally they are still decoupled this way because a size is just a number, I could still change the view any time as long as it has a size. But I wanted to get a community response on this because I haven’t seen many discussions of MVC being used in a game.
(And to be clear I don’t want an answer of why I shouldn’t use it in a game, but do I break MVC by letting it know the view’s size)
EDIT – More details on the game’s needs and why I wanted to pass the view.
Some objects positions need to be set relative to the edge of the screen (such as UI elements) so that they appear relatively in the same place. Sprite sizes are not stretched if the window size is wider such as an IPhone 5 screen. They will just be placed relatively to the screen edge. .If I gave it to the view to handle this, I will need a flag saying that this element is positioned say x number of pixels from TOP BOTTOM RIGHT LEFT. Then allow the view to draw it with that information. Its acceptable, I just wanted to know if there was a better way while still being MVC because it seems this way will be repeating a logic over and over, where as if I knew the view size in the model, I could convert all the relative positions into absolute positions in one run, but with this I have to convert on every update to the screen.
3
If the model doesn’t need to know the size of the view (say for edge detection or collisions), then I don’t think it needs to have that information. Can your model express locations/distances in some neutral format (“layout units” or something) that will make it easy to scale for the various screen sizes? Or does the screen size affect gameplay (there may be more enemies/targets to track on a larger screen)? If so, then it makes sense to define the playfield size in the model.
1
You might be trying to do too much in the model. If the model has to care about screen size, I would say the design is breaking some rules of MVC. Instead, why can’t the controller (or “presenter”) know the screen size and adapt the model data to match? The Controller is technically the correct place for any logic requiring knowledge of both the view and the model.
You didn’t give many specifics (like why screen size is important); it’s fair enough for you to want to keep secrets about your game, but if you can at least tell us what basic function is being performed that requires screen size, we may be able to better tell you how best to implement MVC patterns in your code.
5
Don’t put any presentation support in the model. For example, a model for a chess game would keep track of the piece positions and the player on move, report whether the game is over, and produce a list of all legal moves. All the presentation logic, such as calculating the screen position for a square on the chessboard, and rendering a chessman, should be done in the view.
If you are implementing multiple views, then factor out common code into a view service module or a view base class.
It is good to look at MV* pattern with more views existing in parallel on the same model (that is how proper separation of domain and presentation should work, seamlessly). From this point of view, how could you put screen size into the model, when there could be more screen sizes?
That is, MVP / MVVM provides slightly better structure to solve this – presenter (or view model) are parts which know of the screen size. They are the parts responsible of delivering data to show into the view. But not the model.
OTOH, there is other view (especially when it is a game), where screen size actually should be part of a model – that is when the game logic really depends on that screen size.
So, I would ask myself if the screen size is the necessary part of game logic. If yes, it is part of the model (and any screen-type views are restricted to only that one screen). If not, it is the matter of presenter/viewmodel to take care of this (and lots of other, like skinning/themes for example) presentation detail.
As usual, the answer is it depends.
If you use an abstraction for the screen size in the model, they could live together. For example, the model could know about the size of the universe or visible universe. This would be different depending on the device type or screen size … or simply put depending on the hardware.
If you put it this way, your model depends on information from the hardware (lowest level) and does it’s job. You view will take whatever the model gives to it and do the rendering job on the screen.
On the other hand, you may also use another approach. You may ask yourself, should the Model know about coordinates? I don’t know the answer to this, it depends on your application. Maybe you could use view helpers to adjust for coordinates where needed.
Also keep in mind, many times optimization is the reverse of refactoring or making thing right. If it’s a performance hit you can’t live with, sacrifice the design and make your program do what it needs to do.