What Is a Game?

We probably all have a pretty good intuitive notion of what a game is. The general term “game” encompasses board games like chess and Monopoly, card games like poker and blackjack, casino games like roulette and slot machines, military war games, computer games, various kinds of play among children, etc.

In academia, we sometimes speak of game theory. Multiple agents select strategies and tactics to maximize their gains within a well-defined set of game rules. In the context of console or computer-based entertainment, “game” usually conjures images of a three-dimensional virtual world featuring a humanoid, animal, or vehicle as the main character under player control. (Or for the old geezers among us, perhaps it brings to mind images of two-dimensional classics like Pong, Pac-Man, or Donkey Kong.)

In his excellent book, A Theory of Fun for Game Design, Raph Koster defines a game as an interactive experience that provides players with an increasingly challenging sequence of patterns that they learn and eventually master. Koster asserts that the activities of learning and mastering are at the heart of what we call “fun,” just as a joke becomes funny the moment we “get it” by recognizing the pattern.

Summary show

Video Games as Soft Real-Time Simulations

Most two- and three-dimensional video games are examples of what computer scientists call soft, real-time, interactive agent-based computer simulations. Let’s break this phrase down to understand better what it means. In most video games, some subset of the real or imaginary world is modeled mathematically so that a computer can manipulate it. The model approximates and simplifies reality (even if it’s fictional) because it is impractical to include every detail down to the level of atoms or quarks.

Hence, the mathematical model simulates the real or imagined game world. Approximation and simplification are two of the game developer’s most powerful tools. When used skillfully, even a greatly simplified model can sometimes be almost indistinguishable from reality and much more fun. For example, an agent-based simulation is one in which several distinct entities known as “agents” interact.

This fits the description of most three-dimensional computer games very well, where the agents are vehicles, characters, fireballs, power dots, and so on. Given the agent-based nature of most games, it should be no surprise that most games nowadays are implemented in an object-oriented, or at least loosely object-based, programming language. All interactive video games are temporal simulations, meaning the virtual game world model is dynamic. The state of the game world changes over time as the game’s events and story unfold.

A video game must also respond to unpredictable inputs from its human player(s)-thus interactive temporal simulations. Finally, most video games present their stories and react to player input in real-time, making them interactive real-time simulations. One notable exception is in the category of turn-based games like computerized chess or non-real-time strategy games. But even these games usually provide the user with a real-time graphical user interface.

What Is a Game Engine?

The term “game engine” arose in the mid-1990s about the first-person shooter (FPS) games like the extremely popular Doom by id Software. Doom was architected with a reasonably well-defined separation between its core software components (such as the three-dimensional graphics rendering system, the collision detection system, or the audio system) and the art assets, game worlds, and rules of play that comprised the player’s gaming experience. The value of this separation became evident as developers began licensing games and retooling them into new products by creating contemporary art, world layouts, weapons, characters, vehicles, and game rules with minimal changes to the “engine” software.

This marked the birth of the “mod community, “a group of individual gamers and small independent studios that built new games by modifying existing games using free toolkits provided by the original developers. Towards the end of the 1990s, games like Quake III Arena and Unreal were designed with reuse and “modding” in mind. Engines were made highly customizable via scripting languages like IDid’s Quake C, and engine licensing became a secondary revenue stream for the developers who created them.

Today, game developers can license a game engine and reuse significant portions of its key software components to build games. While this practice involves considerable investment in custom software engineering, it can be much more economical than in-house developing all core engine components. Unfortunately, the line between a game and its engine is often blurry. Some engines make a reasonably clear distinction, while others make almost no attempt to separate the two.

In one game, the rendering code might “know” specifically how to draw an orc. In another game, the rendering engine might provide general-purpose material and shading facilities, and “orc-ness” might be defined entirely in data. No studio makes a clear separation between the game and the engine, which is understandable, considering that the definitions of these two components often shift as the game’s design solidifies.

Arguably, a data-driven architecture differentiates a game engine from a piece of software that is a game but not an engine. When a game contains hard-coded logic or rules or employs special-case code to render specific game objects, it becomes difficult or impossible to reuse that software to make a different game. Thus, we should probably reserve the term “game engine” for extensible software that can be used as the foundation for many other games without major modification. This is not a black-and-white distinction.

We can think of a gamut of reusability onto which every engine falls. One would think that a game engine could be something akin to Apple QuickTime or Microsoft Windows Media Player- a general-purpose piece of software capable of playing virtually any game content imaginable. However, this ideal has not yet been achieved (and may never be). Most game engines are carefully crafted and fine-tuned to run a particular game on a specific hardware platform. And even the most general-purpose multiplatform engines are only suitable for building games in a particular genre, such as first-person shooters or racing games.

It’s safe to say that the more general-purpose a game engine or middleware component is, the less optimal it is for running a particular game on a specific platform. This phenomenon occurs because designing any efficient piece of software invariably entails making trade-offs. Those trade-offs are based on assumptions about the software’s use and the target hardware on which it will run. For example, a rendering engine designed to handle intimate indoor environments won’t be very good at rendering vast outdoor environments.

The indoor engine might use a binary space partitioning (BSP) tree or portal system to ensure that no geometry is drawn that is being occluded by walls or objects closer to the camera. On the other hand, the outdoor engine might use a less-exact occlusion mechanism or none at all. Still, it probably aggressively uses level-of-detail (LOD) techniques to ensure that distant objects are rendered with a minimum number of triangles while using high-resolution triangle meshes for geometry close to the camera. The advent of ever-faster computer hardware and specialized graphics cards, along with ever-more-efficient rendering algorithms and data structures, is beginning to soften the differences between the graphics engines of different genres. For example, it is now possible to use a first-person shooter engine to build a real-time strategy game. However, the trade-off between generality and optimality still exists. A game can always be made more impressive by fine-tuning the engine to the specific requirements and constraints of a particular game and hardware platform.

Engine Differences Across Genres

Game engines are typically somewhat genre-specific. For example, a machine designed for a two-person fighting game in a boxing ring will be very different from a massively multiplayer online game (MMOG) engine a first-person shooter (FPS) engine, or a real-time strategy (RTS) engine. However, there is also a great deal of overlap-all 3D games, regardless of genre, require some form of low-level user input from the joypad, keyboard, and mouse, some form of 3D mesh rendering, some form of heads-up display (HUD) including text rendering in a variety of fonts, a powerful audio system, and the list goes on.

So while the Unreal Engine, for example, was designed for first-person shooter games, it has been used successfully to construct games in several other genres as well, including simulator games, like Farming Simulator 15 ( FS 15 mods ) and the wildly popular third-person shooter franchise Gears of War by Epic Games and the smash hits Batman: Arkham Asylum and Batman: Arkham City by Rocksteady Studios.