2d top-down map: normalisation or not?

I am an absolute beginner with game programming, should this question be poorly formulated, be aware it was not sloppiness by my side, but lack of game programming experience.

The game I am planning to code will use a top-down 2D map as "world". The world might be larger than the window (the window can zoom in or out) and the vehicles can be located at any point of the world (= it's not a tiled map, the space is "continuous").

To clarify with an example: if the world is a terrain of 1000x1000 metres, a vehicle could be at location (327.31, 720.4) metres.

My question is: what is the most convenient way to represent the world internally? I could think to these possibilities:

• do nothing and use metres as if I were working with the physical object,
• normalise to pixels defining the world size as the number of pixels for representing 1000 metres at maximum zoom,
• normalise to 1 defining the word as a square of size 1

...but I am sure there might be some other ones / some of mine could make no sense. It's just that being my first game I don't have a clear pictures of the problems ahead of me, and I would like some guidance in making a reasonably correct initial choice.

Thank you for your time.

• I had this issue. I won't post as an answer - there's already great stuff there. But if you work in some arbitrary unit, you can support any resolution just by tweaking a single value. It also is much easier to deal with in terms of gameplay. Finally, with large numbers such as pixel measurements, physics sims can explode. – The Communist Duck Jul 14 '11 at 16:27

I agree with using a real-world value (meters, feet, etc.) as your basis for distance. The problem with your other two suggestions is that they are both variables. Working with a world size of 1 will cause all of your arithmetic to be floating-point between -1 and 1, which may lead to more floating-point errors. Also, should you ever decide to make variable world sizes ("Large" worlds for longer games, etc.) you will introduce many problems to your code. Likewise, if you use pixels, even at a maximum/minimum zoom level, you will run into confusion as well as problems should you decide to increase or decrease zoom levels.

• This answer is excellent (+1). I particularly like how you explained the potential problems with using "1" for the size of the world. – Randolf Richardson Jul 14 '11 at 3:42
• If you are doing any kind of physical simulation, even if totally made-up, using fixed-point integers will end up causing invalid results. All you have to do is model a single vehicle moving at unit speed on the diagonal and you'll find you have no way to properly represent its position. – edA-qa mort-ora-y Jul 14 '11 at 9:16
• Agreed RE: using meters. It's also going to help you mentally visualize and understand things as well. "That vehicle is 5 meters long", or "These two objects are 500 meters apart" and not have to do mental math all the time to get a feel for what you're doing. – Tim Holt Jul 14 '11 at 18:50
• -1 that statement about integer arithmetic being faster than floating point is not true in general, in fact they are much faster on most modern platforms – Maik Semder Jul 14 '11 at 22:29
• Still using fixed-point values for absolute positions can be a good idea. This leads to constant precision and identical physics all over the world. – CodesInChaos Jul 16 '11 at 14:15

Of the three options you suggested, using meters will probably be best. As you create other data, dealing with length in meters will make you life much easier. Among other reasons, you may decide to change your world size, or different levels may need different sized maps.

You may also decide to use feet (or possibly inches). Part of this decision may depend on what middleware packages you use - some physics engines prefer one unit type or another (though it's almost always configurable). For the most part, you can just choose a unit and go with it.

Normalize to '1' is really not the way to go (what if you have a world not square? or several worlds with different size...).

Using pixels as ... NEVER Mix up gameplay and graphic measures!! Don't lock yourself up so you can't change the graphics without having to change the code.

So meters (feet or whatever measurement you like the most) is the way to go. You will feel much better to code your missile launcher to move at 50 km/h than 0.00076 units/second...