The Engine Room: Build
The life and times of the other FPS engine of the Nineties – here’s how Build brought Duke, Caleb, Lo Wang and others to life in ways contemporaries just couldn’t manage. And included the ability to use toilets in games, of course
In a brand-new feature we take a look at one of the earliest 3D game engines
In 1996, two games were vying for attention in the PC gaming world: Quake and Duke Nukem 3D. Quake, created by the already legendary team of coding geniuses behind Wolfenstein 3D and Doom, was the powerhouse of the duo. The industrial medieval FPS raised the bar for the genre as a whole, made fully threedimensional shooters the norm, and changed the face of online multiplayer forever. It was – and is – one of the most influential games ever made, and rightly appears on lists of the greatest of all time wherever you look. The other game said ‘3D’ in its title, even though it wasn’t truly 3D.
It should have been cut and dry – a clear cut case of one franchise wiping the floor with the other, such was Quake’s undeniable technological weight, as well as the huge amount of hype behind its release. And yet… we still talk about this competition, we debate about which is the better game, Quake or Duke Nukem 3D. Even though one game was backed by what became one of the most iterated and built-upon engines of all time, we still fondly remember the other one. Duke Nukem 3D, you see, goes hand in hand with the Build engine – and the Build engine changed first-person shooters as much as Quake’s, even without that fancy actual 3D lark.
For you see, Build was the pluckiest of underdogs; an engine that might not have had the most grunt of the midnineties behind it, but one that offered a simplicity and straightforwardness
– as well as efficiency – that hit an indefinable sweet spot for developers. And as if this were a story being written specifically to throw twists and turns at the feet of you, dear reader, the man behind Build was… well, a teenager.
Ken Silverman was a 17-year-old born in New York State (and relocated to Rhode Island when his father took on a professorship at Brown University), who had been tinkering with programming from a young age. His experimentation and dedication to the hobby of making stuff took a turn for the professional in 1993 with the release of Ken’s Labyrinth – this Wolfenstein 3D-inspired firstperson game caught the attention of Epic Mega games (well before the days of the Unreal Engine), which eventually released it under the then-typical episodic shareware model.
Ken’s Labyrinth was pretty simplistic – though it featured the ability to interact with vending machines, foreshadowing things to come in Build games – but it did act as the catalyst for Ken’s career. A few months later in 1993, just before he started at college, the teen had signed a contract with Apogee Software to create what would become the Build engine. “After the release of Ken’s Labyrinth, id [Software] put out a press release and some screenshots of Doom,” Ken remembers. “Naturally, I was curious to try to make my own, just as I had done with Wolfenstein 3D and Comanche Maximum Overkill. I started playing around with an angled wall renderer in March of 1993.”
These experiments were encouraged by Ken’s father, who convinced his son to pitch the nascent engine out to publishers around the States. In one of
compared to doom, Build had a smoother framerate – because doom limited its fps to 35 Ken silverman
those cute quirks of fate, it was Scott Miller’s Apogee that showed the most interest, this being the company that both created the shareware model, as used for Ken’s Labyrinth, and gave what became id Software, the studio behind Doom, its first break. It is, after all, a small industry. “Ken’s Labyrinth was less a game, and more of a demo, showing that it wasn’t just the geniuses at id who could pull off fast 3D gaming technology,” Scott explains.
“[Ken] contacted us and we discussed working on a project together,” he continues, “I mentioned that I could put together a team to use his engine. Ken showed us a demo of his Build engine, which would be similar to the engine he knew that id was creating for their coming game, Doom.” It was in such an early state that Ken hadn’t even thought of a name for his creation – but with the program file itself called build.exe, the decision seemed a simple one and so the Build engine was born.
With college approaching – Ken would attend Brown to major in Applied Maths – negotiations about time and study were delicate. With his father helping out in deciding employment arrangements, Ken soon signed up with Apogee and began work in a professional capacity on the engine. Build as we ended up knowing it was born, and soon enough the tech started to speak for itself. u
nfortunately, while the tech impressed, the first two games using Build – both from Capstone Software, and both released in 1995 – were underwhelming to say the least. Witchaven, a fantasy first-person RPG, had some good ideas but was ultimately incredibly dull, while William Shatner’s Tekwar was a wildly ambitious, absolutely terrible cult non-classic. Both titles, though, showed the underlying promise of what Ken had been working on – now full-time after taking a temporary leave of absence from his studies – and it was apparent that Build had a lot of positives over what the Doom engine had wowed everyone with just a year or two previously.
“Compared to Doom, Build had a smoother framerate – because Doom limited its fps to 35 to support simple networking,” Ken explains. “With Build, I had to implement interpolation for the player, sprites, doors and so on, to support rendering at an independent framerate from the physics/network code.” Though players probably weren’t picking up on such technical aspects of what Build offered, there were some things shining through immediately – sloping floors and ceilings differentiated it from Doom’s engine, and there was a much bigger push towards interactivity in the games created with Build, likely brought to life thanks to a map editor
it was stressful being asked to implement things that i had never done before Ken silverman
that allowed designers to quickly switch from editing to playing on the fly.
“The Build engine was quite an improvement over id’s Doom generation of engine tech,” Scott says. “Build had slopes, looking up and down, destructible walls, it could do room-over-rooms [with a bit of jiggery-pokery behind the scenes – RG] and catwalks, and several other nice improvements.” The praise wasn’t just coming from his employers either, with even id’s own John Carmack a very public fan of Ken – even offering advice on improving Build at an early stage. But there was still no killer app – nothing beyond capable tech and a hardworking, albeit stressed, young coder.
“There were plenty of good and bad times,” Ken remembers. “It was stressful being asked to implement things that I had never done before. Before Build, I had never written code that was to be used by others. And figuring out the networking code was quite a challenge.” But it wasn’t all bad, as Ken continues: “My favourite part of working in a team was watching others use the engine or tools in cool ways that I never thought of. When you’re the only one making significant contributions, nothing is a surprise – and that gets boring quickly.”
With a renewed energy as part of a team – and all
the help that comes with working collaboratively – Ken and the Apogee team (soon to be rebranded as 3D Realms) would unleash what it had been working on for some time. For you see, Build wasn’t being built apropos of nothing – there was a certain 1996 FPS being crafted in and around the engine, informing as much of Build’s development as the underlying code informed the game. January 1996 hit, and with it came Duke Nukem 3D – Build’s killer app, and the game that showed you didn’t actually need all the fancy tricks in the world id was showing off to make a game a true great.
Duke was different – not the typical run-and-gun we were used to by that point, the game (as well as jogging and blasting) encouraged exploration and experimentation, rewarded interaction (ten health for using the toilet, natch), and presented players with levels that
would and could dynamically alter on the fly. Who could have predicted those earthquakes that hit in the very first level, warping and destroying part of the building you’re in? It was a revelation, even if on paper it looked like the other 2.5D engines of the time.
“Build is just so well suited for manipulating levels in real time,”
Scott says, “such as falling buildings, exploding walls that lead to new areas, interactivity, and the vast size of levels and high speed of moving around.” This countered id’s design philosophy at the time, which veered much more towards simplicity and focus: “That was very valid and successful,” Scott says, “But with Build we decided to go overboard with features that, in the end, we thought would set us apart and allow our games to do all sorts of things that other games weren’t doing.”
The line had been drawn in the sand – Build, an otherwise limited engine, would provide developers with the ability to make something technologically better than Doom, and for far cheaper than what that license was being sold for.
Duke Nukem brought tight action and a thoroughly compelling game with more than enough silliness infecting it to have set out the stall. Build was to be for the ambitious few, on a low budget, who liked to muck about.
“We started on Blood in early 1994, long before Quake was released” Peter Freese, lead programmer on Monolith’s excellent 1997 shooter explains, “At the time, there weren’t many choices for licensable engines available. There was the choice between the Doom engine, which was outside our budget, and building our own technology from scratch. Working with Apogee – we originally started out as an Apogee studio – gave us access to the Build engine via our publishing agreement through Apogee.”
Peter goes on to say he and the Blood dev team found Build to be a ‘competitive’ engine, but one with limits that were readily apparent: “There were a lot of limits in the types of environments we could create,” he says. “But in a way, being more limited allowed us to be more creative in other ways… Because we were constantly struggling against things we couldn’t do with the engine, versus a full-3d engine, we had to come up with crazy ideas to distinguish ourselves. The room-over-room trick that we created was one example of this.”
Enforced boundaries frequently make for creative solutions to problems, and the lack of coasting was apparent on Blood’s release. Today considered one of the best of Build’s releases, along with Duke 3D, Shadow Warrior and – to a lesser extent – Redneck Rampage, it offered a macabre tale filled with gore, backed up by creative scenarios, puzzlesolving, exploration and weapons. Nobody who played Blood can forget the aerosol/lighter combo.
Releases using Build had quickly shed the moniker of ‘Doom clone’ and become their own, captivating thing – even in a post-quake world where many eyes were on the big boy of the genre, Build was backing some of the greats of the mid-nineties. In fact, in some ways Build had even managed to scoop Quake, according to Ken: “People may point out that Quake’s networking code was better due to its drop-in networking support, [but] it did not support client side prediction in the beginning,” he explains. “That’s something I had come up with first and first implemented in the January 1996 release of Duke 3D shareware. It kind of pisses me off that the Wikipedia article on ‘client side prediction’ gives credit to Quakeworld due to a lack of credible citations about Duke 3D.”
It wasn’t all grit-and-spit, of course – Build always had some fine positives that kept developers using it and helped them bring out the likes of the 1997 double-whammy of Shadow Warrior and Redneck Rampage. Each iterated on what had come before, modifying and speccing up the underlying tech while ladling on a fair amount of snark, cheek, silliness and questionable content. “I think Build and Duke go hand-in-hand, with each raising the stock value of the other,” Scott muses. “I think that Duke Nukem 3D set the tone for Build engine games, especially with humour, talking characters, popculture references, and other craziness. Again, id Software made very serious, streamlined games, so we took our games (Duke Nukem 3D and Shadow Warrior) in a different direction, and the other teams who licensed Build followed our lead, I guess.”
On a technical level there were benefits too, with the aforementioned streamlined editor proving a hit with anyone making levels: “Probably the best, most innovative, feature of Build was its 3D Editor,”
Ken explains. “As it allowed you to edit inside the game itself in the full 3D mode, I believe it was the first game engine to support this.”
Peter, meanwhile, is a fan of Build’s optimisation: “Build had really excellent rendering performance,” he says, “Which was difficult to achieve on desktop hardware at the time. There was some crazy optimised assembly texture mapping code that enabled us to achieve great framerates while still spending processor time doing gameplay stuff.”
Ease of use, smart optimisation, clearly defined limits pushing developers
to work within boundaries, and an anarchic, devil may care, very Nineties attitude behind its games. Build from 1996 to 1998 mattered, and its many positives kept an objectively inferior engine fresh in the minds of many. But it wasn’t 3D, and it wasn’t ever going to be, and the world had gone for that extra dimension. Developers moved on, the engine was left treading water, and history had all but stopped recording the trials and tribulations of Build, the plucky engine that could.
As brightly as it burned for a few years, by 1999 – aside from another Duke Nukem expansion pack – there was little to celebrate using Build.
NAM and Extreme Paintbrawl offered absolutely nothing memorable, and
1999 saw the final commercial release using the Build engine: World War II
GI. It was, as you may have gathered from the fact you likely don’t know what it is, ignorable at best. With releases
probably the best, most innovative, feature of Build was its 3d editor Ken silverman
(the first illegally) from 1994-1999 and seeing three genuine classics, and one arguable, redneck, classic, Build had a good run. But it was over.
Ken Silverman had already moved on by this point, returning to his studies and graduating, working on some other engine projects – including an early version of Build2, available on his website – before ending up at Voxon Photonics, working on a 3D volumetric display known as the Voxiebox. While it was the end of Ken’s story with the engine he created, though, it turned out not to be the end for Build itself – 3D Realms announced in 2018 it would be publishing Ion Maiden, a brand-new, commercial release using Eduke32, a modernised source port of Build. Who needs Unreal, right?
Strangely enough, we’re living in a world where a 20-plus-year-old game engine is being used to create a new commercially released game, and where the gatekeepers of said engine are looking to bring more proper, full titles to release using the modernised version of Build. On one hand, it could be a wave of nostalgia – cloyingly devoted to a technology that has been bettered many times over, monetising our rose-tinted natures and charging us to remember the Nineties. But then, on the other hand, this could all be testament to the fact Build is, and was, an engine supportive of and supported by very creative developers and designers. Sure, it’s a move backed by nostalgia, but that nostalgia itself is backed by release after release in the mid-nineties of all notable in their own way – games of true uniqueness, games of genuine quality and inventiveness, games that had great ideas realised through Build’s robustness, games featuring William Shatner. Build had it all, and it might just be that modern developers still want to tap into that resource and give us a few rose-tinted memories to look back on in 20 years’ time.