It emerges from a set of large, metal doors, telescoping in sections. It is at once skeletal and sturdy. Elegant and warlike. Its rise is methodical, but quick. It assembles itself as it emerges and, in the span of seconds, becomes an elegant instrument of death.
I am watching a simple animation of a single tower from the upcoming game Defense Grid 2, set on a white backdrop on the screen of Hidden Path President Jeff Pobst's computer. DG2 is still in development. It is expected to ship sometime in 2014. It has taken months for the DG2 team to bring this tower to life.
The tower is made of computer code, engineering and art. It is as close to a perfect crystallization of how games are made as can be coalesced from the whole, a single element requiring the attention of designers, artists and coders, assembled painstakingly over the course of months.
And it's still not finished.
Pobst is creating a movie file of the tower animation in Adobe Premiere and adding sample sound effects pulled from a library on his computer. He'll then send this movie file off to Composer and Sound Engineer Duane Decker, who will add in the fruits of his own labors.
Meanwhile, at Hidden Path, another developer is adding "particle effects," a bit of graphical wizardry that creates real-looking smoke, lasers and bullets. And yet another developer is tweaking the tower's artificial intelligence, or "AI," which will determine how, once the tower is deployed into the game world, it will move and shoot, which enemies it will target and how aggressively it will fight them.
By the time it is complete, this single tower will have received the attention of as many as a dozen individual members of the development team, and it's possible the entire team will eventually be called to lend a hand on it, at various stages, depending on how well or not the various pieces of the puzzle come together. More than a dozen developers over the course of four months for just one of the towers in a game in which the towers are only a part.
This is game development.
This is also not quite the order in which these tasks are best completed. Typically the finishing touches like sound and particle effects are layered on near the end of development, once the foundation of how the game will behave and how the levels will be constructed is already more or less complete.
Defense Grid 2 is still months from being complete. The core technology is (mostly) programmed, although some kinks are still being worked out. Lead Designer John Daud is now (finally) able to put his theories to the test, using the new Hidden Worlds engine and level editor to create test levels within the game, but none of those levels — save one — are even close to being ready to play.
And yet, barely more than a month from now Hidden Path will be showing Defense Grid 2 to outsiders for the first time. First to the press at European expo Gamescom. Then, a week later, to the public at PAX Prime in Seattle.
In order to show off the game, Hidden Path needs a playable level. It needs to finish a part of the game before it finishes any part of the game, so that it can show off the game, so that excitement will build for the game that is not yet finished, so that when it is finished, people will buy it.
This is game development.
The level is called a "first playable." It will represent everything Hidden Path knows about how the rest of the game will look, sound and play. But at this stage in the game's development, barely halfway through, there is a chance that changes later on may take the game far enough off course that the final product won't be anything like the first playable. There is also a chance that the first playable won't even be ready in time.
This is part of a yearlong series on how Defense Grid 2 is made. Hidden Path Entertainment has given Polygon exclusive access to all parts of the game's development and every member of its team. We will bear witness firsthand to how this game gets made, from the ground up. Everything will be on record and recorded.
Hidden Path has given Polygon total access to the game it hopes will remake the once-struggling veteran studio as a thriving indie. Our reports will be published between now and when the game finally ships (projected: 2014).
This is part two. (You can read part one here.)
"It's coming in hotter than I would have liked," says Pobst. "I would have liked to be about two or three weeks earlier than where we are right now."
Hidden Path co-founder and Defense Grid 2 executive producer Jeff Pobst is taking point on lining up the finish work for the first playable. He's working directly with the game's writer and composer and when it's time to record voice-overs, he will visit the recording studio in Los Angeles to direct the actors personally.
This is partly because, as executive producer, it's his overall vision that's driving the look and feel of the game. But he's also jumping in on this critical task at this critical juncture because, as executive producer, he's currently the member of the team with the least on his plate.
Pobst serves as president for the company, now in its eighth year. He makes a lot of the business decisions, weighs in more heavily than his co-founders on company direction and planning and generally serves as the resident expert on how to sustain and grow this contract shop–turned–indie developer. Co-founders Mike Austin, James Garbarini and Mark Terrano each play their parts, serving as technology head, design head and finance officer, respectively, but Pobst, as he was during their time together at Microsoft's Advanced Technology Group, is the de facto leader.
Pobst stresses, though, that he's an enlightened dictator.
"My experience has been that when you have really competent people who know their job and they just want to know what direction to be pointed in, you want to stay out of the way, but you want to make sure everyone has the knowledge," Pobst says.
It's hard to pin down exactly where Pobst learned the most about managing teams. The veteran game developer worked for years at Microsoft, as one of a roving band of game developers and software engineers called the Advanced Technology Group, which Microsoft would deploy to help make sure the teams developing Xbox games could make those games as good as they could possibly be.
But his game design experience started at the storied Sierra On-Line, where he worked on installments in the King's Quest series and later oversaw production on third-party games like Homeworld and Half-Life: Opposing Force.
To talk to Pobst, though, is to realize that it all probably started a lot earlier than any of that. Before Sierra. Before Microsoft. Before, even, perhaps, when he worked for the Air Force. But definitely after he sang on TV during a Super Bowl pre-show event, on stage with popular country-western singer Barbara Mandrell.
Most likely the seeds of Pobst's current success were sown in the mid-1990s, when he was at Southern Cal studying to be a film director and, at the same time, a rocket scientist.
"The thing I thought was so cool, when I started taking a lot of film classes, is I was [also] doing a Ph.D. dissertation on an experiment," Pobst says. "I was doing this experimental stuff on arc jets and taking data and trying to figure out the paper I was going to do. I was taking these classes where you take a script and you're trying to make a film.
Pobst on game engines
What is an engine? Even different companies probably consider different pieces an engine ... But I think when I think about an engine, you've got a renderer, and right now most of what we're talking about is in the renderer.
In fact, [the Hidden Worlds Engine] has three renderers. It probably will have more if it's on multiple platforms. It's got a forward renderer, a deferred shading and a deferred lighting. They're different technical ways that you assemble a scene and decide what polygons get sent to a graphics card.
For example, a forward renderer handles transparency very well, but can't deal with a lot of lights, whereas a deferred lighting model handles lights amazingly well, but doesn't handle transparency as well. You have to make some trade-offs when you decide which one. There are multiple renderers inside this engine that, based on which game you're making, you decide, "This is really important for our game." You can use that rendering path. Then, if you decide, "OK, I want to go on a console ..." I've been talking in a PC-based line, but if I'm going on a console, or say you want to do something on mobile or whatever, you have to start thinking, "Well, the architecture of that means I can only use this renderer. How does that impact it?"
So you've got the renderers. Then you've got what I would call the I/O system, which is about loading files, background loading, managing files, saving data. A term you might hear from people around here is serializing. Often serializing just means "saving" for us. But basically it's storing all the data and getting it out and getting it into the engine. That actually can be a really complex set of systems, depending on, well, what's my load time rate? How do I organize data? How am I going to put it in different files so that we can edit and move things around so that multiple people can work on it?
That's part of an engine. Then you have what I would call the sim system, which is, how do you store objects? How do you identify what pieces ...? I have characters. I have towers. I have aliens. I have these things that have some properties, some set of inherent ... What model do I use? What animations do I use? But also, from a sim point of view, this guy has this many hit points. He's taken this much damage. These are the effects on him. Whatever. Something that's keeping track, the bookkeeping of all the different objects in the world and what their state is. It updates their state and lets different parts of the game communicate with other parts of the game to say, "I have injured you." "I have taken so much injury I need to die. Someone handle me dying." That kind of stuff.
A part tied to all of this is a messaging system, which is how each of the different components communicate with each other. What matters in how you design your messaging system is whether or not you can do multiplayer, which is its own system in itself. Connecting, doing lobbies, all of that stuff. But being able to also move messages across to other machines, as well as inside my machine, keep track of if I've lost a message and what do I do, or will the message not arrive on time. All that kind of stuff.
So when we say "engine" we often mean "a group of components." Our other games are using different groups of components, but what no one had really used prior to this was the deferred lighting renderer in the ways that we're going to use it for this game. So Peter found more undergrowth to machete than expected. How's that for a long explanation?
"I realized that they were really similar, in that you start out with an idea of what you think you're going to do. Then you build all the pieces to do your pre-production. You get it all ready and get all done. Then you go take your data or you get your dailies and you start shooting ... Then, at the end, you've got all your data, you've got all your footage and now you have to create a paper, create charts, explain all the stuff you're going to do. Or you have to create a film and pull it all together and make a narrative out of all of that. I was shocked at the parallels."
Pobst was a band nerd in high school. He played percussion and synths and was pretty good at both. Perhaps great. So when he went to USC to study aerospace engineering, he also went out for their storied marching band — and got in. The catch: He had to play cymbals.
"Most of the other people in cymbals were like, 'I wanna be part of the marching band, but I don't even know how to count,'" says Pobst. "I'm actually a musician. Come on. But it turns out that there's a whole hierarchy of things you get to do in a marching band, especially a 250-piece marching band in Hollywood in Los Angeles. They save a lot of those things for the seniors. Turns out there aren't many senior cymbal players. So all of a sudden I became a quasi-senior as a freshman by being in the cymbal group."
On the list of things Pobst was suddenly invited to do: play at birthday parties for celebrities, record on an album for the rock band Kansas, play at Disney Studios, play the Super Bowl halftime show and play at the televised Super Bowl pre-show starring actor Patrick Duffy and Barbara Mandrell.
For that last one Pobst spent two days at Universal Studios watching O.J. Simpson play Hacky Sack, eating lunch with Miami Sound Machine ("before it was Gloria Estefan and the Miami Sound Machine") and sharing stage time with William Sanderson, who was then a star of The Bob Newhart Show, but is perhaps best-known today for his role as E.B. Farnum on HBO's Deadwood.
"He was scared to death," says Pobst of Sanderson. "I was like, 'How are you possibly scared to death? You do this show every day.' He says, 'Yeah, but we do our shtick for the Newhart audience. They come in and they know what they're going to get and they always laugh. This is the first time we've actually ever done it outside our own audience. What if they don't laugh?'"
The shtick in question: Sanderson played a character called Larry who had two brothers, both named Darryl. The three were inseparable, but the two Darryls rarely spoke. Sanderson would introduce himself, and them, by saying, "I'm Larry, this is my brother Darryl and this is my other brother Darryl." It was a moment of understated humor that was classic Newhart, and became that show's signature gag.
"I say, 'Everyone knows the joke,'" says Pobst. "I'm sitting here reassuring this actor. I'm a young kid, an 18-year-old kid, and I'm reassuring this guy that he's going to be fine."
The experience demystified the world of entertainment for Pobst, who grew up in Spokane, Wash. with a high school graduating class of 42. He went on to dabble in film at USC's world-famous film school, but ultimately left the glitzier aspects of his education behind to focus on the less politically challenging world of aerospace engineering.
"I get full-time pay. I have a facility 10 times better than the university's to do unique research and I can tie it all together. This was awesome."
Before long, Pobst was experimenting with spacecraft research, programming giant lasers and studying the effects of high-energy plasma on hydrogen gas.
"It's one thing to write software," Pobst says, "and it's another thing to write software and see big mechanical things move because of your software. It feels like you're changing the world."
Pobst's studies stretched on into graduate school, and he eventually pursued a doctorate. Meanwhile the U.S. Defense Department had become interested in some of the work being performed at the USC aerospace lab.
Pobst was recruited to work in a semisecret installation in the Arizona desert, where he was given a lab full of state-of-the-art equipment and tasked with determining the efficiency of a particular type of satellite rocket thruster.
"So I'm doing my doctorate," says Pobst. "I get full-time pay. I have a facility 10 times better than the university's to do unique research and I can tie it all together. This was awesome."
The thruster Pobst was testing used an electrical current to superheat hydrogen gas, creating thrust. Pobst would fire the thruster then shine lasers into the gas plume looking for hydrogen atoms in various states in order to determine how well, or not, the gas was surviving its trip through the thruster assembly. The more gas that survived as hydrogen molecules, the better. If the molecules got split by the electrical current, they would "disassociate" into hydrogen atoms, thus reducing the effective thrust of the engine.
"There were about 50 people in the world who dealt with this stuff," he says. Manipulating the lasers involved programming giant machines, in machine language, to move the lasers and sensors back and forth on tracks, then positioning the sensors precisely to capture the interaction of the lasers with the molecules and atoms of hydrogen emitted in the thruster's gas plume.
To make things even more complex, the sensors he used were mostly prototypes, developed specifically for this, rather limited, application. And they frequently broke down and required re-programming.
As a result, Pobst emerged from his time in the desert laboratory with a rare combination of incredibly dense skill sets; he was a rocket scientist computer programmer trained to conduct complicated productions and troubleshoot nearly continual setbacks to reach an end goal on time and under budget. To military specifications.
Without realizing it, Pobst had become a game developer.
"Here's the thing I love about the game industry," says Pobst. "Everyone has stories like that."
Pobst's eventual transition into his final form, as a member of the games industry, started with a chance encounter on an airplane.
"The guy behind me is asking questions of the guy in the middle seat behind me ... and he turns out to be a producer at Sierra On-Line making video games," says Pobst, who for years had been a fan of video games. "So of course I'm all perked up and everything. Then it turns out he's with his daughter, and his wife is sitting right in front of him next to me ... As this very loud conversation is going on behind me ... I said, 'Wow, it's pretty cool what your husband does.' Afterward she asked me about me and I told her what I do, and she says, 'Wow, you should talk to my husband when we get off the plane.'"
"Being in video games in 1997 was not a big draw. I even remember, parents would go, 'Are you sure? Is there any money in that? Are you gonna be poor?'"
The producer was Mark Seibert, who was then working on King's Quest: Mask of Eternity. He and Pobst exchanged business cards and a short time later met again for lunch.
"Being in video games in 1997 was not a big draw," says Pobst. "I even remember, parents would go, 'Are you sure? Is there any money in that? Are you gonna be poor?' The questions were very different from what they are today. There wasn't a big giant industry around it.
"So we went to lunch and we had a very long lunch, over Thai food at [Seibert's] favorite Thai restaurant. Afterward, he says, 'Hey, do you want to come and see the office?' I'm like, 'Yeah!' So we go back and he introduces me to Scott Lynch, who was his boss at the time, and is now of course running Valve."
What followed was a long series of seemingly casual meetings with various department heads and producers at Sierra. In actuality, Pobst was being clandestinely interviewed. The offer came shortly after.
The job came with a salary slightly more than half of what Pobst was making as a satellite scientist, but it was his dream job, so he took it. He and his wife-to-be moved home to Seattle and Pobst became "programmer number eight" on Mask of Eternity.
Pobst moved up the ladder quickly, and when Sierra expanded in the late '90s, he was tapped to be the company's first "external producer," working with third-party studios like Relic and Gearbox, helping to usher their games to market with a minimum of fuss.
"Any time I talked to people about how we were working with these external companies, everyone inside the company would say, 'Oh, how does that work?' Because they'd always made games at Sierra with internal teams, or they'd bought the companies," says Pobst. "I had to figure out how our contracts worked. They'd already been done, but now we needed an extension. What's that mean? What's our royalty plan? What [are] our philosophies?
"So I'd go and learn from all these different people. You had this thousand-person company, but no one had done this. They'd already been doing it, but they hadn't been doing it, if that makes any sense. And so I learned the entire business of games. It was the best education I've ever had."
Meanwhile, Pobst's employment at Sierra On-Line became more and more untenable. The company had been plagued with continual reorganizations after multiple acquisitions, and would eventually cease making original games entirely. After a particularly nasty wave of layoffs in the early 2000s, Pobst received a call in Italy, where he was vacationing, to inform him that his bosses had all been fired and would he please prepare a report on what he'd been doing? Pobst decided it was time to go.
He drifted for a few years — first at developer WXP, then consulting for Vivendi's parent company Universal — before landing at Microsoft in 2002.
"The Xbox had launched, but Live had not launched," says Pobst. "I came on right as we were figuring out what we were going to do with Live."
Then came ATG. Then, eventually, Hidden Path Entertainment.
Eight years later, Pobst is sitting in his office, bringing all of his training and education to bear on the deceptively complex problem of making a weapon tower sound cool. And he's starting to grow concerned at the number of delays creeping into the production cycle for DG2.
"I think what happens is that the stuff starts adding up, if you don't catch it early," says Pobst.
I'm sitting with Pobst and Producer Dacey Willoughby in Pobst's office. We've just left a meeting of the DG2 team, another 'round the room affair in the main work area. In the meeting, Lead Programmer Matt "Twig" Johnson unveiled his list of things that need work before the impending deadline to show off the first playable at Gamescom and PAX. The list had 79 items.
"I think that's one of the things Dacey is very good at, catching it pretty early," Pobst says afterward. "But if you don't catch it early, it starts adding up, and you cut whole swaths of game."
The discussion of Johnson's list prompted questions as to whether or not Johnson would make the list available for everyone else to see. There was some back and forth. Johnson seemed reluctant, but the assembled team members — most long-time veterans — wanted to see it. They wanted to know what wasn't getting done.
"Part of it is the human nature to see stuff checked off," Pobst explains later. "But part of it, too, is ... there are negatives to having a more experienced staff ... They've been on a lot of games, and while they aren't producers, they have more gut feelings about how everything else is. Part of what I think they're asking for — I'm not sure, but it's my guess — is that they want to see a scope, see the amount of time left, and say, 'OK. I feel good about this.' Or, 'Hmm. I don't know. What are you going to do, Jeff and Dacey, to make this come under line?' It's a little bit of judgment on where we are on other stuff. Which I'm OK with. But it's stuff that your typical younger group wouldn't ask for."
"If you say, 'Look, guys, it's fun because I tell you it's fun!' the audience doesn't buy into that."
"I'm sure there needs to be more done," Johnson said in the meeting. "It's just a bunch of things. Lots of little things."
"It would be kind of cool to post it and check stuff off, so that people can visibly see it," Willoughby said.
Pobst suggested the list be posted on a whiteboard. Much of the team concurred.
"I'm sure it's not complete yet," Johnson pushed back. "I'm sure there's probably lots of stuff that we should add before posting it up here." And then he launched into a discussion of current issues, sidestepping the debate.
Much of Johnson's current programming concerns are related to UI, the graphical elements players will interact with to control the game. Some of it isn't working and some of it isn't even done. He discussed nodes and "string tables," and, while not quite overwhelming with detail, made it clear that whether or not a list gets on a whiteboard is somewhere near the bottom of his worries.
When asked later, after the meeting, if there's anything specific he's concerned about, Johnson says, "Time."
"Jeff [Pobst] is going to take a build to Gamescom in Germany," Johnson says. "That's going to be single-player. But it still needs to be a complete session. You need to be able to play the game for, I think, 10 minutes. That's the desire: what he wants to be able to show people there, to the press. And so we still need a complete game where they can sit down and play for 10 minutes and experience all the neat things that come along with playing a game of Defense Grid. It has to be just as detailed for them as it does for PAX."
The goal is to send the same build of the game to Gamescom as they're planning to send to PAX, less than two weeks later. The catch is that for PAX, Pobst wants to show off multiplayer, and right now, for Johnson, multiplayer is a huge question mark.
Twig on networking
The server creates an object. We need to communicate that creation to the client machine and have the client machine also replicate that object, and make sure the two are synchronized, are known by the same ID on both machines, so that when the machine says, "I need you to change object ID 100," on the server, and the client says, "Object ID 100 needs to have such and such turned on," it's referring to the same object, the linked object. The Windborne team is doing that work. That fell out from a big discussion that we had not too long after you left, about what that system would look like, the architecture for that system, and who would be doing the work. The Windborne team is doing that work. Part of that work involved changing how we send messages within our engine. What I'm integrating now is the message-sending part. The networking stuff for replicating objects isn't quite ready yet ... but we can take the changes in two stages. It's easier to do it in smaller bits than it is to do it in one big chunk. So I'm integrating all the message changes now, and I'll make sure that our code base continues to run it for a little while. At least a few days. When [the Windborne programmer finishes the networking stuff in Windborne I'll do another integration to take all the object replication stuff he's been working on.
There are a few standard ways to do it, and we were talking [in a meeting] about, "Well, what kind of features do we need for Windborne and for Defense Grid? What does that look like within our code base? Where would we put these features in our engine?" From that we came up with, "Well, we kind of like this way. So let's go implement it that way and see how it turns out."
Looking at the known ways people have used to solve the problem and looking at the requirements for the two projects and figuring out what works best for us.
What we have is kind of a combination of ways that we think will best help both of our projects.
The server is in control of creating objects. It will create an object, assign it an ID in our case ... The ID could be anything. It's an internal number that we just increment as you create more of them. It's different every time you run the game. The server creates this object with an ID, and then it has to tell the client, "I have created this object. This is what it looks like. This is the ID I gave it. Now you have to go and create the same object in your memory using the ID I gave you and this set of properties." Then the client goes ahead and does that. In our system, that essentially means those two objects are linked. We have a reserved range of IDs, so that any ID above a certain value and below a certain value are guaranteed to be linked across the network.
The server runs the game simulation. All requests go through the server. At least in our case, because we're running an authoritative server. The server controls everything. If a client wants to do something, it goes and essentially asks the server. "Hey, I want to do this." The server says, "No, you can't do that," or, "Sure, go ahead." Then the server changes the game state appropriately and then communicates the new game state back to the client. A lot of first-person shooters work that way, because you can't trust players in a first-person shooter. People will cheat. A lot of cheaters that you see are players taking advantage of the fact that whatever they're trying to do isn't authorized by the server. The client is essentially saying, "Go ahead, do that," and they're tricking the client into thinking it's OK for them to do that, when in reality it's not. But since the server doesn't validate it, then that allows them to cheat. Client says, "Oh, I shot a bullet." Server says, "OK, you're facing this direction, you shot a bullet, here's its trajectory, this is what you hit," and sends that back to the client.
That's essentially how authoritative servers work.
"It's an area of concern just because networking has a history of being problematic," Johnson says. "It's easy to do things on one machine. In fact, even doing things on one machine, you can get a lot of bugs. As soon as you introduce a second machine, you get a whole lot more bugs."
Johnson and the networking team for Hidden Path's recently announced Windborne huddled in a meeting room a few weeks ago, brainstorming ways to tackle the networking challenge. They looked at how other games have addressed the issue and what works and what doesn't. Then they laid out all of the networking features they need to accommodate, not just for DG2, but for Windborne as well.
In the end, they decided to innovate their own networking system, taking bits and pieces from what other people have done, but largely building it themselves.
Back in the meeting room, it's unclear who will win the debate over the list. There seems to be reluctance on both sides to press the issue to the point of open confrontation. Perhaps because the team as a whole is still smarting over a previous debate from a week earlier over a similar list, containing unfinished art elements. It's already up on the board, posted there by Willoughby.
"[A] big concern is the level art," Willoughby says afterward. "Our time estimates have not been working out so well for certain things. Things keep coming up for us to work on, like marketing stuff, helping out with that, and doing other miscellaneous tasks. That's getting to be a little concerning for me. ... Inevitably, things start popping up that were not expected."
Part of the issue, at least with the art, is that different team members have different definitions of the word "finished."
Objects in a video game are made of polygons or triangles, which are created by lines of code telling a computer where to begin drawing a line and where to end it. A graphics engine will process millions of these lines of code, eventually (in the blink of an eye) spitting out millions of lines, all connecting to form the framework of an object. A graphics renderer will then layer images over the top of this frame, finally making the object look more or less like a real-world thing, or however the artists and programmers intend for it to look. These over-top images are called textures, and they comprise most of what you see in a video game. And someone in the real world has to make them.
The DG2 team had been submitting "finished" objects without their attendant textures. For the artists, creating the textures is a separate project, with separate beginning and ending points. They believed they had completed the task of designing game objects and that the task of creating textures would happen later. Willoughby, however, expected that both would happen simultaneously.
"They were building, building, building all these modular pieces, which is what we had planned, but then we started discovering things," Willoughby says. "We hadn't been putting them into levels to kind of test how we could place things and see what pieces we were missing. That sort of thing. I had to start accounting for that stuff, whereas I wasn't before. ... Which was bad on my part, because I was kind of assuming that they were doing that while they were building."
Pobst describes this as a relatively common occurrence in game design, or any project involving managing people.
"I think it's one of the reasons ... if you work with the military or somebody, the specs for something are 14 pages long," he says. "We find that to be not very creative, but we need to be a little bit better than we are in being like, 'OK, this needs the pieces built. It's been textured and it's been used in the editor so that we know it will work.'"
All of which is to say that, in game design, sometimes designing the game is the easy part.
Ultimately the debate over Johnson's list is moot. Willoughby, as associate producer, is keeping track of everything anyway. And everyone has plenty to do without worrying about it. But they worry anyway. Because each of them are spending a year or more of their lives on this project, and each of them want it to be great.
"You have to be critical, because [the audience is] going to be," says Pobst. "If you say, 'Look, guys, it's fun because I tell you it's fun!' the audience doesn't buy into that."
Making sure the audience does buy into that — literally — is another person's job entirely.
Shannon Gerritzen — there's no other way to put it — sticks out like a sore thumb.
"I was at the Surfrider Foundation," Gerritzen says, speaking of her former career. She's been at Hidden Path for just over three months, and a part of the game industry for not that much longer. "I worked for an environmental nonprofit. A lot of politics, a lot of surfing, a lot of dirty hippies. [She laughs] You can delete that part."
Gerritzen serves as Hidden Path Entertainment's resident marketing and PR director. While most studios rely on outside teams for their public relations and marketing work, or else enlist support from their publishing partners, Hidden Path, as a self-published indie, decided to take the route less traveled and hire its own. And, as is so often the case with Hidden Path, its choice of who to hire, as well as how that came about, was unusual.
Pobst tells the story:
"We're at this Sony E3 briefing, I think, and there's the food trucks and the big thing. Everyone's milling around. Randy Pitchford [Gearbox President] is there. Randy and I go way back, and we're talking. Mark Rein [Epic Games Vice President] walks up and they're giving each other a bad time about Unreal. Robin Walker, maybe, from Valve is over. We're talking. Kevin [Dent, CEO of Tiswaz] walks up and they all seem to know Kevin, and I don't know who this guy is. They're like, 'Oh, Jeff, you need to meet Kevin.' And of course Kevin's like, 'Oh, a new person!' [laughter] So we talked for much of the next hour ... [Afterward] Kevin and I started talking. He would ping me on Twitter and we'd talk back and forth. I put it out there that I was looking for [PR] agencies. I was talking to everyone and Kevin says, 'Oh, you need to meet Shannon!'"
Pobst arranged a meeting with Gerritzen, although neither knew why they were meeting; just that Dent had said they should.
Dent, a notorious troublemaker on Twitter, is one of the most mysteriously well-connected people in the games industry. His credentials are frequently the subject of furious debate, but more often than not, if someone in the games industry is doing something exciting, Dent knows who they are — and what they're up to.
"Man, you're the first PR person I've talked with who brought up metrics within the first few minutes. I like that."
"Shannon comes to the office and I said, 'What agency are you with?'" Pobst continues. "'I'm not with an agency.' We're sitting in that conference room down the hall and I think, 'Oh?' ... Is [Dent] really that smart, an overlord making things happen? Or does he just kind of throw stuff together? I don't know. But we started talking and I think, 'Man, you're the first PR person I've talked with who brought up metrics within the first few minutes. I like that.' ... We started talking and had a really good conversation."
For Pobst, Gerritzen came with knowledge he didn't posses, about metrics and marketing schedules and mindshare and all of the ways to promote and sell a product that Pobst and Hidden Path, by virtue of having focused for years on working with publishers and concentrating on making a product, hadn't yet learned. The company decided to take the leap of faith.
"I think we're going to see a lot of developers start going this route," says Gerritzen, "because they're starting to self-publish and rely less on publishers. They don't have the tool set to do marketing and PR themselves. Some of them can ... but not all of them have gregarious personalities to go out and say, 'Hey! Look at us!'"
That's what Gerritzen sees as the biggest challenge for Hidden Path. She believes it makes great games, but that its founders don't always feel comfortable telling people that.
"What's a nice way to say it?" Gerritzen says, speaking of what she sees as the studio's biggest weakness. "'Getting them to come outside of themselves and talk about it.' They're so humble. I feel like they feel like they're bragging about what they do. You can see the personalities. They're all hard workers. You come in here and it's quiet. There aren't these huge personalities that run the office and are bold and talking to other people a lot. They're here and they're working."
For Gerritzen, Hidden Path is not just a change of pace, but a change of career and lifestyle. Her passion was and always will be ocean conservation, but with a husband in the games industry (Jared Gerritzen is now the head of rival studio Zombie, in Seattle) she found that working with coastal conservation groups and taking on the challenges of nonprofit work often left her with little time to enjoy her growing family.
"Environmental nonprofit work is a bit of a pressure cooker," she says. "You typically are in it because you love what you do, so I was working 80 hours a week and getting paid for 40. You're bringing your family to things that they're really not enjoying because you're testifying at the Capitol or city hall or something.
"I can talk about the ocean and wax poetic about offshore oil drilling for hours, which bores everybody. But for me, it was a personal choice."
Gerritzen's work often took her to Washington's outer coast, while her husband Jared traveled frequently to Los Angeles and wherever else video game events are held. As a result, the couple found themselves to be "ships passing in the night." Gerritzen knew she had the skills and resume to do marketing work in any industry, and began looking for an exit. Jared suggested, "'Well, what about video games?'"
Gerritzen played the occasional game (Angry Birds, Street Fighter) but never considered herself a gamer. Still, from exposure to her husband's work, she knew and understood that games were rapidly becoming a powerful cultural force.
"It's a livelihood," she says. "It's a creative outlet. It is art — which I know is still a debate and I don't understand why it's a debate. That doesn't make any sense to me."
It's also, as she puts it, a field in which you can see the result of your efforts a lot more quickly than in environmental activism.
"For the little-known world of environmental politics I worked in, it was all things related to ocean health," she says. "We helped write and pass the Seattle ordinance for the [plastic grocery] bag ban. There was an immediate gratification there, but there's also the steps. And things like Trestles, California, which is a beach. TSA [Transportation Security Administration] is trying to build a road through there. They won one step, but then a year later, of course, they found some other way to fight it. So there is that ongoing aspect as well. ... In a game, you do see the immediate ... Here's your year of work or two years of work. Here's your product. Which, as Defense Grid has shown us, is not the end, because five years later people are still playing it and talking about it."
Gerritzen's world is a world of spreadsheets, data analysis, email receipts, tracking programs, calendars and a massive whiteboard charting all of the media coverage and marketing pushes she expects to see for DG2 over the course of the next 8-10 months. I'm on it, and if you're reading this, you're part of her long-view plan falling perfectly into place.
Gerritzen carefully studies not only what people are saying and writing about Hidden Path, but what people are saying and writing about Hidden Path's competitors. Also, what people she talks to aren't saying and writing about. She can track the emails she sends and tell who's actually reading them or who, after reading them, may write something based off of them. Or when they get things totally wrong.
Her long-term goal is to be able to maximize the return on her (and by extension, Hidden Path's) effort. Who to talk to in the press in order to get the most impactful coverage of her game, or who will most accurately represent the information they're given.
"I think press all come with their own idea of what they want from a conversation, for the most part," she says. "Every different outlet, or most outlets, all cover from a different angle. Some want to know about the art. Some want to know about the gameplay. Some are highly competitive and shooter-based. I feel like everybody has their own ingredients that they make a story from.
"I'm not too worried about that. I get more ... My fears, of course, are that ... one, what if they don't like the folks here? ... And two, what if we didn't set their expectations they way we had hoped to set them and they get disappointed in the end?"
The touchstone for all of Gerritzen's planning is rapidly approaching: PAX. Not only is the annual consumer-facing event the perfect venue for showing off a smaller, community-driven game, but its timing, right before the traditional pre-holiday media blitz, means Hidden Path has a window of opportunity to talk about its game before the major studios start talking about theirs.
"For an indie game, the holidays are going to be a very loud time, right?" says Pobst. "This is an opportunity for us to have a window to make some noise and have people say, 'Oh, there's this game. I'm kind of interested in it,' before the roar eclipses us."
"I think, through the holidays, I purposefully go quiet on my content schedule," says Gerritzen. "I don't want to get lost in the noise. I don't want some great piece of news that we have here to go up against a triple-A title piece of news, because I know that we are independent, we are smaller. We can't compete with that kind of noise. So I time mine purposefully, so I get a larger chunk of that pie, I hope, at different times."
Different times like the rapidly approaching PAX.
"I know it sounds scary, but I don't mind the pressure. It's where the surfing comes in handy. I just roll with it."
"My [job] is deciding what to do if we don't have games to play," Gerritzen says. "Building out the booth, so all the marketing and imagery around the booth falls on my plate. Partnerships for in the booth, tech-wise and schwag-wise. It's all coming together. It's just a process. Art can't be made until more of the game is made, so that we have the visuals we need for the art in the booth. It's like that never-ending Catch-22. [laughs] Here's one piece, but we still need more of this piece to get to that piece. It all comes together at the last minute.
"I know it sounds scary, but I don't mind the pressure. It's where the surfing comes in handy. I just roll with it. I make my plan [A], and then in my head I have a B and a C, and I hope that I don't get to C, but I'm totally OK with going to the B plan if I need to."
Plan A would be having a complete, playable level to let fans get their hands on at PAX. Gerritzen says Plan B would be showing off a level, but not letting people play it if it isn't ready for hands-on.
I ask her what Plan C would be.
"C is just," she says, suddenly nervous. "You have a good time and you talk to a lot of people and you hope that people spread some good love because they had a good time talking to you and they saw some nice video footage.
"They go on their way with hopes of something great to play soon."
She laughs dryly and looks again to her calendar showing less than six weeks to PAX. Her eyes get lost in the middle distance.
"We're going to focus on A and B," she says.
Plan A is already running late.
First there was the "jury duty incident," which put programmer Scott Bodenbender behind on building the "pathing" for the alien units, which is more or less how they find their way around the world. Then the game engine was discovered to have issues — big ones — that set development back even further.
The DG2 engine was created years ago, for one of Hidden Path's first games, called War Council. The game was ahead of its time, employing features and technology that punched far above their weight. But the game never shipped and the engine got put in storage — until recently, when it was dusted off to form the foundation of Hidden Path's new fleet of next-gen games.
The problem: nobody really remembered how finished (or not) certain elements of the engine were. The DG2 team opened the box and started counting parts. As it turned out, it was missing some pieces.
"We thought it was in better shape than it was," says Pobst. "And so there's been ... bug-fixing that I don't think we were expecting to find. Things that we thought were in there and working would work for very simple cases, but once you started adding in the features that we're having for this game, all of a sudden they'd fall apart. ... It was hard investigation, and sometimes it was like, 'Oh, that whole system won't work; we have to remake that system.' Which we weren't planning on doing."
"Nobody's used it for quite a while. It's gotten stale," says Johnson. "Some problems have shown up, so I spent some time trying to fix that."
Johnson, who was knee-deep in attempting to resolve an issue with the DG2 level editor a few months ago, has now moved on largely to project management and jumping in to fix issues encountered by other programmers. Like the graphical bugs in engine.
"Just getting all the pieces together," Johnson says. "[The game has] come together quite a bit since [May]. You can build towers now. We have a sample level that John Daud has been putting together. It has buildable squares. You can build towers on them and upgrade towers and we have aliens spawning at a spawn point from a script file. They walk in and they go to the power core housing and take a power core and turn around and leave with it. The towers will shoot at them. They'll die.
"It doesn't look pretty, though. There's lots of stuff that's not finished. ... If it wasn't for PAX, we wouldn't be spending the time to try to clean things up. We wouldn't care if it was rough around the edges. We wouldn't care that there's no scoring system in place yet. We would continue working to try to get all the basic gameplay features in there."
If it wasn't for PAX.
"We have to make a trade-off," Johnson says.
The trade-off is finishing the fine details of the first playable, chasing Plan A, before completing the rest of the core game features. Taking things out of order to make one, single chunk ready for prime time.
Freese on deferred shading
There's a post-process fog pass because we're using a technique called deferred shading. You render the scene out to something called a G-buffer, which has a bunch of information about how to render each pixel on the screen. Then we do lighting afterward.
It's a transition away from the way we did graphics, say, 10 years ago, where we used a technique which we now call forward rendering. We used to render a mesh, a bunch of triangles, and as you render each triangle, you figure out things like what color is this part of the mesh, what lights are on it, and you render all that at once.
The way that a lot of graphics engines work now is that they use this process called deferred shading. When you render the mesh, you render its position and a bunch of attribute information, but you don't render the final process. You don't figure out the final color of the pixel yet. Then you render a bunch of accumulation passes. Here's the directional light. Here's point lights in the scene. Here's fog. Here's bloom effect and other things.
The primary reason for the movement to deferred shading is that it allows us to do lighting much better. Previously, as you were rendering a particular mesh — suppose you're rendering a character in a scene. He's composed of, say, 5,000 triangles. As we're rendering him, we need to know all the lights that affect this particular character. Well, if it's just a directional light or a scene light, it's not too bad, but at some point it becomes very complex if we've got lights ... Imagine he's walking down a street with streetlights all over the place. Which streetlight should we use to affect the character? Then we have to do that for everything in the scene. That problem becomes pathological, because we have N objects times N lights. Deferred shading separates those out, so it's no longer a multiplication problem. It's an addition problem. We render all the characters. We actually render lights now — "We're rendering a light. What does it affect on screen? What's the size of the light and screen space?" Then we add the light to the scene.
It turns out that the way that you do that works well for a whole bunch of other things, like ... It used to be, if you wanted fog in your scene — or atmospheric haze or light scattering, the effect of light moving through volumes of clouds — you would have to compute all that at the same time you're doing all the lighting for this mesh. Now we get to do, "Oh, we're just going to do fog." We basically have this whole scene and we just compute it as a single pass over the whole scene. As you look at each pixel, you go, "Oh, how far away is it? What's its color information?" Then I can write new color information for that.
One way of looking at it is, you have this material volume that light transmits through. As the light moves through that volume — in this case, from a distant point to the viewer's eye, or a virtual camera — various things happen to that bit of light as it travels toward the viewer. It can get scattered out. The physical process is, the photons interact with molecules in this substance, which is either water or air. There's this process called out-scattering, where the light will bounce off particles in the volume, and also a process called in-scattering, which is where light from other sources bounces off those things and then moves toward your eye. As graphics programmers, who work on outdoor rendering, we know why the sky is blue. [laughter] It's the same reason the sunset is red, which is these two scattering properties.
The upside is that the DG2 team will get a chance to road test the major game mechanics before a live audience, with plenty of time to address feedback and make changes before the game ships next year.
The downside is there's a lot of work to do in a very short amount of time.
"God, I have so much to do. I really do," says Graphics Programmer Peter Freese. "I do worry that ... we have this little tiny camera, and we're looking at all the stuff we have to do. Someday we're going to take the camera away and say, 'Shit, there's all this other stuff that we're not seeing.'"
Freese has been head down on wrestling with the engine, finding the missing pieces and attempting to rebuild them. And, in the process, he broke the water.
"The way I was working on it was a way that was convenient for me to work on, but I'm actually doing the real implementation now. So now it's not working," he says.
Freese has been implementing water and lighting shading and volumetric fog, all of which are related and use similar systems. He wanted to see how the water would look, but he didn't want to actually program the water. He just wanted to see, very quickly, how different shading would look on the water's surface. So he faked it, by tying the water into the volumetric fog process, and then, when he went back to make it official, something broke.
"I showed water, but there was actually no water mesh. The water mesh was fiction."
"I just hadn't written the new code to support it," Freese explains. "I showed water, but there was actually no water mesh. The water mesh was fiction. There was not really anything there at the level of the water. It was just a bunch of shader parameters. That's not how we want to do it. We want to be able to actually create a mesh and animate it and do some other things. So I couldn't do some of the things I wanted to do in the way I had implemented it, but I'd done it that way because I wanted to work on the shaders first."
Freese has been making games for almost 30 years, including stints at Sierra and his time at Hidden Path. He is as close to a walking encyclopedia on graphics programing as exists.
"Everything we do in computer graphics is a hack, right?" says Freese. "It's all simulations of things that are really complex in the real world. The standard of all 3D computer graphics is this thing called the Lambertian light equation. You have an object, a surface, and it has a 'normal,' which is which way the surface is facing. And you have light bouncing off that, so how much of that light gets reflected?
"There's this really simple equation that I think James Blinn came up with in the '70s, this Lambert light equation, which is just the dot product of the two things. It's a simple mathematical equation, and it works really well, and so we use it all the time. But it's totally a hack. It's not really what light does."
What light does is bounce and shine through and around objects. It surrounds us and shines through us (look at someone's ears in broad daylight). Simulating all of the various ways that light can interact would be impossible. So programmers like Freese try to mimic it using hacks and tricks and all of the graphical tools at their disposal, just trying to get it "good enough."
"Players don't really directly care about graphics," Freese says. "But it's the way they say they don't care about music or sound effects. These are things that affect them emotionally, even though they're not core to the gameplay. We could just make the game out of simple Lego blocks that have the same game rules, but these are things that affect their emotional state and their sense of immersion and credibility in the environment. It isn't the same value to everyone. Some people say, 'I don't really care about the story' or other things. But they're all things that help, all theatrics.
"My goal is just to make it look good."
In the course of my time at Hidden Path, Freese does get it "good enough." He fixes the broken code and implements an actual water mesh that then interacts with the light and shading to create a very realistic-looking water surface. But in the process he discovers and must repair dozens of minor issues with an engine that was created almost a decade ago, for a game that never shipped.
"What's unfortunate about it is that a lot of the tasks that Peter's working on are pretty simple for him," says Willoughby. "They're the kind of things that he could have easily done in a short amount of time, had it not been for all the bugs that he's been finding. That pushed it out quite a bit."
Which, in part, is why Defense Grid 2 is now, by Willoughby's estimation, about three weeks late. It all boils down to communication; between machines, between people and back and forth again.
This is game development.
The story continues in Part three.
This story is part of a series covering the development of Defense Grid 2. To read previous installments, please visit the Making of Defense Grid 2 page. This series will continue into mid-2014, the projected launch date for Defense Grid 2.
Editing: Matt Leone
Design / Layout: Warren Schultheis, Matthew Sullivan
Illustrations: Warren Schultheis
Photograph: Hidden Path Entertainment