On the fifth anniversary of the release of this unique and underappreciated shooter, Here's an in-depth postmortem that first ran in Game Developer magazine in 2011. It was written by Adrian Chmielarz, who was creative director of People Can Fly.

What could go wrong if your first project is an unassuming old-school PC shooter, and your second project is a big, multiplatform AAA title? Why would things be different if you grew from 15 to 70 employees in a couple of years? How does it feel to go from e-mail interviews to standing in front of the entire world as it watches your live E3 presentation?

Yeah, this could be a book.

Ten thousand things went right and ten thousand things went wrong during the production of Bulletstorm. Obviously there's not enough space to talk about them all, so this article is a very subjective selection, mostly filtered through the design side. It took three and a half years to make Bulletstorm. We've learned, we've grown, and we hope you'll find something for yourself in this story as well.

BULLETSTORM

PUBLISHER: Electronic Arts 
DEVELOPER: People Can Fly/Epic Games 
NUMBER OF DEVELOPERS: Around 80 at PCF 
LENGTH OF DEVELOPMENT: 3.5 years 
RELEASE DATE: February 22, 2011 
SOFTWARE: Unreal Engine 3, 3ds Max, Maya, Photoshop, Modo, ZBrush, Motion Builder, MS Office 
PLATFORM: Xbox 360, PlayStation 3, PC

WHAT WENT RIGHT

1) Focus on core combat loop

///Our philosophy is that it’s better to have a great game that’s just about spitting than a mediocre game about spitting, screaming, and playing the banjo. 

If you have ever sighed at a game’s attempt to offer variety (e.g., not every game needs a driving section), you already know what I mean. 

Also, stop thinking about that banjo game. It’s not going to happen. 

We spent months polishing our core combat loop: shooting, kicking, sliding, leashing. A millisecond here, a 1% more transparent particle there. Improve, playtest to death, rinse, repeat. We knew it all worked together well when we started missing elements of our CCL while playing other games. I cannot count the amount of times I wanted to kick or slide into an enemy when enjoying a competitor's FPS. 

Of course, modern games cannot rely on the CCL alone, but we also don't think that having myriad core features is the right solution. You will never have the time to polish them all properly. 
We decided to focus only on the crucial ingredients, get them to 100%, and have the gameplay variety come from a wide palette of contexts to the CCL. For example, the kick is always the same thing—the same animation, the same sound, the same button—but its purpose can change depending on what the player needs to do. Kick to push an enemy away. Kick to destroy an enemy's armor. Kick to open a door. 

2) Pacing and balancing pass

/// As with most games, Bulletstorm was built by multiple level designers, each working on their own fragment of the game. At a certain point we felt that every level had really great pacing: a good warm-up, varied encounters, and an interesting cliffhanger. 

Most of the levels were done with “big picture” pacing in mind. For example, the Cave level started slow, because the ending of the preceding level was a six-minute boss fight, and we wanted to let players relax a little. 

But as all game designers know, theory is one thing, and the actual implementation is another. When we put the game together, some pacing problems immediately crawled out of the woodwork. The Cave's relaxed opening was a good idea, but lasted far too long. The Underground and Ulysses sections were great on their own, but both exclusively featured one type of enemy (Burnouts), and that was tiring in the long run. The Dam level felt too long, even though in isolation it was one of the best levels in the game. 

We made pacing and balancing our priority. We removed and added battles. We shortened cinematics. We fine-tuned all the values for ...everything. 

In the end, we got a really well-paced game. Unfortunately, it was a little too well-paced for its own good. Wait, what?! 

Imagine a shooter or a horror game that takes eight hours to finish, but where the experience is so intense that you only play one to three hours daily. It means it will take you three to five days to finish the game, which is how we imagined our game would be. 

However, with Bulletstorm, we have seen time and time again that people got so engaged in the experience that they finished the game in one day. It was still eight hours, but played in only one or two sessions. That allows us to enjoy the fact that over 50% of players finished Bulletstorm, which is higher than the industry's standard (this is easily trackable by checking “Finished the game” achievements in services like Raptr—see References for more). But at the same time, opinions started floating around that the game was short.

It was not short by current standards. But to gamers, two four-hour sessions are not the same as five hour-and-a-half sessions. 

We are still proud of the pacing and balancing work, but intensity versus time is something we’ll have to think about in future projects. 

3) Finding the fun through early focus tests

/// We never planned to offer a unique gameplay hook. We just wanted to evolve the genre a tiny bit. Maybe we’d do it by unmuting the main hero, even though it’s a first-person game. Maybe we’d differentiate by making sure that the sidekicks are not automatons spewing context-sensitive comments, but actual people we can have strong feelings about. Our intentions were nothing more than that. We just wanted to offer a fun high adventure—that's it. 

However, the aforementioned focus on the core combat loop, constant iterations, and—most of all—internal focus tests led to the invention of Skillshots. 

I am a big fan of games that offer multiple pseudo-independent systems. That is the core of any emergent gameplay. Bulletstorm has a few systems like that: multifunctional weapons (e.g., the flail chain can wrap around enemies or objects), an interactive environment (e.g., the explosive trash cans of the future can be moved around) and the tools of war (kicking, sliding, leashing).

Players can manipulate and use these systems any way they want. That leads to a lot of emergent gameplay moments. You can kick an enemy into a trash can, which then explodes, which causes another enemy to go airborne and get pierced by a rocket fired by another enemy positioned on the rooftop. 

