Jurassic Park is Your Problem Now

It was just before 3AM in San Jose when his Motorola MicroTAC started bleeping. He fumbled in the dark, groping, trying to silence the phone before it woke his wife. Too late…

“What’s going on? Who’s calling you at… what time is it?” She mumbled, half into her pillow.

He glanced down at the glowing orange digits on the alphanumeric display. The number was one he knew well.

“Three… It’s Tom…” That got her attention. She knew Tom, the bearded, affable head of the Redwood Shores studio and someone they’d both come to think of as a friend.

“Go back to sleep.... I’ve got this.” Rising from the bed, he padded out toward the living room as he flipped open the phone and answered.

“Tom? What’s going on man? You still in Tokyo?”

Tom’s normally cheerful tenor sounded anything but. “Yeah… listen… we just finished a review of Jurassic Park for Nakayama. He’s pissed. You’re the fourth call I’ve made since the meeting. I fired the producers. All of them.” His sigh was audible. “There’s not a chance in hell we’ll make day and date with the movie now, but I got you a year. Can you pull this thing out of the fire?”

As the Technical Director for the studio, he knew all too well what kind of shape the project was in. He’d been sounding the alarm for months. People kept pretending they were in full production when they hadn’t even settled on whether the game was top down action or first person adventure. Coders had no idea what the feature set was. Artists didn’t have asset lists. Whole teams of videographers were running around in Hawaii with Steadicams, shooting random clips of tropical foliage. The sound effects guy was off in a Georgia swamp, poking alligators with sticks and recording their bellows of protest. In short, chaos.

He started to laugh, but then stopped halfway, ending on something that sounded more like, ‘heh’. His voice went low and serious. “Yeah… I can… if I’m allowed to make decisions that stick.”

Silence. And then Tom chuckled. “Done… Congratulations, dude. Jurassic Park is officially your problem now.”

The disaster that wasn’t (mostly)...

When Jurassic Park Sega-CD shipped in early 1994, six months after the movie went into theaters, it was generally hailed as a welcome departure from the usual side scroller fare of the early 90’s. Metacritic didn’t exist at the time, but the average of scores from the major publications of the era landed the game at a respectable 82%. A worthy accomplishment under the circumstances, but the interesting story has more to do with the lessons about game development that the production offered. As one member of the team said when the game went to Gold Master, “This whole damned project is a teachable moment.”

So here are some of those lessons from the guy who rebooted the project and got it over the finish line.

Experimentation isn’t the same thing as prototyping.

“What’s the big deal? It’s just a bunch of sprites moving around the screen…”

— Director of a newly formed Sega of America advanced technology team in an early 1992 meeting with game producers.

People who don’t actually make video games have this understandable misperception that games are just like any other kind of software development. Even very bright, very experienced experts will fall into this trap, because there’s a success metric for games that they don’t understand, one that simply doesn’t exist for other kinds of software.

Fun.

People in the game biz love to talk about ‘finding the fun’. Well yeah… of course they want their games to be fun, but what does that even mean? And why do you have to ‘find’ it?

What they’re really talking about is building a piece of what they think they want the game to offer and then trying it out. Playing it. Touching it. Examining their own subjective reactions to it. Because they’re attempting to figure out whether the thing they’re going to ask millions of people to do for dozens, hundreds, sometimes even thousands of hours, is something they will actually enjoy doing. Obviously, ‘finding the fun’ is a big deal. What may be less obvious is that what’s called prototyping in the world of software development isn’t the same thing as finding the fun. Prototyping is about answering questions based on clear goals and a design that tries to meet them. But what if you’re not sure about the goals? What if you don’t know yet where the fun actually is?

This is far from a rare problem in games.. Famously, in the early days of Halo, the Bungie team wasn’t sure whether they were making an RTS, character action or a shooter. Fortnite started as a survival game. World of Warcraft began as the bizarre melding of a chat room with a point and click adventure. The hard truth is that, when you’re pushing past familiar gameplay, you literally don’t know what you don’t know. And the only way you’ll find out is by building enough that you can touch it.

That’s where Jurassic Park started going off the rails. The designers and producers had plenty of ideas but, instead of taking the time to understand how those ideas translated into moment to moment gameplay, they jumped straight to implementation, not just of one or two ideas. All of them. The result was a confusing jumble, none of which was fun to play.

Focus on outcomes, not organizations.

