The Ultra Street Fighter IV bug list is intimidating. A massive compilation of notes spanning multiple forum posts with contributions from countless players, the list showcases the wide range of oddities that plague the title and have affected Street Fighter IV for at least several iterations. From small errors, such as a special move giving the wrong amount of meter on block, to round-changing glitches like Seth’s EX Tanden Engine causing the game to believe the opposing character is permanently in the air if it hit an airborne opponent not in a juggle state, every character is affected.

The list has exasperated some players, and left others unfazed. However, it has spawned questions such as “How do these problems happen?” and “Can X glitch even be fixed?”

To find out the answers to these questions–and dig a little deeper into what is going on inside Street Fighter IV–I decided to talk to a couple people who have intimate knowledge of the game development process: Sony Santa Monica’s Derek “Omni” Daniels, combat designer for God of War 1 and 2, and Lab Zero Games’ Mike Zaimont, who is the lead designer on Skullgirls. Both men had some good insight into what happened and is still playing out within Ultra Street Fighter IV.

Editor’s note: Both men wanted to make it clear that their opinions and comments are their own and in no way represent the companies they work for or the products they create.

Paul Dziuba: Looking at the list of bugs, etc. in Street Fighter IV, what is your first reaction as a player? As a developer?

Derek Daniels: That there is a lot! Not only that, but the community has done a ton of work putting this whole thing together.

Mike Zaimont: As a fighting game player (not an Ultra SF4 player), my reaction is “this is quite a lot of severe, gameplay-detrimental bugs.” Which is cynical, I’m sure, but also true. Some of that is also because of how many people are closely scrutinizing the game, but I’m comparing it to games where the playerbase has had ten-plus years to examine every nook and cranny.

As a developer, my first reaction was three things:

One, how many of those bugs were caused by leaving things which should be automated up to manual input instead? (Meter gain on block, counterhit damage, etc.)

Two, how many of those things were caused by strange engine design? It should not be possible to specify a cancel window longer than the state’s animation is, for example.

And three, how many of those bugs could have been caught by a Steam beta or a more consistent testing process? I go through all the frames of a new character looking at the hitboxes before we ship them for real, just scrolling through their list at around five frames per second looking for obvious problems. I make sure all their normals chain properly and can cancel properly, etc. It’s easy, it doesn’t take long, and at the very least Poison and Hugo and a bunch of the random chaining problems could have been found relatively quickly with some easy process like this as a final casual check.

(I’m sure Capcom has a large and dedicated testing department, but I have no knowledge of what their compliance process is.)

PD: Although the list of inconsistencies and glitches was compiled in the last few months, some of the issues have been present for many iterations of the game. Had you noticed abnormalities in Street Fighter IV previously?

DD: I grew up playing fighting games in the arcade. We didn’t have access to training mode or frame data or anything like that. You simply learned the feeling of what things you could and couldn’t punish. So for me, my head is full of weird exceptions based on wrong assumptions. When I sit down and look at all the bugs and stuff, I see a lot of bugs that fall into similar buckets. Like, “Oh – seems like some guy forgot to set this flag” type of thing.

MZ: Gotta be honest, I haven’t played SF4 more than five times since Super came out. I did notice things like moves whiffing because their hitboxes were tied to the animations even back in vanilla, like Gief cross-up splash to cr. jab vs. crouching Rufus would just miss, which was odd to me given that even the more accurate hitboxes in Third Strike don’t follow the character much in hitstun or blockstun. (It’s not incredibly surprising though, given that it’s much easier for the developers to do it that way with 3-d models – add boxes once, done). I know the bugs the community pointed out, and the ones that happen in matches, but that’s it.

PD: A lot of the abnormalities people have found in Ultra are incorrect values, such as a move granting more or less meter on block than average. How does this happen, in technical terms? In layman’s terms?

DD: The easy answer to most of Ultra’s weirdness is that Dimps didn’t work on the game. For those that don’t know – Dimps worked on Street Fighter IV all the way from, ‘vanilla’ to AE 2012. I honestly don’t know why Dimps wasn’t involved with Ultra but Capcom used a different developer this time around.

I’m not even suggesting they did a bad job or anything – I think they did a really good job but they didn’t have the experience of working on four previous versions. Before I submit any game I have a giant list of items I double if not triple check. I’m sure Dimps has something similar but this new company didn’t.

When you see bugs like, “X character’s dragon punch command can’t take advantage of the shortcut commands,” that’s just a “Oh yeah, they didn’t even think about double checking all of those” type of situation.

