Creed Critique: Glitch vs. Pretty

March 2nd, 2008 · 5 Comments

One of the things I’m noticing in my playthrough of Assassin’s Creed (although they aren’t the only ones doing this) that is bugging me a lot lately is this mis-placed idea that the character animations always have to “line up” with what he’s really doing in the world. Somehow “next-gen” has come to mean “more real” and designers wind up forcing a bunch of extra work into a title which in the end doesn’t actually solve the attempt to make things look more real.

What I mean by this is that they appear to be attempting to avoid an animation “glitch” where the animation immediately proceeds to an appropriate frame that matches the user’s desired input behavior on the controller. Typically, when a user wants a punch, they hit the punch button, and their avatar immediately glitches (or blends over 2-3 ticks) to the first relevant frame of the punch animation where the fist is coming forwards. However, if a game designer is attempting to make a game more “immersive” a lot of times they will attempt to remove as much animation glitch as possible. I like to call this camp the “pretty” camp, because that’s all they’re really doing.

The best example to use when describing this phenomenon in game design of “glitch vs. pretty” is to discuss the basic jump mechanic. Tank, load the jump program.

Glitch Jumping

Jumping is this special case game-ism in video games, where when most people hit the jump button, they expect their avatar to immediately leave the ground. This is because when people normally jump in real life, especially while running, they are mentally preparing for the jump, and they subconsciously get their running cadence in the proper order/timing to get their foot planted in the optimal spot to execute the jump. So when they get to where they want to jump, they think “jump,” and they leave the ground.

When we jump in video games, our mind is predicting where we want to jump, but we have no way to let our avatar know that we want him to jump in three frames. Our avatar would have to be a mind reader to be aware of our intentions. Some game engines could attempt to sense that an edge worthy of jumping off of is coming up, but what if the user jacks the stick backwards just as they reach the edge (meaning they want to stop)? The game engine can’t predict this behavior, so there’s no point in trying to predict the jump behavior. It would look weird for their avatar to constantly start to anticipate a jump by hunkering down a bit when they run every time they ran near something jumpable, anyway.

So what a lot of games do is just glitch jump. If they detect a successful jump input, they just go straight to the first relevant frame of the jump animation and begin the jump. A lot of players like this behavior (myself included), because it gives them what they want: a jump that is executed on the tick they give the jump input. It’s responsive, and very satisfying. It’s also predictable and repeatable, which makes it excellent for multiplayer use.

If anyone’s paying close attention, though, it can look goofy, because your avatar might be about to land on their left foot, and when you push the jump button, they’re immediately leaping off of their right foot. This is where designers typically try and re-invent the wheel, and get too literal with game input, ergo:

Pretty Jumping

I guess seeing “wrong foot jumping” really gets some designers’ undies in a bunch, so they come up with elaborate schemes to force avatars to jump off of the correct foot. I’ve attempted it in the past, and after giving it just a bit of thought threw the idea out, for reasons you’ll see below.

The first thing they usually try is to force the run animation to keep playing after a jump input is called for, and then execute the jump animation on the correct foot placement. Once the tech is in place to give it a try, it looks great. The only problem is that there are edge cases where a player inputs a jump and has to wait until their avatar has run two complete steps before he actually jumps, because they triggered the jump a frame or two after the only legal foot placement for the jump animation.

Now what? Well, the second thing they’ll try is to make a left footed jump animation (if they had a right footed one before), and add new tech to detect the next possible foot placement for a jump when the jump button is pushed. It looks the same as before, but it plays about 50% better now because the worst case scenario for a missed jump timing is only one full step before a correct foot placement arrives for a jump to take off of.

But there’s still a problem here. Their avatars are still running off of roofs without jumping, because they can still take that full step.

So now the designers have to come up with an elaborate plan to tag all of the jump-able stuff in the game, and detect when the player’s going to be close to them, so that when the player gives a jump input here, they can either:

a). glitch jump in these areas, or

b). force the animation to quickly arrive at the legal foot placement for a jump before they fall over the edge of the building.

And I haven’t even gotten into short jumps while walking vs. long jumps while running, or even longer jumps while sprinting.

