Friday, September 27, 2013

The Guilty Gear macro glitch

A recent discovery in Guilty Gear XX Accent Core and its subsequent iterations has generated a flurry of discussion, argument, and overall bad posting, rendering reasonable people cowering in horror at the cesspit a certain thread on Dustloop has become. The gist of the glitch is this: pressing any button bound to a macro command gives you a negative-edge input of that macro for every frame you're holding the button.

Some quick terminology background: A macro is, in general, one key or input that performs several inputs when pressed. Most fighting games include certain multiple-button macros to make inputs feasible on a default game pad that are otherwise designed for an arcade stick, and Guilty Gear is no exception. You can set any button to perform P+K, P+K+S, etc. Pad players typically bind these to the unused shoulder buttons. Negative-edge is a ridiculous term that refers to a game registering an input when you release a button, as opposed to or in addition to when you press a button. So the way the glitch works is that, in effect, pressing and holding a macro button gives you the macro input every frame for as long as you're holding it. For whatever reason, this doesn't work in training mode.

Since as I mentioned in a previous blog post, Guilty Gear does not have a repeating input buffer (or if it does, it's only one frame or so), this new glitch opens up a world of new input opportunities that were not present before. You effectively now have a limited, infinitely-long repeating input buffer, capable of performing any command that you can coax the macro system into executing for you. You can abuse button priority to make P+K give you commands off of P, for example.

Naturally, this poses some problems. Although both arcade stick and pad players get eight buttons to work with, the Guilty Gear input layout makes using at least one of them kind of awkward, and arcade stick layouts aren't particularly conducive to pressing the far right two buttons. Of course in practice this wouldn't really much of an issue; complaining about input difficulty on stick is laughable. Just man up and learn to press the other buttons.

Notably this would make the game more attractive to play on pad, potentially more attractive than stick, and for a certain set of fighting game players who seek to emulate the arcade experience as much as possible, this seems like a slap in the face. There is a defensible argument that, originally being arcade games, playing a fighting game in a way more faithful to the arcade experience should never be a disadvantage. But ask any Tekken player and they'll tell you that pad is the preferred input method of the community, so again there's precedent to just suck it up and play on pad or take the extra difficulty. Though I fear for the TOs who will have to deal with all the sudden pausing issues as people start bringing all their wireless controllers--I would not blame a TO fearful for his own sanity who banned macros to avoid this exact scenario.

So with the control issues out of the way, perhaps the most compelling argument against the glitch is in gameplay. Having access to a (limited) repeating input buffer can radically alter how the game is played. Imagine trivial reversal windows to beat out blockstrings, or this Justice stupidity:


There are a fair number of other things that can turn into problems, too. So what do we do about it? Here, the "suck it up" answer isn't as obvious. An assumption of input difficulty is built into the game, and certain things are balanced around it. Certainly slashbacks would be stupidly powerful if it weren't for their unreliable execution--you don't need to worry about the miss penalty if it's trivial to never miss. So you can have two major lines of thought that support banning the use of macros (the only feasible way to ban the use of the glitch): making impossible something that isn't possible in the actual arcade game out of purity concerns, and preventing radically negative gameplay effects.

The first argument isn't really justifiable from a pragmatic perspective. Only a handful of Americans will ever play the game on an actual arcade board, so it's not a problem to be able to do something the arcade can't. Console tournaments in Japan, on the other hand, have a stronger position from this argument.

The second argument is the actual crux of the issue, and the pivotal question on whether macros should be banned. Is it worth it to prevent what negative gameplay effects may exist, when doing so makes playing on pad impossible? A fairly large number of players do use pad exclusively (even top players, if not in this game--see SKD). Now I don't have the gameplay knowledge or the community knowledge to know the answer to this question. But, if macros are banned, then new players, who almost exclusively use pad, will be completely alienated. Which leaves only one source of growth for the community: siphoning players from other fighting games, who already own sticks. Is it worth it to restrict growth like that? Of course, the game is old, maybe the only new blood entering the scene is already from the rest of the community, so most new players do actually use sticks.

And is "preventing negative gameplay effects" a goal worth pursuing? One of the golden rules used in fighting games is that the game's default settings go, and the game lives or dies on its own merits. Now I come from a Super Smash Bros. Melee background, I have absolutely no philosophical objection to rewriting the rules to make a more compelling game. It's stupid to let stupidity stand when it can be dealt with--though a significant difficulty of that is in making a standard, which in this case is trivial. So yes, it absolutely is a goal worth pursuing.

Which leads me to my final conclusion: in the absence of total absurdity, let the glitch rock. Unless something absolutely horrifyingly broken is found that cannot be otherwise dealt with, alienating an entire group of players and potential players is dumb. The game's community is small enough as it is, we should be working to make it as inclusive as possible so we can keep playing with more people. We don't need to worry about "arcade purity"--most of us will never see a Guilty Gear cabinet in our lives. Stick players can either learn to use the other three buttons (or two if you really need to keep Respect bound for some reason) or intentionally not take the option. People learned how to plink, we can learn how to actually use a couple more buttons.

The only reason I can see banning macros being worth it is if the glitch turns you into Meta Knight, or something equally broken. Apparently Baiken can do something that might be just that oppressive, so we'll see.

Monday, September 2, 2013

Tales of Xillia in retrospect

Nearly a month ago I made an earlier post about my early impressions of Tales of Xillia. In truth, I beat the game about two weeks ago, but I haven't gotten around to posting a full review until now. Go read my earlier post for proper context for this review.

Features

Nothing has really changed from my initial opinion on all the game's features. Fast travel is great, all of the series staples return in an easy-to-digest format, linking is spectacular, and overall the game feels very robust to actually play.

I actually now have one additional complaint, though. The Lilium Orb, Xillia's leveling system reminiscent of Final Fantasy X's Sphere Grid, seems largely useless. The way the game makes you expand the orb prevents you from specializing your characters in any significant way, and I think the game would have been better served by a traditional system.

Plot

Unfortunately, Xillia's plot falls apart right about the point where the earth-shattering revelation I mentioned occurs. Character motivations become extremely questionable, there's no particular reason why the proposed solutions to the problems should even be necessary and overall it feels like a mess.

As usual, the game has its socioeconomic allegory, which I won't spoil here. I will grant that the sheer attempt at managing the allegory puts Xillia above Graces in the plot department.

I do very much like that the plot makes the word "Xillia" meaningful. Especially in that it makes the pronunciation, officialy "eks-IL-i-a", actually important. This I will spoil: the word "Xillia" comes from "exile".

Cast

The only change to my initial opinion here is that my opinion of Milla's English voice got worse the more I played. I like all of the characters, and they have a very strong dynamic and personal motivations (particularly Alvin and Rowen), but the voice acting was weaker than I've come to expect from Tales.

Battle

Now that I've beaten the game and gotten access to the full range of artes and skills, I can make a more informed opinion on the battle system.

The return of TP in conjunction with AC makes the game flow nicely. One of the problems with Vesperia was that the arte-canceling rules were fairly restrictive, until you got the skills that basically removed every single rule and gave you free reign to do pretty much anything you ever wanted. Having AC solves that problem, in that you can simply cancel whatever you want into whatever you want until you run out of it.

Combos are not nearly as fun to do as in Vesperia, but still are plenty entertaining. Jude basically becomes Ryu, and I had a lot of fun Shoryukening people into the air, kicking them a few times, knocking them down, divekicking their face, and OTGing with a self-buff. Milla is very air combo-oriented, and she has one particular arte that hits a few seconds after it applies, and creating a combo utilizing it feels extraordinarily powerful. I didn't play around with the other characters too much, but Rowen's Arte Tuning solves a lot of the problems I had with casters, so good job.

Speaking of which, each character's unique gimmicks were great fun to use. Snap Pivot allows Jude to teleport behind the opponent when he dodges an attack, and Spirit Shift lets Milla turn a spell into a physical arte; using both was great.

One complaint, however, is that linked normal chains can be frustrating to land. When linked with an ally, your attack chain will change and you and your ally will sort of knock the opponent between you appropriately, but these attacks can be slow and leave both of you vulnerable to other enemies.

Overall

Like I originally thought, Xillia remains a good entry-level Tales game, being representatively good in all aspects. Its plot is its weakest point, but even so it's still stronger than a few other games in the franchise. If someone wants to play a Tales game, point them to Xillia. If someone wants to play a decent JRPG with a fantastic battle system, Graces F is your best bet. If sheer overall game quality is your goal, you want Vesperia.

If you want to utterly crush your rose-tinted glasses, play through Symphonia again.

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?