A look at the Repeating Input Buffer

Recently I picked up the grandfather of anime fighting games, Guilty Gear. In the past I had avoided it because it was somehow even less popular than my preferred game of BlazBlue, and had significant presentation issues that made it difficult for me to visually parse what was happening in a match. After playing it for a couple weeks now (though only one actual week of playing against people), I've gotten over the presentation and now I don't really have any issues telling what's happening--and as a result I found my new favorite fighting game.

GG is fast-paced, has interesting and unique character playstyles, and every character has a huge number of options at their disposal, spanning across movement, space control, mixup, and all other manner of things. I won't go into detail here about everything I love about the game (you should just go play it yourself), but one of the things I don't like about it is what I want to talk about in this post.

Aside from the aforementioned presentation issues, I also don't really like the varying character gravity, the guts system, the close/far dichotomy on Slash-button moves, or throw being overloaded onto forward Heavy Slash. The last two problems are largely philosophical, in that in general, I don't want how my character responds to my inputs to be affected by my opponent. I also don't really want to go too deep into the first two problems; they're for another time.

But my biggest problem with the game, and the one I want to discuss, is the lack of a repeating input buffer.

Input buffers exist in all fighting games that have moves requiring more than one directional input. In order for Street Fighter to determine whether you're trying to throw a hadouken or walk forward and punch, the game has to keep track of whether or not you pressed down and down-forward sufficiently recently before forward+punch. But there are other kinds of input buffers. Street Fighter IV has a notoriously large input buffer for moves performed on wakeup; it's the reason the game's reversal window is so large. Input a shoryuken even a few frames before you could act and it'll still come out frame 1.

NetherRealm Studios games use a different kind of input buffer, where moves are just stored in a sequence and performed in order regardless of how long ago the inputs were provided.

BlazBlue utilizes what I will refer to as a "repeating input buffer". Any time you input a command, if you hold the command, the game will repeat the command every frame for the next five frames, until either you stop holding the command, or the command is executed. For instance, if you wanted to link a special into a 5B (standing-B), you could press and hold B for up to five frames before your character could act, and the move would come out as soon as action is possible. There's some additional weirdness regarding how dashes are buffered; I believe any dash command is automatically repeated for five frames or until execution, with no holding required. This lets you do "microdashes" into other moves. If SFIV had BB's repeating input buffer, one-frame links would not exist; the tightest link would be five frames (barring any combos requiring delays or controlling the opponent's position etc).

To this day I have not been able to think of any reason why a repeating input buffer would be a bad thing to add to a game. The closest thing I've been able to come up with is that difficult links bring a sense of risk vs. reward into decision making, where you run the risk of failing the link and so you may opt not to try it. But fundamentally that does not express the primary appeal of fighting games: overcoming your opponent. On the contrary, it's a question of overcoming yourself (or, from a different perspective, the game engine, if you'd like to think of it that way).

So let's discard that idea. In the remainder of this post I will attempt to discover some benefit, something that can be done only in games without a RIB.  I do not yet know anything I'm going to write; the whole thing will be very stream-of-consciousness. As a comparison point, I'll try to use the other input buffer systems I know. First, let's try to find out if a RIB makes any kind of input impossible, or more generally, if it makes any command sequence that works under a game's current system, fail.

By its nature, the RIB can only hold one command. So, you cannot buffer two consecutive commands at the same time. Of course, this isn't possible in Street Fighter IV anyway, since the game lacks any kind of input buffer outside of its command interpreter and on wakeup. NRS games do provide the opportunity to buffer multiple commands, so some input leniency is lost in a hypothetical version of their games with a RIB.

On the other hand, you could simply increase the number of RIBs available. Create a queue of RIBs, and whenever a new command comes in, add it to the earliest open RIB such that there are no occupied RIBs below it in the queue. Each frame, evaluate the RIBs in order and execute the earliest one if possible. A demonstration:

t=0 <- hold 5B: 5B is put into RIB0
t=3 <- hold 5C: 5C is put into RIB1
t=4 <- action available. Check RIB0, execute 5B, clear RIB0.
t=5 <- hold 5A: 5A is put into RIB2 since RIB1 is still occupied.
t=7 <- action available. Check RIB0, clear. Check RIB1, execute 5C, clear RIB1.
t=9 <- action available. RIB0 and RIB1 clear, execute 5A, clear RIB2.

The usefulness of multiple RIBs seems suspect, since most moves will have more than five frames of committed time after execution begins and the RIB is cleared.

So assuming a time limit of five frames, NRS's input buffer is not expressible with a RIB. You could potentially remove the time limit, and with multiple RIBs you could come close, but even in such a system putting two of the same command into the buffer is impossible. You would need to stop holding the command in order to input it again, thus clearing its previous instance from the buffer.

Let's try to express Street Fighter IV's input buffer in a RIB, then. This is easy: reduce the time limit to one frame, except on wakeup. More generally, any input sequence that works in SFIV currently would work just as well under a 5-frame RIB, except likely plinking. Luckily the RIB means plinking becomes unnecessary.

What appears to be the key thing here is that with a RIB, any command is only executed if you are still holding the command when execution becomes possible. This prevents you from performing commands you didn't intend, which the NRS system or a non-repeating 5f input buffer does not.

What happens, though, if you want to execute a command requiring multiple button presses, and you don't want it to happen on the first frame available? Perhaps you need 5DD to happen 2 frames after action becomes available. Without a RIB, this is fine as long as you press the first D at any point before action is available. With a RIB, you need to not be holding the first D at that point, which is slightly more restrictive. The only game I can think of that requires something like this is Persona 4 Arena, but in that game the single-button version of the command has to come out before the two-button version can (see: Chie 5DD, Narukami j.BB), so the RIB is strictly more lenient anyway.

And that's really all I can think of for potential problems with the RIB. In general, it seems that having a RIB makes inputs strictly easier than having no buffer or a non-repeating buffer. And with that being the case, a 7f RIB makes inputs strictly more lenient than a 5f RIB, so why not go all the way and remove all effective limit on the buffer time? Why not just repeat the input for as long as the button is held, until it's executed? Perhaps there's a technical reason for it; not knowing how the games are programmed, I obviously can't say. Additionally I can certainly believe that having an effectively infinite-time buffer could mess up movement buffering.

So let's stay small and just go with a 5f RIB then. Is there any reason, other than the higher mechanical difficulty, not to have it?