Plus, another common instance I see is that gaining meter is never as simple as some Excel file that you just fill out. There is always a complicated formula with values hidden everywhere: sometimes in the character’s file, sometimes in the general file and sometimes hardcoded for whatever reason that probably fixed a previous bug. Even if you are familiar with all those hidden places, it’s very easy for mistakes to get through. It’s super easy to set a value to 10 and expect 10 only to find out there is some hidden 1.5 multiplier that has turned your 10 into a 15.

MZ: Technical terms and layman’s terms are both the same – the value is entered specifically per move, by a person, rather than having one place that just says “on block generate X% of meter” or “on counter hit do X% more damage,” and the only part that changes per move being the actual damage value. It’s even separately manually typed-in values for standing hit, crouching hit, stand block, crouch block, etc.

For the technical, if you wanted to make this extensible, it makes the most sense to specify a base in one place—like “50% more damage on any counterhit”—and then for each move have an override if you need one, otherwise leave it blank and the base would be applied. But the override should be percentage if the basis is a percentage, not a raw value! That way, if you changed the move’s damage later, it would still be the correct override (“do 100% more damage on counterhit” is still correct if you change the move’s damage from 25 to 50) rather than a now-wrong raw value.

In short, it’s probably slightly easier on the programmers to set it up the way they did, but it leaves room for a LOT more errors. Anywhere you can avoid leaving room for human error, you should avoid it. It’s also MUCH harder on designers: designers had to enter all those extra numbers, and some other poor sap had to check them at least once before they shipped. Aggregated, that’s a lot of wasted time.

The same goes for duplicating moves. If a few moves are essentially the same move, like s.Jab/chained s.Jab/Feng Shui s.Jab/Genei Jin s.Jab, they should make use of as much of the same data as possible. Have the different character states (s.Jab, chained s.Jab) reference the same animation, hitbox, and damage data, and only differ in what their cancel lists or other generic properties are. That way you don’t have to update two or three sets of hitboxes (or forget to update them!) every time you change one move. I’m not sure this is possible in the SF4 engine, though.

Also, enforcing game-wide rules in the engine itself. If moves that cost meter can’t build meter, then tagging a move as having a super meter cost should mean that it can’t build you any meter on hit or block by default, and then have an override that a designer must enable if there is supposed to be some move that breaks this rule. Assume mistakes will be made and design the engine to handle them gracefully. It should not be possible for a designer to copy/paste the values for a regular Tiger Knee into the EX Knee and suddenly have it build meter, for example. The engine should prevent that because it’s easy to enforce, even if the designer mistakenly gives one of the hits some meter gain.

Then there are some things that just make me scratch my head, like the ability to specify a cancel window longer than the state/animation is; that shouldn’t even be a possible thing in your engine! Again, account for human error.

(And things like having a “can cross-up” flag…man…that eliminates so much organic evolution of the game, it hurts.)

PD: From a development aspect, how are issues like these created during production of a game?

DD: We do know that Dimps didn’t work on Ultra but what we don’t know is how much communication the new studio had with Dimps. Did they just get the source code dumped on them? Did they even get all of the source code? Were they able to call up a programmer who had to hard code some Zangief reaction just to make Rose’s Super work or whatever?

The guys working on this had to be ramped up on something that they didn’t create. Not only that but games spend most of their life being a bug=filled mess. It isn’t until they get ready to ship do you start locking down bugs. Reality is that no game is ever bug free, you just try to ship with as few of bugs as possible. And it’s not always black and white to fix bugs either. Sometimes fixing one causes repercussions on something you weren’t even thinking about.

MZ: From what I’ve seen on a few projects, they come from “feature creep,” or not designing to minimize the probability of errors. For example, they probably started with damage/chip/hitstop/hitstun/blockstun per move. So they had a spreadsheet (or whatever) with the various spots for values to be entered. Then, later they wanted to add crouching damage, counterhit damage, block meter gain, etc. and for each of those the programmer just said “OK, I added the field to the sheets, designers can use it this way, go!” Then, after some testing they wanted to change the properties of light attacks that were chained into, so rather than make it an engine feature with safeguards they simply duplicated entire attacks and changed small properties because it was faster to do and there was a time crunch.

I’d bet nobody stood back and really thought about how each thing was going to be used, because it would be more work up front to do that. They did the minimal work to add the feature that was requested so it was done as quickly as possible, even if they knew it would be more work later. No fault there, often the most important thing is just to get it done at that point, so you say to yourself, “I’ll go back and fix it later.”

