It took way too long, but we finally got our internet service activated at the new apartment, so hopefully there won’t be any noticeable interruption in my productivity as we get the last few things moved over to the new place.

Continuing from last week’s projectile lobber experiments, I’ve been prototyping another new enemy type this week. As I was in the middle of replaying Super Metroid, I thought it might be fun to try to replicate the crawling behavior of these guys.

It’s a pretty simple design, and one that’s been used in countless games. The enemy traverses the surface of the world either clockwise or counterclockwise, turning corners as appropriate. But despite its apparent simplicity, this was the first time I’d implemented this particular behavior myself, and it turned out to be an interesting problem to solve.

The first step was to identify the two kinds of corners the creature may encounter: “inner” corners, those in which our path crosses a wall and we turn to crawl along that wall, and “outer” corners, those where the surface we’re crawling on ends and we turn onto the adjacent edge. Each of these cases requires a unique solution.

Identifying inner corners is easy enough. My collision system can send a callback to anything that requests one whenever we collide with anything. So in the event of a collision, we check to make sure the thing we hit was a solid wall and not another entity like the player. If it was, we rotate our velocity ninety degrees in the appropriate direction, adjust our position such that we’re flush against the new surface and not intersecting the old one, and continue our traversal.

To identify an outer corner, I do line traces from the center of our entity opposite the normal of the surface it’s crawling along. If this line trace collides with the world, we still have solid ground and can continue, but if it doesn’t, we’ve reached the end of our foothold and should turn. As in the other case, we rotate ninety degrees and reposition ourself flush against the adjacent edge.

My solution accounts for entities with various collision box shapes, flat or tall. One case I haven’t solved yet is when the collision box is larger than one 16×16 tile in either dimension. This would require doing some additional checks to ensure that we can fit in the allotted space before turning.

Another edge case that arose in testing, and one that I did feel was necessary to solve upfront, is when the surface a crawler is standing on is destroyed out from underneath it. As I am supporting destructible terrain in the Gunmetal Arcadia games, I knew this was likely to come up at some point, so I should probably figure it out as soon as possible.

When I had initially prototyped crawling movement, it was as an alternative to my usual physics path that most other entities utilize. That path handles the typical case of gravity pulling down at a constant rate, and crawlers have no need for gravity most of the time. To address this edge case, however, I chose to give crawlers physical properties so they can respect gravity, but keep this motion suppressed as long as a valid crawling surface exists.

When the crawler’s tile is destroyed, it initially reacts as though it had reached an outer corner. The line trace fails to find an expected surface, so we turn. But if after turning, still no valid surface can be found, we engage physical properties and fall until we hit another valid surface. Once we’ve landed, we suppress physics once again and begin crawling as usual.

A couple of quick notes on future things in case I forget to mention them in Wednesday’s video: