Hi! Today, an explanation of collision detection in games. Less pictures this time, I’m afraid, since I’m mostly talking about code and concepts instead of showing off graphics.
Drawing any random 2d series of hills and valleys and expecting the player to be able to move over them has several problems. First, figuring out how to keep the player out of the ground becomes both complicated to code and computationally expensive. Second, storing a unique set of graphics for each level fills up space incredibly quickly. To avoid both of these issues, games often use something called “tiles” – a pre-determined series of small, square graphic elements that can be repeated (tiled) at will across levels. This not only saves storage space, but means that the player will only ever be colliding with purely vertical or horizontal walls. In turn, that makes keeping the player out of those walls easy and efficient.
Take, for example, this screenshot of Super Mario Bros 3. Each square set of bricks that Mario is standing on is a tile, clearly, but even the pipe and ground are made of tiles carefully designed to blend together naturally. If you already know the basics behind tiles and are looking for a tutorial to implement something like it in a game you’re making, this video explains things far better than I could, and it helped me implement this system in Solid Light.
Of course, sometimes you don’t want purely horizontal or vertical walls – slopes aren’t necessarily bad things, after all. In Solid Light, complications come two-fold: Not only does the player need to be able to either walk on or be pushed off of any arbitrary beam at any arbitrary angle, it also needs to work in only one direction. I want to stop the player from trapping themselves into a corner with light beams, so I decided to only let them push upward and act as a floor, not as a ceiling. Additionally, the player is only one button press away from being able to drop through those floors, so they won’t get stuck.
In order to keep the player out of slopes, I use linear projection to move them out at a right angle to the slope. Previously, I tried snapping only on the x/y axis for performance reasons, but too many edge cases and bugs were introduced to make it worth keeping around. For example, say you keep the player out of slopes by pushing them up vertically until they’re not in the slope. What if the slope leads up to a ceiling, and the player would be pushed into that ceiling by the slope? The ideal behavior would be to stop the horizontal movement of the player, but if the game is only adjusting vertically, the player will end up either inside the ceiling or below the slope – neither of which are acceptable.
Next week, I’ll be talking about the final implementation of the beam in more detail, and probably lighting effects after that.