What happened to the Throw button?


#1

In the latest build v0.10045 there’s no option to configure a throw button anymore. What are the pros/cons of the button? Personally I liked it since I’m not used to SFII style throws. I feel that having the same input for throws as some of the normal attacks (backward/forward A) gives me less control over the character (what if I want to to a bA/fA move up close?)

Thoughts?


#2

The throw button was an experimental thing.
I used to continually argue in favor of it, but it can’t exist for a couple of reasons

  1. They have to pick one kind of throw. It can’t be both throw button AND fA/bA.
  2. Allegedly “fA/bA feels better” and “everyone at every show said so.” says Sirlin, and if you know him you know he will never ever change his mind.
  3. Too many buttons. They don’t want it to be another button, even though 2 buttons could be an option, because they want it to be simple and they may want arena to use extra buttons if need be.
  4. Here’s the most important one: It breaks the yomi counter game. This is the only reason that I can’t argue against and the one that I conceded to. Yomi counters means press nothing. If 2 people try and throw in this game, the faster one wins. If you try and block, you get thrown. If you risk everything to yomi counter, you counter it. But with a throw button that changes, since you don’t need to touch the stick. If 2 people try and throw with a throw button, the faster one gets yomi countered because they’re not pressing anything yet since they’re slower. It essentially breaks the whole dynamic of yomi counters. If a throw button was included, they’d have to include teching, otherwise the YC game would be busted.

The downside to not having a throw button is that you can fA and bA normals when you want to at proximity, and yeah I wish I could but that’s life. If you want to wake up throw, you just have to wait longer than you think you do to get the throw to come out, otherwise it will come out as a meaty.


#3

I don’t understand point 4 though. Isn’t that already like that, if both players fA whoever is quicker would get yomied. Except when it’s within the 3 startup frames of a throw in which case the quicker would win cause the other person isn’t in neutral anymore. or am I missing something of how that mechanically works?

Personally I really dislike not having a dedicated throw button, since it means you can’t use your moves at certain ranges and it feels awkward to go neutral for a simple punch (maybe that last part goes away with enough practice though). I think especially also playing online and with a certain amount of ping, not getting moves out and/or accidentally getting wrong moves out cause of distance feels very annoying sometimes for me. again maybe this will change after a while of getting used to it, but having never played sf2 it just feels a bit clunky


#4

If both players do fA then no one gets YC because both players are pressing buttons

And sorry dude, I am a throw button person myself, but I can’t argue about changing the whoe YC game and Teching around it


#5

The slower player can’t yomi counter because they press forward. Unless they delayed their throw, but that’s an intentional yomi counter followed by a throw.

There are very few situations where fA is better than nA when in throw range. nA is almost always faster and combos better. Really only Jaina loses out bc her fA, B knocks down, but nA, B still does 2 damage. Overall it makes for better gameplay, throw button gives little benefit in exchange for breaking yomi counters.


#6

I still don’t understand how that works mechanically. How is “If both players do fA then no one gets YC because both players are pressing buttons” different from both players pressing throw button (which you say does give the slower person a yomi counter?)

Same with the comment about “The slower player can’t yomi counter because they press forward”. I mean if they press forward they also press A for throw, no? no one just walks forward for no reason. If they walk forward to get in throwing range then throw button would make no difference in therms of yomi counter (cause they aren’t in neutral anyway).

As for losing out, Midori’s neutral can’t combo into anything except flurry punches, which are kind bad imo. I’d rather have the fA 2 hit punch cause that way if they block it’s at least not at a high frame disadvantage. Also sweeping at close range wouldn’t be bad at all either imo.

But I mostly don’t understand the mechanical problems that you say arise from throw button in terms of how it interacts with YC. Like it would seem it should be working already as it does now regardless of whether it’s a button or a direction+button


#7

Well jump in throws you’re not pressing your stick when you land, and wakeups
There are definitely times that 2 players are close next to each other. If two people press the throw button, unless it’s simultaneous, the 2nd one won’t be pressed yet when the first one is pressed. So then the first person gets yomi countered. So you want to be the 2nd person to grab, and then essentially that means you don’t want to grab which then makes grabbing kinda dumb


#8

" If two people press the throw button, unless it’s simultaneous, the 2nd one won’t be pressed yet when the first one is pressed."

