Large Buffer Windows

I only mentioned Raging Storm because it was in the post I quoted, mentioning how fast you had to do the move for it to come out. The double fireball was more about input yes, but basically what I was getting at was that the move had that specific input and you had to do it so fast for a reason.

The Kim example however is PURELY about input buffers. Being able to START the Neo Max input as you’re doing a flash kick and then FINISHING it after you do a flash kick would not be possible without the overly generous buffer window that exists in KoFXIII. Kim being able to do that gives him an invincible reversal into 500 damage as well as boosting his damage to one of the highest in the game, as I mentioned being able to kill a character with 3 meters thanks to the easier input from the long buffer window.

There’s more examples of the buffer window in XIII than that, but that was just the first one that I thought of off the top of my head. You could easily fix those ridiculous inputs that allow extraordinary things by simply making the buffer window shorter, but that was SNK’s design choice and they allowed it. Maybe someone else wouldn’t want one of the best offensive characters with some of the best normals and quite possibly the most hard knockdown/safejump setups to also have some of the highest damage in the game, so they wouldn’t have overly long buffer windows. That is the downside to having long input windows.

I’m not really familiar with KOF XIII, but I’m not sure how what you cite is an example of the input buffer being too large, unless the buffer is literally significantly longer than the entire duration of the flash kick, which seems, even if it’s a ‘fast’ move, to be what I would consider ‘extremely’ large, though I guess I don’t know how long the ‘average’ buffer size is.

All that said, I don’t really see how the buffer is actually responsible for the issue you are citing - why couldn’t a person just do a flash kick and then buffer the entire neomax motion during the flash kick animation? That doesn’t seem that much harder than doing it the way you describe (actually, it seems easier to me.). So maybe I don’t understand what’s actually happening here? I’m presuming that you’re describing doing something like:

D,DB,B,U (Flash kick happens thanks to D>U?), DB,F (Neo Max happens).

Couldn’t you just do:
D,U (Flash kick happens), D,DB,B,DB,F (Neo Max happens) since you have the entire duration of the flash kick to work your way through the motion? Or is it actually a cancel? If it’s a cancel, then it seems like something the developers really wanted to have possible, regardless of the size of the buffer and they’d have just had to find another way to make it happen otherwise? And if it’s a cancel, then the input buffer doesn’t really have to be very big at all for this to work?

Large buffer windows are totally the way to go - the only downside is that you need to make a decision to build your game around animations that support them.

I’m speaking from a developer’s perspective - and supporting large buffers mid-combo means supporting procedural animation blends - that gives you flexibility in your branch points. 2D has it much simpler, of course, since you can just keep a given frame on-screen for a variable time and it looks fine. But back 10 years ago nobody was doing procedural blends, so you had really hard-coded combo branch points, which meant your buffer needed to be short.

Can’t you just have the next move of a string/chain come out at the normal time it would?

That would probably lead to really confusing animations, then. And lots of games already have hitboxes that are waaay off from their sprites/models.

Large input buffers actually get in the way of lots of higher level techniques and make certain things unnecessarily difficult, ironically, because the developer decided to make other things unnecessarily easy.

Just 1 example off the top of my head. Doing a raw kara tiger shot with Sagat in SF4 is rather tight because of the gigantic buffer window. You have to tap :f:+:lk:, let go immediately, then wait as long as possible before inputting the fireball motion otherwise you’ll get a dp/tiger knee every single time. This particular case is a combination of lax inputs, move priority and huge buffer windows, but the fact remains that at the highest level, large buffer windows are really really fucking annoying.

That and they really dumb down the reversal game, but I’m not beating that dead horse :rolleyes: .

Nigga, you gay

You don’t have the entire animation of the flash kick to input the move. Kim’s NeoMAX is usable on the ground only, so you have to cancel into it while Kim is still grounded when he hits the flashkick. It’s kind of like Guile canceling FK into Double Somersault/Flash Kick. Even if that move wasn’t a charge, do you think most players would be able to get out a DB, DF, DB, UF in the space after you input D~U+K, but before Guile leaves the ground?

It’s possible because of the Drive/HD Cancel system present in the game, wherein you’re allowed to cancel specials into other specials/DMs. Kim can cancel the grounded state of his flashkick on hit into grounded specials/DMs, or cancel into air-specials/DMs once he’s left the ground.

I think there are other solutions like skullgirls do. The don’t jump if you’re trying to do a 360 with Cerebella for example.
And negative edge exists for that reason.

No, I mean having a buffer that would mean that certain chains/strings would be executed, regardless of the timing of when the commands were inputted.

EDIT: Unless off course you’re replying to Mr.Strange and not me, then in that case, I get what you mean.

imo nothing inherently bad about them unless you get a charge outta doing things that are unnecessarily difficult

combined with other elements it can be bad

Long button buffers are pretty helpful for linking or juggling when the end of the previous move’s recovery is too hard to tell, but long motion buffers can get in the way like in the kara tiger shot example duck strong described.

Didn’t @Mike_Z come up with a formula for input windows for moves? Something like 4 frames(?) per direction, plus an additional 4 frames for traverse between 2 directions that aren’t adjacent to each other or something.

Okay; That’s much more clear. Still, it sounds like a conscious decision on the part of the developers - an issue like this could easily be fixed by having Kim become airborne on frame 1. (Which is presumably an invulnerable frame anyway if this is a reversal move, so it’s unlikely to matter for any other purpose).

Similarly, the Tiger shot issue mentioned above is more a problem with SF4’s lazy inputs - F, D, DF + Button, F is not the same as F,D,DF,F+Button and if the game is getting them mixed up, that’s not a problem with the buffer, the buffer just exacerbates the problem with the game being stupid. A smaller input buffer makes this problem less apparent, but it’s still a problem. The correct solution is to make the game handle those inputs properly, and not just bandaid the issue by reducing the buffer size.

I’m not a member of the cult of the tiny reversal window either, so I don’t really see that argument as anything more than, at best, a difference of opinion.

Then how am I supposed to DP after spiral arrow? A super will come out.

You have enough room for unique features without resorting to complicated motions beyond the standard SF2 fare. GG’s Venom is complex because of all the setups and angles he can utilize. Even if you make his FRCs and combos easier to execute it will not make him a shallower character.

PS2 melty blood had a 12 frame buffer window, being too generous can be a bad thing. That shit would save inputs you made a week ago and fuck you up with them.

Old Capcom games have it at 8 to 12 frames (even sf2) for each input on a special. Also, you have to factor in the frame skip from turbo (http://combovid.com/?p=5002) which shorten the window.

not if you don’t input the forward command and stop in the “3” position.

Depends on how lenient the game’s command interpreter is.

Then that would make his normal corner carry and corner loops impossible.