Creating Projects

So, how do we stitch creative actions together into a story? Here, I think I do want to model things on the classic RPG pattern. It’s classic for a reason, after all. The pattern is to have a number of encounters, which go together to form an adventure. Adventures are then strung together into campaigns. Now, in a classic RPG, one encounter is a fight. In this RPG, however, one encounter is either coming up with an idea, or realising the idea in concrete form. Thus, we can’t use the classic RPG adventure structure, of fighting your way through the underlings until you hit the big boss.

Instead, I’m going to suggest that the equivalent of an adventure is a single creative project. Of course, you could do a project in two encounters: one to come up with the idea, and one to realise it. However, that wouldn’t be interesting enough, or long enough. The number of encounters necessary will depend on how long an encounter takes, but between four and twelve strikes me as a reasonable range. So, how do we get that many?

This is where I want to use something that Jeff mentioned in a comment on an earlier post: problem decomposition. Each project should be split into a number of sub-projects. These might be obvious “parts”: for example, the beginning, middle, and end of a novel. They could, however, also be things that can’t be separated out so easily. Thus, a novel might be separated into its protagonist, antagonist, setting, and plot. In order to create the novel, you have to create all the bits. The overall goal of the adventure should be a product with a quality over a certain standard, which will then achieve a goal set at the beginning of the adventure. The description of the adventure is, obviously, an important part of making the players care about achieving this, just as it is in any other RPG.

Another lesson that we should learn from classic RPG adventures is that railroading is bad design. This is the application to adventure design of one of our fundamental rules: the players and characters should make decisions that have an impact on the course of the game. Thus, the players and characters should be able to choose how to approach the central problem of the adventure, and it shouldn’t just be a choice between doing it the way the designer wanted, and failing.

Problem decomposition gives us a way to address this. First, once a problem has been split into sub-problems, those sub-problems can be tackled in various orders. There will, most likely, be some orders you can’t choose; if one of the sub-problems is “integrate all your creations”, for example, that really has to come last. However, complete freedom is not a necessary feature of an adventure, and not, in fact, a positive one; the paradox of choice, where having too many options paralyses people, comes into play. As long as there are multiple sensible options, even just two or three, the players are in control.

The order in which sub-problems are tackled needs to have an impact on the final result, probably by having the results of one sub-creation affect future encounters. The most obvious way to do this is to have it make the future creations either easier or harder. In addition, it’s probably best if each choice of sub-project makes some later projects easier and others harder, so that there isn’t an obvious best choice. If one choice is obviously better than the others, it’s arguable that there’s no real choice at all.

One potential problem to look out for here is the risk of cycles of improvement, where you do something that makes another step easier, then do that step, then use the benefit from that step to improve the first step, repeating until both are infinitely good. The rules must be set up to block this, but you also need an in-game justification. Fortunately, that is fairly easy to provide. Going back to redo the first sub-problem would normally require redoing the whole project, since you would lose things that you had depended on in the later creations. Rules to block these sorts of cycle should, therefore, not break suspension of disbelief.

There is a second way that problem decomposition can help us to avoid railroading. It might be possible to split an overall project into sub-projects in different ways. This needs to have an effect on the final project, in order to be meaningful, but as long as the final quality of the project is complex, this is easy to manage. Different decompositions can make different aspects of the final project easy or difficult to improve.

How much decomposition are we talking about? Let’s say that a project needs an idea for the whole project, and then integrating to produce a concrete result at the end. That’s two encounters. To have four to twelve encounters for the whole adventure, we’re looking at one to five sub-sections. One doesn’t make any sense, but we could have a very simple case where the idea for the whole project is trivial, as is integration, and the project itself splits into two parts, each of which requires two encounters. Otherwise, three to five subsections sounds reasonable. If you have three, A, B, and C, doing A first could make B harder and C easier, doing B first could make A easier and C harder, while doing C first could make A harder and B easier. There’s no obviously superior choice here, so that works for avoiding railroading.

If multiple decompositions are possible, we could also have decompositions with different numbers of elements. This might affect the time necessary to complete the project, which would be important if there was a time limit on the whole scenario. In this case, the method that takes more time could be easier overall. It might work better, if you can just get it all finished by the deadline.

It should be obvious from this discussion that writing adventures for this game is going to be fairly hard work, but that’s no different from writing them for any other game. One thing that is a little surprising is that there is still no sign that a gamemaster is going to be necessary. There is no information that needs to be hidden from the players to make the adventure interesting. Indeed, the characters should also know most of the game information in advance. In a campaign, there might be unintended consequences of certain decisions, and it might be better for the players not to know about those when making the decisions in question, but even that can be got around. The characters might not know, and it might be impossible to solve one problem without creating the new one. In that case, the players will have no choice but to go ahead, and they can role-play being surprised.

Finally, I said that there was a reason why the classic model was classic. What is that reason, and does it still apply to this adventure model? The reason is that the classic model breaks an adventure down into units. When designing an adventure, you can treat each encounter as a black box, with inputs and outputs, and connect those boxes together. Then you can design each encounter without having to worry about the details of the other encounters. Of course, you can add details that link the various encounters if you want, but that’s optional, and you only need to worry about it to the extent you want to. In short, the classic model keeps the complexity of adventure design under control, while allowing the experience to feel complex. That is preserved in this adventure model. The individual creations can be treated as black boxes, as only their qualities are relevant to the way that the later sections, and the whole adventure, turn out.

I need to actually write an adventure to work this model out in detail, but before I do that I want to look at character creation. I’ll do that in the next post.