3 minute read

Nobody who has built half a house wants to knock it down and start over. What a waste of effort! But if you're building the house wrong, if it doesn't make a space that people can actually live in, then completing the house would be the waste of time. You ought to knock it down and start again. It's just the same with a game project.

There's much talk about 'agile' development in software development, including videogames, and this word suggests that teams will be flexible. There's some truth to that - after all, the key insight of agile development lay in shortening the development lifecycle to provide more flexible iterations. That was a radical departure from the more traditional method of planning everything out in excruciating detail at the start and then simply trying to implement it all as written. That method had a huge disadvantage - you learn the most important lessons about a project when it's underway, not while you're planning it.

What do you do, though, when you find yourself backed into a corner with no apparent options?

How are We Going to Get Out of This One...?

The last thing anyone wants to do with a project is pull the plug. But it does happen that you reach untenable situations. It's part of doing business and it cannot always be helped.

What we have always tried to offer at International Hobo, though, is more than a 'yes-no' approach to project consultancy. A significant number of the nearly 80 game projects we have helped clients to deliver are 'rescues', projects that got into trouble. What sort of trouble?

Projects that never established a clear vision, and so didn't know where they were heading.

Projects that thought they could make up their design elements as they went, and so didn't think about how all the systems had to fit together.

Projects that had too many systems to deliver in the time available.

Projects that had beautiful art but nothing to do with them.

Projects that became invalidated by unexpected shifts in the market.

Projects that knew what they wanted to be as games but not as stories, or vice versa.

The loss of morale that a team faces when they come up against these sort of problems can be devastating. Which is why it can be immensely helpful to get on the phone to Tracy Island and call for the Thunderbirds to rescue a project from having taken a wrong step.

Can Anybody Help Us...?

It's not a coincidence that the name 'International Hobo' evokes the name of the rescue organisation in the 1960s classic sci-fi puppet show Thunderbirds, 'International Rescue'. If it wasn't somebody else's brand, we'd have loved to have used that name instead! The very mission of the company was to be able to find ways to solve the new problems that the games industry was encountering at the start of the twenty first century.

At the core of our original mission was finding ways to put people with story skills together with people who had game skills. This led to Richard Boon and I coining the name 'narrative design' for the process of making story and game pull in the same direction, a term which spread into the games industry via the IGDA's Game Writing Special Interest Group, which I set up and ran. In 2006, Stephen Dinehart became the first person to be hired as a 'narrative designer'. Narrative design is now a big part of the games industry's business, and we're proud to have had a role in making that happen.

But although narrative design was always a key part of what we did, our vision of it was always based upon the idea that games were collection of assets and that it matters how each of them gets used. What matters is both how it looks and how it behaves in the game systems, and because both the function ("it shoots the player") and the fiction ("it's a tank") matter, every game is always producing a narrative experience for the player. You cannot avoid performing narrative design if you're making games, although you can certainly do it badly!

When we've come on board to rescue a project, we always start with the asset list. What do you already have? That sets a major constraint for what a game could become, which doesn't have to be anything like what the game was originally intended to be. Coming from the outside, as discussed last week, gives us the opportunity to think up new ways of making a game work, by building new options for narrative design from the available building blocks.

I've never seen a project that couldn't be rescued, provided the team is ready to ask for help. The key is remaining flexible, and not getting blinkered by what the project was originally supposed to be... and sometimes, teams need a little help to achieve that.

More consultancy advice soon.