We all probably have a pretty good intuitive notion of what a game is. The general term “game” encompasses board games such as chess and Monopoly, card games such as poker and blackjack, casino games such as roulette and slot machines, military war games, computer games, various types of games between children, and the list goes on. In the academic world we sometimes speak of game theory, in which multiple agents select strategies and tactics to maximize their payoff within the framework of a well-defined set of rules of the game. When used in the context of console or computer-based entertainment, the word “game” generally conjures up images of a three-dimensional virtual world featuring a humanoid, animal, or vehicle as the main character under the player’s control. (Or for the old folks among us, maybe it reminds you of images from two-dimensional classics like Pong, Pac-Man, or Donkey Kong.) In his excellent book, A fun theory for game designRaph Koster defines a game as an interactive experience that provides the player with an increasingly challenging sequence of patterns that he or she learns and eventually masters. Koster’s claim is that learning and mastering activities are at the core of what we call “fun,” just as a joke becomes funny the moment we “get it” by recognizing the pattern.

Video games as soft simulations in real time

Most 2D and 3D video games are examples of what computer scientists would call real-time interactive agent-based computer simulations. Let’s break this sentence down to better understand what it means. In most video games, some subset of the real world, or an imaginary world, is mathematically modeled so that it can be manipulated by a computer. The model is an approximation and a simplification of reality (even if it is an imaginary reality), because it is clearly impractical to include all the details down to the level of atoms or quarks. Therefore, the mathematical model is a simulation of the real or imaginary world of the game. Approximation and simplification are two of the game developer’s most powerful tools. When used skillfully, even a highly simplified model can sometimes be nearly indistinguishable from the real thing, and much more fun.

An agent-based simulation is one in which several different entities known as “agents” interact. This fits very well the description of most 3D computer games, where the agents are vehicles, characters, fireballs, power points, etc. Given the agent-based nature of most games, it should come as no surprise that most games today are implemented in an object-oriented, or at least loosely object-based, programming language.

All interactive video games are temporal simulations, which means that the model of the virtual game world is dynamic: the state of the game world changes over time as the events and story of the game 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 respond to player input in real time, turning them into real-time interactive simulations.

A notable exception is the category of turn-based games such as computerized chess or non-real-time strategy games. But even these types of games usually provide the user with some sort of real-time graphical user interface.

What is a game engine?

The term “game engine” came about in the mid-1990s in reference to first-person shooter (FPS) games like id Software’s incredibly popular Doom. Doom was designed with a reasonably well-defined separation between its main software components (such as the 3D graphics rendering system, collision detection system, or audio system) and the art assets, game worlds, and game rules. game that understood the needs of the player. gaming experience The value of this separation became apparent as developers began to license games and repurpose them into new products by creating new art, world designs, weapons, characters, vehicles, and game rules with just minimal changes to the “engine” software. This marked the birth of the “mod community”, a group of individual gamers and small independent studios who created new games by modifying existing games, using free toolkits provided by the original developers. Towards the end of the 1990s, some games such as Quake III Arena and Unreal were designed with reuse and “modification” in mind. Engines became highly customizable through scripting languages ​​like id’s Quake C, and engine licenses began to be a viable secondary source of income for the developers who created them. Today game developers can license a game engine and reuse significant portions of its key software components to create games. While this practice still involves a considerable investment in custom software engineering, it can be much cheaper than developing all core engine components in-house. The line between a game and its engine is often blurred.

Some engines make a reasonably clear distinction, while others make almost no attempt to separate them. In a game, the rendering code might specifically “know” how to draw an orc. In another game, the rendering engine could provide general-purpose material and shader functions, and the “orca” could be completely defined in the data. Neither studio makes a perfectly clear separation between game and engine, which is understandable considering that the definitions of these two components often change as game design solidifies.

Arguably, a data-driven architecture is what 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 game rules, or employs special case code to represent specific types of game objects, it becomes difficult or impossible to reuse that software to make a different game. We should probably reserve the term “game engine” for software that is extensible and can be used as the basis for many different games without major modification.

Clearly, this is not a black and white distinction. We can think of a cooldown range that each engine falls into. One would think that a game engine might be something along the lines of Apple QuickTime or Microsoft Windows Media Player, a piece of general-purpose software capable of playing virtually any game content imaginable. However, this ideal has not yet been (and may never be) achieved. Most game engines are carefully designed and tuned to run a particular game on a particular hardware platform. And even the most general-purpose cross-platform engines are only suitable for creating games of a particular genre, such as first-person shooters or racing games. It’s safe to say that the more general a game engine or middleware component is, the less optimal it is for running a particular game on a particular platform.

This phenomenon occurs because designing any efficient piece of software invariably involves making trade-offs, and those trade-offs are based on assumptions about how the software will be used and/or the target hardware on which it will run. For example, a rendering engine that was designed to handle intimate indoor environments is probably not very good at rendering vast outdoor environments. The interior engine may 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 that are closer to the camera. The outer engine, on the other hand, may use a less exact occlusion mechanism, or none at all, but probably makes aggressive use of 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 that is close to the camera.

The advent of ever faster computing hardware and specialized graphics cards, along with ever more efficient rendering algorithms and data structures, is beginning to smooth out the differences between graphics engines of different genres. It is now possible to use a first-person shooter engine to create a real-time strategy game, for example. However, the tradeoff between generality and optimization still exists. A game can always be made more impressive by tuning the engine to the specific requirements and restrictions of a particular game or hardware platform.

Engine differences between genders

Game engines are usually somewhat genre-specific. An engine 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 engine. (RTS). However, there is also a great deal of overlap: all 3D games, regardless of genre, require some kind of low-level user input from the joypad, keyboard, and/or mouse, some kind of 3D mesh rendering , some kind of heads. Head 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 shooters, it has also been successfully used to build games in a number of other genres, including simulator games, such as Farming Simulator 15 (mods FS 15) and the popular third-person shooter franchise Gears of War from Epic Games and the smash hits Batman: Arkham Asylum and Batman: Arkham City from Rocksteady Studios.

Leave a Reply

Your email address will not be published. Required fields are marked *