Bethesda Doesn’t Need a New Engine

Bethesda Softworks is infamous for releasing buggy games. Sure, people love the open world sandboxes of Fallout and Elder Scrolls anyway. The games operate like an amusement park where the player can wander freely in search of fun without needing to follow a predetermined path set by the game designer. The open world stuff can feel like repetitive busy work in Ubisoft games, but in a Bethesda game all those dungeons and outposts are hand-crafted adventures with lots of variety and sometimes even a little story. It’s a style of game you can’t get from any other developer. This formula has proven popular enough to make The Elder Scrolls V: Skyrim one of the best-selling games in the history of the medium.

But still. All those bugs.

Bethesda games have graphical glitches, goofy unintended exploits, misbehaving interface elements, malfunctioning AI, unbalanced combat mechanics, broken quests, bizarre animation problems, broken economies, and of course lots of crashes. Every once in a while someone makes the suggestion that Bethesda needs to wipe the slate clean and start over with a new game engine. I understand why people say this, but the truth is that the engine isn’t the source of the problem and replacing it would only make things worse.

The game engine in question has a long lineage. It was originally created by Gamebase and was called NetImmerse. It was rebranded as Gamebryo around 2003. This is the name most closely associated with Bethesda titles. The Elder Scrolls IV: Oblivion and Fallout 3 were both built using the Gamebryo engine of this era. Afterward, Bethesda began working on their own version of the Gamebryo engine independent of of what Gamebase was doing. Bethesda’s forked version was eventually renamed the Creation Engine, which is the name being used today. (Lots of people still refer to it as Gamebryo out of habit.)

For the record, most companies can’t do this sort of thing. If you’re a bedroom programmer and you use the Unity game engine to make an indie game, you don’t get access to the Unity source code. You can build a game on top of the engine, but you can’t change the engine itself. However, if you happen to own a company with some cash, you might be able to pay extra money and get access to the source. You can then make changes to how the engine works, perhaps to gain access to the low-level guts of the rendering pipeline, or to add support for some obscure platform not currently supported by the engine. Even then, you’re usually stuck using the engine for one title. If you decide to make another game, you need to sign another agreement with the company behind the engine. However, if you’re a huge corporation and you’ve got ridiculous piles of cash to throw around, then in some cases you might be able to pay a one-time fee and get open-ended access to the source, meaning you’re free to do whatever you want with it. You can grow it into a new engine over time and use it on multiple games without needing to offer more money or ask for permission. (If the original engine author is smart, they’ll stipulate that you can’t license your version of the engine to other companies. Otherwise, they might end up competing against their own engine.) While the details have never been disclosed, I suspect the latter case is the kind of deal Bethesda made with Gamebase.

Bethesda is now in control over their own engine, and their engine is notoriously buggy. This leads many people to conclude that Bethesda should throw the whole thing away and start over. People say it in print, they say it in YouTube videos, and they say it often in comments. This is an understandable reaction and I understand why people have it. On the surface, it sounds reasonable: If the engine is full of bugs, then replacing the engine should get rid of the bugs.

Sadly, it’s not that simple. This isn’t a technology problem. This is a problem with the company culture, and those kinds of problems are a lot harder to correct.

18 years ago, Joel Spolsky wrote an article titled “Things You Should Never Do, Part I,” which cites the famous case of how Netscape — the original king of the web browsers — basically killed their product because the developers wanted to re-code everything from scratch. This is actually a common story. Wiping the slate clean is a very tempting thing for programmers. Over time, code gets complicated and hard to manage. Often programmers will long for the early days of a project, when they were working on a blank canvas. There weren’t a lot of dependencies, compile times were short, and it took you five minutes to find and fix a bug instead of an afternoon. Over time, a project grows in complexity and becomes a terrible snarl of cobbled-together technology. It’s easy to look back on those early days in a project as some sort of golden age and wonder how it all went wrong. The thing is, it didn’t go wrong. The mature software is complex and fiddly because it needs to do complex and fiddly things. If the same company rewrites the same software using the same team of developers and the same development process, then they’ll spend years of precious time and millions of dollars in opportunity costs to wind up with a less polished version of what they started with.

So maybe the solution is to throw away the creation engine and license a modern, stable, feature-rich engine like Unreal Engine or CryEngine? Except, Bethesda games have some rather particular needs that aren’t covered by the typical off-the-shelf engines. Bethesda games need to store the state of the entire world. Players expect that if they slay the Underking, loot his tomb, and pose the Underking’s twice-dead body with his face pressed against the seat of his throne, they should be able to come back days later and find the tomb exactly as they left it. If they toss 400 cheese wheels on the ground in the town of Whiterun, then those cheese wheels better still be there the next time they visit. The game needs to be able to handle large-scale AI behaviors that have agents roaming all over the world and going through a daily routine, even when their part of the world isn’t loaded. Most importantly, the game needs to be very open to modding so that end users can make sweeping changes to the gameplay, art, sounds, music, animations, and interface, using self-contained package files. These aren’t impossible-to-solve problems, but they do run against how a lot of modern game engines are designed. If Bethesda wanted to use one of the big-name engines out there, it would require extensive modifications. That would just lead them back to where they are now, with buggy games based on an engine that’s been twisted in ways it was never designed to go.

The problem isn’t the bugs. Every game has bugs while it’s being developed. What counts is how you deal with them, and I suspect Bethesda’s bug-fixing machinery is neglected and broken. Either management doesn’t care, or the leadership doesn’t know how to correct their process.

Every company has a slightly different procedure for dealing with software bugs. Some developers like Valve and Blizzard use an iterative process of constant playtesting, which would necessitate continuous bug fixing. Other developers save the debugging for last, which means if they run out of time then the bug-fixing stage gets cut short. (I’ve always suspected that Obsidian Entertainment is the latter kind of developer.) Some development teams have people dedicated to debugging, while others have the entire programming staff share the burden.

Tracking and fixing software bugs is a long and complex process. You need a robust team of dedicated people to exhaustively test the software and identify the problems. These reports go into a database where they can be described, categorized, and prioritized. Then those problems can be investigated by the programmers who will enact a fix. Then the new version of the software is provided to the testers, and they can make sure the problem really is fixed for all known cases. If it isn’t, it gets sent back to the coding staff for another go. This is a complex process that can involve dozens of people.

It’s not like bugs are limited to their engine. The new Bethesda game launcher apparently shows the same lack of stability and penchant for odd behavior that infects their games.

Maybe the Bethesda debugging and testing process is broken and things are getting marked as fixed without being reviewed first. Maybe there’s no discipline and programmers can add features whenever they want, thus creating fresh bugs in areas that have already been tested and approved for release. Maybe programmers are free to select which bugs they want to tackle so you end up with a few that are ignored because nobody wants to deal with them. Maybe the process works fine, but the team isn’t given enough time to do it properly. Maybe their system of organizing bugs is so terrible and confusing that important issues get lost in the shuffle. Maybe they don’t have enough testers, or the testers aren’t thorough enough to find all the problems. Maybe the team just doesn’t care, because management doesn’t care, because the bugs don’t seem to hurt sales.

Whatever the cause of the dysfunction, Bethesda’s janky engine is a symptom of the problem, not the cause. If management put a priority on fixing their development process and was willing to spend money to make sure the software was stable, then it would happen. Bethesda employs smart people. The job could get done. If management isn’t willing to take those steps, then a new engine would turn out exactly like the current one.