Architecture logicielle & Développement

This talk is to compare with the “Better game through usability” talk, as the process is roughly similar. However, there is a big difference: while usability testing focuses on making the interface and general usability better, design by playing focuses on improving the player’s experience from a gameplay point of view.

As explained by Bruce Shelley (Ensemble Studio), designing game by playing them is a process defined by “playing a lot in order to improve different aspects of your game”. This process has been applied successfully by Ensemble Studio since its inception, and continues to be used today to design their new games. To implement Design by Playing, you don’t need many resources: what you need is a team of game developers who love to play games. The process is then a succession of rapidly handled phases:

• Implement a new feature.
• Test to see if the feature is fun to play with.
• If yes, keep it – if no, remove it.

Of course, this is a simplification of the real process, which can involve more than that. For example, game developers are a bit biased about their product, so you’d better use external testers as well (again, not the QA team – as their role is to find bugs and playability issue, not to understand the funniness of your game. As a matter of fact, they can also be categorized in the “professional hardcore gamer” category and this category is not representative of the mass audience – so their opinion might also be biased): your family, your friends, the girl you tried to date last weekend in that bar, or – if you are less reluctant about showing your early game prototypes to the average gamer – you can even abduct them at your local game retailer.

The result of such game design process is – by the experience of Ensemble Studio – well balanced games that appeal to a broad audience. Hardcore gamers find something to feed them while casual gamers are not turned away by the complexity of the game: everyone can have fun playing the game.

Of course, there are some drawbacks. The first one is that you can’t design by playing without a first game design – and of course a first implementation of this design. You need something to initiate the whole process.

Next, it’s impossible to design by playing without making numerous different builds of the game. Over the course of 3 years, Ensemble Studio generated more than 4,000 builds of their game “Age of Empire 3” – that’s more than 5 builds per day. So the first thing to do if you want to apply the same process is to make sure that your build process is efficient – if you need half a day to build a new version of your game, you’re screwed.

There is also a big problem related to the game design document: with that huge number of iterations, experiments and builds, it’s impossible to keep them up to date. Ensemble Studio used a very “agile” process to track ideas that worked and those that didn’t: basically, a sheet of paper (well, many sheets of paper).

But the biggest drawback is related to the project management itself: you just never know what will be implemented next, and as a consequence you’ll have a hard time to estimate the time you’ll need to finish your game. It’s also very difficult to manage a milestone based deal – because you just don’t know what you’re going to push in your game for the next milestones. If you’re an independent developer that doesn’t rely on a publisher to sell the game, that can be fine. Otherwise, this can prove to be quite difficult.

Strangely enough, feature creep is not exactly a problem: if you don’t have the tie to add a neat feature before shipping, just don’t add it. Bruce Shelley mentioned that near the end of the development of Age of Empire 1 they brainstormed to find new ideas. The result of this brainstorm was a multi-pages document where every feature was supposed to be implemented in the game. In the end, only half a page of these found their way into the game – and most of the unused ideas were used as a base to create Age of Empire 2.