But I would never have thought of naming these crazy actions—and indeed, I would never have thought of Skillshots at all—if not for internal focus tests. 

To some developers, the focus test sounds like something to dread. They think: “There’s a reason why I’m the creator, and they’re the consumers.” That’s fair enough, and there is some truth to it; but on the other hand, there’s also a reason why Blizzard wins so big after spending insane amounts of time playtesting and fine-tuning. 

Our early focus tests were nothing official. We were just watching each other play. In casual conversations we debated what was fun and what sucked. 

But it was during these monitored play sessions that I noticed people were using Bulletstorm's emergent combat not to be efficient, but to have fun. A headshot is a much faster kill than leashing an enemy toward you, then kicking him into a cactus. And yet still people kept on doing that, and even much more elaborate things. They were experimenting. Testing theories. Having fun. 

“Hey, why don't we actually reward people for being creative?” I thought. “How about we call it a Skillshot system?” And one of our core selling points was born. 

4) Many companies, one game

/// You can imagine the fragmentation challenges we faced with PeopleCanFly as the main developer and creative owner, Epic as co-developer and quality enforcer, and EA as the publisher. And there were a number of additional companies from all around the world helping us as well (in Germany, USA, China, Sweden, and Poland). 

This stuff is not for the faint of heart. 

Oddly enough, coordinating the outsourcing was not the hardest part. With good, dedicated producers in place, it’s actually something I am sure to repeat in the future. 

It was the PCF/Epic/EA cooperation that caused the most problems. Everybody was equally important, and everybody could influence any part of the development process: design, production, and so forth. For example, both EA and Epic were giving us independent feedback on the milestones and playable builds. It was a mess.

Fortunately, we all noticed that very quickly. We understood that the key to fluid cooperation is a proper distribution of roles and responsibilities. In other words, sometimes you have to let go. 

We immediately streamlined all these processes. Using the feedback example, EA was no longer sending feedback to PCF but to Epic. Epic then merged EA's feedback with its own, empowered to remove whatever they disagreed with, and then sent one unified chunk of feedback to PCF. This way we only had to deal with one source of feedback, were no longer prey to multiple masters, and stopped worrying about the priorities of the feedback items. 

If you are working with several partners, letting go is the key. One of you knows more about the marketing than the other, another is a better judge of quality. Clearly define who is responsible for what, and make life easier for everyone. 

5) Unreal Engine 3

/// Ha! What a surprise: a guy from a company owned by Epic, creator of Unreal Engine, praising the Unreal Engine. Good one! 

In 2004, we released Painkiller. The game took two years to make, with a 15-person team (on the average). We had a long single-player campaign, and a fun multiplayer mode that was a CPL (Cyberathlete Professional League) game of the year. And we did all that using our own engine, which we created from scratch. 

Painkiller was really an extremely simple game at its core, though, and yet still we struggled. We had to outsource cinematics in order to finish the game on time, for example. If it had been any more complicated—and I am not talking about big stuff like going multiplatform, I merely mean things like featuring a sidekick—the game would never have happened.
Instead of merely listing the benefits of Unreal Engine—something you either already know or can easily google—let me just tell you three facts from PCF's past. 

First, we decided to switch from our own engine to Unreal well before we had any idea that one day we might be a part of Epic. It was worth it to hear Mark Rein scream, “Finally!” into the phone. Second, from the moment we got the engine, it took us only a month to prepare a demo for publishers—a demo that Epic saw and said “Hold on for a second there, let’s talk.” Third, it took us two months to make two levels of Bulletstorm for a pitch demo that we showed in Leipzig to various publishers, and which got us a deal with EA. I have absolutely no idea how we could have achieved that without UE3. 

WHAT WENT WRONG

1) Creative f-bombs

/// Bulletstorm was often critiqued for its seemingly endless stream of four letter words. 

Do you know any swear word in a foreign language? German, French, Polish? When you say it out loud, no biggie, right? Not a problem to use it during a family dinner, I assume? 

That is how all the f-bombs sounded to us. Being Polish, all the strong language in Bulletstorm was just exotic and fun to us. We did not feel its power. In other words, Epic thought this is what we wanted and respected our creative vision, while we had no idea this vision was a bit more than we really wanted.

It was only at the end of the development, when I read the Polish translation of the game, that I realized how dirty we were. I swear a lot. A LOT. Yet still I ... kind of blushed.

But, to be honest, the language would not have been a problem if not for its creative usage. There are games that use way more f-bombs than Bulletstorm, and yet somehow it's less of a problem for them. Why? 

That’s because most of the time the language is forgettable. If you hear a character say “You f***** scared me, you a******!” you forget about it two seconds later. Although, if he says “You scared the d*** off me!" it stays with you for a little bit longer, which creates the impression that the game is much fouler than it really is. 

We tried to solve that by adding the language filter. Originally we forced the players to make a choice before they even got to the main menu. With best intentions to make the experience more fluid we moved the option to one of the submenus.

Big mistake. No one noticed it existed. It cost us a few prestigious reviews and a sea of tweets from angry gamers.

Next time, do it like Brutal Legend: a forced choice, during the game, right before the first f-bomb. Personally, just in case, the game should ask the players once more some time later. 

2) Slow beginning, debatable ending

/// I am not a fan of action-packed openings to video games. You do get players’ attention, even if the attempt reeks of desperation, but the inevitable lull after the intro is over is a pacing killer. I think the only time I