1KM1KT Free RPG Community

While writing my guide, I've uncovered two really good free RPG design paradigms. However, you can't really do both and this annoys me. I'll demonstrate:

Paradigm 1. Release small, release often
Taken from software engineering (continuous delivery), this idea is that you don't wait until the game is finished. You wait until there is just enough to play and you release for feedback. Then you build the game in small chunks until it is complete. I like this because you are forced to break the creation into smaller chunks. Smaller chunks are easier to deal with, you get more feedback early and having a conversation with others about the game helps spur you on. I'm trying this with Icar at the moment and although I really like the idea it is a difficult mindset to get into.

Paradigm 2. Design backwards
Again taken from software developement (Domain Driven Design), this idea is that when you design something, you write down what you want the affects on the world to be first, then work out the mechanics and finally write down the attributes/skills. Most game designs begin with statistics and work on from there. I think this often gives you a system that doesn't necessarily fit your original game concept. In those cases, you might have well as started with a generic system.

The problem:
If you design backwards and release often then you're unlikely to release a game that can be played. You will end up publishing the end results of the mechanics rather than the mechanics themselves!

I don't see any issues here. I think the issue is that the "design backwards" thing is sort of a foresight thing while the "release small & often" thing is more of a practice.

For instance, one of my goals with Orchestra was to build a game with relatively capped advancement that still allowed very obvious superiority (i.e. better people win a good majority of the time, but can still be beaten), so the mechanics that followed were built around that, then I tried to release as much as possible as soon as possible.

One of the ideas behind Undercover Hero Squad is that it'll be pretty easy to fail at almost anything or succeed at almost anything (I'm drawing from dramedy anime for the source- people with skills should succeed against all odds, but they can still make stupid mistakes). There will be some system to allow characters to pull off epic feats, but it will be limited to something like their top two talents (modifiers applied), and they have to burn power for it.

You could indeed take design backwards to be foresight but I am thinking more as a lengthy process. It's not really designing backwards, that's just thinking about what effects the will make on the game.

For designing backwards, you actually do the design of the game effects first. You write down what the players say and do, what the PCs actions are and run through a few cases before you know what the system is that does it. Doing all that is a lot of work but you must complete it before you release... unless you're releasing your notes.

I guess I start by designing normally with a goal for the game then start thinking of all the things the players could do and then figure out how they do it. Part way through I come up with a mechanic that fits most of them and then go back to designing around the goal. So is that forward, then backward then forward again?

I think the release small and often is opposed to backwards design because it needs something functional to start with that can be built on. Designing backwards requires that there is no defined structure at the beginning, only actions.

Within limits, each module could be designed backwards. It wouldn't be pure, but you could get some of the effect out of it.

this reminds be of a tougue and cheek P2P rpg (HOL) in which the the game was build as a joke. when it got released the fans liked it so much they asked for the one thing not in the book....character creation rule. they had to make a supliment for it.....

The Release Often paradigm seems like it could work well enough with the Design Backwards, although perhaps not always in the obvious way: the game would essentially evolve across platforms. It would start out as a very rules light (or even rules free) game similar to improve acting. With each release, the experience of the game itself would change bit by bit until it more resembles a standard RPG.

While it would be an interesting process, it seems likely to have PR problems. Specifically, if it got fans on the first release, they'd probably be less and less pleased with each subsequent release as the game itself would change away from some of the free form elements that might attract them. In turn, it might then have problems attracting new players, as it would have a reputation of being "that fluffy, LARP-like thing."

Video game designers do this all the time - or at least the companies marketing them.

Ancillary materials like images or stories, or creator interviews about concept can be released as often as you like (ie My blog of stories) to keep people interested, and design the world. Conversely, actual rules can be worked in the opposite direction. Its annoying when stories depict things that can't happen in the rules (like when electronic designers show cut-scenes instead of game-play) but its a forgivable oversight.

One idea that might work with RPGs is to release a module or adventure early on. It gives a sample of the locations and adversaries types, gives people something to play (rules light, with another system, or the prototype game), and makes you think early on about power levels and what is right for starting characters.

As we have said often enough - work from story. You can release the literature in sections or chapters, and emulating the texts is the forward goal of the mechanics.

Ah CA, you've been a little coy there, sir! You've not mentioned how you use that paradigm on your own excellent blog . By releasing stories a little and often, you're building up a fair amount of canon - which leads me to another question that needs its own thread!