This piece is part of a series of articles that ran in PC Gamer UK issue 326 celebrating Baldur's Gate. For more quality articles about all things PC gaming, you can subscribe now in the UK and the US.
Baldur’s Gate is powered by the Infinity engine, a bespoke technology created by BioWare specifically for the game. Simple in its exterior, Infinity makes the complexity of Advanced Dungeons & Dragons playable with just a mouse, and makes use of a visual style that boils down to a bunch of animated sprites walking on top of some beautiful paintings.
Looks can be deceiving. Beneath those simple backdrops was a deep and complicated engine made up of many different tools and technologies. It was hugely advanced and also hugely idiosyncratic, while getting it to work in the way BioWare wanted was, frankly, a nightmare.
While BioWare itself was not a new studio, the Baldur’s Gate team was almost entirely new to the games industry, with many of its designers coming straight from university. “It was just a bunch of crazy kids going, ‘Let’s just do this thing! How hard can it be?’” explains Trent Oster, formerly senior artist on Baldur’s Gate, and one of the founders of BioWare. “The answer is it’s really hard, [and] really easy to do things in a bad way that makes things slow and makes things horrible.”
Breaking backgrounds
Baldur’s Gate is famous for its use of prerendered isometric backdrops, which enabled BioWare to represent its fantasy world in far more detail than was possible with real-time graphics. But even prerendered, each of those backdrops had a native 5120x3480 resolution—way higher than any computer from 1998 could have rendered without exploding. “Each image of that massive background was cut into a 64x64 tile, and each one of those was mastered down to its own little palette of 256 colours,” Oster explains. “At runtime [Infinity] would load those little 64 bit chunks as it needed them, and it would convert them into a 16-bit colour representation that would then be rendered to the screen.”
The Infinity Engine would then perform a prototypical version of modern level-streaming, adding new chunks of the background into memory as the player moved forward, and dropping off-screen chunks as they were no longer required. This ‘tile-management’ system was incredibly complicated, requiring a huge amount of work to optimise and necessitating lengthy loading times between screens.
Also, the dividing of backgrounds in Baldur’s Gate into tiles increased the assets of an already huge game exponentially. “At the time, most games were throwing around 100, 200, 500 in-game assets,” Oster says. “Baldur’s Gate was throwing around 20,000 to 30,000. If you count individual tiles that made up areas, it was into the hundreds of thousands.”
To manage these assets, BioWare’s lead programmer Scott Grieg created a memory management system called Chitin. This worked a little like a slide projector, offering your 4MB PC a tiny window into Baldur’s Gate’s much larger dataset. But problems began to arise when Grieg decided to make Chitin multithreaded. “Chitin wasn’t multithreaded inherently. But partway through development they designed the AI system and the pathfinding system, and part of that design was getting excited about the idea of multithreading,” Oster says.
In theory, this was a great way of offloading the data Infinity had to crunch through to make the game work. But at the time, multicore processors didn’t exist. “When you actually think through how the data is held in the processor, and how it’s interacted with, what you just engineered is a scenario for countless pipeline stalls,” Oster points out.
The team tried to alleviate this problem by highlighting certain threads as ‘critical’, which meant they had to complete their processing before any other threads could run. But Baldur’s Gate had over a million lines of code, so many critical threads were not labelled as such, resulting in massive performance headaches. Oster points out that in the code base there are five separate ways players can trigger an area transition. “In many cases, it was code that was almost identical but literally different by one or two parameters.”
Cover-up job
Amongst these core technical issues were dozens of other problems. Baldur’s Gate’s UI is not an overlay, it’s hard-coded into the game. Again, this was done to increase performance. “Baldur’s Gate’s UI is fat to cover up the screen, so you don’t have to render as much of the background,” But this also meant the only way to make a change to the overlay was to do it via the game’s code base. Want to move an icon from the left to the right of the screen? You could potentially break the game.
All of this meant that BioWare created problems for itself that could only be solved through brute force, testing every line of code, painstakingly clipping out objects in the background so that characters could walk behind walls. “The approach that BioWare took at the time, was, ‘We don’t know the right way to do this, we don’t know how to automate things. Let’s throw humans at the problem, and with enough sweat the problem will go away,’ remembers Oster.
This, ultimately, is the real story of Baldur’s Gate. The trials of BioWare’s Infinity Engine were not just technical, they were physical, too. “It was a monumental achievement at the time,” Oster concludes.
