How do I separate model positions from view positions in MVC?

Question

Using MVC in games (as opposed to web apps) always confuses me when it comes to the view. How am I supposed to keep the model agnostic of how the view is presenting things?

I always end up giving the Model a position that holds x and y but invariably, these values end up being in units of pixels and that feels wrong. I can see the advantage* of avoiding that but how am I supposed to?

This idea was suggested:

Don't think of it in units of pixels, think of them in arbitrary distance units that just happen map to pixels at a 1:1 ratio. Oh, the resolution is half of what it was? We are now taking the x/y coordinates at 50% value for screen display, and your spells casting range is still 300 units long, which now is 150 pixels.

But those numbers conveniently work out. What do I do if the numbers divide in such a way that I get decimal places? Floating points are unsafe. I think allowing decimal places would eventually cause really weird bugs in my game.

*It'd let me write the model once and write different views depending on the device.

Answer 1

The suggestion of using arbitrary distance units is a very good one, and once it really clicks, you'll see that floating point vs fixed point is only a matter of how you represent your numbers. Using only fixed point is of course the most accurate solution, but floating point inaccuracies start to show mainly when you, for instance, exchange floats between two games that run on different hardware. Performance-wise floating point calculations are very well supported by modern CPUs and GPUs, you don't need to worry about optimisation.

Think of your view as a camera that can be pointing at any direction and zoom in and out. What the camera sees is just the model represented by some xy(z) values that map the model's position in the world. You might see terms like "world coordinates" or "world space" used in this context.

When you want to take a picture with your camera, in other words render your frame, you take the model's world position and calculate what would the position be in the current view (which always starts from 0, 0 and ends with your screen resolution's x and y components, eg. 800, 480). Let's pretend there is no rotation or zooming applied to the camera, for simplicity's and example's sake, so it boils down to knowing your camera's position in the world (using world space coordinates) and knowing the size of one unit of world distance in pixels. Then you can find out how many distance units your camera covers and which models are currently in view so that you can draw them.

Here's my artistic take on what I'm rambling about. The camera renders a portion of the world, world is 500 units wide and 500 units tall, camera instead uses pixels to draw but it maps what it sees from world units to pixels.

    +-----------WORLD------------(500,500)
    |                                |
    |                                |
    |                                |
    |       =====           ===      |
    |                                |
    |                                |
    |      +--CAMERA---(800,480)     |
    |      |             |           |
    |      |      @      |     ===== |
    |      |    ====     |           |
    |    (0,0)-----------+           |
  (0,0)------------------------------+

Answer 2

Surely the numbers might start out as nicely divisible but if you're doing any kind of trignonmetry, or accelleration, etc, they end up as floating point anyway quite quickly?

Thinking of distance measurements in pixels is convenient, but if you wanted to break away from that why not invent your own measurement, say 100 units = 1 pixel ? Or some other multiplication. There wouldn't be any programmatical advantage but no disdvantage either (assuming you always have to do some sort of conversion for the window size anyway). Psychologically it might help you break away from the notion that aspects of the view are infiltrating the model, and would stop you accidentally plotting using Model values as they'd immediately be seen as huge.

Incidentally assuming you do do some kind of units conversion from distances in your game to 'something' in pixels according to the screen size, then the original distance is your model unit and the 'something' is the view unit, so that's the point where you're separating the concerns.