Tech Feature 008: Game Engines
As followers of the gaming industry, I’m sure many of you are already familiar with the term “game-engine”, and you hear it being used a lot. However, I bet many of you sometimes wonder quietly to yourselves “what exactly is a game engine? How does it work, and what does it look like?” In what many of you expect, a game engine is similar to a motor engine, it’s what makes the game “go”. Generally speaking, the concept of the game engine exists to abstract the details of doing common game-related tasks, like rendering, physics, input and so that developers can focus on the details that make their games unique. On these grounds, most game engines are designed with a component-based architecture that allows specific systems in the engine to be replaced or extended with more specialized componentry. For instance, a good example of the more specialized componentry in Starforge, is the proprietary Tree Engine used to render and create the trees and foliage in the game. Further to that, other components include physics, often having their own separate engine (Havok, being a good example of a popular physics engine). Having either in-house or specialized components allows for greater control and higher quality output, to deliver the most maximal product possible. Things that the game engine is responsible for are: Loading, displaying, animating models, collision detection between objects, physics, input, GUIs, portions of AI even and audio. However, as mentioned above, game engines can be either a fully integrated suite, include some additional specialized engines, or be entirely comprised of specialized engines to create a custom piece of middleware for use by the developer.
Let’s get into the history of the game engine and how it evolved a little bit, here. Prior to the existence of game engines, games were typically written as singular entities: a game for the Atari 2600 or the Amiga, for example, had to be designed from the bottom up to make optimal use of the display hardware. This was due to memory constraints and the state of the art of hardware at the time, so games had to be fully optimized to utilize every bit of precious memory as efficiently as possible. Third party engines did not become common until the rise of 3D computer graphics in the 1990s when iD software released Doom, as the first truly 3D video game environment. Prior efforts in 3D gaming were using something called vector 3D, which is the equivalent of drawing a cube on a piece of paper, or other flat surface. Such was the popularity of iD Software’s Doom and Quake titles that they rather than work from scratch, other developers began to license the core portions of the software and designed their own graphics, characters, weapons and game content around them. And so the modern “game engine” was born. The separation and creation of a “middleware”, essentially a platform from which the software could be grown and the specific rules and data from basic concepts such as collision detection and game entities, could be kept separate and handled to a greater degree of depth, meant that development teams could grow and specialize. Modern game engines are some of the most complex applications written, and feature several systems interacting with each other to ensure a precisely controlled and maximally leveraged end-user experience. Game engines have also been broadened and made more intuitive to utilize, edit and control, as such is the example with Unity3D, originally a game engine for iOS.
Unity3D is the game engine of choice for Starforge, along with proprietary extensions and plugins to go along with it. Unity is an entire game development ecosystem, essentially. It features a powerful rendering engine, animation system (known as Mecanim), and has a highly configurable editor. The editor allows for quick workflow, real-time modifications to assets, behaviors and other components of the game, a scene view to be able to see and interact with the game environment, and the ability to be plugged into a vast array of tools to get the most out of their project. Another feature that the Unity suite has is a very detailed and deep memory profiler – Essentially a visual representation in real time of what’s going on in the guts of your project, allowing developers to identify performance bottlenecks and bugs.
One last key component related to game engines that will be touched on is the API. As gamers, you may’ve seen this acronym before. API stands for Application Programming Interface. API’s are interfaces that operating systems and libraries provide so that one can take advantage of their particular features. In practice, an API often comes in the form of a library that includes specifications for routines, data structures, object classes and variables. So game engines utilize API’s to perform specific sets of functions or routines to accomplish a specific task or interaction with another software component. To get a little more technical, for object-oriented environments (such as Unity3D), an API is an instruction of how objects work – usually expressed as a set of object-classes, with a list of class methods associated with it, varying depending on the language used. Classes are associated with a set of behaviors that affect real functionality within a program. All the necessary API’s come in the form of an SDK, or Software Development Kit. SDK’s come with all the necessary API’s, tools, scripting interfaces and libraries needed so that programmers can create their games.
So there you have it! What a game engine is, how they came to be, a particular example and how they work! Hope you all enjoyed reading this issue of Tech Feature!
-- Stephen "Hatchling" Smolley