Why (and how) you should leave Unity and Unreal to make your own engine

So often, you're greeted with the splash screen of Unreal Engine or "Made with Unity" when booting up a game, two of the most common game engines today. These are robust and mature engines, but they're not always the best options for independent developers, according to longtime developer Rez Graham. At a GDC 2024 talk titled "A Case for Making Your Own Game Engine," he advocated for building games on your own tech through frameworks and libraries—existing tools that offer some major advantages, and admittedly some disadvantages developers should be aware of.

Graham has been making games independently under BleachKitty following his work at Electronic Arts on The Sims series. From his perspective and experience, the most popular game engines aren't always the best fit for development, and it really depends on your goals and the type of game you want to make. That makes sense on paper, but he outlined several factors that need to be considered when deciding whether to build your own tech or work with existing engines. 

Licensing fees to use a third-party engine in perpetuity will add up, and Graham stated, "It is generally cost-effective in the long term. My suspicion is that nobody in this room is making a game and they're like, 'Okay, cool. That's done, I'm going to go be a farmer for a while.'" The implication is that you'll be using your own tech for future projects as well, and it's not just a one-time investment. Having full control of an engine and how you use it is important to Graham, and he continued, "It's cost-effective in the long term because you're investing in your own company, in your own tech, in your own world. You build the thing that you want and nothing else. So that's extremely important, that's extremely powerful."

Foundational thinking

The idea is that you'll have a foundation that's particularly great at making the kind of thing you want to make, as Graham says, "You can say [for example], the type of game I'm making is this roguelike-style game. So I'm going to use this framework and then I'm going to build on top of that with the exact systems I need that may enable me to make roguelikes fairly easily." However, the engine building process and development should overlap, which he suggests, "I'm not saying, let's start by spending two years building an engine. What you do instead, you build your own tech. You make your game and you extract stuff out as necessary."

In terms of using interconnected frameworks, Graham gave an example of what he means in practice—using SDL for OS, rendering, sound, and input since it is well known (SFML works well, too), then Box2D for physics, Tiled for level editing, Tinyxml for XML loading, and Sol/Lua. He reiterated that there are tons of free, open-source libraries to pull from as well. And with all these frameworks working in harmony, you can create something that works specifically for you where you have full control and a deeper understanding of a lean game engine.

One of the disadvantages he mentioned was that using these kinds of frameworks often require C++ knowledge, saying, "Even if you don't actually require somebody to write C++, it probably requires low-level knowledge or understanding." But this makes the troubleshooting process easier with these tools letting you identify the problem and fix it as opposed to sifting through the potential wave of error messages from an Unreal or Unity engine.

While you won't have to worry about licensing fees with your own tech, Graham acknowledges that there is a higher up-front cost since, of course, building your own tech takes time. In a follow-up question, he also recognizes that going with something like Unreal or Unity is the best option for bigger games, and pointed to Cyberpunk 2077 as an example. Since that game was built on CD Projekt Red's REDengine, "The designers were working on a moving target. The engine was continuously being built as the designers were trying to make the content for it, so it didn't really go well for them."

Another factor Graham pointed to was "automatic knowledge" for when you start to get others involved in your project. You essentially forgo the institutional knowledge other developers may have of more prominent game engines, which means you need your own documentation and generally need people who know C++ at least on a basic level when using the aforementioned frameworks.

As ubiquitous as Unreal and Unity may be, he pointed to several well-known independent games that were built on their own tech, which included games like Stardew Valley, Bastion, Darkest Dungeon, Shovel Knight, Into the Breach, and many more. Graham reiterated that building your own tech still depends on the kind of game you want to make.

The last point Graham made was that independent games can push the boundaries and be experimental, particularly in technical innovation, saying "Epic is doing their own technical innovation, Unity is doing their own technical innovation, but they also have to be all things to everybody. They can't go too far off the beaten path."

He concluded, "There are some really interesting indie games out there now that do some interesting technical innovations... When you build your own tech, you can do some really crazy things, and that's what we're missing."

Game Developer and Game Developers Conference are sibling organizations under Informa Tech.