A game engine is software which make up a video game.^[1] There are many software frameworks available to aid in game development. A framework is software which has been partially constructed and can be completed by adding the missing functionality. Many frameworks are marketed as game engines, they make game development a lot easier, and have become synonymous with the term game engine. Some of the most sought after features are sound playback, scripting, artificial intelligence, networking, multi-threading libraries, localization tools, advanced computer graphics, collision detection and response system, and the ability to make games for multiple platforms, ideally enabling the possibility to develop and test the game on a PC and then quickly deploy it on a console, tablet or mobile phone.

The term game engine was popularized in the mid-90s with the advent of the Doom series of games by id Software. Doom had a reasonably clear distinction between assets and core simulation components, which made it easy to reuse the code and simply change the data (assets) to create sequels and brand new titles based on the same technology.^[2]

As time went on, software components were designed to became more generalized and reusable across many games. Game studios, such as Epic Games and id Software, could create new titles cheaply, and licensing out the game engine became a viable second-stream of revenue.^[3]

Today, there are companies that focus specifically on creating commercial game engines and game development tools, such as Unity Technologies.

The line between a game and its engine is often blurry, Jason Gregory in his book Game engine architecture argues game engines are data-driven, while software with hard-coded logic, or specialized code for each game object may still be a game, but is not a game engine.^[4] Video game developers will create data, often called assets or media, the build system will invoke the game engine's Asset Conditioning Pipeline, compile an executable, and bundle the massaged assets together to create a computer application.^[5] The types of data can often be categorized as graphics, audio, world data, and with the advent of scripting languages being incorporated into game engines, even game logic can be data.

Game engines consist of many components, called libraries. A library is suite of versatile functions and/or classes. Some of these libraries have vendor specific implementations, for example, on the UNIX-like and Windows-family of operating systems the hardware accelerated graphics library must be linked into the application as a shared library. Some game engines allow these libraries to be swapped out, these are called modular engines.^[6]

Many modern game engine frameworks, have easy to use API-s which allow a wide variety of software to be created.^[7] Often game engines are specialized for the game in production.^[8]

Most game engines are written in object oriented programming languages, and the entities in the game world are naturally objects. Very often, there is a base class all objects derive from, in Unreal this is the AActor class, in Unity3D, this is the GameObject class.

A big problem in object oriented programming is whether or not an object "has-a" object (composition), uses-a object (aggregation), or "is-a" object (inheritance).^[9] Historically, class hierarchies have quickly gone out of hand, and inheritance can result in the Diamond of Death problem.

In modern engines, components are quickly becoming the norm, the trend has moved towards composition and aggregation.^[10] In Unity3D, a GameObject is composed of objects called components which alter the behavior of GameObject.^[11]

Game engines try to solve simulations which are constantly being changed by input from a user. A loop runs repeatedly, and during it, various subsystems are updated at differing rates. In games, this is called the main game loop.^[12] Frameworks will implement the main game loop for the developers.

The simplest way is to step forward a fixed delta time, usually running the main game loop as often as the user's computer monitor refresh rate.^[13]

The problem with this approach is that if a frame (delta time/timestep) consistently takes longer to generate than the fixed delta time, the simulation will appear to run in slow-motion.

The simulation will run too fast if a bug prevents it from waiting the reminder of the fixed delta time, after an update iteration.

These effects often become apparent when a user's computer hardware differs from the developer's hardware.

The simplest solution to the problems found in a fixed timestep is to deploy a variable timestep. By measuring the time spent between the last frame and the current frame, one can move all the agents in increments multiplied by the delta time. This rewards video game enthusiasts with high frame-rates.

The problem with this approach is that certain game subsystems must be run at a fixed timestep, such as rigid body dynamics; agents not detecting collisions will result in a lack of collision response, which could result in inaccurate simulation.

The simplest solution is to find a timestep the simulation is stable under, and locking the simulation to that timestep.

Another solution is to update rigid body dynamics and game logic relying on it at a fixed timestep, and the rest of the game as often of possible.^[14][15]

Hardware manufacturers find it difficult to increase single-core performance, so they add multiple cores onto a CPU instead.^[16] To take advantage of this, many games use different models to use all the cores on a system.

Some engines have utilities to make "jobs", sending specific code over to one of the cores and then reciving the data later, asynchroniously. ^[17]

Another common solution is to put every game engine subsystem on its own core. The results of one system could be fed into the next system, body dynamics data is fed into game logic which is fed to both graphics rendering and audio rendering. Other approaches are also possible, this solution often results in data lagging one frame behind inside a subsystem.^[18]

