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.

  • Screen size can be in the model just fine, the question is what populates it, at what time, and does it invert the logic/responsibility flow? You should just make sure that you do all those things nicely.
    – MrFox
    Commented Oct 23, 2012 at 17:39
  • i think your logic of decision, should be directed from controller. Thus any communication between view and model should go through controller.
    – Yusubov
    Commented Oct 23, 2012 at 17:40
  • the model doesn't know anything about views, by the way to mention about various screen size u can use other properties.
    – user160595
    Commented Dec 17, 2014 at 10:23

5 Answers 5


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.

  • I'm marking this the answer because the first sentence here helped me come to what I believe is the right answer for my project. My model doesn't really need to know the size for edge detection or collisions, in-fact since everything doesn't move it doesn't even need to know positions - I can leave the positions and placement up to the view. This way if I wanted to use the model again in the future with a completely new view I could. Though anyone reading this in the future should read all the answers because they are all really great. Commented Oct 24, 2012 at 17:36

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.

  • It need to know because I am building for multiple devices. IPhone 4, 5, IPad. Positioning and placement is relative to the view. How would the controller tell the model adapt? I mean I could tell the Model what device it is, but then I would be hard coding the sizes in to the model, and its not necessary because it can be done dynamically. Commented Oct 23, 2012 at 19:28
  • 5
    @AwDogsGo2Heaven Instead, have the model understand units of size. For example, a chessboard is X by Y squares in size. The view (controller? whatever.) can convert pixel size of 130x300 into "Hey, model, you have 10 squares by 23 squares available to you".
    – Izkata
    Commented Oct 23, 2012 at 20:41
  • @Izkata A more canonical way to do this is to express position on a scale of 0 to 1. You can then simply multiply this by the screen resolution to get actual on-screen position. Commented Oct 23, 2012 at 22:31
  • @Izkata do you mean I can infer the size to the model using abstract units? So the controller can tell the model: you have 10 by 23 squares, do something. Commented Oct 24, 2012 at 1:00
  • @AwDogsGo2Heaven Pretty much, yeah. suszterpatt's idea is also good, but if your model already has some sort of abstract unit available to it (like a chessboard having the tiles), I'd go with that
    – Izkata
    Commented Oct 24, 2012 at 1:17

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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