Paying the price for bad games

Desperate games call for desperate measures. Last year, executives at Electronic Arts found themselves between a rock and a hard place. They had planned a revival of the basketball simulation series NBA Live under the new brand NBA Elite. The game was to be largely innovative, and was meant to go above and beyond the average yearly sports game update. However, near the end of the game’s development cycle, the company was forced to face a sobering fact: the game wasn’t going to come together in time. The publisher had already released a delayed, glitch-filled demo that players considered highly disappointing. What’s more, the competition, 2K Sports’ NBA 2K11, was shaping up to be the finest basketball game in years.

With its options dwindling, EA chose the road less travelled and cancelled NBA Elite at the last minute, a costly choice as the company had already made large advertising buys and flushed millions into development. Was it a savvy business move that protected the company’s brand, and raised consumer confidence that EA stands for quality? Or should it have released regardless of the long-term consequences? Would it even be ethical for EA to hope consumers made the mistake of buying an inferior product?

Some projects just don’t pan out. It’s a fact of life in the videogame industry. Sometimes ideas that sound great on paper just aren’t fun when put into practice. Sometimes a team – for whatever reason – doesn’t coalesce. The market can shift drastically between conception and release; sometimes the publisher simply runs out of the money or patience to see a project through.

Is the only option to cancel, waste millions of investor dollars and probably cost dozens or hundreds of people their jobs? Is there a sensible middle-ground between getting customers to pay for your shoddy game and condemning your studio?

EA's cancelled NBA Elite - a version of the game was released for iOS, however

One creative option that has become popular lately is the paid-beta approach taken by games such as Minecraft and SpyParty, whereby gamers ‘buy’ the game in its beta (or even alpha) form on the understanding that the game is not yet complete. This can go a long way towards helping smaller developers raise the cash to finish development while being fully honest with the players. The other option is to go free-to-play, offering players the chance to try the game risk-free, with the opportunity for further payment if they want to continue to immerse themselves in the game. When done properly, both options can be beneficial for the consumer and lucrative for the developer.

Many people hasten to point out that an ethical wrongdoing implies malicious intent. So for a publisher or indie developer to be firmly in the wrong for charging customers for a bad game, they’d have to set out to make a poor-quality game – which, obviously, no company sets out to do. So how do bad games happen?

In 2010, Game Developer magazine featured a high-level analysis of all of its post-mortem articles. It analysed what went wrong (and what went right) throughout the development of 24 different videogames. The study found that 56 per cent of all problems arose from issues in management of the production.

This is to say that when a project fails, it’s rarely the fault of the grunt coders, artists or even the designers. Far more often it relates to how the team is managed. This can relate to people being overworked or a team that has trouble communicating. It can also factor in excessive crunch time and staffing problems. These kinds of scheduling hiccups can lead to a lack of time for a lengthy code freeze – a period where new features have ceased to be added and all focus shifts to removing glitches – which can have a serious knock-on effect.

“One tiny code change can lead to massive bugs,” says Simon Carless, global brand director at UBM Techweb and director of the Game Developers Conference. “What developers aim to do is to have zero critical bugs before release. But if your game is gigantic, and if the amount of time from the final code freeze to release is too short – and indeed, if fixing bugs introduces more bugs, as it often does – you can see how this might happen. Luckily, the Internet provides a way to help patch problems. And unluckily, the Internet also provides an ’out’ for publishers or developers that may make them a tiny bit less paranoid about finding all the issues, since they know that they can patch.”