Experienced PointsGame Responsiveness is More Than Just Good Frame RateExperienced Points - RSS 2.0
People are still talking about framerates and resolutions, and which of the new-gen games support 960p and which ones have successfully made the jump to 1080p. The idea is that games with a higher framerate are "more responsive". That's true, although if you're really worried about having a game feel responsive, framerate might be the least of your worries.
Game development has become radically complex. So complex that no single human being knows how the entire system works. A modern console is the work of dozens of specialists, each with their own domain: The console controller, the device itself, the operating system, the game engine, the rendering engine, the rendering hardware, and the monitor. Each of those systems is designed to be as "black box" as possible. The idea is that if you're working on the rendering engine, you want to be able to focus on this one job and not sweat the details of what the operating system or or monitor is doing.
In the old days -- and I mean the really old days -- the whole system was much simpler. If you used an Atari 2600 controller, then you nearly had a direct line to the processor. If you tore one apart, you would see that each input was a simple circuit. By pushing left, your physical pressure on the stick completed an electrical connection that flowed right into the device, and the game programmer wrote machine code that would test to see if that circuit was open or closed. In programmer talk people call this coding "direct to the metal".
But as the industry grew and the complexity of our gaming devices increased, we needed more layers of abstraction between the disparate systems. Each layer is another task that needs to be performed between the moment you push a button and the instant you see the results onscreen. Let's look at the journey:
Let's assume you're using some sort of wireless setup, since that's probably the most common. You waggle the Wiimote, push the Xbox A button, or smack your thumb on the spacebar to create some input. The device encodes this new state into a packet and broadcasts it according to whatever protocol it's using. (Which is very likely Bluetooth.) The wireless receiver catches the packet, unpacks it, figures out what device it's from, and hands the data off to the device driver.
The device driver takes the data and turns it back into some sort of useful input, figuring out which buttons are down, which ones are up, and so on. Then it hands that off to the operating system. The OS needs to have a look at it just in case you've done something that requires its attention. For example, if you've hit the Xbox guide button (the big green glowing X in the middle) or the Windows key, then it needs to take some sort of drastic action. Assuming none of that is going on, the OS will pass along the input data to the game.
The game itself very likely has another layer of abstraction inside of it, and perhaps even more than one. Engines like Unreal or Unity tend to have an indirect way of asking for input that lets game developers use (roughly) the same code for Xbox, PlayStation, PC, and so on. So these button inputs get translated into some intermediate stage that maps "A button" to "jump", or whatever. At this point the game engine is finally aware of your action and is able to respond. Congratulations! We're (conceptually) halfway there!
There might be a bit of delay inherent to the game itself. When you hit the jump button in a modern platformer like Uncharted or Tomb Raider, the game sort of makes a note to begin the jumping animation the next time the current run animation comes around to the point where the game can blend from the "run" animation to the "leap" animation. Other actions (such as shooting) ought to be more direct, although I wouldn't be surprised to learn that there was a tiny bit of animation fudging when you pull the trigger, too.