From GPWiki
Jump to: navigation, search
GPWiki Logo 64px.png   This user is also a GPWiki forums user.

Draft Article

Part 1 - Frames of Gameplay

A Rapid Series of Images

Video games are interactive animations that work by displaying a rapid series of images generated by a computer to graphically represent the features of gameplay. You probably understand how the modern power of computation is used in video games to change the way animations play by simulating effects such as movement in unique responses to players' input. By displaying images in a rapid series with only changes that are consistent enough for viewers to perceptually interpret these changes, the technique of animation enables players to perceive dynamic behavior happening in the game. These changing images -- frames of gameplay -- are principally necessary to visually render the reactions video games should produce when players give their own input using controller devices. In fact, a low frame-rate will appear choppy only if too much change happens to be apprehended by viewers; however, video games can also render these dynamic animations to serve aesthetic purposes aside from gameplay and player-interaction alone (in the traditional sense of animation). A rate of how fast the frames of gameplay are displayed to viewers is conventionally measured by how many frames are displayed in one second of time. An ideal frame-rate is usually considered to be at least 60 frames per-second. The notion of "frames per-second" is often abbreviated as 'fps', just like how the term "miles per-hour" is abbreviated 'mph'. A poor and choppy frame-rate is usually observed below 20 fps, though this always depends on how much change occurs between every frame in corresponse to the frames' display rate. If nothing changes, your frame rate may as well be zero: a still, non-changing image doesn't require multiple frames to represent it.

Interaction, Motion and Space

This is a guy named Bit:


Our first goal is to interpret players' input to make Bit a controllable character who may move around within our game world. Imagine how this might be done by a game programmer. Game programmers write broad-level instructions that get repeated every frame to control how the "frames of gameplay" are generated by the computer. This particular routine of computer-instructions which gets repeated to continually produce each frame of gameplay is usually referred to as the 'main loop.' We will learn more about this idea soon, but for now, all you need to understand is the principle that you can repeat instructions in a procedural way to produce very complex and dynamic results, such as the interesting events of gameplay that are the basis of why some video games are fun to play. For learning practices, let's consider how to give 'Bit' the ability to move 'right' when the 'right arrow key' of a conventional keyboard is pushed.

What exactly does "move right" mean? What is the location of Bit in the first place? Where is he within our game world?

The location of things on the map of a game world can be specified using coordinates. This coordinate space can be visualized as a nice square grid; it's formally called the 'cartesian-plane'. With a procedural unit system, it is possible to continously represent more particular locations between grid squares. For example: 1 meter = 32 pixels, 1/2 meter = 32/2 = 16 pixels etc. Broadly, this includes rational numbers and so on.

Well, this is a spatial issue. We can represent Bit's precise location by using a point on the cartesian plane.


In screen space, the vertical direction of grid coordinates is downwards, rather than the conventional upwards y-axis. The positive x-axis remains to the rightwards direction.

By tradition, you may be familiar with the cartesian plane's y-axis going upwards. Contrary to this common convention, you will find that the y-axis goes downwards on computer screens and most 2D graphical systems.


To program a computer to represent this character's location within the game world, we may delve into the most widely used tool for programming games: we'll describe this spatial representation using a language of programming.

What are Programming Languages?

For now, I'll save your interest and try to avoid talking in generic terms. A very common feature of programming languages is the capacity for programmers to handle active information within a computer using labels of text (textual-identifiers) known as 'variables'. The particular language you choose to develop a game with will have its own specific rules about how variables may be named, but typically, most languages:

  • Support variables and other features in the language handled with textual-identifiers in general, to use more than one character, unlike formal mathematics (i.e. representations denoted with a single letter or symbol, like 'x', etc).
  • Do not allow spaces within textual-identifiers. Valid examples: "CheeseCake" or "cheese_cake", invalid: "Cheese cake"
  • Textual-identifiers cannot begin with numbers or contain symbols (e.g. "'!@#$%^&* ), although they may contain numbers if they aren't a starting character of the identifier. Valid example: "abc123", invalid: "123&abc"

Despite how one key convenience of programming languages is to trivialize the format (text-encodings) which programmers may code programs, these strict and often convoluted syntactical rules, such as those listed above, are an inherent consequence of this feature.

Todo: Representing points. Todo: Reacting to the right key.

if (IsKeyActive(rightArrowKey))
	characterX += characterSpeed;

It's possible to support movement in any 4 of the arrow keys' directions, like this:

if (IsKeyActive(rightArrowKey))
	characterX += characterSpeed;
if (IsKeyActive(downArrowKey))
	characterY += characterSpeed;
if (IsKeyActive(leftArrowKey))
	characterX -= characterSpeed;
if (IsKeyActive(upArrowKey))
	characterY -= characterSpeed;

Pay attention to which arrow key causes what. To help you sort things out and understand what's happening here, have another look at the

The Main Loop and Time

The notion of the main loop is regarded as the broadest section of a game's program which, in generalization, is a category that envelops any instructions which are repeated frame-by-frame to procedurally produce the actions of gameplay. Todo: How to construct a main loop and regulate its frame rate etc.

Advanced Information and Related Pages

The Viewport and Graphical Composition

Instances and Transformation

Animation Techniques

The Crux of Input

Game State; a Summary and in-depth Topic Overview

(though they were not covered above, include networking and management; beyond scope)


  • State Management
    • Top-down State Control (Active-State Manager) e.g. Switching from the main menu to a specific mode of the game, loading new resources, initializing various components etc.

Part 2 - Exploring Game Features, Content and Behavior