Sit your ass down. Don’t think of going anywhere because we have got some subject matter to discuss, you and I! That’s right, we’re going to talk about how things work, and not things like lasers or claymore mines. HELL NO! We’re talking movement, chummy boy, something you know about a little too well, no doubt. Before we get into it properly, you gotta know a few things about some things, ya hear!? I need to get it into your head just what it takes to make all those Cara Lofts and Drathan Nakes spin in circles like ballerinas on fire.

Almost every video game is somehow linked to movement, but achieving motion is no small task. You can’t just tell a pixel to do the tango, but here we are, pixels waltzing in FF15 and Overwatch alike. The magic behind the scenes is as fascinating as it is frustrating, and the technical problems presented by creating motion can provide opportunities for devs to experiment. Mind you, this entire article is just to fill you in on how we achieve movement in the first place, so, prepare for some wordy words.
 

FAIR WARNING, WE’RE GOING TO GET TECHNICAL.
NO, SERIOUSLY, IT’S GOING TO GET WORDY.

 

Not this wordy, but wordy. Like a ghoti.

 

The First Steps


 

Inside every computer and every console are some common parts. You’ve got your RAM, your PSU and a whole bunch of other bits we don’t care about to allow two parts to operate correctly. The Central Processing Unit (CPU) is like the brain of your gaming rig, telling everything else what they need to do to and when to get it done so you get the results you want. The Graphics Processing Unit (GPU) is the powerhouse of your machine, and it’s job is to do very little other than image processing and output. The GPU is plugged into a monitor or TV and sends whatever it’s outputting straight to the screen you’re looking at, but this doesn’t happen continuously.

Because computer scientists aren’t afraid of blowing people’s minds, GPUs update whatever data they’re holding onto in batches. These batches, otherwise known as frames, are sent to the monitor when it asks to get them, not when the GPU says it’s time. If the GPU makes a new frame halfway through outputting to the monitor, screen tearing will occur and you won’t be getting a one-to-one picture of what’s happening. Worse still, the frame is made after taking into account all of the necessary factors, including your input, so your button mashing might not register in time to make it into the next output. The takeaway is that the image on the screen isn’t updating continuously, and the consequences give us a few issues but kinda work out for us.

 

Pictured: The part of your computer that never updates fast enough.

The bonus of outputting things in frames is that humans are capable of seeing motion in strange places. If we output similar looking frames fast enough (which we can most certainly do!), the images blend together in our minds to create the illusion of motion. Given a high enough Frames Per Second (FPS), of which 30 not enough by any stretch of the imagination, we can make smooth motions and convincing natural movement. This also dictates the timing of all actions that happen in the game, since the rate at which the game updates will influence how fast you can input your commands. “Why the hell would we do this, though?” I hear you whine, still unhappy at the literal miracles science has gifted unto you like a generous step-mimic. Well, there are other damn good reasons why things are the way they are.

 

But… Why?


 

The big reason why we don’t just continuously update everything is because of the digital nature of these machines. Every bit of information is either a 0 or a 1, and while we could move away from transistors, I’d rather not have a thermionic valve heated CPU. We also don’t have the luxury of infinite memory and lack the processing power to rival Deep Thought, so we have to make do with temporary buffers. Think of image processing like a fridge. You can’t put infinite food in the fridge, nor can you immediately put as much food as you want in the fridge, so you have to do it in batches. Mind you, once you sort yourself out with a fridge that can hold enough pizza to feed a village of 800, you have to deal with how game design works.

 

States, man.

Hardware limitations are a large part for why we render motion frame-by-frame, but we also do this for theoretical reasons. Video games are more like traffic lights than clocks in that they are almost always state-based. If the player presses a button, the character is set into a state of ‘moving’, an animation plays, sounds play in the background and the game updates accordingly with each new frame. Updating these states frame by frame is a lot easier than trying to perfectly react to every input. These states can be extremely tightly packed, even indistinguishable to the human eye, but make no mistake, games are just collections of states. Besides, if you can’t tell that you’re running through a series of constantly updating states, who cares?

