Baldur’s Gate: Enhanced Edition Postmortem

Trent Oster, head honcho of Overhaul Games, has written a five-page postmortem article for Gamasutra on the company’s recent enhanced remake of Baldur’s Gate. If you’ve been following the game or want some inside info on some of the challenges faced during the game’s development, this article is sure to be of interest.

What Went Right

1. Fans and Community Early on we knew one of the key elements to succeeding with the Enhanced Edition of the game was to bring in as many people from the modding and fan communities as possible. By working with them and listening to them, we could make the right changes and try to improve the game to better meet their needs. Our first few attempts were crude — an invite-only Reddit, some direct e-mails — but things rapidly turned around with the launch of the official message boards where we could speak directly with the modders and fans and listen to their concerns.

We shared new content with them as early as possible and acted on their feedback to make the game a better experience for users and a better platform for modding. We did this through hosting a long-running private beta. We would push a new build out to the beta group, have them poke it and respond with suggestions and feedback.

—

What Went Wrong

1. Epic Code Complexity

We began work on the project almost two years from ship. At the start we planned to “ninja in, make some minor changes, replace the graphics system and ninja out.” As we began to work with the code base, we found severe performance and stability issues with the engine. We traced some issues back to the core threading model of the Infinity engine.

Infinity was multi-threaded before there were processors capable of parallel code execution. As such, it was designed around a concept of threading that never really emerged. The main issue was that all of the threads shared the same set of data. The problem is all these threads were created and they all hit the same memory and as such, blocked each other, stalling all threads until the current one completed.

The code was also heavily laced with critical sections, which caused (in some cases) 70 percent of execution time spent in no-ops. Our long-term solution was to machete in and remove the threading, removing a couple hundred thousand lines of code from the game. The end result was more stable and had fewer performance irregularities. The “ninja-in” approach was tried in other areas, as well, and every time the end result was consistent. We always found a ton of complexity solving an era-specific problem that no longer applied. We continue to find roadblocks in the code and we’re improving it as we go.