A toolkit, not a game
A game engine is a collection of software that handles the common technical jobs every game needs, so that a team can focus on what is unique to its own game. It is a foundation: it can draw images, play sounds, read the player’s inputs and simulate movement, but it does not decide what the game is about, how it plays or what it looks like.
A helpful comparison is a kitchen. The engine supplies the stove, tools and plumbing. The team still has to decide the recipe and cook the meal. Two games built on the same engine can look and play very differently.
Engines vary in size. Some are small libraries for a narrow purpose, while others are full production environments with editors, asset tools and support for many platforms. Some companies build their own for their own games, while others use engines available from third parties. Which approach is sensible depends on the project, the team’s skills and the platforms involved.
The main jobs of an engine
Rendering
Rendering is turning a description of the game world into images on screen. The engine manages the models, textures, lights, shadows and effects, and sends instructions to the graphics hardware. Because the same game may need to run on different devices, an engine often hides platform differences so that developers do not have to rewrite the drawing code for each one. Features such as ray tracing and image upscaling are usually exposed through the engine as options to switch on, though what is supported depends on the engine and the hardware.
Physics
Physics systems simulate how objects move and collide. They handle gravity, bouncing, friction and whether a character is standing on the ground or blocked by a wall. Real physics is complicated and costly to compute, so game physics is usually a set of approximations chosen to feel right and run quickly. Engines often provide collision detection and basic simulation, while the team tunes the numbers to match the feel of their game.
Input
Players interact through keyboards, mice, controllers, touchscreens and other devices. An engine reads these inputs and turns them into actions the game can understand. A good input layer lets a team map actions to different devices and supports options for remapping, which matters for adaptive controllers and other accessibility needs.
Audio
The audio system loads sound files, mixes them, and positions them in the world so that a noise appears to come from the right place. Engines may also handle music transitions and effects such as echo in a large room. More advanced approaches to spatial audio are sometimes built in, sometimes added by extra software.
Animation
The engine plays animation clips on skeletons and blends between them, so that a character can move smoothly from standing to running. The artwork itself is made in other tools, a process described under 3D modeling, and then imported.
Scripting and logic
Teams need a way to define behaviour: what happens when the player opens a door or an enemy sees them. Engines usually offer a programming language or visual scripting tool for this. Some use a mix, with performance-critical systems in a fast language and gameplay logic in an easier one.
Artificial intelligence support
Many engines include tools for navigation, such as working out routes around obstacles, and for organising decision-making of non-player characters. The designers still define how those characters behave.
Networking
For online play, an engine may provide the basic means of sending data between machines, handling players joining and leaving, and keeping the game state consistent. Complex matters such as lag compensation usually need extra design work from the team.
Asset management and tools
Games contain huge amounts of content: models, images, sounds, levels. Engines supply a way to import, organise and package this material. Most include a visual editor in which developers place objects, adjust settings and test the game without leaving the program. These editors are where designers do much of their level design.
The main loop
Under all of this, most engines run a repeating cycle, often many times per second. In each cycle the game reads input, updates the state of the world, runs physics and logic, and draws a new image. The speed of the cycle is what is measured as frame rate. If any part takes too long, the whole cycle slows and the player may notice stutter. This is why engines are built around efficiency, and why teams spend time profiling to find slow spots.
Why teams use engines
- Saved time. Building rendering, physics and tools from scratch can take years. Using an existing engine lets a team start building the game almost immediately.
- Proven code. Widely used engines have been tested on many projects.
- Platform support. Engines often help a game run on several platforms with fewer changes.
- Shared knowledge. Documentation, tutorials, and a pool of experienced developers make hiring and learning easier.
- Faster experiments. Quick tools make it practical to try ideas, which supports building a game prototype early.
Trade-offs
Engines are not a perfect answer. A general-purpose engine includes features a particular game will never use, and may be less efficient than custom code for an unusual design. Teams depend on the engine’s creators for updates and fixes, and licensing terms or costs may apply. Switching engines mid-project is usually painful. Some games also take on the look or behaviour that the engine makes easy, which is a reason some teams choose to build their own technology.
Large studios often use a customised or in-house engine, while smaller teams commonly use an existing one, though both patterns have many exceptions. The choice is typically made during pre-production.