For someone who follows the video-game industry closely, they’ll probably hear the term “game engine” thrown around a lot. That’s especially true around game announcements, press conferences, conventions and during some investor calls.
So what are they?
Well it’s more than just an industry buzz word. The engine a game uses can drastically change the type of game or the process it took to make it since not every engine does the same thing. And with that in mind, not every game runs off an engine, but they help to do a lot of the leg work during the development process.
Game engines provide a baseline framework for more abstract concepts. These are ideas like collision detection, physics, graphical user interfaces, artificial intelligence, scripting, sound, memory management, networking and a whole list of other functions. Generally, those concepts are evenly divided out into other components as part of the whole, like a rendering engine, audio engine and physics engine. Engines even make it easier to port games onto other platforms. However, not every single one works well on all hardware.
What they don’t do is put content in the game. Think of it like a movie studio: All the tools to make the film—from the cameras and stages to the special effects—are there except something needs to be filmed still. Before engines were standardized, it was more like having to build the cameras for every movie.
In the early days of game development, every game was made from scratch, and, in a sense, that made every game wholly unique. The problem is that meant everything was made from square one or from modifying older games. What game engines helped to do was, for example, create a basic physics system that could be used across projects instead of building a different system after every new release. The end result was shorter development cycles, more projects being developed and the chance to create more complex games.
The concept of engines started to pop up during the early 1990s. id Software was among the early pioneers. The company developed a set of tools that could work for multiple games. Doom Engine, later known as id Tech 1, was launched in 1993 and was used in the first Doom game. The company is now on id Tech 6, which was first used (in a beautiful cyclical manner) for the 2016 release of Doom.
Some developers have their own internal engines: EA and Frostbite, Crytek and CryEngine, CD Projekt RED and REDengine. Other companies develop their brand and license it out: Epic Game and Unreal Engine, Unity Technologies and Unity, Idea Frabrik and Hero Engine.
Most of the time, you won’t see a company with their own engine outside of the major players like EA. It takes a tremendous amount of time and money to create one, but when you have the resources to do it, like EA, it’s worth it because it’ll cut down development costs in the long run. Now, many of their recent games and all future projects from the publisher are going to be built on Frostbite. That includes the EA Sports titles Mass Effect: Andromeda, Battlefield 1, Mirror’s Edge Catalyst, to name a few.
This is a very superficial look at engines largely because of their nebulous nature. No two engines are alike, and the bigger ones, REDengine or Frostbite, have such a wide scope of abilities that the companies had to create internal wikis of thousands of pages to cover it all.
Today, there are a couple of options freely available for hobbyists. Game Maker is the simplest one with a number of tutorials to guide users through the steps. Unity and Unreal are more complex tools, especially Unreal, but anyone can go to the developers’ sites to download the engine to start making games. Unreal would require a hefty PC to run smoothly, however. The best part is neither one requires knowledge of coding to start, thanks to the nature of how engines work. I’m not saying you could make good games, but you can at least start.
I mean, you might make good games, but I can’t.