If movement already works and feels fine, then hey, that means the devs got what they need. This will sound as blissfully ignorant as someone who doesn’t believe in fridges (like an old lecturer I had), but we can always just up the FPS count to make everything work better. If something is smooth enough to pass off as organic movement, chances are that no one except the animators in the room will care much beyond that. So, it won’t matter that we don’t mimic life 100% correctly, because we get it right enough anyway, but there are some consequences which hinge on this batched updating.

 

Screen tearing is a consequence, but is it really that bad?
… Of course it is.

 

Lagging Behind


 

Let’s assume your console or PC runs at 60 FPS, which means there’s a ~17ms window between each frame. There will come a point – perhaps at the 12ms mark – that the game will have to stop taking input information to start doing calculations for the next frame. Any input you give after those 12ms won’t appear in the next frame but in the frame after. Yes… Input lag… I’d rather drink the dusty remains of my sons’ ashes before accepting the perils of input lag, but I neither have a son nor control over how developers code their games. Responsiveness can be a huge issue when your game starts to chug below 60FPS, which can make running and jumping almost impossible, but it’s even worse with Vsync on.

So, we’ve seen what happens at 60FPS, but what happens if you can’t afford a 1080GTX and can only run at 40FPS? That’s a 25ms delay between frames, which is longer than you might expect, but you’re a real masochist and decide to turn Vsync on. Vertical Synchronisation (Vsync) stops the GPU from outputting anything until after the monitor finishes its current refresh cycle. Thing is, if you can’t meet 60fps for your 120Hz monitor, you can’t just ask the monitor to change it’s refresh rate to 80Hz. No, the monitor will have to adapt the output to every second run, and then we start getting some gnarly problems.

 

Two frames too late

If the GPU starts outputting just under every second run of that 120Hz, the closest it’ll get is 60Hz. Realistically, you’re looking at 30FPS and a ~33ms window between frames. To give you an idea of how bad that is, grab a stopwatch and double tap it. Chances are, you’re able to push the button in and out within 15ms. Now your input won’t register for another 15. The problem here is that jagged movement is not only unresponsive, it’s confusing to the player whether their actions will go through this time round. Just imagine trying to aim properly when your crosshair overcompensates your motion just enough to overshoot the target. After all, you didn’t have any new input until the next frame, right?

Because we’re subdividing motion into frames, quirks are bound to emerge, but they’re not all bad. Hitboxes are an interesting concept to think about; They must occupy a set space in a frame, and that frame has a particular number of pixels associated with it. As you move from state to state, your position isn’t just well defined, it’s downright malleable. You can change hitboxes on a frame-by-frame basis, and many fighting games do, but you don’t need to do it in the expected way. This also makes movement a lot more interesting than a one-to-one mapping that follows the player model, but there’s so much more to say. Until part 2, I guess…

 

Next time, we find out why this little dude is more interesting than Lara Croft.
Little troublemaker. Look at his little scything claws! Adorable.

 

Final Thoughts… For Now


 

Creating movement in games is as complicated as it is counter-intuitive. It’s easy enough to say motion is analogous to films, but when you think of the ramifications this approach has, it can seem very strange indeed. The limitations of digital hardware also presents a unique opportunity to experiment with the quirks rendering each frame provides. Mind you, when you consider just how unnatural it is to achieve fluid motion in video games, it almost seems like a blessing in disguise. Well, apart from the input lag. Eugh. I’m gagging at the thought… Input laAUGH… Disgusting.

Nick Ballantyne

Nick Ballantyne

Managing Editor at GameCloud
Nick lives in that part of Perth where there's nothing to do. You know, that barren hilly area with no identifying features and no internet? Yeah, that part. To compensate, he plays games, writes chiptunes, makes videos, and pokes fun at hentai because he can't take anything seriously.