Why Unblockables Work (???)

Lately I've been focused on why UB's happen, so I analyzed three of them to find out the common ground:

Sent Spit beam: projectile normal, causes Twitch-untwitch-twitch style guard, dummy must land or wake up into UB, proper set up *seems* to have high success rate among top players

Doom Crouching Roundhouse: sweep normal, no apparent Untwitch, 100% setup following successful UB

Chun Stomp: jumping normal, no apparent Untwitch, 100% loop seems possible from a connected UB


As far as success rates, I can't vouch for the Sent UB as I haven't worked with it a whole lot. However, I've noticed an odd similarity between Doom's and Chun's. With each, I have the most success when I create a set pattern to follow in between UB attempts.

For example:

With Chun I do jumping d.HK close and deep, let Chun recover and fall to the ground, hit s.LP immediately following landing, hold forward as the LP recovers, walk up to the dummy, and repeat another close and deep unblockable stomp. When I get one UB, I've consistently gotten 3-4 more in a row using this method.

With Doom I do d.HK, doesn't matter what the range is, then wave dash back, then towards and d.HK unblockable again. I can repeat UB's 100% until I mess up the dash timing. I've done a bunch of other easy Doom patterns with the same results.


Conclusions:

After weighing all of the individual characteristics of these Unblockables, I've concluded that there is one specific nuance occurring that ties all three together (along with most, if not every other unblockable).

As far as I can tell with what I know about the game, these are unblockable because the game engine doesn't see a hitbox during part of the move's animation. With Sentinel this is easy to see with a jumping-away Dummy-- because of the aforementioned "untwitch" in the twitch-guard caused by the beam.

You can't see this happen with Chun or Doom, but I believe that the same issue is happening in the eyes of the game engine, except instead of a twitch-untwitch-twitch pattern, these normals simply sometimes start in "untwitch" state by animating the hit-portion of the move without first displaying the start-up (that causes twitch-guard).

Observe that with most normals, there appears to be a very quick twitch, and then untwitch while the normal is still out. Twitch guard has to be caused by a specific piece of data, whether its related to the presence of hitboxes, or attached to a specific number of frames specific to each move is a mystery to me. However, when you look at a regular normal, versus something like Tron HK Rock which causes twitch guard all the way through [Edit: not exactly true-- see below], even when hitbox data is not active, it presents an interesting conundrum. Specifically, it causes twitch throughout even though if you jump into the rock before it's thrown (when Tron holds HK to keep rock above her head), you will not get hit.


The question now remains: Why are these only unblockable part of the time?

Frame Trimming: (EDIT: THIS MATH IS INCORRECT, 1 in 5 FRAMES SKIPS)

[These numbers need to be fixed, but the concept stands]

Let's consider a curious part of the Marvel engine. The Dreamcast version (and at this point I think arcade as well) does NOT run at 60 fps. Instead it runs at a steady 72 which is translated down to 60 by the introduction of a frame skipping cycle that drops every 4th frame. So 15 times a second, there's one less frame than there should be.

This is the same phenomenon that makes Joo's 100% Sequences necessary for Programmable Pad combos to work flawlessly. These PPAD sequences are basically just a method to find where in the frame cycle you are at a given point. Pretty genius, as Magnetro pointed out to me and I'm only now really understanding why.

Full Circle:

From a cold start, i.e. outside of one of my patterns, I feel like I'm getting a random UB about 25% of the time. It's a hunch and a rough estimate; I can't really say because I'm not a computer and I can't test for this properly. I guess the only way to test is to try it once per training instance, then restart and try again. Do that a hundred times and get back to me (:]) .

However, what I believe this to mean is that one in four times, you'll execute a potentially UB move (let's say Chun Stomp) and the key point of animation (tied to the start-up) will land on the skip frame. When this happens, no twitch is registered, the game reads only the hit frames, and the dummy gets bwapped. It's my belief that any consistency in positioning or anything else being a factor in the move being unblockable is really just based in a habit, conscious or otherwise, of falling into a pattern once the first UB is achieved. After all you can hit it 1/4 times, and once a pattern is established, its feasible.

Connections:

I look at it like this: 1/4 is a perfect example of a nice, round musical tempo. Almost any drum beat you can think of is rooted in this, or a subset of this, and there are plenty of musicians that can manipulate, hear, and play notes with far more precision than 15/60th of a second.

Using this knowledge, I applied the idea of staying in a set tempo after landing Doom's UB, and was able to consistently get it with scary precision. Like 100% precision. There are really two things to pay attention to in order to do this-- first check whether it hits as a UB, then stay mindful of where in the cycle you are at from that point forward. What that basically means is that when you hit cr.HK, thats the first beat, and you just gotta make sure to dash (or do anything) in rhythm, and its a cakewalk to get the UB again.

What I think this is actually doing-- and this is a trip -- is creating a manual 100% Sequence that you can follow. More truly, I guess the Sequence is really the fact that the first UB hits (you know you're at the right spot of the cycle), and the rest is just the manual sequence to manipulate the cycle.


Problems and Possible Solutions:

1.) Tron HK Rock could be seen as a projectile throughout even though its a normal first, followed by a projectile. The Rock could be its own sprite. This would take away the uniqueness of that twitch scenario and take out some of the argument behind twitch being related to anything other than active hitboxes.

2.) There are plenty of 1 Frame Normals that aren't unblockable, ever. Mega Man, Magneto, Spd-Up Wolvie, Shuma and others all have them, and they aren't unblockable. However, I DO finally have a theory as to why this might be:

Every move has a Start-up, Hit frames (with hitbox data), and Recovery. Logic says that these should be separate. Since when did MAHVEL follow anything resembling a system of logic? After all, Start-up, Hit, and Recovery are all the same thing, with the 'difference' coming in the presence of a hitbox entering in at some point. They would overlap freely if it weren't for that.

What if Capcom was savvy to this presence of UB's? And of course they are-- every game is plagued with a handful, and they try to fix it for the next installment. What if they simply overlap the frames that cause twitch guard with the hit frames? Maybe this would solve the problem. Or even simpler, what if they took all the obviously applicable 1 frame normals, and told the game to 'look' for the frame cycle and then insert a buffer frame as necessary? It could be that Doom, Chun, Sent and others just slipped by without being tagged as being dangerous.

All this is just coming from my brain-- I don't know how games are programmed, but this sounds plausible to me so who knows.


Lastly,

Its MAH-ble BAYbee. These UB's work, so we can always just enjoy 'em for the scary little nuggets of death they are. It's my own fault for being a curious motherf***er. I lose sleep over this so you don't have to.

Very Special Thanks to Joo (and by extension Magnetro) for paving the way for anything technical Marvel!!! Respect to Risunomeijin (for introducing me to the Chun UB) and Shin (!!!) for being all-around Chun Gods. Also big thanks to Mixup, Shoultzula, Philopia, JudgeRL and everyone else who's put up with my incessant babble/brainstormed with me regarding this stuff at all hours these past few days, and taught me a thing or two about how not to be a scrub.


~ECGief