Creed Critique: Glitch vs. Pretty

by Steve Bowler on March 2, 2008 · 5 comments

in combat,critique,design,uncategorized

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.


Comments on this entry are closed.

Previous post:

Next post: