Style Study: Motion Blur in Street Fighter 3

by Mike
Wed, September 23, 2009 -- 19:04 UTC

One of the classic problems of 2D animation is the tug-of-war between frame economy (each drawing takes lots of work/time) and high-speed movements (the faster the move, the more likely it is to “strobe” if you skimp on frames).  There’s also the issue that, even with a lot of frames, some movements are so fast that they would usually become little more than a blur on film.

As you might imagine, developing a 2D fighting videogame really brings this problem front-and-center. Most of the gameplay in a typical fighting game centers around two large characters executing high-speed attacks, continuously, for minutes at a time. Because traditional sprite-art games typically eschew the use of any semi-transparent pixels, they often have to get pretty creative to emulate the effects of motion blur.

Today I went through my Street Fighter 3 sprite collection* to pick out some good example frames, and was surprised to discover a different fast-motion solution for almost every character.  As I went through them frame-by-frame, it became more and more clear that the lead animator of each character was essentially allowed to use whatever technique they preferred to achieve the effects they were after.  What follows is a grab-bag of these tricks in action.


This first one is the character Makoto.  This is what I think of as a pretty typical post-Disney stretch, being used to sell one hell of a jump-kick.  Notice that the contour line around the foot is consistent with the contour treatment on the rest of the character.


They’re also pretty fearless about stretching the physical length of the attacking limb, to further accentuate the speed and force of the hit. Again: classic Disney.  Makoto in particular is an absolute masterclass of physical animation, with her oversized gi and super-long headband flying every which-way.  The fact that these animators are doing it all within 120-odd pixels square just makes it more impressive.


With Oro, they really loosen up and go nuts with the squash-and-stretch.  In addition, there are more subtle differences: notice that the contour treatment is lighter on the fast-moving limb than on the rest of the body.


Here you can see the contour change even more clearly.


And check out this transparency hack, eh?  You wacky Capcom animators!


…and now for something completely different.  Akuma’s movements are very stiff and staccato in comparison to Makoto’s and Oro’s, though it’s not clear if that’s a deliberate stylistic choice to differentiate their martial arts or just a quality-control breakdown.  However, this motion-lines technique is how all his fast movements are treated.  Like all the techniques used in this game, it works very well, but what an odd contrast!

Finally, we have Chun-Li. As the original Fastest Character In Street Fighter, this character is all about speed! Strangely, her animators seem to be doing everything they can to avoid squash-and-stretch. When it is used, it’s used… weirdly. In general, the character almost feels like it was filmed using a higher shutter speed.  Check it out:


The frame above is the closest I could find to the sort of treatment we saw on Oro, but the foot is clipped to a point. I wonder if that’s to emphasize the contrast between her exaggerated thighs and small feet?


The stretch/motion-blur is pretty dramatic here, but… it’s sitting behind a proportionately normal and fully rendered limb? Plus, the motion trail is actually lit, or at least gets darker in an effort to achieve some sort of fading effect.


Now they’re completely disconnecting the blur element from the limb, and introducing some of that semi-transparent-looking stuff we saw with Oro.


Same deal, but even more obviously out-of-step with the stuff we saw before.


Finally, here’s a frame from her famous lightning kick attack.  This was probably the official Fastest Fighting Game Move Of All Time when it debuted in Street Fighter 2 (possibly tied with E. Honda’s hundred-hand-slap), and yet its execution in part 3 is extremely underwhelming.  After seeing all the juicy speed effects on the previous characters, this ghost-limb trick really feels like a missed opportunity to me.  Again with the high-shutter-speed gag.

Fun as it was to pick apart the monolithic game art achievements of yore, this style study left me with more respect for the Capcom art team, not less. I’ve logged more hours than I’d like to admit on this game, and never once noticed these discrepancies. I’m sure some of that comes from the fact that only two characters can fight on-screen at a time, so the visual hodge-podge will only ever get so ridiculous. However, I suspect the bulk of said hodge-podge skates by because, at these framerates, your brain is only subconsciously able to process what it’s seeing (let alone register that Chun-Li has three legs). “Persistence of vision” is all about our brain wanting to believe in continuity between frames, and these animations have all been ruthlessly tested and refined towards accomplishing that mental sleight-of-hand. The fact that they went about it in different ways turns out not to matter very much, because they all ultimately achieved their goal: the illusion of speed.

Once again, I am amazed by the users’ tolerance for inconsistency in the final product.  Take heart, game artists!  Your players will forgive you for far more trespasses than you’ll forgive yourself!

*I got all the frames for this post from this excellent website and, by extension, from the seminal Capcom fighter Street Fighter 3.  Go check it out if you want to see these animations in motion, and pick up a hefty dose of inspiration while you’re there!

FallGuy Prototype – Day 3, part 2

by Mike
Sat, September 19, 2009 -- 2:04 UTC

This is the second in a series of posts that document the process of building a prototype game in about 7 days.  Because I am writing it, it places special emphasis on the particulars of how the art and animation got made.  It’s also getting increasingly technical.  You can catch up with Part 1 here.

When we left our heroes, the time had come to start on the first screenshot mockup of FallGuy.

The first decision was game resolution. Most of the great modern pixel art games (DoDonPachi, ProGear, Street Fighter III, etc.) run somewhere in the neighborhood of 320×240 pixels, but there tend to be subtle variations on those numbers depending on which arcade board the game was designed for. I looked at screenshots of vertical shmups like Ikaruga and the bulk of the Cave lineup, and arrived at the conclusion that 224 pixels wide by 320 tall was going to work fine for our needs on this project.


As soon as I had a resolution target, I made a blank Photoshop file at that rez and started working on our protagonist. The main character sprite is the representation of the player in the game, so getting him right is one of the most important art tasks. He needs to have the correct scale, a clear silhouette, good contrast with the environment (i.e. background, enemies, bullets), and general visual appeal. Finally, he needs to support core gameplay functionality with things like a clearly-indicated hitbox and a logical point from which bullets can be emitted. As I didn’t have any environment art yet, I focused on scale/silhouette/gameplay for the first pass.


My crappy, crappy earlier designs.

When I was done, the character was just a simple black outline with a white fill, but all the heavy lifting of the character design was largely squared away. And yet… he wasn’t excellent? Really at all? This is probably a good time to mention that for this project, I was focused on getting things to the Good Enough line and then moving on, with a plan to return and polish/revise/start over if time allowed. For example, the character above is doing something with his right hand that looks more like a lewd gesture than holding a pistol. That issue became obvious as soon as I got him to this point, but the clock was ticking! Rather than embark on a complete character redesign, I simply considered the odds that all this art would get thrown away anyway, decided those odds were rather high, and focused on the biggest bang-for-buck revisions I had time for.

For example, if bullets are supposed to come out of that right hand, it should probably be aligned with the center of the character instead of being 5 pixels off to the right. That was an easy fix, so I made it (and a few others) before I started animating. Anything more difficult than that fell right off the back of the results train, and not just for expediency’s sake either. The fact is, I’m enough of a novice at this style of art that every single piece I create teaches me another 5 important lessons, so the payout of just putting miles on the tires still greatly exceeds the payout of mastering a single turn of the track.*

Before Hal could actually use the art I’d created, I had to convert it into whatever format he needed on the code side.  After some brief discussion, we determined that the easiest (though somewhat painful) solution was to create animated .gif files and then go through the laborious task of converting them into .swf files in Flash.  This process cries out for automation, but javascripting workflow improvements in Adobe’s CS3 suite was way, way, WAY out of scope for this project.  I sucked it up, checked the converted main character test image in, and got to work on his first animation.


The idle loop is actually somewhat rare in the classic shmup world, as most player craft are spaceships or airplanes of some stripe and have no soft bits to apply constant motion to. Typically, that sort of thing is limited to some sort of flicker in the exhaust of the jets or rockets or whatever the propulsion system of the ship is. In contrast, our character was wearing a business suit, and had no jets, so the natural idea was to animate his clothes flapping in the wind as he flew through the air.

This brought me to a tools question that I’ve been meaning to find the answer to for a while: what software will I use to produce these animations? For previous projects, I had used the following process:

  1. Animate at high resolution in an open-source 2d animation program called Pencil
  2. …export that animation as an image sequence…
  3. …then batch downrez/crop the frames to the target size in Photoshop CS3…
  4. …import those frames into an open-source pixel animation program called Pixen
  5. …and proceed to cleanup/color from there.

Long as that list is, this process actually had some nice things going for it: it allowed me to animate at high rez, which is great for someone who is new to the expressionist mental kung-fu that pixel art requires. Additionally, passing through Photoshop gave me access to all the filters and associated knobs/buttons that make it the definitive industrial raster software the world over. Finally, it worked, which is always a plus.  Unfortunately, this pipeline suffered from having a lot of difficult-to-automate steps, and from relying on not one but two pieces of buggy open source software.

For the idle loop, which looked very simple anyway, I decided to try doing the whole process in Photoshop.

Many people don’t know about the remora of animation support that clings to the underside of Photoshop CS3; I suspect its presence would be classified as a bug by the folks over at Adobe. By that version of the Creative Suite, almost all the animation support features had been relocated from Photoshop/ImageReady to another Adobe app called Fireworks. However, just enough of it remains in Photoshop that you can still get animations done if you plan carefully. And as we all know, if you’re animating in 2d, you should be planning carefully anyway.


Only an Armani would flutter like this.

What I learned from doing this animation in Photoshop was that you can indeed still use it, but it’s a deeply counter-intuitive workflow for someone with a traditional animation background. For example, it stores individual layer visibility state per-frame instead of the typical discrete-images-along-a-timeline metaphor. This probably makes a lot of sense when you’re creating web graphics, but it’s maddening if you’re planning to draw a custom image for every frame anyway. One useful side-effect of that design decision is that you can use the feature in concert with layer and group masks to achieve useful things like per-limb frame offsets and the like. Unfortunately, such feats are unwieldy in the extreme, especially in comparison with any given 3d animation package (where the difficulty of said feats would be most readily compared to that of falling off a log).

There are of course days when it’s worth the pain, so I’ll definitely keep Photoshop it in my back pocket for certain classes of task, but most of my takeaway was that I should find a better (or at least more straightforward) tool for my meat-and-potatoes 2d animation work.


My next task was to animate him swinging his sword with gust and bravado.  After the weirdness of using Photoshop, I felt renewed excitement to revisit Pixen. While buggy, Pixen was obviously designed from the ground up for this exact purpose (probably after looking at GraphicsGALE), and I was able to stop fighting the tool after just a few hours and focus my energy instead on bringing the character to life. That old 2d animation juice started to flow for the first time in years, and actually I managed to create something I was pretty happy with:



The lessons of Pixen were to save often, and keep things simple whenever possible. This is because it’s definitely, definitely going to crash on you all the time. The core functionality is (fairly) safe, but the further you venture out into the badlands of the extended feature set, the greater the odds that you’re going to step on a landmine.  Also, even though it’s got lots of neato features like per-frame layers and custom palettes and so on, I found the complexity of wrangling all the moving parts of a 10 frame animation to be all that I could handle. Even something as simple as dealing with layers pulled me out of my fragile groove and got me thinking about my tools again, instead of what I was trying to create with them.

I suppose that was the other lesson of Pixen: that besides being the best of what was around, it was also good enough on some absolute scale of my particular needs.  The day will probably come when I convince Tim to write me the pixeling tool of my dreams, or at least to spot-weld features and bugfixes onto Pixen until it becomes that tool.  For now, though, I’ve used nothing better for turning jumbled piles of pixels into believable animated characters.

Thus concluded Day 3. See you next time for Day 4, which features Unexpected Reversals and A Moment Of Truth!

* FYI, you can count on more tortured/mixed metaphors in that style from here on out.