But how is that different from the dynamic we have now where we press 2 buttons to throw instead of just one?


#9

I don’t know about you, but if I’m intending to throw someone, I hold the stick down.


#10

Under the current system (hold forward or back and press attack to throw), the most likely scenario if both players are trying to throw is:

  • Both players start holding toward/away while in throw range of each other.
  • At the moment one of them presses A, the game checks whether to throw:
  • It sees that the player who pressed A is both moving and within throw range.
  • It also sees that the other player is on the ground and pressing either left or right (and no other buttons, meaning they’re vulnerable to throws.
  • Taking the above into account, whoever presses A first will throw the other if both are trying to throw.

This is, as far as I know, identical to how some versions of SFII handle throwing (except that the check for throw vulnerability doesn’t factor in Yomi Counters in SFII, obviously). On the other hand, if both players are trying to throw and there’s a dedicated throw button:

  • Both players stand in throw range of each other. Because they’re already in range, there’s no need to move closer.
  • At the moment one of them presses T, the game checks whether to throw:
  • It sees that the player who pressed T is within throw range.
  • It sees that at that moment the other player is pressing no buttons, because they aren’t moving and haven’t yet pressed T.
  • Taking the above into account, the game decides that the player who pressed T first gets Yomi Countered.

This is entirely realistic because, for example, you don’t need to hold forward if you jump in (since your forward momentum keeps you moving forward once you’re in the air). I’m not contriving a scenario here; I’d be surprised if this didn’t happen in real gameplay.


#11

Yeah, basically the “correct” way to throw with a throw button nearly 100% of the time would be to let go of left or right first, just in case the other player tries to do a throw before you do (in which case you’d win by being slower). It adds a pointless extra step of execution without decision-making, in a way that isn’t clear to beginning players.

In other words, having a throw button would lead to having an option select available, and one of the implicit (if not explicit) design goals is to avoid option selects, and require the players to actually make a decision and commit to it.


#12

Thanks Hobusu for detailed examples. Now we got some scenarios to analyze :slight_smile:

Okay, so first, can we agree that outside of jump in’s people are usually not just standing near each other and not pressing buttons? Feel free to correct me on this of course, but I think we can ignore this scenario for the sake of this argument and thus focus on the dynamics of jump ins

The scenario you mentioned was after jump in and I’d agree this is the closest we will get to both being close but not necessarily moving, so let’s analyse this a bit further :slight_smile:

We have two ways that could happen I think. Either Player A makes an empty jump and then tries to throw or he jump attacks and tries to throw after the block stun ends (let me know if there’s one I’m missing though).

In case one, player A empty jumps, player B most likely blocks (holds backward) and then gets caught with a throw, cause he didn’t anticipate the empty jump. Here, neither option would make a difference, since he’s not gonna react to the empty jump either way.

Case two would be Player A jumping in and attacking and then trying to throw after the block stun ends. This is where the main difference is, IMO. In case of no throw button what will happen is. Player A jump attacks, then either 2.a) presses fA too early and gets and attack animation out, while player B will buffer the throw and throw player A right after he comes out of blockstun becase the throw start up frames are way lower than any fA attack startup frames.
or 2.b) happens which is, player A waits a bit for blockstun to finish before he tries to throw, but then also Player B will most likely get the throw because his timing will be frame perfect (because he buffers the throw) and Player A’s most likely wont be (because he has to manually time it)

(this is also an okay option select sorta, because if A does an attack string the throw won’t come out to begin with and you keep blocking, you only throw if your opponent tries to throw and then you automatically win)

But since player A knows that he can also do 2.c) wait in neutral for a bit longer after landing in case B does this option select, in which case he will either YC B’s throw or if B doesn’t do that and just presses back for blocking he can still get thrown by A with fA

(but of course since B knows that as well, he can instead go neutral real quick before hitting fA instead of buffering his option select to catch out A’s delayed option and thus we have a cool mindgame again)

If there was a throw button it would go differently. player A would try and startup the throw in such a way that the active frames are active just after hit stun is over, in which case he either 3.a) times it right and gets the throw because B will just be out of block stun and start up his throw or 3.b) he times the throw too early, the throw misses cause B is still in block stun and A gets thrown instead after B comes out of blockstun
In scenario 3.c) A times it slightly too late such that A throw starts up while B’s throw is active in which case B throws A
or we have 3.d) which is what you’re talking about I think, A is way too late and gets the Yomi Counter because his timing was off by too much, such that his throw didn’t even start up before B’s throw hit its active frames.

