Back in the early days of id Software, in December 1990, Tom, Carmack, Adrian, and I hatched a plan for the ultimate RPG. We were inspired by our D&D adventures, all of us gathered around John Carmack’s expansive gaming table with snacks, Coke, Dr Pepper, and plenty of pizza. In our campaign, there was a powerful group known as the ominous Silver Shadow Band. Its members rode on the back of a giant silver dragon, and if anyone saw its shadow, they knew the Band was either high above or nearby. Each character in the Silver Shadow Band was the ultimate expression of one of D&D’s stats, from the most intelligent character to one capable of nearly splitting our universe in half with his strength. That strongest character was Quake. To us, Quake was legendary, and he may as well have been only that. As a bunch of low-level peons, we rarely saw him or other high-level characters. However, we were lucky to go on an awesome adventure with him once or twice. The Silver Shadow Band did contract work for Justice, an even more powerful group. To us, Quake became more than just a character, and our adventures with him were the highlights of hundreds of hours of dungeon crawling. He was the embodiment of a superhero in a world of our own making.
We thought it would be incredible to play as Quake in a computer game—to wield that kind of superhuman strength, to fly on the back of a dragon. And who wouldn’t want to use his two extraordinary superpowers? First was his hammer, capable of destroying most everything in his path, which we imagined players using as Quake used it—to flatten enemies to paste. Second was the omnipotent Hellgate Cube, which floated above Quake and delivered devilish damage to enemies that dared challenge him. Sizzling Quake’s foes with lightning bolts seemed to be the Hellgate Cube’s favorite action.
As we were finishing up our first Keen trilogy in December 1990, we were enthusiastic about making Quake our next game and introducing him to our growing fanbase. Quake was going to be our next game. We even inserted this promo text into the first, official id Software release, Commander Keen in Invasion of the Vorticons:
COMING SOON FROM ID SOFTWARE
As our follow-up to the Commander Keen trilogy, id Software is working on “The Fight for Justice”: a completely new approach to fantasy gaming. You start not as a weakling with no food—you start as Quake, the strongest, most dangerous person on the continent. You start off with a Hammer of Thunderbolts, a Ring of Regeneration, and a trans-dimensional artifact. Here the fun begins. You fight for Justice, a secret organization devoted to vanquishing evil from the land! This is role-playing excitement.
Hyped by that premise, when Commander Keen shipped on December 14, 1990, we headed off for our Christmas vacations, but our imaginations exploded with ideas. We imagined Quake as a proto-God of War-like character battling huge enemies; our D&D adventures made real! However, we had just shipped our first 2D side-scroller, which in itself was a huge innovation. The distance between what we just shipped and what we envisioned? Light years. We wanted to put more on the screen and to give the player substantial agency in their gameplay, but CPUs were still slow, and the technology available couldn’t match the game in our heads.
Moments like this one, what I call the “possibility bridge,” are common in game development. As game developers, we have to see beyond the current horizon to imagine the possibilities that others either didn’t see or saw but overlooked. Thinking What if? and coming up with functional answers to that question leads to innovation. However, it’s not always possible to bridge the gap between imagination and what one can actually do with the available technology or resources. With Dangerous Dave in “Copyright Infringement,” Carmack believed he could cross the smooth-scrolling bridge, and he did. With DOOM, I believed I could create new dimensions in gameplay and game space by inventing the abstract level design style, and I did. There was no way we were crossing this “Quake” bridge in early 1991, though, and on that we were unanimous. We didn’t want to deliver a version of Quake that was anything less than what we envisioned Quake to be—supremely powerful, badass, and without parallel. We decided to put it on ice, but the dream of Quake never went away.
And so, in late 1994, with DOOM II out the door, Heretic about to launch, and the continued avalanche of DOOM-themed product opportunities, our development team had a meeting to discuss our next original game. Everyone who shipped DOOM II was there: Carmack, Adrian, Kevin, Dave, Sandy, American, and me. We knew what we were there for, and the sense of excitement was palpable. While it seems like a no-brainer that another FPS was in the cards, that wasn’t a given. When we entered the room, all we knew was that we were making something new.
Once everyone was seated, Carmack kicked things off. He had been doing research into a new engine for quite some time while we were cranking out DOOM II’s levels.
“Okay, we’re here to talk about our next big game,” Carmack began. “I’ve been thinking about the next technological improvements we could make, going beyond DOOM II.”
“That’s what I like to hear!” I said. Carmack and I agreed that the DOOM II engine was only going to take us so far, especially since the modding community had embraced it and was producing a continuous stream of content. We had to do something new. That, and we liked chasing new tech. Since Commander Keen, we had become tech-authoritative, because technology was what enabled our game design to have a leading edge.
American chimed in to agree. “This’ll be great,” he said, smiling.
“Our next game engine is going to be fully 3D with better gradient lighting,* and play over the internet using a client-server model,”† Carmack continued. He was eager and excited, and listening to him talk, so was I.
“Awesome, we can finally make Quake!” I exclaimed.
Hearing him say “fully 3D” was all it took. The possibilities for enhanced play and game design were obvious to me. Any design ideas I had were possible, because in full 3D, anything is possible. It gave players a full six degrees of freedom: right and left, forward and back, and, critically, up and down. We were reaching a technological tipping point, where constraints of the past were disappearing. With DOOM and DOOM II, most players believed that they were playing in a true 3D world, but it was a carefully crafted illusion. The levels were rendered in 3D, but everything else—enemies, walls, floors, stairs, you name it—happened on a 2D plane. Textures were projected onto X and Y coordinates in such a way that it created the illusion of perspective. Enemies were made smaller if they were farther away, and environment textures were stretched accordingly. With the exception of programmers and artists, many people probably didn’t notice the illusion, and we took that illusion as far as we could with elevators and elevation changes. It wasn’t 3D, though. We called it 2.5D, and while it was genuinely amazing, it limited the design potential. With a 3D engine, that was no longer the case. With true 3D, we could have one area directly over another, truly vary elevation, and allow all game entities and objects to exist in 3D space. This innovation dramatically changed the potential of level design, strategy of movement, and gameplay.
As a game designer, with each iteration of Carmack’s tech, I pushed the hell out of it, suggesting things I suspected the engine could do and creating the best gameplay from each iteration of the engine provided. Being a programmer myself allowed me to connect with Carmack and understand his intent in a way I suspect few others could. It also gave me a window into the possibility and potential of his engine because I understood it and respected it from a technical perspective. We were a great match and enjoyed working together. While this was a significant technical challenge, I felt confident he could do it. With Carmack, when he says he’s going to do something, it’s not a wish or a possibility. It’s done.
When I said we could make Quake, though, most people in the room had no idea what I was talking about.
“Quake?” American asked.
“Yes, Quake!” I said again.
Sandy echoed American: “What’s that?”
“Quake is a game idea we had in 1990 that we abandoned because we didn’t have the tech to make it. I mean, nobody had the tech. This new engine—a fully 3D engine—could do it,” I said.
Sandy was curious. “What’s it about?”
“So, back four years ago or so, we wanted to make this game about a badass named Quake,” I said. I filled them in on the adventures of the Silver Shadow Band, Justice, Quake’s hammer, and Hellgate Cube. As D&D players themselves, they got it, and like I said before, who wouldn’t want to play as a superpowered character like Quake?
“It was going to be an RPG, but we can make it into anything,” I said. At one time, we imagined being kings of every genre.
Adrian remembered Quake and our 1991 hopes for the game.
“Sounds good to me!” he said. I knew that Adrian’s imagination was already considering new ways to scare the hell out of players in full 3D with the better lighting possibilities offering even more options to him.
“Then it’s settled! Quake it is!” Carmack declared.
This was usually how our big game decisions went—some quick thinking, some agreement, and our destiny was set for the next year or so. Of course, there were many more meetings to be had, but the big picture, the “where are we going” part of the journey, was decided. Carmack was just beginning his tech R&D, so it would be a while before the rest of the team could jump in, and as much as Quake tried to overtake my conscious thought, I decided to wait until January to dig into the possibilities for Quake’s design. For me, December was going to be a busy month.
For starters, I was writing the DWANGO client in preparation for shipping it on the Heretic disk. There was a lot of activity between me and Kee to get the DWANGO.EXE program working as intended: downloading DWANGO server phone numbers from their master list, allowing connection to any DWANGO server over the modem, authenticating the player logging in, handling a busy lobby full of players talking to one another (and sending messages from the lobby into active games, too), launching deathmatches, and handling credit cards. It was nothing short of revolutionary to have a pre-internet service where players dialed in and just started chatting and playing with other people. Players used to have to call one another on a landline and agree to connect modems to play. DWANGO was the bridge between the dark ages of modems and the shiny new internet. DWANGO supported DOOM, DOOM II, and Heretic at release.
Heretic was also in the closing stages, and I flew to Wisconsin near the middle of December to oversee the final state of the game and to make sure all the features were in. The excitement and energy of the Raven team was unmistakable. Examining the build, I was so impressed. Their skills expanded with their exposure to NeXTSTEP and the DOS cross-development environment.* Design wise, creating abstract level designs was an altogether new thing for anyone outside of id, but they had embraced the style and delivered. Beyond that? There are so many things big and small that go into shipping a game. That they did it in just one year showed how skilled and in sync the Heretic team was. I felt good about the time I spent pursuing this deal, directing the game, and helping to get it across the line. It was well worth it and satisfied my goal of expanding id Software’s business.
While there, I had to adapt our LAN and modem connection programs for Heretic since they were made for DOOM and DOOM II. I also updated my DM.EXE program to support Heretic. Testing my code and the game, Heretic really felt like an id Software game. It played great. I approved the gold master† as final, and the team and I celebrated with dinner before I flew back to Dallas. At 11 p.m. on December 23, 1994, I uploaded the shareware version of Heretic as HTICV1_0. ZIP from home. Like DOOM, Heretic shipped as shareware with a registered boxed version available directly from us. Heretic sold half a million copies in its first year and generated a hefty return on id’s investment of $500,000. Raven did an excellent job.
At long last, it was time for a holiday. They were never intentional, these January-to-Christmas development periods, but over the previous few years it just seemed to be the way it worked. The success of our games gave us the ability to give gifts like we were Santa Claus, and I loaded everyone up with presents, especially Michael and Steven, who loved LEGO. I got Kelly and the boys a new house, too. They were still in California, but we traveled back and forth as often as we could. Meanwhile, at home, Beth was doing well and was busy getting our house ready. Her love of cooking filled the air with smells of the holidays—cookies, cakes, and dinner roasts—and visions of starting work on Quake in the new year danced in my head.
As 1995 began, anticipation greeted us on our return to the office. I wondered if Carmack had done anything over the holidays. He and I both had the same tendency to work over breaks. Since he’d announced his desire to create a fully 3D engine, I had not been able to shut my brain off and had been doing a lot of research. I woke up, fell asleep, and dreamt thinking about Quake’s design and 3D gameplay. What possibilities would the new engine offer?
Nowadays, when game programmers start assembling the technology for a new game, the first question is often, “Which engine should we use?” It’s a question as important as “What game should we make?” In 1995, we didn’t ask this question, because there were no “off the shelf” engines to use—we crafted our own engines for our designs from the ground up, and that took a lot of expertise and time. If we wanted an engine that was high-speed, full-3D, texture-mapped, internet-aware, server-based, and capable of making Quake, we had to invent it. There was no engine that could do what we wanted it to do, and these were all the things we wanted Quake’s tech to be.
Our first task as a team was to explore the design and tech possibilities for Quake. Carmack and I sat down in his office to discuss it. These two primary pillars of id Software—engine and design—were inherently linked to one another in a Möbius strip. The gameplay design dictated the needs of the engine, while the engine gave potential to the game’s design. Carmack and I were always pushing on those edges from the inside. From Carmack: “What if the engine did this? How might that affect gameplay?” From me: “If the engine could support this, I could get this gameplay.” It worked in the other direction, too. The engine could constrain the design or the design could slow down the engine, but avoiding those issues was an unstated goal of ours. These conversations were always engaging negotiations and never edicts.
I had spent a lot of time thinking about the design of Quake, beginning with its birth as a character in our D&D campaign to its abandoned 1991 post-Keen incarnation right up through to today.* What, if any, gameplay features did we want to keep? What did I want to add? There were so many things we could do in 3D, and the trick was to focus on only those things that gave us the best gameplay and game design for the engine in question. Heading into the meeting, and knowing the engine would be 3D, I envisioned bringing these features forward from our 1991 RPG attempt:
• A main character, Quake, who was an all-powerful badass.
• A medieval world reflective of our D&D adventures, which took place mostly outdoors in rich settings.
• Quake’s powerful hammer, which, when thrown, returned to him.
• A small extra-dimensional entity, the Hellgate Cube, that orbited Quake and attacked enemies. It also had the potential to go off exploring.
• Integration of a silver dragon, if only aesthetically.
Additionally, I wanted to focus on these new features to take advantage of and show off what Carmack had shared about his engine plans thus far:
• An action RPG with a fantasy aesthetic, where stats and stat management were not at the forefront and potentially not included at all.
• Continuation of Design Rule #8: If a level could be made in DOOM II, then it’s not good enough for Quake. Design needed to be as cutting edge as our engine. Looking up and looking down needed be key pillars of our level design.
• Multiplayer gameplay that emphasized single, co-op, or deathmatch play between two or more players. The client-server model allowed us to have more than four players in the game, and I wanted to explore what we could do with this.
Beyond these features, there were too many dependencies between code and design to dig in deeper. As the design director, it was necessary to have a clear understanding of Carmack’s key engine features, so I was eager to have our discussion. For game design well into the 1990s, this negotiation between design and code was a quintessential chicken-or-egg problem. When the engine is already done, as it is with today’s Unreal Engine, much of the gameplay, or at least suggested optimum gameplay, is built into the engine itself, and the team chooses the best engine for a predetermined design job. The Unreal Engine, for instance, is used for many FPS games because it was originally built as an FPS engine. When there is no engine, though, it’s a question of which comes first, the design or the engine? In our case, only the core of the engine came first (a 3D engine with a client-server model) and then grew by design from there. Carmack and I had a collaborative process so that one idea played off another.
It’s a challenge to get across the complexity of this situation for people who were not developing games at the time, but this might help: look at the features in latest Unreal Engine. Now, get rid of all of them except the online and 3D bits. That’s where we started with no idea of where we were going. Every idea Carmack and I discussed was balanced on every other idea to consider whether they might work together. The engine was still just an idea of a 3D space. Even fundamental stuff like movement, physics, weapons, and enemies didn’t exist. The features that design scoped out affected code and vice versa. In essence, we were designing the world and what you could do in that world simultaneously, accepting benefits and trade-offs. It’s a collaborative partnership where we want code to be just as excited about what it’s building as design is about what it can create.
Sitting in Carmack’s office, we were both looking forward to exploring Quake’s possibilities. We were still using NeXTSTEP workstations to develop Quake, and we were sticking with the C language, not C++, for speed (Objective-C was used only for the tools that I wrote). On the art side, we had a new workstation added to the mix, the Silicon Graphics Indigo, which we planned to use for 3D modeling. As always, game development is fluid, and I recognized that nothing we were here to discuss was promised or written in stone. However, I hoped to come away from this meeting with an understanding of the baseline design of the engine. Knowing how Carmack planned to architect it allowed us designers to make a more advanced game.
Carmack began with, “Okay, well, I’m going to base the engine on a new networking model where game clients connect to a game server. Multiple Quake clients will connect to a Quake server for single, deathmatch, or co-op play. If you’re playing single-player, you will have the server and client running on the same PC. You could also host a multiplayer game on your PC and other PCs can connect to it.”
The great thing about the client-server model is that players wouldn’t be limited by the network speed of other Quake players that were connected to the same server. With DOOM, everyone who was in a multiplayer game ran at the speed of the slowest player’s connection because they all had to be in perfect sync with each other. With Quake, that limitation was gone.* Players were going to love it. The client-server technology was new at the time. Our only experience with game network models was DOOM’s peer-to-peer model. The client-server model had not been used in an action game yet; it had only been used on mainframe computers for slow, primarily text-based games.
“Even better, there’s no way to cheat because the server is authoritative,” he continued. “The server is what runs the game code, and the clients are merely displaying the state of the game. They can only send commands to the server.”
I was curious, though. “You’re going to need to write that code first then?”
The order in which he wrote the code dictated what the design team was able to do.
“Yes, I need to get the networking architecture working so it’s passing information between the client and server and simulating a game. Then, I can start working on the client architecture and the renderer.”
I nodded. The success of the client-server code affected everything else he planned to write. We discussed the technical details of the architecture and imagined how it might affect gameplay, particularly deathmatch gameplay. Even though we were here to discuss Quake, new technology excited both of us, and we enjoyed these conversations. We were also eager to talk about the 3D engine because of the opportunities it afforded for gameplay.
“I’ve been thinking of a scene on a hilltop where the player is looking down at some enemy he wants to take out,” I said. “Another player comes up behind him and—SLAM!—smashes him in the back of the head with their hammer, and the first player is falling forward down the hill and their entire view is rotating on that axis as it would in real life.”
I was standing, waving my hands like a conductor. “Or imagine a central hub area where you can see into these other paths. One of the paths has some crazy huge monster patrolling in it, and the others are either empty or have some minor enemies milling around. Imagine feeling like Quake, all powerful, and you could just jump right into that shit, take on the boss and experience sheer terror right away! I want players to know that the game is hard-core dangerous, and that we’re not trying to hold their hand.”
We could see it and feel the potential experience. Everything else that was out there wasn’t even close. DOOM, Heretic, and Rise of the Triad were 2.5D. Even games in development that we knew about, like Duke Nukem 3D, weren’t close. Ultima Underworld was true 3D with six degrees of freedom, but it also had six degrees of slowness, and didn’t fit with the fast-paced action RPG we were leaning toward. Myst, which continued to top the charts along with DOOM and DOOM II, continued to baffle us. We didn’t understand the lure of an empty, slow-paced world. We knew players liked the story, but we were interested in creating games that let players make their own stories about amazing battles or deathmatch victories. Seeing the potential for Quake was an incredible place for us to be.
Carmack shared more about the research and work he had been doing thus far. Everything Carmack said about his code translated into a potential player experience in my mind.
“I’m really happy we’re going to true 3D,” I said. “No more sprites.”
“Well, we will be limiting the use of sprites to UI elements only, I hope. The world will be textured, and we will have twice the light levels as DOOM. The lighting will depend on where you place lights in the world and how bright you make them.”
Calculating the light in the level was a huge step forward for level design. Instead of meticulously specifying the light level of every area in the game, we were now able to put lights wherever we liked, with a brightness level for each light. In turn, the engine knew how to cast that light into the world and created wall textures that transitioned from bright to dark smoothly. In DOOM, the entire wall texture was always the same light level. In Quake, walls could now have complex lighting patterns depending on where the lights shone. In a nutshell, it allowed artists and level designers to create far more realistic and immersive environments.
“Can you imagine a Baron of Hell coming out of that darkness?” We didn’t have enemies for Quake yet, so I substituted one of DOOM’s instead. I had never been so excited about the potential of a game.
“So, okay, thinking of those enemies, what are you planning to do for the video buffer? Are we still using 8-bit or are we going 16-bit color?” I asked.
The bit depth of the video buffer—either 8-bit or 16-bit—determined the amount of colors I’d have to work with. With 16-bit color, I had 65,536 colors at my disposal. With 8-bit, it was just 256. Carmack’s answer determined whether I would be designing colorful creatures or mud monsters. In addition, 16-bit color mode would allow for smooth gradient shadows.
Carmack was writing the renderer, so he had a feeling 16-bit was too much data for current video cards. “We are going with VGA to start because the data size is one byte per pixel versus two bytes per pixel,” he said, “and I want to be above 30fps (frames per second) frames per second and closer to 60fps.”
That made perfect sense—drawing twice as much data takes twice as long and slows down the framerate. Getting close to 60fps was critical for movement to feel good. Future 3D video cards would be able to handle 16-bit color at a high framerate, but we weren’t there yet. I wasn’t at all disappointed. I just needed to know what I had to work with.
“With shadows, that means we will have fewer colors to use. How many levels of brightness will the colors have?”
I needed to know the levels of brightness to determine how many distinct colors were on my palette. If each color had four levels of brightness, for instance, that meant I had 64 distinct colors to work with since each of those four would be coming out of 256 colors total (64 colors x 4 levels of gradient each). However, I knew there would need to be more levels of gradient than that to get the effect we wanted.
“Well, yes, we will have fewer colors,” he said. “I plan on having sixteen levels of brightness per color, so that would be a maximum of sixteen colors in the 256-color VGA palette,” he said.
“Hmm, well, if Quake is a medieval game, the limited color palette will probably work. Lots of mud and rock colors.” I laughed, “Plus red, of course.”
“Medieval would work perfectly with that palette,” he agreed.
“Since we’re making Quake, and he has his huge hammer, this game could be about hand-to-hand combat, like, imagine completely obliterating something, smashing it and hammering it to gibs*,” I mused.
“And don’t forget the Hellgate Cube. It has a mind of its own!” Carmack laughed.
“Yeah, maybe it needs you to pulverize enemies to feed it? If you don’t feed it often enough, it could get upset and leave for a while.” I was into it. “But if it’s happy, it can suck the souls out of your enemies. Also, you could have a devastating area attack if you slam the hammer into the ground, like if you get surrounded. Will we be able to have camera shakes for that?”
“Definitely, that will be easy with the way I plan on setting up the gameplay code. I’m going to write a simple C-like programming language so designers and coders can add whatever they like and see it work immediately. The server will just load the files and parse them quickly,” Carmack said.
This was exciting. What Carmack was doing was separating the engine from the gameplay. The division between engine and gameplay can be tricky for those not in the industry to understand, so I’ll explain it this way: Imagine the engine is an actual car engine. It has the basic rules by which it functions to turn gas into power. The gameplay is what happens when the player presses on the gas or the brake, changes gears, or installs a nitrous switch to supercharge the fuel intake. All of these things affect the engine, but the engine needs to be specifically programmed to respond to these inputs. So, a game designer programs “press the gas” and Carmack programs the engine to respond to that gameplay. That’s the basic idea, anyway. An engine might allow for the player to walk in the game world. The gameplay is what happens when a player steps on a trigger, thus opening up a monster closet, and takes a bunch of fireballs to the back of their head.
For designers, separating the gameplay from the engine meant we could make quick gameplay changes without needing to compile the whole engine. What was minutes now took seconds. Even better, modders could just write code to make changes to the game. They would not need the Objective-C tools we used to build the game or access to Quake’s source. With our previous games, each build process compiled the entire engine. The process was a minute or two, which may not seem like much, but it adds up quickly when you are making dozens and dozens of iterations a day. It also breaks design flow.
“Such a great idea,” I said. “We could really increase our development speed.”
I thought for a moment to explore an example of how this might work.
“Here’s a test,” I said. “Since combat will be mostly up close, how about Quake throws his hammer for distance attacks? He did that in the D&D campaign, and it was awesome!”
“Sure, that could be done in the new language,” Carmack answered. “I’ll just call the language QuakeC. QuakeC can do the camera shakes, the hammer attacks, enemy AI, and anything else we need for gameplay.”
To the layperson, it may seem that separating the gameplay code from the engine would allow us to develop both of them quickly and independently. However, the gameplay QuakeC code could only do what the engine allowed it to do, so with the engine unfinished, there was less functionality in QuakeC. I’m getting ahead of myself here, but as an example, when QuakeC was first made, we could not put enemies in the game because the engine code didn’t handle moving AI characters around or drawing 3D models yet. Later, when the engine supported AI pathing and drawing of 3D models, QuakeC was changed to allow the drawing and moving of 3D enemy models. This is how, over time, the functionality of QuakeC increased, and we could eventually control all aspects of what the engine could do from QuakeC. In a nutshell, it meant that real gameplay code couldn’t be written until the engine was done—or stable, anyway. We could write parts of it incrementally, but not get a feel for how it all worked together, which is essential to game design and gameplay.
DOOM’s engine took two and a half months, and while Quake was certainly more complicated, we didn’t think it was light years away. Waiting for an engine to be developed was a necessity at id. We were also busy with plenty of other things. In the meantime, we level designers could experiment with QuakeC, but whatever we wrote was likely going to be tossed out with any big engine update or optimization.*
Next, we needed to pick a target CPU (central processing unit) to benchmark the game’s performance throughout development. Getting the game running smoothly on the target CPU would help ensure the game played well on release. With a lot of Assembly language programming, the latest 75Mhz Pentium CPUs in 1995 were fast enough to deliver the game we’d dreamed of, and they were only getting faster. At least, we felt certain it was within the range of possibility. In addition, we were now able to use two times more memory than DOOM, so we could spend some of that memory on speed optimizations to reach our 60fps target framerate, and some more of it on the complex 3D levels we were going to make. Having this extra memory meant not having the super-tight constraints of the past. For example, PC games before DOOM used only 640K of memory, which is why they were so limited in scope. Before that, in the ’80s, 8-bit computers typically had a maximum memory size of 64K—a tenth that of PCs in 1991. We still had constraints with Quake, of course, such as an upper memory size of 8MB, but on the whole, the extra memory allowed us to make a bigger, better-looking game.
I knew that with a move to a 3D engine, DoomEd, my long-serving level editor, was getting its walking papers. QuakeEd, like DoomEd, would be a tool to allow designers to create levels and connect objects we placed in the levels to QuakeC code for functionality such as enemy placement, torches, doors, item pickups, teleporters, and anything else we need. I’d need to code it from scratch to account for the new engine and our switch to 3D.
“I can’t write QuakeEd until you get to the client and start defining the world data,” I said.
“Correct. In the meantime, I’ll set up a skeleton project for it so I can add code for a 3D renderer when I have time. After I figure out the basics of world construction, I’ll define the data, and you can take it from there.”
Once Carmack had those bits defined, I could move forward with programming QuakeEd. Everything we had discussed from 3D to QuakeC sounded great to me. We had a preliminary idea of what we wanted, and as we began the new year, we had to create all the tools and tech necessary to make an engine capable of building a full 3D world. Even nowadays, FPSs push engines and computers to their limit, and creating an engine, the tools to support it, and a design to show it off is a Herculean task. We’d done it three times before, but this engine was the most complex one yet. We guessed it to be about ten times more difficult than DOOM’s engine. This metric allowed us to estimate the time it might take, but in the end, it was only a guess. We were charting new territory.
It was as good a time as any to sync up about business, and so I jumped into it.
“While you’re working on the engine, we’re going to get started on the retail version of registered DOOM,” I said.
Releasing a retail version of DOOM was long overdue. We had a deal with GT Interactive to put DOOM on store shelves, and I wanted to add a new episode, “Thy Flesh Consumed,” to create value and entice players who already had the shareware or mail-order versions.
“I’m sure it’ll reach way more people by being at retail,” I told him. “American and Shawn are going to pitch in along with some mappers. I’m calling it DOOM SE for now, Special Edition. I’ll update the codebase to v1.9 for it, and we can release a patch that upgrades our DOOM registered customers to it for free.”
Carmack nodded. I knew he was ready to get back to coding.
“Oh, one more thing. Since Heretic has shipped, I’m getting Raven started on the sequel. I’m calling it Heretic 2, but we’ll come up with a cool name later.”
With that, we both had our plans for the next little while, and based on our conversation, the design of Quake expanded to include new elements. If we had written a press release for Quake as we did for DOOM, it may have listed these additional features:
• Explore a dark and foreboding 3D medieval setting full of devilish and diabolical enemies.
• Engage in hand-to-hand and hammer-to-head combat with your foes using Quake’s devastating hammer.
• Rip enemies’ heads off and take them to a sacrificial altar to power yourself up.
• New damage reactions—hits to the back of the head can result in you falling face-forward and tumbling into a cavern.
• Collect an array of thrown weapons to target enemies before they get too close.
• Use your hammer for new area-of-effect attacks.
• Slay enemies to power up your Hellgate Cube, which feeds on their souls.
• Watch where you look—if enemies catch you looking in their direction, they might just come after you.
I couldn’t wait to get going on QuakeEd once Carmack determined the data structures, and, eventually, to get working on the game itself. Carmack returned to his work on the foundations of Quake’s 3D engine, and the rest of us got busy with DOOM SE, and I worked with Raven Software on the beginning of Heretic 2. Carmack was facing a massive programming challenge—building an engine from the ground up to do something neither he, nor anyone else, had done before—and I knew there was no place he’d rather be.
* Gradient lighting allows for smooth blending of color from one shade to another. Instead of blue direct to black, for instance, the blue progressively gets darker.
† A client-server model is a network architecture that allows clients to access a server to request and receive data. DOOM and DOOM II were peer-to-peer.
* A cross-development environment allows programmers to develop the game using a computer different from the one the game would run on. For example, games that run on an Xbox are created on PCs.
† A gold master is the final copy of the game created by the development studio. The gold master is then given to publishing partners to create production masters, which are used for duplication.
* In 1991, the game didn’t get far. We created a crude overhead 2D map of a town with solid walls for walkways and buildings you could walk into. We realized that it wasn’t going to be able to represent the game we held in our minds. It was two weeks of effort, and we learned how to fail fast.
* With Quake’s networking architecture, each player’s PC was only going to be talking to one other PC, the server. With DOOM, each player’s PC had to talk to every other player’s PC. That’s a lot of data moving around and slowed the game down.
* Gibs (pronounced “jibs”) is short for “giblets,” the bits of meat that come packaged inside whole turkeys or chickens.
* Our early experiments in QuakeC, like American’s “Spike Shower” and “Guided Fireball,” didn’t make it into the game as updates to the engine rendered some gameplay written in QuakeC obsolete.