So now the player pretty much has no idea how jumping works, or why his avatar jumps immediately some instances or jumps 15 ticks later at other times when he asks for it to jump. And then there’s the weird times when it does a shuffle-step thing so that it can jump at the edge of a building…and…?

The final result of “pretty” jumping typically winds up just confusing players. I don’t think we as designers are winning anyone over with mushy gameplay that isn’t responsive, and I think we’re fooling ourselves when we say that it somehow “looks” better.

Our brains fill in the gap of the missing step when we jump in a video-game. We only remember that we desired to jump, and that we actually jumped. The end result desired when a button is pushed is that we actually jump, not to look good in the time preceeding the jump. It’s bad enough that there’s a 3-5 tick gap from when the brain thinks “jump” to when the jump button is pushed, and then a 3-5 tick gap depending on blend times in the animation and the amount of time it takes the electrons to reach the game engine for the actual button press. Even with glitch jumping, there’s possibly a 6-10 tick delay from the brain thinking “jump” to the avatar actually leaving the ground.

Now visualize how much more frustrating it is when you forcibly delay that even more by making the avatar run another step (5-15 ticks) to make sure his foot is planted properly. Yes, it certainly animates better, but we’re not playing a movie here. We’re playing a game. Interaction, and therefore reaction, is key, not the animation quality.

And this is my primary beef with Creed’s gameplay right now as I play through it. It’s pretty much a “make it pretty” style game, not a glitch game. This would be fine if all I was asked to do was push my way through crowds and talk to vendors. Unfortunately I’m tasked with combat and jumping across rooftops. Imagine, if you will, a Mario game where you were expected to wait to jump until your sprite had animated to a position where it looked logical for your legs to be jumping. The game would be largely unplayable.

And as much as I’m enjoying the climbing and scrambling around in Damascus in Creed, I’m finding the game…largely unplayable.

Although it is pretty, I’ll give them that.

Bookmark and Share

Close Bookmark and Share This Page

Save to Browser Favorites / Bookmarks

Email This to a Friend

Copy HTML:

If you like this then please subscribe to the RSS Feed.

Tags: combat · critique · design · uncategorized

5 responses so far ↓

1 JP // Mar 10, 2008 at 10:59 pm

The term I believe you are searching for is “animation-driven control”. And yeah it’s a modern tragedy for the most part.

Interestingly, Zelda (the modern 3D ones) and other games with passive jumping completely avoid this problem. The player simply tilts the stick in the direction they want to go, and if they hit a ledge and jump, the game figures it out. Player gets what they want, game gets to plot out the animations how it wants.

Regardless, I think animation-driven controls, even when they’re well-done, stem from a cognitive fallacy that’s unique to games that you touch on peripherally: to the player, the jump happened as anticipated. It’s only to the people who aren’t playing, who are watching, that the pop is visible. When we’re controlling something, our brains do all the interpolation we need really.

Yet another place where films and games are worlds apart no matter how badly some folks wish it weren’t the case.
2 Kriss Daniels // Mar 13, 2008 at 2:05 am

There is also a third way, which allows for somewhat smother animation, however it requires a small act of learning on the case of the player. Which means although I technically prefer it, I would never use it or advise anyone to use it.

Simply jump on button release, allowing all the time while the button is held to be preparing to jump. Its not glitch proof but It’s something of a halfway house between the two.
3 RotBot // Mar 13, 2008 at 11:27 am

Jump on release is used well in skateboarding/snowboarding games. But you’re right that most people won’t enjoy platformers controlled like Tony Hawk.
4 raigan // Mar 13, 2008 at 5:45 pm

We’ve been thinking of trying jump-on-release for our new game — good enough for Commander Keen, good enough for us.

It definitely takes a bit of getting used to though!
5 Dathgale // Apr 8, 2008 at 2:52 am

A jumping animation doesn’t even have to glitch as the article describes. The game can simply interpolate between the character’s position when the player pressed the jump button and the jumping pose that matches whichever foot was on the ground at the time. There’s really no need to make it so difficult to line up a jump.