But you never do. You NEVER do. There is always more work to be done, and the gold master date always comes too soon. So I’ve learned it’s better to set it up properly at first, think about some use cases and how to avoid possible errors later on, and take a little bit longer now to save yourself massive headaches later. Sometimes all it takes is saying to the group, “What if on our third sequel we end up wanting to go back and change this for every move for every character?”

PD: Many of these oddities predate Ultra Street Fighter IV. Why are these issues only being addressed in the community now?

DD: The community is just more mature these days. It’s like reading on NeoGAF when people complain about 720p/1080p or 30fps vs. 60 fps. Consumers just weren’t as educated as they are now. We knew the SNES version of HF felt better than the Sega version of CE but we couldn’t put it into words like people can today. Plus with the advent of the internet it’s easier to crowdsource all of these bugs. Before a player may have found one or two but they were found in a vacuum so to speak. Now everyone is sharing Google documents and getting lots of people to contribute.

MZ: They’re certainly not only being mentioned now, like I said people have talked about the various hitbox issues, and things like EX Messiah Kick LK building meter, since the beginning.

Part of it is the community-created tool, Ono, which allows people to go in and see the minutiae of how the actual game is set up. This lets the community find errors a lot more precisely than trying a hundred things in training mode.

Part of it is also the number of players scrutinizing the game, and the fact that fighting games encourage that sort of attention to detail.

A big thing, though, is the general sense among players that the Ultra update was — I guess I should be nice — let’s go with “of inferior quality compared to the previous updates to SF4.” :^) They did have an extremely long time relative to the changes and the content that was added, so it is moderately odd that what shipped has so many problems. I think the community expected more for their money and their patience, and to see an update with this many NEW problems is surprising, to say the least. So those problems are receiving attention proportional to this general…discomfort. (I mean come on, how does the team forget to add a training mode option for Delayed Wake Up, a new feature that your PR department talks about all the time? Sorry, but really now.)

PD: Taking a look at the list, how long do you think it would take to fix these problems? Are there any problems that could pose a complex solution?

DD: This is where things get tricky. While players have learned more about game development compared to 10+ years ago, most of them now fall into the group of knowing enough, only enough, to be dangerous. In all honesty, fixing any bug with a game this mature (five years?) is a complex situation. Look at some things that seem innocent, like fixing Rufus’s EX Messiah to not miss on crouching opponents – their fix for Ultra made it so that now Rufus can juggle opponents out of the air. Whether or not that was intention or accidental, I’m not sure. But it just shows that changing anything is like playing with fire.

While some fixes are probably safe – there is some move of Elena’s where the opponent can’t delay wakeup against, yeah, that should be safe to fix – it’s some of the other stuff that will have domino effects that no one is even thinking about. Especially if they are situational / character specifics. A bad example would be, “Oh man, Zangief has a hard time with the Blanka matchup, let’s change his green hand so it punishes blocked Blanka ball.” That sounds awesome until you realize green hand is now so fast / goes so far it punishes all kinds of things that were not intended in other match ups.

Other bugs are just crazy! Like side-specific bugs (left corner vs right corner) – a version of that bug has been in almost every version of Street Fighter that I can think of, including vastly different engines! CvS2 2nd player could cross up when 1p couldn’t. The fact that some variation of this bug has cropped up in multiple games, multiple engines, multiple developers points that some things are really hard to solve.

The length of time is even harder to say. Some of the bugs seem like actual typos / not thought of situations. Those should be easier to fix. Especially for the characters that are new to Ultra. However, looking at even Vanilla SF4 so many of the mechanics / systems had tons of character-specific exceptions. DP FADC into full Ultra juggle…except for Sagat when done in the corner. Tons of things that simply didn’t make sense. Assuming this new developer doesn’t have direct access to Dimps or even Seth Killian to explain why things were done, they are probably guessing on a few things. Why the hell is Chun’s techable window for forward throw 1F longer than normal? Is that a legit bug or was that some obscure balance thing they did? Who knows. Should they even fix it? That’s a whole other debate.

MZ: I’d be interested to have someone like Error1 go and stream fixing all the listed scripting bugs using Ono! (Aside from the ones that require changing code, of course, like the music not turning off at Volume 0.) Then we’d get a real estimate.

The vast majority of the errors are simple fixes, though. I’ll probably get reamed for saying this, but whatever.

Some are extremely easy, like meter gain / chip damage / counterhit damage / active frame marked as counterhit / startup frame not marked as counterhit / wrong counterhit frame advantage / wrong invincibility window / things building meter on block / things having the wrong hit reaction in some cases or not being hard knockdown / wrong throw tech window / etc. I bet all those combined are under one working day for a single person to fix, at most. Boring work, heh.

