Blogs - escapementstudios

One problem I ran into recently while working on the demo for ITD (which hopefully will be done soon) was making the boss level physically long enough. This boss chases Bump until you beat him, so the level needs to vary in length depending on how much time that takes. In The Dark wasn’t really developed with this sort of level in mind, but luckily there is a fairly simple way around that. The test version of this level looks like this:

When the player runs past the green line, first all objects that have fallen behind the red line are deleted, and the space between the two lines is reset to look as if the player hasn’t been there yet (lights and props repositioned, light switches flipped etc). Then Bump, the boss, and the camera are teleported backwards so that it appears as though the player is simply running in front of the next identical house. The boss physically blocks the player from back tracking, so the illusion shouldn’t be broken. Once the boss is defeated the script is turned off and the player can finish the level, without ever seeing that they’ve been one house away from the end the whole time.

Plenty of games have used this technique. It’s fairly easy to pull off but I had never tried it with a game that relied on a physics engine. I suspect this will be used a few times in the game, and not just for boss fights.

Making Bump move 100% the way I would like him to is impossible. But by the time In The Dark is finished, I hope that he will move how I want him to at least 99.9% of the time. In The Dark only relies heavily on physics because it has to, if I were making a traditional platformer or something I would write my own collision system. I’m stupid for relying on the physics any more than I absolutely necessary, but over time I’ve removed almost all of the physics properties from bump, and really just rely on it for collision and as a means to consistently propel him around.

So why are physics engines so bad for handling characters in games, or really anything in games other than crates and barrels? (sure see a lot of those in games nowadays, huh?) The problem stems from classic games, you can lay most of the blame with Mario. In classic games (this applies to 3D as well as 2D) there wasn’t really any processing power to handle realistic momentum, collision, or even acceleration so games cheated. At the same time, speed and scales were exaggerated to make the games more fun and skill based. Everyone started copying the early games that did this, and now, it’s so ingrained in most gamers that when a game attempts a realistic simulation it “feels wrong.”

This is most obvious with jumping. Technically, when you’re in the air you should have almost no control of your overall body movement. Games aren’t allowed to do that. If you have to set up your jump before leaving the ground many games would be unplayable. In modern games theres usually either scripted, fixed jumps or some compromise between a realistic level of control and Mario Bros level of control. In The Dark uses the latter by reducing the controlling forces by 75%, it would be reduced by 90%, but precise jumping is fairly important to the gameplay, and any more would be frustrating. The other major issue with jumping is vertical velocity. Using realistic acceleration values feels extremely “floaty” and Bump suffered from this for a long time. The easiest solution is to highly exaggerate the upward force, and add a large downward force after the crest of the jump. In addition to this players naturally expect the amount of time the jump button is pressed to vary the jump height, which means it is necessary to continue applying upward force after the character has left the ground. Many games use techniques of this nature, and anyone who has played a lot of modern first person shooters has probably at some point seen a character die while jumping, and watched the ragdoll awkwardly bounce or fly into the air.

Bump’s jump was initially just a hard upward push that could only be applied if he was standing on something. In no time it evolved into a system where pressing the jump key activates a timer, and he is pushed upward until the key is released or the timer runs out, at which point he would go into a falling mode where he was pushed downward. This lasted for a long time, up until I started working on a “netbook” mode. As it turns out the timer system doesn’t work so well if your frame rate fluctuates. Bump’s jump height could vary as much as 15 pixels from jump to jump, simply because of the rough framerate. The forces were normalized to sync with the frames, but if your framerate isn’t smooth it’s not going to be perfect. The newer solution simply says that Bump will jump a minimum of 180 pixels upward, or a slightly longer timer expires. The timer allows some variance in jump height in case bump is standing on something moving, and means that he won’t jump forever into a ceiling 175 pixels above him. I’ve made little tweaks here and there since then, but I was still running into some issues. The most common related to exploiting bump’s momentum for better jumps. A light that was too steep to climb up could be used to perform a super jump by running into it and jumping at the same time. The incline would nudge bump upward with quite a bit of force even if he only visibly moved up 1 pixel, and adding up these forces could send Bump soaring into the air. The opposite problem would occur when running down a ramp. The downward momentum would mostly cancel out the jump making it mostly useless, and while this may be realistic it’s not what the player would expect. Now starting a jump zeros Bump’s Y velocity which has pretty much fixed all these problems, and it usually acts how one would expect it to.

Rotation is another complicated problem. Most games have no ability to rotate the character at all. Instead most modern games use animation tweaks such as inverse kinematics to make a perfectly level character move on an incline. Even in a game like Mario Galaxy, Mario is always standing straight upright in respect to gravity. Even knowing all this, initially bump could rotate freely. There is so much running on varying inclines in In The Dark that in order for the animation to look good, Bump needed to rotate. Problems cropped up constantly, jumping into the ceiling would cause Bump to rotate if the ceiling and floor weren’t parallel, running on rough surfaces like a pile of boxes caused all kinds of crazy things to happen. This is where the advanced foot detection I talked about before comes into play.

According to the physics engine Bump can not be pushed to rotate, and using the footing system he is manually rotated to match the incline of whatever he is standing on. The only time this isn’t used is when he rolls into a ball. Rolling is the only time Bump can rely heavily on the physics engine, because he’s incapable of jumping or doing anything else that might cause weird things to happen. Technically there are two different kinds of rolling in In The Dark. The first is manual rolling, when running, if the player presses down bump will go into a roll. This is not unlike rolling in the classic Sonic the Hedgehog games, it makes him slightly faster, and slightly shorter, so it may come in handy for squeezing through tight spaces. The other is forced rolling. Forced rolling is used to prevent bump from doing things he shouldn’t. It happens automatically when Bump tries to climb certain things (in many games, a surface to steep to walk up can be overcome by running at it and jumping repeatedly) and it can be manually activated in scripted sequences like if something hits bump with a lot of force for instance.

Finally there is restitution and friction. Both of these are key to a realistic looking physics simulation, and both are pretty much worthless for controlling characters. Unless you’re playing as a super ball or on a trampoline, no player expects the character to bounce when they fall to the ground. Bump still has a small amount of restitution but his footing system also makes him stick to the ground a bit so that he doesn’t bounce around when landing. The reason it isn’t disabled completely is a small amount of bounce back can make his movement feel more natural when running into things or jumping into the underside of a table. Friction will either be overpoweringly strong, or uselessly weak. In The Dark manually dampens Bump’s movement whenever he’s standing on something that isn’t slippery. When on a slippery surface, the built in friction is allowed to take over and he slides around like crazy. Now the only time problems arise is when Bump is teetering on the edge of something, where it feels like he slides around too much. I’m currently working on fixing that at which point levels and artwork will be the only thing in between us and finishing In The Dark