Functions Revisited

Cross-posted here.

Functions

Everything the GM sais has a goal, a purpose. Let's call that purpose FUNCTION. For example if the GM tells the players to do a skill check, that's a function. If you want the players to get intrigued by an NPC, that's a function, too.

A game session consists of such functions. When you are GMing, you GM to achieve these functions and if you achieved the purpose of the functions in a session, it is a successful session. You achieve catharsis by the good chosen pattern of successful functions. For example if you want to make the players laugh or cry, that's not a function, because it's very hard to tell one single function wich would achieve that. But a combination of functions could help. So, don't forget: a function alone won't have a big impact on the players - always think about the function as the direct purposes and goals of a story element. For example rolling the dice or uncovering an information.

Of course these functions aren't static. Sometimes (or many times) you have to alter functions on the fly, that's fine. But always be aware how that will affect the game session (the pattern of functions) and how that will affect what you are telling the players.

Types of Functions

At this time we can differenciate two classes of functions: MECHANICAL and DRAMATICAL FUNCTIONS.

MECHANICAL FUNCTIONS are things that are prescribed by the rules set of the RPG you are playing. For example if you put a monster to fight in front of the players, that's a mechanical function. If you ask at a point of the session a player to roll for skill check, that's a mechanical function. Etc.

DRAMATICAL FUNCTIONS are anything else. These are mostly things that happen in-game, but these can be things like HOW you discribe a person or a place. Dramatical functions can be deeds done by NPCs or the change of the weather or that a monster steps in front of the players and attacks them.

You should see by now, how small scale a function is. By telling the players that a monster attacks them you use a dramatical functions. But switching to round based combat and using the combat break-down described by the rules for fighting, that's a mechanical function. The two types can intertwine very much.

But if they can't be distinguished easily, why is it important to make a difference between them? The answer is simple: they are hard to differenciate by the players, but a GM has defined goals using the functions. A fight can be desperate or heroic or anything else, that depends very much on the dramatic functions used while having a fight. This could mean, that the decision of the power level of an enemy is the bottom line of a mechanical and a dramatic function: The GM wants to achieve a bitter fight against a main antagonist. This is a dramatical function. Wich means you have to size the values of the enemy to look stronger than the PCs, but not too strong - so to find the exact values for the enemy is a mechanical function.

The Rooting of a Function

There is another way to classify functions. In theory you can distinguish between a function and its realization. For example a function can be that a player should roll a defined skill check. The realization of this function covers all these things and possibly many more things: how you ask the player to do this, how does the player interpret this, what the result of the check is, how you interpret the result directly. (There are seperate functions wich work as the possible consequences of the check roll, but HOW you decide among these consequences is still part of the skill check.) We can use the realization of a function to classify them.

A function wich is rooted on the players' side or short a PLAYER-SIDE ROOTED FUNCTION has one defined realization for the players and many possibilities for the GM. For example: if you want to raise suspicion for the players, you have to watch for the players' reactions. You can decide among many tools at hand when the time comes and you mustn't stick to what was written beforehand. You have to push the issue until the players get suspicious, but you mustn't go any further. Else the function didn't succeed. When a function didn't succeed for the first time, it's not uncommon to adlib new functions wich compensate the difference. These functions can be seen as siblings of the unsuccessful one.

This means: a PLAYER-SIDE ROOTED FUNCTION has a definition based on the realization for the players, but can have many realizations for the GM.

A function wich is rooted on the GM's side or short a GM-SIDE ROOTED FUNCTION has one defined realization for the GM and can have many interpretations for the players. For example this is true for a skill check or many other mechanical functions. The GM knows why these functions are asked for, the player can only guess, unless they are described and interpreted by dramatic functions.

But don't forget: it is totally possible to have player-side rooted functions wich are mechanical and GM-side rooted functions wich are dramatical. For example if the players have to find a switch and throw it to open a door, it is a dramatical function wich is rooted on the GM's side. Or when a player casts a spell without explaining the GM why it is done, that's a players-side rooted mechanical function.

The players can have functions, too?

While you, as a GM when writing an adveture make up functions, there is a possibility to adlib functions on the fly. The GM does this to succeed in a function wich failed before. But players do this all the time. For them play consists mostly of adlibbed functions.

We can classify functions based upon whether the GM makes them up or a player. We are talking here about the ORIGINATOR of a function. So, there are PLAYER ORIGINATED and GM ORIGINATED FUNCTIONS.

And subconsciously we already classified functions as ADLIBBED FUNCTIONS wich are made up on the fly while playing the session and PREPARED FUNCTIONS wich are decided early on in a calm context. For example a GM originated prepared function is the adventure written beforehand, a player originated prepared function is the PC.

Objects Carrying Functions

