A Look Under The Hood

A classic Breakout-style ball simulation can be created rather easily. However, once you include spin, complex balls, or move to a full physics simulation, complexity quickly spirals upwards. I asked Josh Welber, lead programmer of Large Animal Games’ LEGO Bricktopia, for some tips on managing the ball simulation.

Is there an obvious point where ball motion becomes too complex to manage with a simple motion simulation?

Josh Welber: A simple motion simulation where the ball reflects perfectly from collision works well if you are going for the classic Breakout mechanic where: (a) all obstacles are rectangles, (b) the walls are always static and, (c) the ball has a constant velocity.

When you start adding arbitrarily shaped obstacles and walls, animated obstacles, or want a more realistic and variable ball motion, you will want to consider a more general physics solution (either home-grown, or built out of one of the many open source packages: http://en.wikipedia.org/wiki/Physics_engine).

Is there anything developers should look out for when using a full-blown physics system in their Breakout games?

JW: The tricky part of working with a more generalized physics simulation is that Sim tends to want to control everything.

For instance, artificially changing the velocity of the ball or other properties of the world can upset the simulation. Most robust systems will allow this to happen at some point in the integration/collision loop.

However some systems rely, for instance, on the velocity vector to determine how to resolve collisions over multiple steps – artificially changing that vector inbetween integration loops can “fake out” the physics simulation, causing it to resolve collisions incorrectly.

What impact did this have on developing LEGO Bricktopia’s implementation of fast/slow ball power-ups and paddle bump?

JW: In order to have realistic ball movement as well as retain control of ball speed, we implemented a system where the ball speed was artificially increased or decreased by applying small forces to it if it was outside the target speed range. For slower movement, we just threw in a “bullet time” trick, where we controlled the simulation time (We would slow down the entire sim in certain cases. That is, instead of integrating the real elapsed time, it would integrate say 50% of that time, so everything would appear slower).

The paddle bump was another place where we needed to implement some artificial forces to get what we wanted. The paddle is actually really massive compared to the ball, so that real result of say a “super bump” would be a tremendous increase in speed.

However, the force correction system I mentioned above would make sure that the ball would rapidly slow down if it was going too fast. The result was a satisfying bump without any crazy unpredictable ball speed changes.

What facets of the ball simulation are you most proud of in LEGO Bricktopia?

JW: I would say the brick stacking/paddle mechanics, and getting that to play nice with the ball. The player has the ability to catch LEGO bricks on their paddle, changing the paddle’s shape and unlocking a range of strategies for completing the levels. Getting this stacking mechanic to work seamlessly with the overall physics simulation was a real challenge, but it really paid off in the final game.