Graviton: Technical stuff

Developing this game wasn't all that easy. On the first platform, the SonyEricsson T300, the hardware maxed out at 13 FPS. This presented a problem, because in order to make the movement of the ball feel realistic I had to take very small steps. Preferably just one pixel at a time, then check for holes and collisions, move the ball another pixel, and so on. But that would mean a maximum speed of 13 pixels per second, which would be too slow.

The solution was to take several "invisible" one-pixel steps in between animation frames when the ball was moving fast. Like this:

The eye won't notice if the ball jumps a few pixels, as long as the physics work correctly during the motion.

Ignoring the holes for now, the board is logically represented by a grid where each square is either a wall (red) or not a wall. When the acceleration and deceleration have been taken care of, the main rule for making the game feel realistic is, not surprisingly, that the ball must never pass through walls.

For each one-pixel step I take in any direction, I go through the control pixels that have been colored in this last picture (which illustrates the case of a horizontal step to the right). If any of the green pixels are inside a wall, I kill the horizontal speed and take one step back. If any of the yellow or blue pixels are inside a wall (I've presumably hit a corner), I kill the vertical speed and take one step down or up respectively. Thanks to metal-against-wood collisions being relatively inelastic, this model works reasonably well even though it doesn't allow for bounces.

Originally I had planned to let the labyrinth be reflected in the shiny surface of the ball, but there just wasn't enough processor power to spare, so I skipped that, except for when the ball drops into a hole.