The secrecy of games development

The secrecy of games development

By Al Bickham

August 31st 2012 at 2:14PM

The Creative Assembly's Al Bickham discusses the risks of revealing too much about your game too early

I recall some years back when I worked for a publisher; someone on the QA team took a screenshot of the PS3 trophy list for our upcoming game, and posted it online.

He was out the door within the hour.

The poor fellow probably just wanted a little recognition that he was working on a super-cool project.

That’s understandable, but it’s hard to fathom how, steeped in the heavy atmosphere of non-disclosure at every publisher or big developer, he came to the conclusion that this would be an okay thing to do. As opposed to, say, a critical breach of his contractual obligations.

High secrecy isn’t so much the domain of the indies – at least not to the extent of the large studios with big-publisher backing.

Without the ammo-train of global marketing support, indies have to work harder on discoverability, and the kind of open, play-during-Beta approach that’s making gems like The Indie Stone’s Project Zomboid a growing success appears to be a healthy symptom of an evolving business model.

THE WALLS HAVE EARS

It’s a different story entirely for triple-A. When content differentiation is your stock-in-trade, your game’s unit price is higher and you’re competing over limited market-share, secrecy becomes more critical.

You can plug every perceived hole, NDA the world and its dog, and thread yourself into ribbons as you noodle around the web looking for leaks.

But leaks happen, and with so many people in your organisation working to prevent them, they generally happen for reasons you hadn’t anticipated.

Over the course of a big development cycle, other factors stride into play. Marketing and PR exist in elastic tension with dev; the marketeers want game-facts set in stone so they can execute a smooth campaign that rises in intensity over time, and creates a level of predictability.

Thus, creating a planned rollout of features over time; which means limiting the amount of information delivered at any given beat of the campaign.

The flipside is that, through the course of the development cycle, features change; prototyping throws up red flags for features not worth iterating upon.

Iteration highlights faults with features that looked great on paper or at prototype stage. Some features work, but just don’t add anything meaningful to the game, so they don’t make the cut; some change well beyond their original conception.

Your game evolves, the feature-set alters, and you don’t want to scream about ambitious features early on that may not materialise in the final game. We all know how that pans out.

So what happens? You limit the information delivered publically at every given beat of the campaign.

It’s infuriating. You want to shout it from the rooftops: ‘look at my awesome game! Look what it does! Look at our wimple tech!’.

You announce your game, and there’s this palpable exhalation of relief across the studio, followed by a happy buzz. But the dev and marketing costs for getting a game to market prohibit full transparency; it’s just too risky to shout about your more detailed plans early on.

It annoys journalists and developers alike, but that’s the way it has to be.

A MATTER OF SCALE

To the indie dev team, this may sound like our diamond shoes are too tight, but it’s indicative of the different scales our industry operates at, and the close consumer-connection we have that’s so rare in other markets.

If one indie’s communication is confused, patchy, or features are dropped or otherwise left unfulfilled, then the response from fans is more likely to be sympathetic.

If there’s 100 of you, suddenly you’re crooks and cheats.

Finding out where the thin line between sympathetic fan and outraged consumer lies will happen to everyone sooner or later, and the proliferation of Kickstarter projects is likely to narrow the search very quickly.

Indies have a special relationship with the gaming public which armours them against many of the public perception problems corporate developers face, but there are lessons in information management to be learnt from the bigger companies.

Whatever size you are, thinking a little more about what you release, when, and with whom, is some of the simplest and most effective public relations work you can do.

And it can even head off customer perception problems in the future which, if you’re living and dying by your limited exposure, can end up being far more vital in the long run.