The Game Loop

CS 4730 - Computer Game Design

​

​

CS 4730

Event-Driven Programming

• Consider all the programs you’ve written up to this point
• Did they do anything when the user didn’t ask for something?
• Was there processing in the background?
• Or did it mainly respond to user input?

CS 4730

Event-Driven Programming

• The event-driven paradigm works great for a lot of systems
• Desktop apps (i.e. you type something, press a button, and the program does something)
• Mobile (i.e. you tap on the screen and it responds)
• Web (... kinda… as long as you are thinking asynchronously)
• But is this what we want for games?
• Well… maybe if we were only programming board games…

​

CS 4730

Event-Driven Games

• Consider board games
• They are, in fact, event-driven in many cases
• There are some things that happen “behind the scenes”
• Updating tallies
• Shuffling the deck
• Deciding the moves of the “bad guys”
• But not all games are like this

CS 4730

How are video games structured?

• It’s easier to see that a platformer is not terribly “event-driven”
• Yes, there are “events”
• Player presses a button, triggering an action
• Player character collides with another entity
• A timer ticks down, ending the game
• But all of these things are in constant motion
• Even a “static” board game experience has things going on
• Animation, for example

CS 4730

The Game Loop

• Video games are structured around the concept of a game loop
• In broad strokes, for every frame of animation on the screen the game must:
• Update the game state
• Display that game state to the screen

CS 4730

The Game Loop

​

​

​

​

​

​

​

​

​

Credit: Walker White

CS 4730

The Game State

• The game state is comprised of the current values of all variables for all objects in the game world at that precise moment
• It is a “snapshot” of the game
• The game state is CONSTANTLY changing
• A game is like a flip book

CS 4730

Flip Book / Game State

• Each picture is one�snapshot of the game�state
• Each is one frame of�animation
• A flip of a page is an�update to the world, then�a display

CS 4730

The Game Loop

• Thus, the idea is that to do a video game, the game engine is in a perpetual loop of
• Update - getting all input from the user, making calculations based on rules/procedures/actions, changing all the values in the world that need to change
• Draw - take this new game state and put it up on the screen
• Then do it all again

CS 4730

Step 1: Player Input

• Remember: player input is one set of variables that enter our equation to affect game state
• Input is typically polled during game loop
• What is the state of the controller?
• If no change, do no actions
• However, we can only read input once per game loop cycle
• But good frame rate is short and most events are longer than one frame

CS 4730

Step 2: Process Actions

• Remember you are working in fractions of a second
• At this split second, what do you need to do?
• Consider: Pressing A to Jump
• Is this the first frame in which the jump button is being pressed?
• Is the PC standing on something that allows for a jump?
• Is the PC in mid-air and another jump is allowed?
• Is a jump “reverse gravity” or a static value that doesn’t change?
• Is this a subsequent frame in which jump is still being held down and does that matter?

CS 4730

Step 2: Process Actions

• Does the action create an interaction?
• Is there a collision with an object (i.e. wall, floor, etc.)?
• Is there a collision with a resource?
• Is there a collision with an NPC?
• Did you create a new object with the action (i.e. projectile)?
• These interactions are added to the current game state

CS 4730

Step 3: Process NPCs

• An NPC (Non-Player Character) is anything that has volition in the world that isn’t you
• NPCs take input from the AI engine (maybe!) but not from a direct controller
• Work on the idea of Sense-Plan-Act:
• Sense the state of the world around it (how can we “cheat” here to make an NPC “harder”?)
• Plan what action to perform (usually limited choices)
• Act in the world

CS 4730

Step 3: Process NPCs

• Did any interactions just occur?
• How does the NPC respond to any PC behavior (if possible)?
• Sense: What can the NPC “see”? Does it have perfect knowledge?
• Plan: How “smart” is the NPC? Is there a limited action set?
• Act: The computer can move things “perfectly.” Is that what we want?
• More in AI!

CS 4730

Step 4: Process the World

• Physics!
• Lighting!
• Networking!
• And more!

CS 4730

Step 5: Prepare to Draw

• You only want to draw what is actually on screen
• Drawing things off screen takes up WAY too much processing for the time frame you have to work with
• Decide how the player is viewing things (angle, depth, etc.)

CS 4730

Step 6: Pre-draw to Buffer

• Video cards / drivers have robust buffering
• Draw all the pixels of the frame to a temporary buffer
• When the buffer is full / ready, swap it with the current frame on screen
• This reduces “screen tearing” as much as possible
• Screen tearing can occur with information from two (or more) frames gets intermingled

CS 4730

Step 7: Swap Buffer to Screen

• This step (and the previous) is rarely done by a game designer with a modern game engine
• Engines such as Unity manage almost all of this for you
• Some engines (such as MonoGame) will ask the programmer to use the painter’s algorithm to properly layer the screen the way they want

CS 4730

High-Level Game Architecture

​

​

​

​

​

​

​

​

​

Credit: Walker White

CS 4730