I’ve been responsible for a number of engines and frameworks over time, but they have been predominantly built for the purpose of solving some specific technically difficult problems. As we have embarked on the business of developing games ourselves, the need for a more comprehensive game engine is evident. We could use one of the existing engines out there, but my history with developing them leaves me with too many ideas on the subject to give it up.
In this first instalment, I explain my thoughts on the role of a game engine and the overall scope of what I intend to achieve.
The challenge facing a game engine is to help the developer express their game design concisely.
An engine for resolving the challenge of physics or rendering is great, but that isn’t a game engine at all. It’s a graphics engine, or a physics engine, usually with a token entity system built on top of that. These types of technically-oriented solutions can simplify code that deals with their particular subsystem, but do little to assist the general process.
What then are the basic elements of a game design that an engine should treat as its basic units? Rules. Many of these rules are simple; “Mario is hurt if he touches the sides of a goomba”, and others take the form of simulation systems such as physics. Entities are defined in terms of how the game rules apply to them. This is rarely described in such a formal way by game designers, but during implementation the core task is to distil the design down to these types of basic ideas and then express them in code. The goal of the game engine is to allow each game rule to be specified with as little code as possible.
There are three key factors I will be focusing on in my own engine design:
1. Minimize code to define a rule.
2. Allow custom rules with minimal overhead.
3. Make gameplay code as readable as possible.
In the next Game Engine Design post, I’ll lay out the high-level component view of the engine and describe how I intend for the parts to work together.