Game developers care greatly about getting the most out of their computer systems, optimization is a massive part of engine development. Computers have finite resources. Memory, processing power, storage devices and networking have intrinsic quirks which require optimization for peak performance.

You have been lied to all your life. RAM is not random access memory, it hasn't been for many years, CPU-s retrieve coalesced memory faster than randomly accessing memory.^[19] Special care must be taken when processing data, a game engine will try to access data which is not far apart, as randomly accessing data is slow.^[20] Ideally, the data should be retrieved in continuous chunks, it should be accessed by consistently reading upwards in memory, while additionally avoiding memory gaps.^[21]

In C++, the memory allocation constructs new and delete are often overridden to track exactly how much memory has been spent and to reckon how much memory is left on the system.^[22] There are a plethora of data structures used to manage memory.^[23][24]

A common optimization for storage space is data compression, often all the data is compressed.^[25] Some engines will store all the data into one package, other engines will have one package for each world. Creating a local filesystem in this way also solves data locality problems which speed up load times.^[26][27][28]

When writing online games, there usually are two types of data to be sent, data which needs to arrive no matter what and data which is in constant flux. TCP/IP can be used for data which must arrive, such as player names and chat messages, and data which is changing, such as player positions, might be sent using the fast but lossy UDP protocol. However, having two sockets, TCP/IP and UDP; at once, is not recommended.^[29]

The build system will take all the source code, libraries, and assets, compile them individually and link them together to create platform-specific data files and an executable.^[30] Often, the build system will invoke a few tools to get the final touches done, such as the resource database, to find what data is being used in the game, the asset conditioning pipeline, to get the data compiled and linked together for the target platform, and the translation preprocessor, to get the correct languages included with the data.^[31]

Continuous Integration systems are, in most serious development environments, used to automate builds, and revision control to manage a build's source code.^[32][33][34] It is common to have builds for debug, release and production.^[35][36] Various features will be switched on or off on the different builds, debug has debug symbols intact, release will run fast enough to run in real-time but with debugging and assertions still turned on, and production will be compiled with all possible optimization flags and have all debug tracing, asserts, debug menus, command-line-interface and debug graphics deactivated.^[37]

Tools are used to create assets, to translate the game and to get assets into the game.

To create content (assets), Digital Content Creation tools are used.^[38] These include 3D modelling software, graphics editors and audio editing and recording tools.

Tools are made to keep track of what content (assets) are used.^[39] Some engines make quite complex resource databases making the tracking of the content visual, and enabling the ability to select resources in the game and adding them to levels through IDE-s, such as Unity3D's IDE and Unreal Engine 4's UnrealEd, at Naughty Dog they go for a much more minimalist approach to keep track of what assets are in use, they have MySQL database with a simple web front-end called Builder, which can invoke the Asset Conditioning Pipeline and manipulate two kinds of resource files, actors, which is Naughty Dog's jargon for agents, and level data.^[40]

Game data, assets or media, often go through a similar pipeline as source core.^[41]

Special tools are often designed for the Digital Content Creation tools to export the data so that it can be processed by the application.

A resource compiler is a tool which prepares, or massages, the assets for use in the application. This may include converting the assets, or invoking an exporter.

Resource linkers package all the files together for use by the application.

Many games are localized.

To support characters for other languages than English, Unicode was invented. Most computer applications will use Unicode to represent text.^[42]

Often, all the text strings are processed by a preprocessor to create a file for translators to fill in, and during runtime the strings are looked up in a lookup table and swapped out with the correct Unicode characters for the user's language of choice.

Modular engines designed in an object oriented fashion, might use abstract classes to provide a standardized interface for each module. This enables modules to have many different implementations which a developer may choose from, or easily extend by adding new modules. Some modules only work on the hardware its designed for, so being able to swap them out can help make a game engine cross-platform.

Even non-modular engines take advantage of a vast array of libraries, often marketed as engines. They can be categorized as the following.

Audio in games is complex and the module is often implemented similarly to the graphics rendering module, as sound moves a lot like light does, across the world.

Often called physics.

Often overlooked. Sometimes, the standard template library might be good enough, other times a cross-platform optimized filesystem module is designed for faster load times and data compression.

Graphics rendering is probably the most impressive part of game engines.

Animation is a complex topic which is still in its infancy.

Artificial intelligence in video games is weak AI. The goal is to make the computer fun to play with.

In competitive games, computer controlled agents in the game world will not play expertly. Instead an attempt is made to make them behave like human beings.

Exposing the framework to scripting languages allow rapid prototyping.

Wikimedia Commons has media related to Game engines.

• List of game engines
• List of first-person shooter engines
• 3D computer graphics
• List of game middleware