|
I've been toying with this new role-playing game idea of mine for the past a couple days. And you know what, I've realized that designing a complete role-playing game is a complex undertaking indeed. From reading Eric Zimmerman (et al.) I do know that designing any game is a second-order design problem but I'm talking about much more than that. The interaction in around the game table is very complex and can be structured in many ways, leading to more design problems in the way. Putting a rpg together reminds me somehow of software architecture design.  There, I'e said it. Not in a detailed way, just the way that you won't be able to design a new system perfectly before seeing or concepting some of its parts in action.
And this brings me to agile software development. Agile dev has been presented as a solution for complex, risky and uncertain software projects (so, most of them, actually ;) ). I've thought about how to go about designing a game in an agile way. Here's what I came up in regards to rpg design:
- Specify one specific game instance / situation
- Design a system / Tweak existing one for that instance / situation
- Playtest
- Assess, keep the things that worked
- If specified instance / situation not fully covered, back to step 2
- Refactor the designed system to fit with the whole
- Finished? If not, go to step 1
I'm sure some elaboration is needed. The first step involves specifying a single use of the system. I imagine it would be best to start from a small part of the system, like how to handle a specific situation in the game. It is best to start from the most critical and risky parts of the system. In later iterations the design can jump to one instance of game meaning something between the final game and a scenario for the game. Something with more restrictions than the final game is likely to have: For example, if you are designing a generic thriller game it could be preferable to first produce a sub-set of that, like a game to handle Infernal Affairs/Departed kind of two undercover guys at the opposite sides of the battle kind of stories (I've not spoilt the movie(s) for the two of you who haven't seen either I think ;) ). Maybe even with a playtest / demo scenario kind of set situation.
Designing and playtesting would be done as usual, I'm not going into those in detail. Well, a bit. Playtesting should be done in proportion of the specific game instance / situation in question. If a single mechanic is being developed in the iteration, it may be enough to playtest it yourself or with the help of some random friends just messing about with it. But with game instances you should at least do one or more playtest sessions yourself or even try to recruit somebody from outside to test the game it on her own.
Refactoring the system involves taking the results from the iteration in question and integrating it with the rest of the system. I imagine this can be pretty tricky (what to keep, what to lose, how to structure the whole system). The good news is that it all will be tested in the next iteration.
Are all rpgs designed like that? Probably not. Like agile methods in software dev I think this kind of exploratory design process would be best suited to projects with much uncertainty. Like games with new kinds of mechanic, interaction, goals, whatsoever.
The advantage of this approach as I see it is that you get a grip on some part of the game you are aching to design right away. The idea might change, you might find out that you can't yet get your head around some part of the whole but you get to divide the big ugly uncertainty to pieces you can swallow (agile riddle: How do you eat an elephant?)
The other thing is that you get constant feedback via the playtesting. This helps you keep your feet on the ground and your head out of the clouds if you analyze the playtest results objectively.
But this is just my first thoughts on this matter. I will try to use this process with my new game idea that I got from Denise Bonal's play Les Pas perdus (Asemalla in Finnish). I'll report on how it works as I go on.
|
