Hi, it’s SKD again. I get a lot of people asking me about Proximity OSes and why they work, so I’d like to make a definitive write-up on the subject. If anything needs clarification, please let me know. This is all the sense I’ve made of the mechanics, so some information / numbers might be updated with further exploration.
This is a fairly advanced concept and assumes a decent knowledge of system mechanics.
I’ll cover how the OSes works in both BB and GG, because they’re actually very similar! Video examples will come from both games, but rely on the same concepts. I may occasionally say barrier, but faultless defense functions the same way, so option selects involving barrier also apply to FD the same way.
Definitions and Logic
First off, what is proximity guard? Proximity guard is the blocking animation your character makes when attempting to guard a move. Depending on distance from the opponent, your character will go into a guard animation if you are holding 4 or 1 during the startup, active frames, or recovery of attacks.
What is so special about it? Like barrier or faultless defense, proximity guard is a “forced” guard animation. Your character will make the animation to guard, even if they’re not in blockstun at the time. This is important to keep in mind because these forced guard animations are prioritized in certain states, which I’ll get to next.
The state that is relevant to these option selects is “landing recovery”. I put that in quotations because it isn’t quite the landing recovery that you intuitively think of, like landing recovery being a window where you are unable to do anything when hitting the floor (like blocking!). I’ll make the distinction to call that specific kind of landing recovery “forced landing recovery”, and call this special kind of landing recovery we’re going to be concerned with “standard landing recovery” (If you’ve seen me post about this, I sometimes refer to this as trip guard thanks to how similar the state is to Street Fighter trip guard, but for the sake of this article it will be referred to as standard landing recovery).
The reason I went with the naming convention of “standard” is because this landing recovery gets applied to most landing situations in the game. If your character jumps and lands and is not in forced landing recovery, they are in standard landing recovery. It’s a bit difficult to notice what this state does, but how it works sets up the foundation for these option selects.
While forced landing recovery varies in length based on the move you use (and restricts your actions entirely!), the standard landing recovery length is fairly consistent, as far as I know. In BB, this landing recovery length is 5f, and in GG it is 4f. Unlike forced landing recovery, standard landing recovery only restricts certain options. For those 5f, you cannot walk, crouch, backdash or jump. But it can be cancelled with attacks, forward dashes, and…you guessed it, forced guard animations!
If you’ve been keeping all of that in mind, then the next step is fairly clear: combining the standard landing recovery properties with proximity guard!
Where’s the OS?
So this is where it starts to get a bit technical. Proximity guard is a forced guard animation that has no priority over actions, and has no total duration (It takes 0 frames to actually happen). Effectively, inputting a guard will cancel your standard landing recovery, (you can even use barrier to shorten the length of the standard landing recovery itself). However, in the case of proximity guard, we get the cancelled landing recovery only in the case of an attack coming out (there is an exception to this: throws! Throws don’t activate proximity guard, as shown in the video below) and because proximity guard has lower priority than most inputs, options that standard landing recovery initially restricted become possible only in the case of proximity guard activating. This is the basis of the option select.
So…what does it do?
In a nutshell, it lets you perform an action only in the case that your opponent tries to attack you. This can be manipulated and applied to many situations. For example, you can use this to cover both DP and Backdash on wakeup in safejump situations, letting you simultaneously cover every wakeup option.
But for the sake of this article, we’re only going to be looking at it in an isolated situation to examine how it works. If you’re interested in applications, that is in a follow-up article to this one.
Below is a video if it in action! There are 3 recordings used, and each is played back 3 times. The first playback shows what happens in the situation that there is no proximity guard, the second shows the lack of proximity guard activation on throw, and the third shows the activation of the option select by causing proximity guard. This is then repeated for the other recordings.
For the sake of explaining the concept, these are some common forms of the OS. I’ll detail each one and why I included it in the video below it.
For all of these, keep in mind the core properties of proximity guard. It has no total duration, and also very low priority over other inputs.
In this case, the input is (written from 1p side):
8 (land) 4 <-this notation means hold, if you don’t know!
The input is simple, but it’s timed so that the backdash gets placed into the standard landing recovery. In the case of no proximity guard, because the landing recovery never gets cancelled and the backdash is restricted, nothing happens. In the case that proximity guard activates, the standard landing recovery is cancelled by the 4 input, which doubles as the backdash attempt. Due to the priority of backdash over proximity guard, backdash successfully comes out in the third playback!
For this recording, the input is:
8~ (land) ]7[ <-this notation means release.
An even easier input this time, but the timing is still important. In this case, the 7 input plays a double role. Because your jump is restricted during standard landing recovery and 7 is a valid guard input (still a back direction), landing with a 7 input will check for proximity guard while trying to jump at the same time. In the case of no proximity guard, the guard animation never completes, and the jump input remains restricted. In the case of proximity guard, the 7 input begins proximity guard, and due to the priority of jump over proximity guard, causes jump startup to begin.
*Note that while I have written the input as held (a useful input to prevent yourself from getting a double jump) you can simply input the 7 when you land. However, holding 7 upon landing will automatically buffer the guard + jump on the first possible frame, so the timing becomes much more simple.
This one is rather complex, but has a really cool result!
The input here is:
8 236236 (land) [ABC]~4~]ABC[
For this example, it’s important to note that barrier (and faultless defense) has priority over jump (unlike proximity guard, which jump has priority over) so a 7 input with barrier will prevent you from jumping.
Similar in concept to the option select in Recording 2, this is based on option selecting a jump with a 7 input! However, because the input is so convoluted, I’ll break it down step by step.
8 – The jump (wow!).
236236 – A compliant input to buffer super on the way down (the 7 doesn’t cancel it).
(land) [ABC] – This happens while you’re still holding 7, and is slightly delayed. Because it’s a barrier input, if you do it too early, you’ll cancel your first standard landing recovery frame into barrier and be unable to check for proximity guard!
~4 – At this point, we move from 7 to 4 to prevent a jump from coming out when we release the ABC input.
]ABC[ – Releasing the ABC input after pressing 4.
Here’s where it gets a bit complicated: we need to think of what each input does in the proximity guard situation, and the non proximity guard situation.
No Proximity Guard – Upon landing, the 7 input checks for proximity guard in an attempt to cancel into jump. But because jump never begins, your ABC input (with held 7) comes in, and becomes barrier (despite the buffer of the 236236 from earlier, barrier has priority over the super, so barrier comes out). Then you move to 4, and release barrier. The end result is a barrier flash for a few frames.
Proximity Guard – Upon landing, the 7 input checks for proximity guard in an attempt to cancel into jump. Since proximity guard happens, and then the 7 input buffers jump startup. At this point, the 236236 input is still in the buffer. In the previous example, barrier took priority over the super, but now, because you’re in jump startup where barrier isn’t possible, the super takes priority, cancelling the jump startup. The end result is Phorizer if your opponent tries to attack you.
Those 3 variations are the most practical forms of the Proximity Guard OS. Recording 1 displays OS backdash, Recording 2 displays OS jump, and Recording 3 displays OS special. How other proximity special OSes are performed is pretty contextual in use, but the fundamental idea is there and usually requires use of barrier to out prioritize inputs. In summary, the end results are:
No Prox – Nothing
Prox – Backdash
No Prox – Nothing
Prox – Jump
No Prox – Barrier / FD flicker
Prox – Special
Because these “No prox” outcomes are so non committal (having you either do nothing, or flash barrier for a few frames), you can do (almost) whatever you want! For example, if backdash doesn’t come out, you can choose to stick out a normal, or dash forward instead. This is where the real strength of the option select comes from.
Anyways, that is about it for the logic behind the proximity guard option select itself. Eventually, it gets tangled up in other option selects and becomes a monstrosity of thinking about compliant inputs, but that is a topic for another article. If you’re interested in applications, stay tuned for a followup article! Thanks for bearing with me.