someone pointed me to this article on rapid game prototyping. it's specifically about computer games, not roleplaying games, but I was struck by some of the similarities to the Iron Game Chef/24 Hour Ronnies approach: four comp sci students designed 50 games and only took a week on each game. here are the rules they followed for each design:

• Each game must be made in less than seven days,
• Each game must be made by exactly one person,
• Each game must be based around a common theme i.e. "gravity", "vegetation", "swarms", etc.

several of their conclusions are things we've found out here as well: constraining time and creativity during the design stage improves the design, for example. a couple of their points hold the potential for elaboration or adaptation to rpg design methods.

for design advice, they suggest "pre-prototype your prototype". this resembles the oft-repeated advice here to write out or imagine how the players will play the game before designing any mechanics. the canonical example of this on the Forge is this sticky note from Roy, but Ron has reiterated that point. I've even repeated it to people, but like a fool, I often skip this important step and my designs have suffered for it. you need to get your basic concept first, of course, but this should be the step you do before you do anything else: IMAGINE HOW THE GAME IS PLAYED, instead of what happens in the SiS and how to make that happen.

another bit about design that seems useful is "gather concept art and music first to create an emotional target". from the description, some of this is for pure inspiration rather than what will necessarily wind up in the game. this can be adapted to rpg design: when you are coming up with your one-sentence high concept pitch for your game and imagining players playing it, watch movies, listen to music, and search for art that matches the mood, tone, and fictional Color you want. if you find clip art you can use, squirrel it away for your PDF. if a particular movie scene strikes you as being exactly what you'd like in your game, jot it down in your notes; you can "file the serial numbers off" later; for now, just imagine the players describing these scenes during play.

the development advice seems especially ripe with ideas for RPG design. first, there's "build the toy first". a "toy" is the gimmick of the game, whatever you selected as your limiting concept. if you latch onto the concept of PCs literally evolving or mutating during play, you need to work out the rules for that first, then link it to character generation and rewards cycle, then flesh out the rest of the game. if you choose "wacky robot servants cause accidental mayhem", you need to work on your accidental mayhem rules first, tie that into resolution, then add in chargen and reward cycle and finish the system.

a couple of the other bits of advice are harsh but true. "cut your losses": sometimes a game isn't going anywhere, so just trash it. "if you can get away with it, fake it": don't worry about exact modifiers or detailed shopping lists for now, just provide the general guidelines and develop the rest during playtest. "you can't polish a turd"/"but overall aesthetic matters" kind 0f fits with that, too. and "nobody cares about your great engineering"... this feeds into their gameplay advice: "complesity is not necessary for fun" and "experimental does not mean complex". I think it was Jared Sorenson who stated that you shouldn't have more than two or three unusual/exotic elements in an RPG; everything else should be pretty standard. you need to build on the familiar and focus on playability, not on intricacy.

the other bits of gameplay advice are pretty damn good, too. "create a sense of ownership". some would say this has never been a problem in RPGs, what with people getting so attached to their characters; but, with a lot of the newer designs cutting back on character options or available stats, it's a bit of advice that's getting missed. I've screwed up a couple games this way: Last Breath and Darling Grove both need more of a sense of character uniqueness to build player attachment. if you want to de-emphasize individual characters (playing troupe style, for example,) then something else needs to take its place; the players need to build and own something.

"build towards a well-defined goal". there's a very quotable passage in the article for this bit of advice:

Without a gameplay goal, a prototype is just a toy – not a game. For some reason, people seem to enjoy having the opportunity to fail. A goal can be anything – like “collect x number widgets in a x amount of time,” or “keep the system stable,” or “traverse a space without touching anything bad,” but it was difficult finding a goal that didn't feel a little tacked on, (like anything involving a “time limit”).

Hey John,

Good stuff. One point:

a couple of the Ronnies had time limits or easily-fulfilled end conditions. Ron's commentary was something like "wait a minute, you mean we suddenly have to stop playing?" if you're going to have an "end game", it's better if the end game can lead to further play, such as when a minion becomes a new master in My Life With Master or when the Fell Weapons destroy (and remake) the world in Charnel Gods.

I'm not sure that's an accurate paraphrase of Ron's concern. The issue isn't that a game ends, but that the trigger for ending the game is independent of intentionality on the part of the players. My Life with Master ends. There's no further play with the same characters after the Master is dead. And so does Violence Future. The player characters die. The key is that the ending is a direct output of player choices.

Paul

thanks, Paul; I was perhaps a bit too extreme in my description of the problem, although in my defence, I was thinking of how one of the end conditions of MLWM is that one of the minions may become the new master. you didn't write it into the rules, but in my mind, that opens the possibility of playing another series of sessions with the new master.

but still, you're right; the main issue is that in MLWM and Charnel Gods, the players play towards a satisfying conclusion, while a mistake some people make when designing an RPG with an endgame is that the game ends suddenly, against the will of the players.

Hi John,

Fantastic reference, great reading and analysis on your part.

Best,
Ron

The sudden endgame is rather similar to the rapid prototyping idea itself - it prompts the player to choose the best of his ideas and present it as soon as possible, or miss out on presenting it at all. Possibly if your feeling 'What, weve stopped playing now?' you just didn't embrace that concept enough.

talysman wrote:
IMAGINE HOW THE GAME IS PLAYED

Heya John,

What do you think about rapid prototyping and repeating design assumptions? Does a rapid design approach let design assumptions (like having to have a combat system), slip in without notice?

Hmm, back in the day, when I studied programming, they hammered into us the virtues of structured design over prototyping.  And the main reason is one not unfamiliar to RPG designers - you find yourself tampering and tampering trying to fix your prototoype when you would be better off redesigning from scratch.  Prototypes are tar-babies.

But I think thats rather different from the 24-hour game concepts.  They should be seen as an exercise in proof-of-concept I think, and thats a reasonable goal.

Not to veer this thread too far, but structured programming tends to work well when you know your specification /requirements in advance and can then go through and address each in a rigorous and methodical manner.

Computer games development is not at all like that in general. The requirements are hard to specify things like 'is fun', 'feels good', 'involving' and so on. It's hard to say that (for example) a jump needs to cover 1.5m and last 0.7 seconds to "feel good" without fiddling about to get those numbers in the first place. Games development used to do (and still does, in some cases) this by altering the final production game, which can entail a lot of rework (if a jump of 1.5m feels better than 2m that could mean animations need to be altered, levels need to be reworked and so forth.)

Hence this new 'prototype early' idea. You throw things together as thought experiments and rough gameplay tests (as described in the article) in a pre-production phase. Then, once you feel that the design is 'fun enough' you can then write a more formal spec from that and take that into full production using structured methods or whatever else. Obviously, as you point out, a risk with this is mistaking the prototype for the game and taking a prototype too far, which has it's own problems.

Moving this back to RPGs, it seems to me that a comparable approach would be to take the "think of how it's going to be played" concept and then build the core of the resolution mechanic (for example) as a prototype to ensure that the 'chassis' of the System does what is required of it. Only once that is fun do you start writing in earnest. I think this is the way most people here are working but I think it's worth thinking about.

As an aside, I think the Ronnies are a good example of getting rough prototypes made quickly, although I'd say that they may be too developed to really be considered a prototype anymore.