Process of play

4 June, 2008 at 12:42 pm (rpg theory) (rpg analysis)

What matters

In my opinion (and this is definitely an opinion) what actually makes different gaming styles different is what the participants do. The core activities. This also means that I consider running a game and playing in one to usually be different games entirely; being good at one does not imply competence in the other.

I am specifically discussing about games in play; what the books say may or may not be tightly linked to this, assuming such books even exist. Some books are designed with very specific style of play in mind, while others are designed to be flexible (saying that one of these is inherently better than the other means that one is simplifying the issue).

Process of play

The way I think about this is to think about the play itself as a process. It is useful to also consider some activities that live on the fringe of the play, like campaign preparation, session preparation, character generation and note-taking, especially if the notes are shared.

It is also useful to treat certain subprocesses as distinct processes. This allows arbitrary accuracy by zooming on the interesting subprocesses, such as resolution and character generation and preparation, and ignore whatever is considered boring or obvious.

Example process: persistent fantasy

I’ll embrace the idea of subprocesses here. On the most abstract level that still carries some information, the process is

1. Design the game
2. Discover, create and compile a suitable random generator
3. Blog about steps 1 and 2.
4. Play a session.
5. Record the session, the characters, the setting and the list.
6. Go back to 4.

That is quite high-level. I think the fourth step could use a bit more analysis, so I’ll create another process chart for it.

1. Get a number of players to actually play the game.
2. Explain rules to any who are not familiar and want to know them before play.
3. Invoke the random generator (or reveal whatever has been generated in advance).
4. Note the characters that enter play because they are on the top of the list.
5. Generate remaining characters.
6. Build the starting situation.
7. Add characters to the situation.
8. Play.
9. Update characters that have changed.
10. Consider any feedback that is offered.

Here it would be possible to elaborate on a number of steps, but 8 probably is most in need of it.

1. Participants weave their characters and other fictional entities together.
2. Play produces complications.
3. Players use the fiction and the rules to mostly advocate the success of their characters.
4. Play produces complications.
5. Game master guides play so that the complications are resolved (if they are interesting) or ignored (if they are boring).
6. Complications are closed or are not immediate enough to demand being adjudicated in actual play.
7. End play.

The interesting part is that there are several different lenses that all provide different and often useful insight. Here’s another one, again on the subject of play.

1. Game master describes a scene. (Sometimes player, often everyone throws ideas around and GM integrates them).
2. The same is done to other characters that are not in any other scene, in arbitrary order.
3. Game master or player makes some situation dynamic; that is, some entity takes action.
4. Other participants react if something controlled by them is in the scene.
5. 3 and 4 continue until the scene ends, the GM takes the spotlight to another scene or there is a suitably strong conflict and dice get involved.
6. The ending scene happens.
7. End play.

Elaboration

Actually these processes do not work well in one dimension (line). A flowchart would be sufficient to cover most processes, though great detail might demand using the third dimension (more are never needed).

My gut reaction is that it is impossible to create a unique presentation for a game as a flowchart. The reason is that there are severa, congruent processes that feed on each other; for example, the scene-by-scene consideration and the complication-by-complication approach. Neither can be reduced to the other and even further breaking them down would not lead to same elements; a complication might happen and be resolved inside a scene, or might encompass several. Further, different players have different roles and adding all of these to a single chart could face similar problems. (I am unwilling to even try constructing anything resembling a formal proof, so all this handwaving must suffice. Please do disprove these musings if you can.)

Different ways of slicing play

These are all examples. The probability that I am missing something big and important is very close to 1.

The way fiction is created is one fruitful focus. It is closely tied to observing who adds to the fiction and how, which is where Forge theory is useful. Some generally useful steps include who frames scenes and how much do they define, can players assume details not mentioned by the GM and is character and setting background generated in play or before it (or after it). Other patterns are how detailed information is conveyed; long boxed text-like descriptions, or upon request, or not at all; and are very important elements lavished with detail.

The way spotlight moves around presents another interesting object. Who gets to actively play, how are different players handled, how does seating and such affect it all, and so forth.

I am most interested in the way the story is formed. Namely, what I called complications, but what could also be called story (or plot) threads or elements or seeds. For example, when a villain escapes, a new story thread is opened, as it is assumed that the villain does not simply disappear. The way these story threads are generated, intertwined and resolved is of great interest to me.

The way mechanical resources move around in play is worth some attention. Some games have very formalised ways of moving resources around, others far less so. On the formal side there are such games as Rune, D&D 3rd (and 4th even more so), Capes and Universalis. They benefit most from analysis on the resource level. Work on this subject has already been done by John Kirk in Design patterns of successful rpgs.

Formalisation?

All flowcharts can be analysed as graphs. Petri nets seem particularly interesting, but I’d have to read a lot more on those.