Is there a good tutorial on how to decide game metircs. For ex. : I modeled all my 3D objects using meters as the length unit. I want objects to move at a certain speed (m/s), etc... Since the screen is measured by pixels, how can I still use meters as my measuring unit when rendering and manipulating objects ? thx.

If you're in 3D, the camera projection matrix will take care of turning meters into pixels, based on distance.

If you're in 2D ortho mode, you'll have to decide on a scale yourself. How much of the game field do you want to see? If you want to see, say, 20 meters in each direction, and the player is 2m tall, then you want the screen width (say 1024 pixels) to match 40 meters, so each pixel is 40m/1024 ~= 0.04 meters wide.

I would highly recommend using and sticking to a well-known units system, ideally SI. Cases will invariably crop up where you need to convert some of these units to something specific to your API, but this is unavoidable either way.

If all of your lengths are in metres, times in seconds, forces in Newtons etc. then you can guarantee that any calculations you make will also come out in the 'right' units and you have the bonus of being equipped with intuition. I know that a car weights somewhere around 1,500kg and that it can travel up to 40m/s. So when choosing a momentum for my car crash simulation (should I be sick enough to write one) I know that 60000.0f is a reasonable top-end momentum. If I were working in pixels, clock-ticks and pounds, I'd be totally lost and would have to resort to trial and error.

As hplus0603 said, your projection matrix will take care of perspective when rendering in standard 3D: a 6cm ruler from 20cm looks as big as a 6km train track from 20km, so pixels aren't an issue. Similarly, if you are pushing sprites around a screen, you may want to work the code in some usable format (your 32x32 pixel hero may be taken as 180cm tall) right up until the moment it gets rendered, when you'll need to scale into pixels accordingly. Note that in most cases, you can set up your projection so that screen space is defined in dimensionless coordinates. If appropriate, make full use of this, as converting miles to dimensionlesses is simpler than converting miles to pixels.

The particulars of your units aren't all that important, so long as you are consistent. However, working in meaningful units for as much of the process as possible will help prevent bugs and aid debugging.

Regards
Admiral

What would you suggest for a large terrain map? Or massive buildings? Obviously rounding could become an issue. I know this kinda drifts off topic, but I'm aware that some games use map partitioning techniques to combat rounding errors; using [x, y, z, ID] vectors, where ID points to a map partition, and the x, y, z are relative within that partition. Are there other techniques that address the representation of large objects with minimal rounding problems (without using doubles)?

Quote:Original post by Tachikoma
Are there other techniques that address the representation of large objects with minimal rounding problems (without using doubles)?

Yes. There is fixed point. A normal 32bit integer with 16bit on either side of the decimal point give you a 65km world with precision down to .015 of a milimeter for the entire world. None of this losing precision as you leave the centre of the world, which never made much sense anyway. I actually did this in one engine, and with the vertices of objects as float offsets to the fixed point location (it does make a bit of sense for precision to be lower for big models) it was all a bit overkill. It worked well, but it was a bit annoying, and I never made use of it's potential anyway.