Dart

Dart is an object-oriented programming language designed to be familiar to programmers coming from object-oriented languages like Java or C#. The Dart language is stricter than JavaScript and, in turn, programs written in Dart can run significantly faster than programs written in JavaScript. An example of Dart is shown in Listing 20-1.

Listing 20-1. An Example of Dart

main() {                              // This is where the app starts executing.
  print(new Fibonacci(10));           // Print a new object's value.
}
 
class Fibonacci {                     // Define a class.
  int original, fibo;                 // Declare variables with (optional) types.
  String toString() => ‘$fibo’;       // Define a method using shorthand syntax.
 
  Fibonacci(int value) :              // Define a constructor with list initializer.
    original = value, fibo = fib(value) {
  }
 
  static int fib(int n) {             // Define a class method.
    if (n < 2) {                      // Control flow and expressions.
      return n;
    } else {
      return fib(n-1) + fib(n-2);     // Arithmetic operators.
    }
  }
}
// Want terser code? Write a one-line function instead:
// fib(n) => n < 2 ? n : (fib(n - 1) + fib(n - 2));

Dart provides a familiar but modern syntax. Contrary to JavaScript, Dart has first-class support for classes and allows for (optional) type annotations, which are used only during development to catch programmer errors early.

game_loop

The sample code provided in this chapter is part of the game_loop package available via Dart’s package management tool, pub. If you decide to write your next game in Dart, you can use the code directly. However, if you decide to use a different language, it should be trivial to port the code from Dart to your language of choice.

The easiest way to get game_loop is to add it as a dependency in your project’s pubspec.yaml. You can always find the source code for the latest version of game_loop in its GitHub repository at http://github.com/johnmccutchan/game_loop.

Inputs

This section covers the inputs that your main loop will receive from the browser. This includes user input as well as the display synchronization event and time.

Outputs

This section covers the outputs from your main loop. This includes unseen internal game states as well as audio and video output.

Fixed Time Step

The first step is to lock the time delta used to update your game state. This means no matter how much time has elapsed between frame callbacks, the game state is updated as if a fixed amount of time has elapsed, like so:

// Update game.
const fixedDt = 16.0;  // milliseconds
update(gameTime, fixedDt);
gameTime += fixedDt;

The above code snippet is sufficient to get deterministic game update behavior but suffers from another problem: it leaks time. Consider the case when 18 milliseconds elapses between frame callbacks but you only move the game forward by 16 milliseconds. You’ve lost 2 milliseconds. Not much time, but the game will lose around 3.6 seconds per minute. It adds up.

// Compute delta time.
var dt = time - lastTime;
lastTime = time;
accumulatedDt += dt;
const fixedDt = 16.0;  // milliseconds
while (accumulatedDt >= fixedDt) {
  // Update game.
  update(gameTime, fixedDt);
  accumulatedDt -= fixedDt;
  gameTime += fixedDt;
}

// Compute delta time.
var dt = time - lastTime;
lastTime = time;
accumulatedDt += dt;
const fixedDt = 16.0;  // milliseconds
if (accumulatedDt > 2.0 * fixedDt) {
  // Lose time.
  accumulatedDt = 2.0 * fixedDt;
}
while (accumulatedDt >= fixedDt) {
  // Update game.
  update(gameTime, fixedDt);
  accumulatedDt -= fixedDt;
  gameTime += fixedDt;
}

User Input

The browser delivers each input event with a separate callback invocation. The callback invocations transition execution from C++ code in the browser to your script code and then back. As quickly as possible the script code should add the input event to a queue of events and exit. Processing the queued input events is done in the frame callback synchronized with the game state update.

Detecting and classifying user input is done on the queue of input events and is game-specific. For example, a first person shooter game needs to know if the W, A, S, or D keys are down and how much the mouse has moved since the last frame. The main loop is only responsible for providing the buffer of input events to the game.

Timers

The internal game clock (gameTime) is managed by the main loop. Any in-game timers, such as the timer tracking the door that stays unlocked for two seconds after the player steps from a pressure plate, must be kept in sync with the game clock. If the in-game timers used a different clock than the game update, the timers would not fire when expected. You can solve this by moving the timer time forward inside the main loop, like so:

// Compute delta time.
var dt = time - lastTime;
lastTime = time;
accumulatedDt += dt;
const fixedDt = 16.0;  // milliseconds
if (accumulatedDt > 2.0 * fixedDt) {
  // Lose time.
  accumulatedDt = 2.0 * fixedDt;
}
while (accumulatedDt >= fixedDt) {
  // fire timers.
  fireTimers(gameTime, fixedDt);
  // Update game.
  update(gameTime, fixedDt);
  accumulatedDt -= fixedDt;
  gameTime += fixedDt;
}

Include support for both periodic (repeating) and single shot timers as well as support for cancelling timers.

Rendering

The final task of the main loop is to trigger rendering of the game. Rendering is always done in the frame callback, which is synchronized with the browser’s own rendering pipeline.

renderTransform(frame, x) = transform(state[1]) * (x) + transform(state[0]) * (1.0 - x);

renderTransform(frame, x) = transform(state) + integrate(velocity(state), x);

Digital Input

Digital inputs are either on or off. Keys, mouse buttons, digital gamepad buttons are either up or down. Digital inputs have the following properties:

• Digital input id (key code, button id, and so on)
• Last time pressed
• Last time released

Detecting if a digital button is up or down can be implemented by the following code:

bool get down => lastTimePressed >= lastTimeReleased;
bool get up => lastTimeReleased < lastTimePressed;

Analog Input

Analog inputs have a value inside a limited range (e.g., -1.0 to 1.0 or 0.0 to 1.0). Analog sticks and buttons on gamepads are examples of analog inputs. Analog inputs have the following properties:

• Analog input id (key code, button id, and so on)
• Last time updated
• Value

Users of analog inputs may want to consider applying a dead zone filter to the value. Dead zone filters cancel small movements in the analog value by mapping the value back to 0.0. This helps the input feel less twitchy.

Positional Input

Positional inputs are positions in a 2D coordinate system. Mouse cursor and finger positions are examples of positional inputs. Positional inputs have the following properties:

• Positional input id (mouse id, touch id)
• X position
• Y position
• Delta x position
• Delta y position
• Time

In each frame there may be many positional input values for a specific device. A first person shooter may accumulate the delta x and delta y position values for the entire frame and use the aggregate to adjust the view angle of the player. A touch-based game may move a kinematic object through the scene based on the input values.

Game-Specific Code

Mapping from raw input values to game-specific input values allows game controller code to be reconfigured by the player. The player can decide which button or combination of buttons is used for the jump action (see Figure 20-2). Game-specific inputs are modeled using the same three generalized input types mentioned above, but the state of these virtual inputs have values set by game-specific code.

Chords

Chords are another virtualized input type. A chord is active when multiple event states occur simultaneously, such as when the analog stick is held up and the A button is pressed (see Figure 20-3). A chord may or may not be triggerable when other buttons are pressed. Chords can be detected by tracking the state of the individual inputs involved in the chord over time and checking if the chord is active after each input event.

Sequences

Sequences are active when multiple event states occur in a specific order and within a certain amount of time. A famous example is the Konami code: UP, UP, DOWN, DOWN, LEFT, RIGHT, LEFT, RIGHT, A, B, A, B, START. A directed graph state machine can model sequences. The sequence starts off in the READY state, and as each input event is processed, the sequence can move forward to the next state or back to the READY state if an invalid input is encountered (see Figure 20-4).