Fixing Ken’s plink-air-hurricane / Makoto’s plink Tsurugi is also easy, as is Evil Ryu’s s.LP always being the chained version and his chained s.LK being cancellable, Rolento being able to do reversal or jc’d Supers, removing the height restriction on Cannon Strike from Hooligan Combo, or Cody’s U2 dust breaking counters.

Editing hitboxes/hurtboxes and duplicating boxes between moves is also easy, if tedious, though it depends on your editor’s ability to copy/paste. So all the chained/FengShui/GeneiJin things are not that hard, there are just a lot of them.

I assume it is easy to edit the cancel window on moves, so fixing all those bugs where linking still gives you the chained version etc shouldn’t be that bad. I don’t know how it works with animations that vary their timing, if you have to special-case it or what, but the ones where the move is always played at the same speed are small fixes.

Adding and removing vulnerable boxes before/after active frames is just a matter of someone doing that. Adding specific vulnerable boxes where it says moves “have no hurtboxes designated” is more work but is also a subjective decision, perhaps they think the animation-provided boxes are okay. I’d honestly skip those listings, since the character can be hit, or do them on a case-by-case basis.

Poison falling out of Gouken’s EX Tatsu and things like that take a bit more work to test and fix, but it’s just adjusting boxes until it works. :^)

Some things require more subjective judgment, like Cody U2 being punishable on air hit or Cammy U2 being negative on hit, but if they decided to fix them those are also short.

The small remainder, like Guile’s turn around script, Gen’s U2 from prejump, Rose’s U2 orbs being different sometimes, Sagat’s Ultra missing, Seth’s Tanden Engine counting ground attacks as juggles, Chun’s s.Fierce xx RH SBK being different, etc. are the things that would require investigation and real work.

The weird graphical effects bugs, left-right corner inconsistencies, and other things that require code changes are harder to fix, and impossible for the community to change. Not allowing characters to wrongly pass through each other, for example, is a solved problem and should have been fixed as a general engine change many versions ago. A hacky version of continuous collision will more than suffice. (Skullgirls does it! If I wrote it, it can’t be that hard.) And really, someone should have taken a few days and found the root cause of unblockables and just gotten rid of them as a whole, DWU or not. You’re a programmer, without you there is no game! It can certainly be done.

So I guess the tl;dr is – the majority of the work is pretty easy to do, there is just a lot of it. If I were assigned to this and asked to provide an ETA to my superiors, I’d estimate a week, ten days tops, to clear 99% of it with designers’ approval on the iffy parts.

PD: Competitive players have dealt with weird hitboxes, wacky damage and other assorted problems in their games since Street Fighter II. How does this list compare, at face value, with some of those problems? Should competitors even be worrying?

DD: This all goes back to people knowing more than they did before. In all honesty they shouldn’t worry, but now that people have seen behind the curtain, so to speak, they are going to. Looking at the list and seeing as much tourney footage that has been streamed so far – I haven’t really seen any huge impact. Maybe a weird hitbox here or there – but Alpha 3 had way stranger hitboxes and people love that game.

MZ: No and yes.

On the one hand, eh. Some stuff is busted, but some stuff has been busted since the beginning and people still played it. There is something wrong with every game people play, and sometimes those things are what make the game fun. Players will deal with the way the game works, as they have in every other game. If something is advantageous they’ll abuse it, and if it’s detrimental they’ll avoid it. For example, moves only build the “wrong” meter on counterhit if you assume there is a “right” amount of meter to build – if you just assume it’s supposed to be different per move or random, then it’s fine! Classify all bugs as “tech,” problem solved. If the game is fun for you then any problems can be glossed over.

On the other hand, wtf. People paid money for this, they deserve a polished update. Capcom had what, a year and a half? That’s not a year and a half of work, even with porting the SFxT characters and Decapre. My apologies to the dev team, but it is not. I personally expected a higher level of quality from it, as a package. (Not more content, but they may as well have not even added button config on character select, for example, since this version doesn’t save tournaments any time.) Plus, if this is a game where people will be winning money playing it, and some of that money even comes from the company that created the game, then it is a little weird to let people play a product that is this buggy in essentially random ways.

From my end – like I always say, if you enjoy it, play it! But while you’re playing it, consider whether you think it is in the community’s best interest to reward this level of workmanship with money and adulation, and what accepting this now might mean for SF5 later.