Lag, Control, and You

Talking about control isn't something that should be new to you. It's not some aspect of game design that slipped by your critical radar all these years and suddenly has been given new light. I'm sure you can still remember your thoughts when the Wii's controller was first unveiled; how impressed you were (and still are) at the SNES controller's simple, yet refined curves; how weird it was to see the Virtual Boy's double D-pad; how happy-yet-disappointed it was to see the Playstation controller evolve only under the hood - rather than on the outside - as each successive console was revealed. This is something that doesn't need to be said at all, as you should already know all of this. All of it. Still, though, I have things to say about control in relation to shmups. I'll try my best to stay on target.

First off, let's define something here: "control". Control is comprised of any and all aspects in games that allow you, the player, to interact with the game. The most prominent factors are some sort of input apparatus (e.g. a controller) and a monitor/television/Tiger Electronics LCD screen for viewing the status of a game. The factor I'm most concerned about is lag, which is no stranger to almost all other genres of games, especially fighters, racers, and FPSs.

Lag in itself means different things. We have:
1. Lag from human response time - This is how long it takes you to see something, calculate what you want to do, convert that to controller inputs, and make your body carry out those actions. This takes longer for more complex inputs (such as the infamous "The Mohawk"). 2. Lag from controller-to-console-to-monitor - This is easily the shortest lag of all, yet it tends to gain the most hatred for ever existing. This also includes the online gaming route of controller-to-console-to-server-to-console-to-monitor. 3. Lag from game-related issues - Intentional slowdown, intense calculations, etc. This technically takes place during lag #2, but it deserves its own recognition. 4. Lag from Light - The time it takes for light to reflect off the monitor, travel through space, and into your retinas. I think I'll ignore this one. And since we're all so visual nowadays, here are those same 4 kinds of lag, presented in one cohesive diagram:

Human Response Time Lag
In regards to response time, I don't have too much to say. This is the easiest lag to alleviate, though it takes the longest to achieve. The only way to make this lag go away is to keep on practicing until pressing buttons becomes second-nature. Luckily, practice in one game usually rolls over to other games, and even to other consoles. It varies from person to person. Some people are super quick at reacting, but aren't too accurate. Other people may take a few extra milliseconds to realize what's going on, but usually pull through. And of course there are people who are unfamiliar with their input device and have to look down at their hands more often than they look at the monitor.

Electronic Limitations Lag
Lag from the controller to the monitor is some kind of new-found beast in this generation. Back when we all had wired controllers and CRTs, no one even mentioned this. Now we've got Street Fighter IV vets who talk down upon wireless controllers' inferior speeds for sending input signals. There are forums dedicated to finding the right HDTV so as to minimalize the time it takes to process a composite signal into a digital format. Many HDTVs come with an option to switch to "Game Mode", which sacrifices cleaner visuals for less processing time.

