Time for action – from input to output in slow motion

Each game world has certain properties: the level, the score, players and enemies, position and speed of objects and characters, inventories and skills, maybe a countdown timer, and so on. These properties together are the game state.

Each game world also offers some actions: the player can decide to walk, jump, drive, fight, use equipment, take or drop items, change game options, and so on. There are also events that happen without user input: traps are reset, power-ups respawn, automatic doors open or close, and so on. We call these incidents game actions. Game actions are triggered either by the player (in response to input), or by NPCs and objects, as part of the main loop.

Let's zoom in on one day in the life of the average event-driven video game:

  1. The player's input triggers a game action. For example, the user clicks to attack an enemy, the user presses the W, A, S, and D keys to walk, and so on.
  2. The game action updates the game state. For example: a successful attack decreases the enemy's health, walking changes the player's location, pushing a ball increases its momentum, and so on.
  3. The update loop polls the game state. For example: what are the current locations of characters relative to any traps? What is the location and momentum of the rolling ball?
  4. The update loop performs tests and decides which game action it should trigger. For example: if the enemy's health is zero, it dies and the player gets points; if the player is close, the trap goes off; as long as there are no obstacles, the ball keeps rolling, and so on.
  5. The game action updates the game state. For example: the dead character is removed from the scene and the player's score increases, the trap inflicts damage on the player, the location and momentum of the rolling ball have changed a bit, and so on.
  6. The game outputs the new game state. The output includes audio and video that communicate the updated game state to the player. For example: the scene is rendered in 3D and displayed on the user's screen, sounds and animations play, the score display is updated, and so on.
  7. The player watches the new game state.

The listen-update-render loop continues running even if there is no player input—this means steps 1 and 2 are optional. The driving force is the main event loop, not the player.

What just happened?

The listen-update-render loop is the heartbeat of your game and brings action and interaction to an otherwise static scene. You understand that game actions update the game state.

The whole event loop is made up of familiar pieces: for the Listen step, you use Java event handling. You represent the game state as Java objects, and implement game actions as Java methods. In the update loop, you work with standard conditionals, timers, and randomizers, to advance the game by rules that you specify. The loop is the mastermind that pulls strings in the background for you.

As an example, let's implement a simple game action that changes the game state.

上一章目录下一章