Where do games go wrong? Article

Designer

During the process of making a game, a lot of things can go wrong. You could write a book about the potential pitfalls of game production (evidenced by the fact that some people do), but for me it all boils down to one crucial component: the designer. How many times have you seen interviews with designers who talk about a committee mentality and inviting input from everybody on the team? Now consider some of the world's most famous game designers, people like Shigeru Miyamoto, Yu Suzuki and Shinji Mikami. Their visions are singular and unquestioned, and the results are a reflection on their respective imaginations.

The job of the game designer is, obviously, to design the game. "That's not to say it is all cast in stone - far from it", according to one of our correspondents, who we'll call Dungeon Keeper (a sneaky hint at his past). "The designer should be prepared to make sweeping changes during the course of the project if that is what's required. Everyone can make a valid contribution but, at the end of the day, the designer is the one who has to collate and ultimately decide which ideas to implement."

The quality of the designer is a concern shared by another of our correspondents, erstwhile Brit-in-exile Bubby. "Designers deliver worlds where rooms are needed, novels where two lines of text are needed", he says, the painful memories piercing his subconscious. Designers make or break the game before anyone else does. You can build up one of the most intelligent and experienced development teams in the world, but if you give them the job of creating what is effectively a Tetris clone, nothing good will come of it. Come up with something original, potentially enjoyable and just plain exciting, and the team will respond. Entertainment breeds entertainment. Strong team morale and a design from somebody who knows and plays games is critical, and a good game is one dictated by gamers throughout.

Project Management

Even if you employ a good designer though, his work can easily be scuppered before it gets anywhere near retail. Fundamentally, as Bubby puts it, "it all comes down to poor management of the team and poor decision making". Bubby's scapegoating of poor project management is also the focus of another member of our panel, young Digit, who knows from experience that it pays for the designer to be the strongest and most experienced member of the team.

"Planning is tantamount to a game's production, and if that isn't handled by someone trained in project management the whole thing will go tits up", he explains. The most important component of project management is scheduling. "You need to slot together what people produce, be it design, art or programming, and ensure that when designer A needs artwork X, it's actually there and not scheduled to be produced three months down the line."

Dungeon Keeper agrees. "One of the hardest things in a game's development is guessing how long things are going to take. With ever increasing demands by publishers to deliver the goods on time, developers might find themselves having to compromise their final product to meet the deadlines. This is either in the form of refusing to alter a flawed design or changing the design but taking too long and missing the deadline. Talk about your all-time rock and a hard place situation."

"The whole production cycle needs to be scoped correctly", Digit adds. "If someone starts assuming that there will be time down the line for something to happen, rather than ensuring there actually is, you run into problems". There is a solution though, as Dungeon Keeper reminds us. "This can only be avoided by building in sufficient 'tweaking' time at the start of the project. Most developers tend to massively underestimate how much time they will actually need for this process", effectively signing their own death warrant.

Individuals and inflexibility

Laying the entire problem on the doorsteps of one or two people is a mistake though, as Bubby explains. "Programmers promise to deliver the latest, greatest features, then deliver a half-baked half working bodge that gets past the latest milestone but fails to provide a solid system to build a full game on. Artists deliver models and environments that are completely unrealistic for the technical requirements." Management is still to blame for employing these people to begin with, but by failing to do themselves justice, they let the entire team down.

"A better lead programmer would have delivered a realistic polygon/memory budget early on for the art team to work around, and a better artist would have demanded a poly budget to begin with", Bubby adds. "Developers consistently wait too long to fix (painfully obvious to outsiders) core problems with their technology and design, leaving it to the point where only 'quick fixes' can be applied to flaws in the game design or code."

Comparing videogame production to that of a movie is a total mismatch, and it always has been. Take for example the problems that a viewer may perceive with a Hollywood blockbuster. One might criticize bad plots, hammy acting, continuity errors, bad make-up, poor choice of costumes, anti-climactic visual effects, bad camera angles and a poor script for a start. These problems are the result of poor writing, acting, casting, editing, camera work, research and design decisions, and inadequate budgets - problems which stretch throughout the development and production cycle of your average movie and yet barely scrape the top layer from a barrelful of potential problems.

Apply the above pitfalls to the process of making a videogame. As a developer you not only face perceived problems with your game at the end of the road, but preconceptions and desires from punters which could thwart your plans right from the outset, and it's a combination of individual failure and inflexibility which is responsible. "The game should be played as often as possible as it is only through playing of the game that you will find out whether it's any good or not", Dungeon Keeper believes. "If elements of the design prove to be less fun than originally anticipated, then they should be taken out, or at least altered to be more fun. A problem that is sometimes encountered here is the programmer or artist stating that 'well, that's how it was originally supposed to work' and either not wanting or not having time to change the item in question."

External Pressures

As if all this weren't enough, developers are under constant pressure from publishers and license owners to adjust their vision. This messes with the whole carefully oiled dynamic by injecting confusion and last-minute problems into the already frantic maelstrom of development. Digit's experience with previous employers has taught him a thing or two about external pressure, and he sighs wistfully as he thinks of how it might work.

"You should have a clear project proposal okayed by the money people (publishers) from the off, which will define very clearly what you are going to do", he says, stroking his chin. "That makes it harder for them to change their minds about fundamental aspects of the game well into development without them bearing the cost of the change and accepting the project timeline will have to be adapted." Publishers ignorant about the realities of game design? Surely not!

"There will always be niggles that crop up and annoy developers passed on from nameless people with a vested interest in the game elsewhere", he says, stifling a cough which sounded an awful lot like the word 'marketing'. "You have to put up with those, but they will often turn what might have been a great section of the game into something totally indifferent based on one person's ill-informed opinion sat in an office miles from anywhere, and also probably not fully appreciative of what is trying to be achieved." Okay chap, steady on. Digit's right though - how often have you looked with a sense of complete disbelief at something in a finished game, pondering just how and why the people responsible came to this particular conclusion? For me, it's a day-to-day occurrence.

Game development also faces the machinations of a minority. "There is also the fact that some people will request changes purely so it looks like they're doing their job", Digit adds. "Those situations are hard to swallow. Sometimes, mostly with licensed games, if you look at the list of people credited in the back of a game manual it will be three or four times as long as the actual number of people who physically worked on producing the game itself. All those other people need their say in the way the game is made at some intangible level."

Conclusion

So what makes a bad game? Too many Chiefs and not enough Indians. The problem with game development at the moment is that everybody has a hand. In the 1980's the whole thing could come down to one or two people working together on each other's side of the project as much as their own. Those games had problems too, but they were problems born of technological dissonance, budget issues, real-life work commitments and unpredictable consumer interests. Fast forward to the present day and we have developers and publishers slipping and sliding all over the stock market, folding and ejecting staff. An enormous amount of money is anticipated and required by those on every side of the projects that do see the green light. Perhaps if we moved back to smaller teams with an array of people doing exactly as they were told, things would be a lot more entertaining and blame a lot more assignable if things were to go wrong.

The key to this creative freedom is for producers and publishers to stop hassling the developer and let them get on with their work. Don't rush your games, chaps. If you want to hit a particular release date then plan ahead and don't go blaming the developer when a finished product is completely unobtainable a week prior to its delivery date. The key to a good game is a well-staffed developer with a good design document left to its own devices. If you don't know this by now, then you should.