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
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.