It is easiest to write a session where the functions follow each other in order. It becomes more interesting if you give it some structure. The solution is: you don't write one list of functions, you write more lists of functions. Each of these lists are carried by an object in the game session.

But what is an object? The answer is a bit circular: an object can be anything wich carries just enough functions to work as a simple list. If the party is going around in a city and has to visit places and buildings, then every place can be one object. If the players are making politics and meeting and talking to important NPCs, then each NPC can be an object. If you know what are the important panels of the session, you know what are the objects.

If we define what objects do we usually use, we can make up typical functions wich are carried by them. For example an object type is the NPC. Note, that the object NPC is not the same as the imagined person or character in the world. The object 'NPC' is a bunch of functions wich can be or will be activated in the game session. You can think about the object as the person depicted in an episode of a series. Of course those viewers who saw many episodes until now got to know the character very good, each and every episode showed another facet of this character.

So, let's take the object type NPC. It's reasonably to have function types like these:
- INFORMATION: The NPC reveals an information. It is important that you can set the conditions and circumstances of this and whether you set. For example: 'IF the PCs agree to take the mission, the wizard tells them that it will be very dangerous.' Of course when you are writing an adventure, this can be shortened, like an item in the list titled 'WIZARD': 'IF PCs agree to take mission: 'It will be very dangerous.''
- ASKING: The NPC asks the PC to do something. ('Please kill him for me.', etc.)
- QUESTION: The NPC wants to have some reaction from the PC. Not necessary a question, but any behavior that would prompt the character to a reaction. (For example: 'She grabs for the hilt of her sword with flaming eyes. What do you do?')

These are just some examples.

Mechanism of Objects

Objects can work differently. You have a list of functions, but how and when dou you activate these functions. This depends upon the nature of the object. If it is a place, the functions are activated in order, but only when the PCs are present or push to the inner of the building.

A complication could be an object, too, for example when travelling on difficult terrain, you tell what difficulties the characters have. This means that the functions of the object "TRAVEL" are activated in order using some interval.

An NPC can work more complicated. Functions can be activated in order as the NPC pushes them towards the PCs or they can be activated as the PCs get to know more and more about the NPC wich reminds us rather the building example. It is up to you, how you think the session should work.

Of course the fun doesn't stop here: you can have objects wich appear only in the adventure when some obscure functions are activated, because in the end operations with objects are just functions, too.

Can the Obejcts Interact With Each Other?

They can, but they shouldn't. If you wan't to have a total realistic setting where NPCs have ambitions and they fight for the power in a political world against each other, that's fine. You can have the NPCs throw functions at each other. But it does undermine the purpose of using the functions.

Why? Because functions meant to simplify the world and turn it into a usable portion of setting where a session can happen. You can decide what will happen in a session by thinking about relationship maps of NPCs, but functions are not for this. Functions are there to minimize the paperwork: you write up only those things wich affect the players. (Yes, the players, not the characters.) Like this you envelope the players in a setting and they won't see that behind the scenes there are not as much flesh as around their characters.

Structure and Pattern

Now we can talk business. A function in itself is nothing. Why should the female NPC be sexy? Why should be a warrior cool? Why should be a wizard old? These are all dramatic functions and if this question arises, you have to answer them. And there is no better answer than another function that justifies it.

If the players and/or PCs are all male, it has a purpose to throw in a sexy female NPC - to entertain the players or to influence the PCs or both. There is a player originated prepared dramatic function: my character is male (or I AM male, that's a function, too!) wich leads you, the GM to incorporate a sexy female NPC, wich is another function. If you are playing in a high fantasy setting, that's a dramatic function. Wich explains that the wizard should be old.

There are other times when functions interact with each other. When the PCs stop by an inn and have a good time before going off to kill demons knee deep in blood. That's a conflict between two functions.

When functions interact with each other in a coherent, synergyc way, that's called a structure. And if a structure repeats, that's called a pattern.

The interesting things come when structure and patterns not only arise by the GM preparing the the functions beforehand, but when the they arise from the reaction of the players. If there is a goal of RPing, that should be it.

I think I can't think of more, but I am open for any questions regarding the details of this model.

Peculiar Functions

This is only the beginning. If you use plain and simple functions, that can be too straightforward. You could require HIDDEN FUNCTIONS wich are not visible for the players until it's too late. You can use this for two totally different types of adventures. It's just evident that when having a detective game you should have hidden functions. Leads you tell the players, but they won't notice even if they know about it. (For example that one of the NPCs is always smoking - just like the murderer. You just tell them, every time they meet the NPC, that (s)he is smoking.)

Or it is a must when you as the GM want to have the players a catartical discovery. The trick is that when telling them the information, they mustn't uncover the truth, but when uncovered they have to see the leads as they look back.

I'm open for questions.