Combat timing continuum

There is a continuum of combat timing measured by the time allotted to perform the actions you need to perform to play the game

On one end of the scale, there is the "twitch" type. This required instant response and target tracking, the flight simulator is a good example. On the other end of the spectrum, you have pure turn based play, where your time allotted to select your move can be as long as you want. Usually, though, you have a time limit where you forfeit your turn if you don't make one.

Neither of these system are really effective in MMORPG style games. Twitch combat is too fast for the client-server interface to handle, and pure turn based is too slow. Imagine having to wait for everyone in your raid to choose an action. At least ONE person would always be in the bathroom, getting a soda, on the phone, etc. It would be excruciating. It would be like doing a ready check for every spell cast. Twitch is fine for a client only game, and turn based is fine for solo battles against NPCs.

What we have left is a combo. You select an action, then that action forces a delay before or after the action is executed. Even that has a continuum:

On the fast side, you make the delays as short as possible (Or have ways to shorten them to create a burst in the activity rate.) but you still have them slow enough to allow the client-server interface to keep up. This system works best if you have abilities that are synergistic with each other and/or can be best used in a rotation, you then learn the rotation and use “muscle memory” to synchronize your button pushing with the cadence of the battle.

On the slow side, you have abilities with longer delays, but less determinism in the subsequent actions. You're expected to “read your opponent' and select the ability that will best counter whatever they are doing. This is more of a strategic system.

You can even change the dynamics of the delay. The delay can be before the ability is used, like the cast timer for a spell, after the ability is used, which makes it like a turn based system with a very short “default action” timer, or as a cooldown for just that ability, providing instant use of the ability followed by a delay before the ability can be used again, but other abilities can be used in the interim.

So, what is this “client-server interface”? That's what we think of as “lag.” It's the latency between what you do and what you see. The brain operates at about 18 Hz, meaning it fully changes it's state about every 55 milliseconds. The visual cortex is a bit quicker, with pattern recognition down to about 13 milliseconds, but that still needs to be servoed to the hands, so I'm sticking with 55 milliseconds. There is another concept called the “Nyquist frequency.” In a nutshell, the Nyquist frequency is twice the data sample rate of the receiving system (In this case, your brain, at 18 Hz.) To put in in English, “Your input data has to be twice as fast as you can process the information to eliminate most sampling errors.” Go ahead and google all of that to wrap your brain around it. I'll wait.

The bottom line is, to support a game that is max twitch to present state changes to your computer, (And as a result, your eyes and brain.) that client-server interface has to run at 25 ms latency or less. I don't care who you are, or where you live, you are NOT getting 25 ms of latency. 50 perhaps... minimum. Unless of course, you're in the same building as the server, directly connected to it by a high speed interface. Hmm. When people are initially developing a game, guess where they are?

In addition to using abilities, there is also movement. Movement follows the same rules as abilities, except that there is never a delay. It would be absurd to artificially insert a delay when you press an arrow key to move. Of course, there IS a delay, it's the latency. But that's between what you see and what actually happens. Step back and think about that if you need to. I'll wait. When you combine forced movement AND combat timing that approaches the minimum client-server interface time, you exacerbate the problem even more in that you increase the statistical possibility even more of the game client presenting a movement/action cue too late for the player to respond to it. You have “violated the Nyquist rule.”

Here's the problem: Online games that tune their combat systems to be “most exciting” at close to the edge of the client-server interface in an effort to provide a more “twitch” feel for the game are playing a very dangerous game. Sure, it's AWESOME FUN when tested with the server in the next room, but once you start the release cycle, not so much. People with really fast connections have a distinct advantage, and people with really slow connections have a distinct disadvantage. The fast connection people suddenly find they have no one to play with.

Online game developers need to step that knob back from 11 and start thinking “strategy” instead of “twitch.” Sometimes? There is just too big a gap between what you “want” and what you can really do.