Building Ground to Stand On
collision fixbot level design level editor line math lines math surfaces whiteboard demergo programming
Post by Dan, Programming Director at Demergo,
Early on in the design of Project Fixbot, we knew that we wanted large and somewhat complex levels, designed primarily around our movement style. We needed to be able to handle different kinds environments, and we wanted a lot of flexibility when it came to the design of the actual levels - this included the ability to have the ground at weird slanted angles. But this created some new challenges for us: how would we handle collision, with all of the different kinds of things the player could collide with?
One common way of doing collision is to handle it by using the object's bounding box and sprite to decide if collision has happened. Sometimes this includes using per-pixel collision to handle odd-shaped objects. The problem with using the bounding-box method in this case is the flexibility we wanted with our environments (weird slants and the like). Per-pixel collision checks can be expensive on performance, and in our case it wouldn't handle all our movement style easily.
That was when I decided to use "surfaces" (as we call them) instead of using bounding-boxes or the art assets themselves for the collision.
I figured out that all we really needed to handle all of our movement and collision was an invisible line. These lines (surfaces) would tell our engine how the player and enemies should interact with it - whether that's by colliding or bouncing or something else. Using these surfaces lets our team jump from level design to level implementation much faster. While Joel and I were creating the surfaces and how they would work in the engine, Todd was creating a level editor that would let us create them. In the level editor the surfaces get created on top the level art assets, allowing Zak and everyone else building the levels to match things up quickly.
Getting the surfaces working correctly involved a lot of line-based math programming. In code, our surface class has a lot of helper methods we had to create to do things like computing the slope of the line, checking the distance between a point and the line, and checking to see if two lines actually intersect at all. Another tricky part was deciding what side of the line the player was on so that we could rotate him accordingly - it would be really annoying for the player if he launched Fixbot at a wall only to end up inside of it; getting that part working was one of the first major hurdle for us to get over.
Overall, the surface method has been difficult to implement properly, but has been very rewarding. With a lot of hard work and a lot of staring at the whiteboard, we've managed to build ground to stand on.
Reposted from Fixbot Blog