Developer’s Notes 0001 – Revisiting Box2D (Start)

This is an excerpt taken from my OneNote page regarding Box2D. If anything, it shows that I took a lengthy hiatus from this library and I wanted to get back into using it. However I hit the same wall I hit before which was determining a sane pixel-to-meter scalar which is required for a proper implementation. Also, it clearly outlines that I’m not a physicist in any way and that I write in a very wordy manner.


Something that I’ve always had trouble with regarding the usage of this library is the scalar for pixels-to-meters. The official notes from the library developer state that it’s really dependent upon the game as to what value this scalar should be. However that response always struck me as odd; why should this value be so volatile as to not have some standard that works for a majority of cases so that you can at least get started using it? I always thought there would have to be some common expression of this scalar that could be applied to any rigid body in a simulation unit. As it turns out, there may be one although I’ve only been able to catch glimpses of it here and there on the internet.

One site in particular, run by an Italian ActionScript developer, makes a claim of an “unwritten rule” that 1m is equivalent to roughly 30px. ( I have seen this claim on a few other fringe sites that have appeared in the recesses of Google searches however there has been nothing that has substantiated this claim by any leading developers or physicists who use this library for simulation purposes.

The core of the issue stems from the units that Box2D uses to express rigid bodies. Relying on the MKS (meter-kilometer-second) system, a 1/1 ratio between meter and pixel doesn’t exist. Knowing that the conversion factor of a meter to a foot is 1/3.28, if a 1/1 ratio between pixels and meters existed, a 320px X 64px image would be 320m X 64m (1049.6ft X 209.92ft) which would most likely not translate to a real-world object that we would want to exist in the simulation.  Furthermore, the force that would need to be applied to that body to get it to move, assuming it were a non-static body, would be immense.

There is a small paragraph on the official wiki for Box2D which is effectively a FAQ. One of the questions is as follows:


There are a few things to take into consideration while reading this example:

  • The scalar chosen in the example (0.01) appears to be entirely arbitrary. There is no real rhyme or reason as to why it was used instead of another arbitrary scalar like 0.25.
  • The scalar is applied not only to the dimensions of the sprite (measured 100px X 100px thus making its rigid body representation 1m X 1m (100 * 0.01)), but also to the coordinate system as well in order to accurately reflect the body’s relative location. In the example, the sprite starts at Pixel Coordinates (345, 679). To Box2D, and based on the chosen scalar, it would actually be located at (3.45, 6.79) as a result of ((345 * 0.01), (679 * 0.01)). Upon moving, the sprite is then located at (2.31, 4.98) in Box2D Coordinates. The translation to Pixel Coordinates requires the inverse operation of the scalar applied ((2.31 / 0.01), (4.98 / 0.01)) which would place the sprite at (231, 498) in Pixel Coordinates.
  • The example clearly does not state or even remotely lean to an “unwritten rule” that would be indicative of the 1m/30px ratio. Instead it leaves it up to the reader’s interpretation as to what the scalar should be.

Clearly there will have to be some investigation as to what would work well. The information that I’ve been able to find here should be sufficient enough to get started with a simulation to play with.

Game Development – Migrating to Classical Mechanics

Let’s clear up some possible confusion regarding the title of this post. I’m not necessarily directly talking about game play mechanics as I am talking about the branch of physics called Classical Mechanics. You know, the fun stuff that helps us describe motion of mass under certain types of forces and the effects, both direct and indirect, resulting.

Well it’s fun for me anyway. Even though I hadn’t necessarily realized how much I’d forgotten about really simple stuff.

And let’s clear one more thing up here. I’m not a professional mathematician or physicist. I’m a software engineer. So if you’re looking for a primer on those areas, you’d be better served by Wikipedia/Wolfram, sites dedicated to those areas, or proper coursework. More importantly, my understanding of certain concepts might not be as robust as a skilled professional in either of those areas but I’m confident enough that I can describe what I see in everyday life enough with classical mechanics to be proficient in what’s called applied mechanics (that was actually my strongest point).

What I wanted to talk about here is something that I’m sure every game developer has dealt with at some point in time when designing a 2D game (strictly 2D). But to best describe what I’m getting at, I should probably start with an example.

Moving a block from one point to another is a relatively simple task to accomplish. Assuming that you’re not using an origin offset of some type, moving from point A to point B would look like this:

A simple affine transformation
A simple affine transformation

Geometrically speaking, this can be accomplished by a simple affine transformation. However, even though you could get away with expressing this event with an affine transformation, it’s not taking into account how this would happen in the real world. Even autonomous movement doesn’t occur without some type of external force being applied to the object to make it move in a certain direction. That being said, an affine transformation like this wouldn’t actually happen without some force being applied to the rectangle to make it move from vector A to vector B. Visually, the player may or may not be able to tell the difference between which method you chose to use. But we all know which one is more fun. 🙂

With that example, I wanted to point out that even in the most seemingly simple situations, it’s really easy to avoid the use of classical mechanics. But should you even if you could?

The really nice thing about classical mechanics is that the rules for movement, collision, and forces are all already laid bare before you. Even better is that these rules and observations are and have been made about real-world objects and these rules can be expressed mathematically (thus you’re translation point into software). At that point, it’s nothing more than to write a utility class or a series of methods that parameterize those expressions and make arbitrary calls to them in code as needed.

Ignoring classical mechanics means that you’re basically left to invent your own set of rules for these behaviors. Not only would that mean that things would probably not do what a player would expect them to do, but it makes a significant amount of work for a developer.

One particular point of difficulty for developers looking to migrate to using classical mechanics would be the change in understanding of objects in the game world. You can no longer look at your objects and entities as mere rectangles and circles with dimensions based in pixels. Now you have to start thinking about how these objects relate to real-world counterparts. Gravity now comes into play thus properties like mass, density, volume, etc.. are all now factors. It’s not enough to simply say “the user pressed this key so now I call this method to do a transformation to make the player move from here to here”. Now it’s more or less along the lines of “the user pressed this key so based on the current factors like gravity, applied friction of the area they’re standing on, if the wind is blowing or not and how fast, how fast can they move in the direction requested and move them accordingly”.

It all comes with the territory transition though.

A really simple but fun exercise for this transition would be to try and write a Pong clone implementing as much of classical mechanics as possible. It’d be fun to discuss this so I think I might try to do so soon.