The Problem Engines Solve
Every video game must do certain jobs: read the controller, draw things on the screen, play sounds, keep track of objects moving around and decide what happens when they touch. In early games, a programmer wrote all of this alongside the rules of the specific game, often from nothing and often in assembly language for one particular machine. When the next game began, much of the work started over.
A game engine is the answer to that waste. It is a body of software that handles the common jobs, so that developers can concentrate on what makes one game different from another. The term became widespread in the 1990s, but the underlying idea is older.
Early Reuse
Even in the 1970s and 1980s, developers kept collections of routines they had written, such as a fast way to draw a sprite or a method for reading a joystick, and reused them across projects. Some small companies built internal toolkits that let them release several games using the same core. Adventure-game makers wrote interpreters, programs that ran a story stored as data, which allowed one piece of software to run many different stories. That approach was used by the makers of several well-known text adventures, and it is one of the earlier clear cases of separating a game’s code from its content.
This separation is the key conceptual step. If the rules of the engine are in one place and the levels, characters and scripts are in data files, a team can add content without rewriting the program. It also lets different people specialize: programmers work on the engine, while designers and artists work on the data.
The 1990s and the Shift to 3D
The idea became prominent when three-dimensional games grew popular in the 1990s. A well-known shooter from 1993 by a Texas studio is often cited as an example. Its programmers organized the software so that levels, graphics and sounds were stored in separate files that the main program loaded. Because the structure was open enough for others to understand, fans made their own levels and modifications, and some licensed the engine to make commercial games.
Licensing became a business of its own. A studio that built a strong engine could sell it to other studios, which saved them the cost of building their own. Several well-known engines of the mid and late 1990s were used this way, and many games sharing an engine looked and played similarly in their basic mechanics, even when their stories differed.
An engine for three-dimensional games typically includes:
- A renderer that turns descriptions of shapes into pictures on screen, relying on the progress of computer graphics.
- A physics or collision system to decide how objects interact.
- Audio handling for effects and music.
- Input handling for keyboards, mice and controllers.
- Scripting or tools that let designers define behavior without changing the core code.
- Support for networking, so that several players can share a game, which links to online multiplayer.
Tools and Editors
As engines matured, the surrounding tools became just as important. Level editors let designers place objects visually. Asset pipelines converted art and sound files into formats the engine could load quickly. Debugging tools helped teams find problems. In large studios, the tools sometimes involved as much work as the engine core.
Later, general-purpose engines became available to small teams and individuals, some at low cost or free. This lowered the barrier to making games and contributed to the growth of independent development. A developer with a small budget could build a polished game without writing a renderer from scratch, which resembles the way a previous generation of hobbyists used BASIC and assembly routines on home computers.
Some of these engines are organized around object-oriented programming ideas, in which game entities such as enemies or doors are represented as objects with their own data and behavior. Others use different structures, and designers debate which is better. It would be inaccurate to claim that there is one standard way.
Benefits and Trade-Offs
Reusable engines bring clear advantages: faster development, more reliable code that has been tested in earlier projects, easier porting to different hardware, and a community of people who know the tools. But they also have costs.
- Games built on the same engine can feel alike, because engines make some choices easy and others hard.
- A general-purpose engine may carry features a particular game never uses, which can add weight.
- Dependence on a commercial engine means depending on its owner’s pricing and decisions.
- Some developers prefer to write custom engines to achieve a specific look or behavior, accepting the extra work.
Neither approach is simply better. Engine choice is a business and design decision, and teams weigh budget, schedule and ambition.
Engines and Preservation
Because engines often outlive individual games, they have also become a subject for preservation. Some old engines have had their source code released, which has allowed enthusiasts to update them to run on current computers. Projects like these rely on source code archives and careful documentation. When the code is not available, fans may rebuild an engine from observation, a slow task that is rarely perfect.
In short, game engines are one of the clearest examples of a general pattern in software: once a set of problems has been solved well, it tends to be packaged so that others can build on it.