TRI­ALS OF IN­FIN­ITY

Baldur’sGate’s en­gine hides a labyrinth of in­no­va­tion and hu­man grit.

Baldur’s Gate is pow­ered by the In­fin­ity En­gine, a be­spoke tech­nol­ogy cre­ated by BioWare specif­i­cally for the game. Sim­ple in its ex­te­rior, In­fin­ity makes the com­plex­ity of Ad­vanced Dun­geons & Drag­ons playable with just a mouse, and makes use of a vis­ual style that boils down to a bunch of an­i­mated sprites walk­ing on top of some beau­ti­ful paint­ings. Looks can be de­ceiv­ing. Be­neath those sim­ple back­drops was a deep and com­pli­cated en­gine made up of many dif­fer­ent tools and tech­nolo­gies. It was hugely ad­vanced and also hugely idiosyn­cratic, while get­ting it to work in the way BioWare wanted was, frankly, a night­mare.

While BioWare it­self was not a new stu­dio, the Baldur’s Gate team was al­most en­tirely new to the games in­dus­try, with many of its de­sign­ers com­ing straight from univer­sity. “It was just a bunch of crazy kids go­ing, ‘Let’s just do this thing! How hard can it be?’” ex­plains Trent Oster, formerly se­nior artist on Baldur’s Gate, and one of the founders of BioWare. “The an­swer is it’s re­ally hard, [and] re­ally easy to do things in a bad way that makes things slow and makes things hor­ri­ble.”

Break­ing back­grounds

Baldur’s Gate is fa­mous for its use of pre­ren­dered iso­met­ric back­drops, which en­abled BioWare to rep­re­sent its fan­tasy world in far more de­tail than was pos­si­ble with real-time graph­ics. But even pre­ren­dered, each of those back­drops had a na­tive 5120x3480 res­o­lu­tion—way higher than any com­puter from 1998 could have ren­dered with­out ex­plod­ing. “Each im­age of that mas­sive back­ground was cut into a 64x64 tile, and each one of those was mas­tered down to its own lit­tle palette of 256 col­ors,” Oster ex­plains. “At run­time [In­fin­ity] would load those lit­tle 64 bit chunks as it needed them, and it would con­vert them into a 16-bit color rep­re­sen­ta­tion that would then be ren­dered to the screen.”

The In­fin­ity En­gine would then per­form a pro­to­typ­i­cal ver­sion of modern level-stream­ing, ad­ding new chunks of the back­ground into mem­ory as the player moved for­ward, and drop­ping off-screen chunks as they were no longer re­quired. This ‘tile-man­age­ment’ sys­tem was in­cred­i­bly com­pli­cated, re­quir­ing a huge amount of work to op­ti­mize and ne­ces­si­tat­ing lengthy load­ing times be­tween screens.

Also, the di­vid­ing of back­grounds in Baldur’s Gate into tiles in­creased the as­sets of an al­ready huge game ex­po­nen­tially. “At the time, most games were throw­ing around 100, 200, 500 in-game as­sets,” Oster says. “Baldur’s Gate was throw­ing around 20,000 to 30,000. If you count in­di­vid­ual tiles that made up ar­eas, it was into the hun­dreds of thou­sands.”

To man­age these as­sets, BioWare’s lead pro­gram­mer Scott Grieg cre­ated a mem­ory man­age­ment sys­tem called Chitin. This worked a lit­tle like a slide pro­jec­tor, of­fer­ing your 4MB PC a tiny win­dow into Baldur’s Gate’s larger dataset. But prob­lems arose when Grieg de­cided to make Chitin mul­ti­threaded. “Chitin wasn’t mul­ti­threaded in­her­ently. But part­way through de­vel­op­ment they de­signed the AI sys­tem and pathfind­ing sys­tem, and part of that was get­ting ex­cited about the idea of mul­ti­thread­ing,” Oster says. In the­ory, this was a great way of of­fload­ing the data In­fin­ity had to crunch through to make the game work. But at the time, mul­ti­core pro­ces­sors didn’t ex­ist. “When you ac­tu­ally think through how the data is held in the pro­ces­sor, and how it’s in­ter­acted with, what you just en­gi­neered is a sce­nario for count­less pipe­line stalls,” Oster points out.

The team tried to al­le­vi­ate this prob­lem by high­light­ing cer­tain threads as ‘crit­i­cal’, which meant they had to com­plete their pro­cess­ing be­fore any other threads could run. But Baldur’s Gate had over a mil­lion lines of code, so many crit­i­cal threads were not la­belled as such, re­sult­ing in mas­sive per­for­mance headaches. Oster points out that in the code base there are five sep­a­rate ways play­ers can trig­ger an area tran­si­tion. “In many cases, it was code that was al­most iden­ti­cal but lit­er­ally dif­fer­ent by one or two pa­ram­e­ters.”

Cover-up job

Amongst these core tech­ni­cal is­sues were dozens of other prob­lems. Baldur’s Gate’s UI is not an over­lay, it’s hard-coded into the game. Again, this was done to in­crease per­for­mance. “Baldur’s Gate’s UI is fat to cover up the screen, so you don’t have to ren­der as much of the back­ground,” But this also meant the only way to change the over­lay 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 break the game.

All this meant BioWare cre­ated prob­lems that could only be solved through brute force, test­ing every line of code, painstak­ingly clip­ping out ob­jects in the back­ground so char­ac­ters could walk be­hind walls. “The ap­proach BioWare took at the time, was, ‘We don’t know the right way to do this, we don’t know how to au­to­mate things. Let’s throw hu­mans at the prob­lem, and with enough sweat the prob­lem will go away,’ re­mem­bers Oster.

This, ul­ti­mately, is the real story of Baldur’s Gate. The tri­als of BioWare’s In­fin­ity En­gine were not just tech­ni­cal, they were phys­i­cal, too. “It was a mon­u­men­tal achieve­ment at the time,” Oster con­cludes.