Going full retard, touching the third rail, etc.

I really didn’t want it to come to this, but after playing Operation Smash I don’t see what choice I have in the matter. I’m talking, of course, about implementing slopes in my game. I whipped up a little test area to see what I was getting myself into, approximately. I don’t have any slopey tiles yet, so I’m just placing a ramp object into the physics engine and turning on debug mode so I can see it, represented as a green outline. The video below demonstrates why this isn’t simple:

As you can see, running up a slope that then abruptly transitions to a table top results in the character catching some air. The same is true when coming off that table top. This is the correct, physically simulated behavior, but it’s not what I want to happen. I want the character to remain glued to the ground until they jump, or until they drop off an actual ledge. There are a bunch of other complications, some of them simple to solve (like the character sliding downhill) and some of them arbitrarily complex. This is yet another demonstration of why it’s worth considering *not* using a physics engine to create platformer games, which often want non-physical behavior. Doing a little bit of research into what I was getting myself into, I came across a relevant forum post, quoted below:

The problem is Box2D rewards consistency, and old school platforms are anything but. They are usually implemented as hacks (beyond the basics, I mean).

It’s my belief you can recreate most of the feel in Box2D, by discarding large and large amounts of the physics. E.g. start doing your own velocity calculations instead of using ApplyForce. But the more you discard, the worst the physics becomes.

For the record, I’ve been manually applying linear velocities since the very beginning of the project. Another indie game dev chimes in:

Echoing the sentiment that all collision is a hack. The only time it isn’t is when everything in the world can be defined in some extremely regular and consistent way. Approximating characters as AABBs, circles, capsules, or spheres and adjusting their boundaries to fit sprites/models as they perform different animations breaks all the “expected behavior” that makes a physics engine go. Along the way, you pretty much always end up with game-specific stuff where you say something like “oh I want the player to be able to grab ledges, and crouch-walk through low areas” and then you have to add hacks that cross collision with animation and player state to get the effect down. Hence the motto of my old boss, “collision is gameplay.”

This sounds… nauseatingly familiar.

So, what’s my problem? Why am I giving myself this headache?

First, I just played the new indie Metroidvania Operation Smash, which has a ton of lovely organic environments that use sloped surfaces all over the goddamned place. It’s pretty great. Seriously, you should buy it. Slopes definitely allow your environments to look a lot more interesting and varied.

Second, and this is the more important factor, I’ve wanted sloped terrain since before I started serious work on the game. Slopes allow you to sprint through an area and change your elevation without jumping. That’s a pretty great feature, which Super Metroid makes use of to great effect. The only reason I banned slopes from the game was to make it simpler to implement and therefore faster to get done, which is laughable at this point in the development.

I’m calling this an experiment, where I have a week to convince myself that either slopes are great or totally not worth the effort. I honestly think it could go either way.

Leave a Reply

Your email address will not be published. Required fields are marked *