Here too ofc both can consciously decide to delay their throws juuust a little bit to catch the other out on purpose, and ofc, if one anticipates that he can just neutral A for a 2 hit combo

But notably no scenario includes anyone pressing buttons quicker in a “having quicker fingers” kind of sense, since all the decisions of whether to press a button or not to press a button happen early enough, that one can either do it as an input “string” where there’s no downtime or then it’s a buffered throw which will come out on frame 1 of being in neutral or then it’s a timing thing where one can mistime his button presses and get lucky, but also one can purposefully delay a button press to bait the YC (which is fair game, I think)

I think the main difference of throw button vs no throw button is what TYPE of pressure one can have after a jump in attack and how the dynamic goes between the one who blocks and the one who jumped in and what options either have.

And since GRAG mentioned option selects, currently there’s the one I mentioned above (the 2a) 2b) )already in the game and is easy to execute if one wants to. Then there’s the timed delay where you go into neutral for a split second before pressing buttons, but quick enough that you can still block if need be, which works on either scenario (and also beats multiple options). So I don’t think we’ll get rid of option selects (some are just hard to time), but having them in also leads to next level mindgames, so I kinda don’t mind it either way.

And as for the “correct” way to throw, the same would then be true currently that the “correct” way then would be to just tap forward/backward the moment you hit A and not hold it (which is just as awkward).

So in summary, the only scenario I think where being slower is better with throw button would be 3d) which can happen on accident, because the timing window is quite small. On the other hand it can also be treated as a “time-crossup” where the player executing it can’t be sure if it ends up coming out on time or slightly delayed (like in a crossup where you can’t be sure if they need to block left or right). Of course B knows the timing is precise and A might not be delayed and so can then just delay as well, which again can be beaten by a well timed neutral A and thus we have the mindgame originally intended for YCs I think.

The main difference between having a throw button or not would be whether A can more quickly apply pressure by threatening to throw of whether he needs to wait a bit, cause he can’t win the throw timing vs B after a jump in currently.


#13

Without the throw button, you should let go of left and right, then push towards+A on the same frame to do the same thing.


#14

Hmm. This is technically true.


#15

I was about to make the same point as sharpobject.

Also, you could technically make a throw button that only works on f/b, and in neutral taunts (would mean that the neutral button press would remain as an option for the arena, as “replace taunt with X”) or something. The main benefit would be the no overlap with f/b normals, and throws being their own “thing”, which I think would be a lot better for new players instead of throws/yomi counters emerging semi randomly and leaving them in a “wait, what just happened?” state (if you don’t believe me that this happens, watch Max’s stream of the game). Further benefit could be that the throw whiff anim could show you the throw range, which right now you kinda have to intuit from “where does my knee become a throw”.


#16

Yes, I was going to say the same thing. How is having to press direction+attack on the same frame (the moment you want to throw) any different that having a dedicated throw button to press on the same frame (the moment you want to throw)? Other than the latter being less execution heavy (which I thought was the point) and far more reliable. Hell you could make the throw button something you hold simultaneously with a direction to throw at the earliest game-allowed opportunity - the moment you’re back in waiting for input neutral - in the direction you’re telling it to. Less frame perfect execution needed, and you can still counter it by doing nothing.

It’s basically the exact same thing as the difference between a special move being quarter circle + attack and special move being one button. Can’t accidentally get something else - and what matters is the read not the execution right?


#17

If this becomes an actual problem of any kind, yomi counters could be given a small “startup” time so to speak, where the first couple frames you’ve let go of all controls for doesn’t count for performing yomi counters.

It might be beneficial for other reasons too, like preventing accidental yomi counters if someone is switching from moving left to right or vice versa, and merely happened to be in neutral for a frame and were thrown then.


#18

Looks like the throw button is an official, non-optional part of the newest build : 0

I wasn’t a fan of it back when it was an optional toggle, but it looks like I’m going to have to learn to live with it for, at minimum, a few weeks.


#19

Hmm. Rook buff I guess?


#20

well would you look at that