Hi, I'm supersoup, a developer and occasional writer. I'm a game developer by passion, a web developer by practice, and a product of the 90s by tas... Read more
Reviewed by Benjamin Barr
What is a game engine? Well, what comes to mind when you read the word “engine?” If you’re like me, it’s an image of metal and bolts sitting at the heart of a vehicle. Something that converts electricity or combustion into energy — the beating heart of our cars.
Engines are the sum of many parts. And each component, no matter how large, small, or misshapen, serves a specific and important purpose in allowing the engine to work its mechanical magic.
That’s precisely the image game developers hope to invoke in regards to “game engines.” Game engines are the collections of code libraries and frameworks that bring games to life. Though they’re often invisible, game engines are always hard at work so long as the game is running.
What is a Game Engine?
As mentioned above, game engines are collections of code in the form of libraries and frameworks. But what exactly does that mean? Let’s break down some common terms so we can see both the forest AND the trees. Note that these explanations are simplified, and this is just an overview.
A line of code is what’s known as a statement. Statements are the individual leaves and branches in our forest analogy. They are the elements that comprise the larger constructs we’ll be discussing.
Get enough statements in one place, and you have a library. These are the trees.
Libraries are collections of code focused on providing solutions to specific problems. You may have heard of program “.dll” files—that acronym stands for “dynamic linked library,” and that’s exactly the sort of library we’re talking about.
If you’ve got a problem to solve or mission to accomplish, there’s a library for that. One of the most widespread and popular libraries in use today is OpenGL (Open Graphics Library). As the name implies, it’s focused on providing an easy-to-use graphics standard for a wide variety of platforms.
Take some libraries, mash them together, and you’ve got the makings of a framework. This is a small clearing.
Frameworks are higher-level collections of code than libraries. They generally incorporate multiple libraries and other granular components to attack different issues at once, orienting them toward producing a particular experience. This is where we start to see the proto-engine emerge from the proverbial egg.
A common framework is Microsoft’s .NET Framework, which gives a programmer the digital tools to handle everything from in-line database queries to multi-threaded, asynchronous code.
All of this functionality focuses on a particular goal. But this goal can be broader and more difficult to define than that of the library. So, let’s say that .NET allows for “a dynamic, portable, and robust experience for users and developers via modern, high-level features” and move on.
There’s other data and code constructs we could discuss, of course, but at this point, we’ve talked about the trees enough. Let’s talk about the forest.
The game engine is a collection of all the preceding constructs, and then some. Each engine is filled to the brim with libraries, frameworks, and other bundles of code for interfacing with hardware and handling features like graphics, audio, input, networking, physics, AI, and more.
Back in the day, custom game engines were built for each and every game. Moreover, they only worked on one particular hardware, like the Atari 2600 or the NES. But as time went on, the development of new standards and common architectures resulted in different systems and system series, which could all share code. And so the game engine was born as a matter of efficiency: write code once, run wherever you could, and reuse code for future games.
How Does a Game Engine Work?
All these libraries and frameworks cooperate under the hood, and the result is the game you see on your monitor, hear through your speakers, and manipulate with your input. Each component of the engine interfaces between hardware, the operating system, and the engine itself to produce a result. These results forge a game from the digital aether.
For example, OpenGL translates data which represents 2D or 3D objects into instructions for the GPU to render them. FFmpeg turns recorded sounds into bits and bytes and back again on the fly. PhysX handles the logic and data behind physical interactions to simulate virtual objects with real-world properties like mass and inertia. And that’s just to name a few standout examples from common engine subsystems.
There are hundreds, if not thousands, of libraries and frameworks that go into your favorite games and their engines — and that’s to say nothing of the components developed explicitly for individual games. That’s right: even an engine can’t cover all the bases.
The rabbit hole goes pretty deep. And all the thousands of code statements across these libraries and frameworks are executed hundreds (if not thousands) of times each second so you can capture the flag, tell your Sim to sleep, or rage at an uninformed noob. Consider that the next time you feel like trolling.
Examples of Popular Game Engines
With their portability and reusability, modern engines are tuned and tailored for a variety of situations. But there are a few standouts that you’ll see time and again.
Unity is one of the more common game engines these days, especially in the indie sector. Among AAA developers, the Unreal Engine is more common, with greater visual fidelity and more powerful workflows that make the most of a massive development team. If you’re a fan of Bethesda, you’ve certainly encountered the Gamebryo engine, powering titles like Morrowind, Oblivion, and Fallout 3. The Source engine is Valve’s baby, powering everything from Half-Life 2 to Portal 2 and Left 4 Dead.
And that’s just a few of the most common engines on the market. There are certainly dozens more, and each one does something unique, special, or just downright quirky that the rest don’t.
Examples of Popular Game Making Tools
Each engine boasts a suite of development tools, called a Software Development Kit (SDK). Usually, the SDK contains another collection of frameworks and libraries (including the source code for the engine in some cases) designed to create and convert content for use with the engine. Some of the frameworks in the SDK might be APIs for interacting with the engine, while others might be self-contained solutions for other problems in the development workflow.
For Unity, the primary development tool is the Unity Editor, and it’s equipped to import and work with assets from a wide variety of standard file formats. The Unreal Editor is for the Unreal Engine, of course, and works in much the same manner. Some engines like Gamebryo and Source don’t have comprehensive editors, choosing to provide proprietary tools for level design only — the Construction Kit and Valve Hammer Editor, respectively.
In all cases, you’re likely going to be making content externally, then converting and importing the assets with the SDK. However, modern extendible editors for engines like Unity and Unreal are seeing a push toward enabling the creation of certain assets right in the editor.
Features like Unity’s Shader Graph and Unreal’s Niagara Editor — allowing for the creation of shaders and visual effects, respectively — means that the number of different programs you need in your development workflow is shrinking as time goes on. But some are so specialized and well-designed that they simply can’t be replaced with a generalized variant as of yet.
Some common external development tools you may have heard of include:
- Adobe Photoshop and GNU (for 2D graphics)
- Maya and Blender (for 3D modeling)
- Audacity and Adobe Audition (for audio)
- Sony Vegas and Adobe Premiere (for video)
- Microsoft Visual Studio and IntelliJ Idea (for programming)
Advice for Beginners
So you want to grab an engine and start making games for yourself? That’s great, and I strongly encourage it — whether for fun or something more serious. Take a moment to consider this advice, though, as it may save you some trouble down the road:
Start honestly. Don’t go into game development expecting to pay the bills from the word go. You’re not going to start making money overnight as an indie dev. Game design is an art form more than anything else. No one starts painting or sculpting because they believe they’re going to “make it” and rake in the millions. You become an artist for the creative outlet, to capture emotion, to express something fundamental about life.
The starving artist is a stereotype for a reason. That said, don’t let that dissuade you. Creating games is an incredibly fun and fulfilling hobby/side job/potential full-time job that can help you develop real and marketable skills.
Start cheap. Some engines come with multi-thousand dollar licenses attached, though it’s common in the industry for major engines to provide a free version for “hobbyists and indie devs.” Just make sure you follow their rules and regulations.
And if you don’t have the skills to make your own assets, don’t sweat it. There are lots of places you can find free assets around the web. Some are completely free, and some only asking for attribution in return. Make sure you abide by the stipulations of the license agreements but feel free to make use of those when you’re starting out. You can make your own later.
Start small. You’ve probably got a game in mind already. It may be something you haven’t seen yet, or the game you wish you could play. Or perhaps it’s simply a variant of a game you played that you think could be better. And that’s a great start.
Whatever it is, take that dream, tick the “Preserve Aspect Ratio” box, and scale it down. You can have the same dream, sure — just a little smaller. You’ll save yourself tons of trials, tribulations, and heartbreak by doing that now rather than later.
Making a game is monumentally challenging, especially when you’re learning as you go. Don’t be hard on yourself, scale back your ambitions, and make something simple for starters. You can create your fresh take on Civilization for your second go-round. For now, try a Breakout clone.
Take a look at the different engine APIs and see which one makes the most sense to you. If you’re just getting started with programming, “none of them make sense” is a perfectly reasonable answer as well. Take to Google and YouTube to look up tutorials for your engine, or perhaps tutorials for your engine’s core programming language. Just start small, and chip away at learning the language of the computer one bit at a time.
Further Reading
Keen on learning more about game development? Check out our other guides below:
You must sign in to comment.
Don't have an account? Sign up here!