This is the mother of all zombie outbreaks, the F5 on the Fujita scale, the 10 according to Richter. The end is here, now. Standing against the tide are the survivors, one of whom you choose to control in a 3rd-person action game like no other. Your only quest is one of survival, you define the mission by how you define the word. Many will band together and work to improve their lives by building a society, utilizing skills and training from their former lives to rebuild infrastructure and order. Some will go it alone, preferring to scratch out their own safe harbor. All will have to face the rising tide of the undead, the perfect foe, a relentless enemy. All will fight.
That’s how Brant began his description of the game we were envisioning. His words evoked a picture of players taking on the challenge of long-term survival in the face of the zombie apocalypse, including everything from pulse-pounding combat to strategic decisions about where to make a stand. We saw this premise as an opportunity to make an online world focused on player-driven experience instead of static, treadmill content.
In short, we would empower you to try out your real-world zombie-survival plan.
We were rapidly forming a high level picture of the game:
- Zombie survival. We start with an unwavering focus on bringing the whole zombie survival experience to life. It’s not just combat. It’s about meeting survival needs. Food, water, shelter, ammo… You’ll need them all.
- Amazing action. Absolutely zero compromise on the moment-to-moment look, feel, and fun factor of the game. You shouldn’t have to put up with unexciting mechanics just because they’re packaged in an addictive wrapper. The game must play like a great console action game.
- An evolving, dynamic world. These sound like buzzwords you’ve heard so many times before, but for us it’s a real goal: creating a game where players’ choices and ability to build have permanent impact on the world. It informs everything we do design-wise.
- Player choice and empowerment. Every one of the points above is tied to this. A survival situation is about making choices. Great action gameplay is about responsiveness and feel, but it’s also about freedom, and the way to have an evolving, dynamic world is to empower players to affect that world.
So there we were last summer, breaking things down feature by feature. The pieces were falling into place quickly. Every conversation about booby-trapped vehicles or zombie dismemberment seemed to trigger someone saying, “Damn. When do I get to play it?” But enthusiasm doesn’t automatically mean success. We were talking about an ambitious concept with real design and implementation challenges, and that’s why today’s press release and our follow-up Q&A document describes two games, code-named ‘Class3’ and ‘Class4’.
To explain why, I’ll need to share some development philosophy. There are whole conferences dedicated to the topic, but here’s my short list:
- Know what you’re making. This is a point Jeff emphasized early on. “You know the number one reason projects fail? Because not everyone on the development team is trying to make the same game.” Sound crazy? You might be surprised. Especially with larger teams, it can be a challenge to keep everyone on the same page. Right from the start, Jeff challenged me to define three pillars for the game — three sentences that would represent our goals and guide us throughout development. “These three pillars should never change.” It took 20 minutes. [And will be the subject of a future post! — Emily]
- Commit to greatness. By and large, people are in this business because of their love of games. They hunger to make something great; they dream of creating a classic; but there are a hundred things that can derail that ambition. Some are internal, but many are external: budget, schedule, morale, direction, support, etc. Are they helping the game be great or are they sabotaging the process? We know Microsoft shares our goals and believes in our vision for this game and when they want to support something, they have the muscle to do it.
- Put your ideas to the test. We all make mistakes. Even me. (Er, even I?) Luckily, avoiding mistakes isn’t actually the key to success; it’s finding them fast and being willing to fix them. That’s why so many development tips are ways to put your ideas to the test early and often: Hiring only gamers. Rapid prototyping. Agile development. Philosophy of iteration. Strong tools and pipeline that allow rapid refinements. Usability tests. All of these help you catch mistakes and fix them quickly.
You probably know that most online world games are buggy and incomplete at first. 
It’s not because the teams suck. The games are so big and complex that it’s hard to make one that functions, much less one that’s good. Teams can spend years trying to get all the big, complicated pieces into place before learning if their game is any fun. And that makes it hard for them to know what they’re making; it makes it hard, during that seemingly interminable slog, to continue to commit to greatness; and it makes it impossible to put their ideas to the test early and often. In other words, it’s not a formula for success.
So we asked ourselves if we could plan our project a different way. What if we didn’t tackle the full size and complexity of Class4 from the start? What if we committed to making the core gameplay fun first? Not as a little tech demo but as a fully-realized game. What would that look like?
- You’d get the great action Foge promised. Melee combat, gun combat, driving and exploration. It wouldn’t need absolutely every gun and vehicle and zombie variation we could imagine, but more than anything, this part of the game would need to feel complete, not placeholder.
- You’d be able to play with a friend. Cooperative play is a defining part of being in an online world, and it’s damn cool on consoles. We had to have it. With our online world experience, we’re comfortable not tackling every technical and performance challenge of having massive numbers of players running around at the same time just yet. We know how to solve those problems. To start, though, what we’d need is two-player cooperative play.
- You’d be able to build. You should be able to decide where and how you want to find shelter. An isolated hideout for the night? A fortified base? How fortified? How many survivors do you bring together? Will you grow your food supply or scavenge for it? All these things should be up to you to decide.
- You’d be in a dynamic, evolving world. We‘d also need our dynamic world systems designed and working. We wouldn’t have to implement every possible kind of change that can happen to the world — for example, we don’t need to tackle complex features like seasonal changes — but we would need enough to have the world feel genuinely alive.
We immediately dubbed this game ‘Class3’, and we could see it would be an ambitious but feasible XBLA game. The more we talked about it, the more we liked the idea. There was a lot to like:
We’d get real-world feedback about our game. Do you always avoid areas with Screamers? Are you complaining about the balance between machetes and chainsaws? Hell, do you want more involved farming options than we anticipated? The more feedback we get about Class3, the better Class4 will be. And not just the game. The team. Class3 is a chance to ramp up our community team and gain experience talking to you and gathering feedback. This will help them hit the ground running for the more complex community management issues that’ll come with Class4.
We’d make the game fun right from the start. There’s a paradox to game development: Designers make better decisions the more the technological limitations are known, but programmers better define technological limitations the more the design is known. Chicken, meet egg. The bigger and more complex your project is, the more you have to work around this issue. (Hey, how does car customization affect UV layout on vehicles and overall texture budgets? Oh, it depends on the car variety in a typical area, does it?) In a game, everything is related in some way, so a smaller, more focused game doesn’t just mean fewer things to do, it removes unanswered questions and speeds up the things you have to do. That puts fewer obstacles between us and building our core gameplay.
We’d have a full production cycle of experience with our pipeline and our tools. That gives us a chance to refine them before kicking off large-scale Class4 production. Every game developer dreams of having the perfect toolset, the one that lets you spend your time making the game fun instead of struggling just to get things working.
Finally, we’d have to put up or shut up in short order. You guys don’t want to read blog posts from me for the next half decade where I tell you how amazing and revolutionary and uberleet-yadda-yadda our game is going to be. I don’t want to play the role of PR wonk doing interview after interview that amounts to “Trust me. Someday you’ll see it’s AWWWWESOOOOOME!”
More than anything, that last point excites us. Is it a challenge? You bet. But that’s what we want. For us, it’s not about the talk, the hype, or any of that other nonsense. We live to create, to get stuff into your hands, and, we hope, to make something you’ll love.
And that’s what we aim to do.