In the meeting of department heads that happened six hours after that early morning call, the finger pointing was legion. Art was calling out Programming because animations were hitching. Programming was complaining that the design was changing every few days. Design was bitching about Amblin ignoring design documents for weeks and then suddenly rejecting them. It was the Spiderman finger pointing meme twenty years ahead of its time. Some of it was deflection. The producers were conspicuously absent and the department heads all walked into the big conference room that morning expecting to be next. Some of it was the inevitable tribalism that emerges when big teams are organized around areas of expertise.

But there wasn’t time for tribes. This studio was going to live or die on what they could get done in twelve months. So the former studio TD, now producer and project director, used a technique that he learned doing experimental projects for the Army. The phrase ‘tiger team’ originated in a 1964 paper written for the Defense Department, but it got famous when NASA was trying to save the three astronauts of Apollo 13 from what looked like a cold and inevitable death.

He borrowed the term and told the department heads they were still in charge of their people, but the project was going to be divided into functional chunks, clusters of features that were naturally related to each other. Then those features were going to be built by little teams made up of coders, artists, animators, audio specialists… whoever was needed.

Most importantly, each tiger team had a single customer. Him. If Amblin bitched, he took the heat. If Sega executives had ‘suggestions’ he handled it. The members of each team moved their desks so they could sit together. The project director met with every team every day. He listened. He helped them solve problems. He didn’t second guess them. He told them what his non-negotiables were and let them do their jobs. The result spoke for itself.

This technique is, in a very real way, the same one Valve so famously embedded in its employee handbook. It’s how TLG operates at a fundamental level. Teddy Roosevelt said it pretty well over a century ago, “The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint to keep from meddling with them while they do it.”

The size of a meeting is inversely proportional to its value.

This isn’t a new revelation. We all know how easy it is for a room full of people to spend hours on nothing but procedure. On Jurassic Park, especially when the team was learning how to work in a new paradigm, very frequent, very small meetings helped cut through the noise. Back in its early days, just after the EA acquisition, the Stockholm based studio DICE was famous for their variant of technique, with team members going to the break room and hashing stuff out. It’s an old trick for a good reason.

As a distributed studio, TLG takes this method to its logical endpoint. We rely on individual contributors to constantly reorganize themselves with the aim of optimizing every single day for where they can have the greatest impact. It’s not a way of working that everyone is comfortable but the results can be phenomenal

The Iron Triangle is really a tetrahedron.

Project management experts are fond of labeling the three corners of the infamous project triangle as Time, Scope and Budget inferring Quality as a sort of consequence of the other three properties. Nothing could be farther from the truth. Quality is never a ‘consequence’. It’s governed by conscious choices, just like the others.

Part of what Jurassic Park got into trouble with its uncertain design was pressure from Marketing to extend the feature set - the assumption, of course, being that bigger scope would yield higher quality. But, as Ben Ostrander, one of the unsung sages of the early pen and paper game design world was fond of asking about features, “Does it make your game better or just more complicated.” More often than not, it’s the latter.

There’s no question that adding scope to Jurassic Park increased time and budget but it actually had the inverse effect on quality. At TLG, our general approach is to aim for the highest quality our skill set can achieve within the constraints of time, budget and scope. We try to set the height of the pyramid and then look at what that does to the other three corners.

Possible is not the same thing as valuable.

Probably the biggest failing of Jurassic Park as a game experience was the commitment to FMV as a core element of the game’s presentation. This was a direct consequence of Sega’s desire to offer something no other game console could do at the time. Obviously, they wanted that offering to be tied to the unit’s CD-ROM and some early work with CD based full motion video seemed to point the way to a whole new paradigm in games.

Jurassic Park used FVM extensively, both in the form of cinematics framed as video communications from characters in the story and in educational content shot with the prominent paleontologist Robert Bakker. Unfortunately, while the video looked quite good on a PC, even in the relatively low resolution of 320x240, the limited color range of the Genesis graphics chip made the game’s video sequences look grainy and heavily dithered in the final version of the game.

This is a poignant example of how easy it can be to let your design be dictated by shiny new tech instead of the player’s experience. It’s also an illustration of the fallacy of sunk cost. By the time of the project reset, enormous amounts of money had already been spent on video production and only a small number of sequences with two of the story’s characters remained to be shot. Sega leadership ultimately mandated that the FMV stay in the game and, while it did get some positive notices for novelty, and even writing, its overall reception was lukewarm.

Lessons Learned

In the end, Jurassic Park became the best reviewed, best selling game on a failed platform, the first in a series of missteps that led Sega to step out of the hardware market in 2001. But that’s a topic for another post… or three.