When making a game, one thing you have to decide early on is what you will use as units. Having a game unit allows you to consistently express things like distances and speeds. Below, you can see the units I use for Super Retro Crossover. Since the world is split up into tiles, 1 unit is equal to 1 tile (16 pixels).
Having a unit that makes sense and is easy to wrap your head around is important. For example, if I tell you that Mario’s max walk speed is 5.625 game units per second, can you imagine how fast that will be in your head? With the units I’ve chosen, it’s pretty easy. He’ll move past about 5 and a half tiles every second.
Units shouldn’t always have a direct relation to pixels though. For example, one unit is equal to 16 pixels now, but if I wanted more detailed graphics, one unit might equal 32 pixels or 64 pixels. It’s generally a good idea to think of rendering as separate from the rest of the game engine.
I’m telling you all of these things because I did them wrong in Super Mario Bros. Crossover. In that game, one unit was equal to half a pixel. Look how much more confusing this is!
In this case, Mario’s walk speed would be 180 game units per second. That’s a lot harder to visualize in your head. The point is, keep your game units simple and intuitive!
14 thoughts on “Game Units”
Hmmm, interesting. And funny considering how i can’t help but feel like SMBCO is not wide enough, looks very squished into my monitor.. large LARGE black areas on both sides. But i realize also that it’s based on old NES ratios.
But a higher pixel density allows for more precise control over stuff… Isn’t that a good thing? D:
If you separate rendering from game logic, you have all the control you need.
I’m enjoying the frequent posts. Keep it up!
I couldn’t even imagine measuring in pixels, that makes the graphic you showed in your vid recently make total sense. Thx for the great post!
U want this game translate to chinese? If u want pls give a language file to me.(And in china mediafire/dropbox walled)
All the stuff I did before measured stuff by pixels. I should probably start using units.
Good point. Do you always use the delta time of framerates in your movement speed calculations to ensure frame rate independent movement?
Yes, but I will most likely switch to a fixed time step at some point.
A problem I tend to encounter when using delta time is what if there is a low enough framerate that momentarily causes the movement to “jump” a larger than normal distance so then my collision detection may pass through an object? Any suggestion?
Have a max delta. That’s what I did in SMBC.
Genius…thanks for the tip.