As an avid fan and tournament-goer for Super Smash Bros. Melee, I can confirm for those out of the loop that pros will only play serious matches on CRTs. This is a fact across the United States and in international countries (I know you're there, Sweden, France, and Japan). Any HDTVs at a tourny are often used as the "just messin' around" TVs, the ones that are ignored during serious gameplay. Almost all players choose not to use the wireless Wavebird, despite its high review marks, to avoid any channel-switching shenanigans / battery-related tragedies. Does all of this attention to the saving of milliseconds make that much of a difference?

Yes. This is why MadCatz's billion-selling fight sticks have wires. They don't want any potential customer to doubt for a second that he or she will witness electric lag before purchasing one of these bad boys... especially when he or she will be dropping 150 big ones (i.e. dollars). Using HD cables on an HD console with a newer HDTV has become less of a problem. It's still there, but I feel technology is closing this short-lived chapter soon enough.

Intentionally Programmed / Intense Calculations Lag
When we press a button, we expect to see a result on the screen immediately (or rather, in such a quick manner that it feels instantaneous. Can't ignore physics after all.) If we press a button, wait, and then see the result appear on the screen, there had better be a good reason for it. Going back to Melee: if you try to jump, your character will first duck down and prepare for jumping, a Principle of Animation known as "anticipation". It makes the jump more believable, and only takes a few frames to accomplish. The game runs at 60 frames/second, so we're talking about a very short amount of time it takes to finally see your character leap into the air. This kind of lag is short enough to be ignored (...well maybe that's a poor example, as pros love to exploit this moment to wavedash all up and down their opponents' grills. It's hardly ignored at all and many players love to count frames to calculate how to achieve an added boost in--

Oh... right, shmups.

Intentional Lag in Shmups
The kind of input lag without immediate result that can really mess up gameplay can be found in many shmups. Let's look at Irukandji by Charlies Games. I hate to use this as an example, as I just love Charlie's other shmups to death, including the so-well-done (and 100% nsfw) Space Phallus, but I have a point to make here. The game takes place underwater. When you try to move, your ship takes a few frames to get up to speed, to simulate the water friction that would be found in such an environment. When you let go of movement inputs, the ship takes a few frames to slow down. This means if you want to move in a completely opposite direction than you currently are moving, then it takes about twice as long as usual to come to a stop, then start from rest and build that momentum back up to go the other way. The bullet patterns never get too complex to require intense weaving, and I totally understand that it's underwater and should feel like we're under water. But come on... this is a shmup.

I guess it makes little sense for a ship to be able to stop on a dime in any direction, but sometimes it's just needed. In shmups, it's almost always needed. And they're still tough as nails without any momentum lag. Plus, ya know, we have far more important things to complain about...

Here's a quick and dirty graph of the time it takes to reach full speed as compared with how much we should be tolerating it. I picked these games off the top of my head, so I can't exactly say they're accurately placed (especially since there are no numerical values for the axes). This graph is based simply off of my personal experience with them. Also note that the red bar exponentially reaches intolerability very rapidly.

Faster than Fast
It makes even less sense that most shmups allow your ship to move at full horizontal and vertical speeds when moving diagonally. The X and Y-axis movements are separate forces, so if you move diagonally, you actually end up combining their forces. Following Pythagoras, this means you'd technically be moving at ~1.414 times your normal movement speed. Ever wonder why speedrunners in FPSs move diagonally through worlds? Ever wonder why bunny hopping works so gosh darn well? Now you know.


That's all fine and dandy, but why don't more shmups force you to only move at your maximum speed? Many arena shmups impose this limitation, such as in Geometry Wars, but it's unheard of in vert and hori shmups. Why? Well, just think about it: As you wiggle through a swarm of pink death candy, you continuously hold [up] and sometimes press [right] to sneak through when an opening arises. If you could only move at maximum speed when moving in both directions, your vertical speed would slow down momentarily until you let go of [right]. This can very quickly become annoying and ultimately spell both your doom and a non-braggable NO RANK status at the leaderboard. It's cool with me to find this in arena shmups, especially when using analog sticks, since both your ship and the input device move in similar circular fashions.

Compensating for Something Small
It's possible to get used to sudden bursts and halts in speed as you weave in and out of certain death. It's possible to compensate for your ship's inability to change direction faster than in 0.2 seconds. It's possible for the mind to calculate everything happening on screen, tacking on an additional 0.2 seconds of leeway knowing that this one game was designed to feel more believable.

Back in the 56k modem days (33.3 for moi), we had to know when to let go of our sniper rifles' triggers in TFC, assuming the intended target would continue his trajectory and land under that big red spot just as the lag caught up and registered a hit. That was unnecessary skill, but we compensated. My point is, we shouldn't have to make that compensation, especially if the reasoning is because the developer(s) decided to make things not as responsive as they could have been.

True, there are plenty of instances where a little bit of intentional lag is passable, but when input-results become too delayed, the game isn't even worth getting good at. An exceptional exception is found in Mushihimesama Futari 1.5 (gazuntite) for Xbox360. The game intentionally creates gamespeed lag when too many bullets/killer insects are on screen (so as to emulate the arcade version). Your beetle-ship still responds faster than Lassie at an unsupervised well, but the whole game is slowed momentarily, allowing you to make even Neo a bit jealous.

Shameless Plug
And for those of you who were patiently waiting this whole time to make a comment about my own shmup's ship taking a little too long to move back and forth, I know. Trust me, I know. I obviously had my reasons, but I don't think they really make a difference at this point (especially after having rambled for much longer than was needed for something you already knew). If I ever make another shmup, rest assured you'll be stopping on dimes and moving at ~1.414 times your maximum speed all day.

[cross-posted from SHMUPtheory]