Roles And Functions 1604

What is this game?

This particular game is an intention based system created to generate the reality collaboratively with the failsafe systems to protect the most important story threads for every participant.
In human language: people sitting at the table have an idea on what they would like to happen in the story and they implement it playing the game together using the tools at their disposal, depending on the role they have.

Intention based system

Action based system (Typical role-playing game)

In action based system the narrative is surrounded around the idea of “what is happening” and “what is the player character doing”. The narrative is focused on perception, observations, actions - things which actually “happen” in the fiction. The mechanical resolution of the conflict takes place in the world of the game - between the actors interacting in the game (characters, environment…)

For example:

Cleaver the barbarian is trying to stop the goblin army approaching the village. His player has an idea - if Cleaver kills the chieftains, the goblin force will be in disarray and they are unlikely to attack the village. So: he found a place where the goblin chieftains are located and he attacked them. After a long fight he has managed to kill them. The tests - the overall mechanics - were focused around dealing damage and avoiding damage. However, the game master has said that a small force of goblins went towards the village.
Note, that even if the player controlling Cleaver wanted to stop the goblins from getting to the village, the game master was able to override his decision and he decreed that some of goblins has managed to get there anyway. So killing the chieftains was not directly correlated with what Cleaver’s player wanted to achieve.

Intention based system

in intention based system that is surrounded around the idea of “what do you want to happen” and “who would like something else to happen”. The narrative is focused on priorities of storylines, who is in conflict with whom, intentions - who wants what. The mechanical resolution of the conflict takes place on the meta level - between the players sitting around the table. After a conflict is resolved, the actions are retroactively created from the resolution of the conflict. So nobody knows what actually happened until we know which intention “won”.

For example:

Cleaver the barbarian is trying to stop the goblin army approaching the village. His player has the same idea - if Cleaver kills the chieftains, the goblin force will be in disarray and they are unlikely to attack the village. The conflict is between the player and the game master; the player uses Cleaver’s “tactical skills” and the game master uses goblins’ “discipline”. If Cleaver wins, this plan will prohibit the game master to use goblins against the village assuming he succeeds in killing the chieftains (because that was the stake of this conflict). Let’s assume it happened. So now Cleaver needs to kill the chieftains; if he wins, no goblins will go towards the village.
Note: this time the game master is not able to act against Cleaver’s player intentions. Both people know exactly what is going to happen after a conflict and the reality becomes “crystallized” as they play. Both the player and the game master have the power to implement their vision of what should happen in the game into the fiction.


In action based systems there exists a very strong asymmetry of preparation and work - but also power - between the player and a game master. It is very easy to generate meaningless conflicts; it doesn’t matter how many goblins you kill, because the intention was never a stake. Only actions. So the game master is able to implement whatever he wishes while the player cannot really influence the story - conflicts are not called for things which really matter.
On the other hand, action based systems require the game master to be a mind reader. Player tells the game master what she wants to happen and the game master needs to infer why the player wants that to happen. Sometimes the mismatch is hilarious.

Let’s have a Prince who is a womanizer (NPC)
Let’s have Eve, who is a seductress (player character)

Declaration of action from the player of Eve:
“I want to seduce a Prince”.

Action based system:
Game master has no idea why Eve’s player would like to seduce a Prince. But ok, why not.
Let’s make a test then – Eve’s “seduction” versus Prince’s “calm” and a bonus modifier to Eve for the “womanizer” part.
… And let us assume that Eve failed the test. What does it mean? A professional seductress failed to actually seduce a womanizer. We have a cognitive dissonance - this result does not suit what we expect the story to have. It’s like Cleaver the barbarian being beaten in a duel by a child…
In short, this sucks.

Intention based system:
Game master has no idea why Eve’s player would like to seduce a Prince. So he asks “why, what would you like to achieve?”. Eve’s player answers “I would like to get access to the whole palace so we have it easier later”. So the conflict – in reality – is not “will Eve seduce the prince” but “will Eve get full access to the palace”.
Let’s make a test then – Eve’s “seduction” versus Prince’s “calm” and a bonus modifier to Eve for the “womanizer” part.
… And let us assume that Eve failed the test. What does it mean? It might mean that Eve has managed to seduce the prince, but she also attracted some other guys and they will follow her all the time so she can’t walk in the palace completely freely. Or, that the Prince is not really interested in girls. Or, that the Prince would like to meet up with her somewhere in the garden and he will not get her to palace (because his wife waits there – oh wait, we have just generated the fact that he has a wife…).
There is no cognitive dissonance between the fiction and the result of the conflict. Seeing what actually happens on the level of intentions – “which side won” means we can now take this intention and implement it into the story in a way most suitable for the side that won. Everything which was not generated in the conflict is a subject to be changed by a conflict, by retroactive creation of actual actions from the intention.

Generate reality collaboratively

The main purpose of this system is to create and intertwine story threads generated by different people into the same storyline. Those stories are created collaboratively - that is, everyone can and should pitch in - but using conflicts. If there were no conflicts, it would be exactly the same as three people sitting around the campfire and agreeing with each other. If there are conflicts, there exists emergent behavior and not a single person sitting around the table knows what will actually happen and how the session is going to end.
The system is calibrated in such a way that the roles with less influence on general creation of the world are more likely to force their vision upon those parts of the world which interest them. That way the role of “game master” here called “prototypist” will usually create the sketch of the mission, basic conflicts between nonplayer characters and how this story would end without those characters. The role of “player” here called “engineer” will usually react to the sketch an existing situation, influencing the environment and nonplayer characters and rewrite the part of the mission. From all those things an emergent story will be born.
If there exists a person sitting around the table who had no influence upon the story throughout whole session, something has gone terribly wrong. This means that one of the roles did not perform their functions correctly.


Traditional role-playing games

In traditional role-playing games there are usually three main roles. Player, game master, processor.

A player is responsible for creating a character and for playing that character according to the character’s motivations, dreams and personality. In some systems a character is an avatar of a player (player speaks completely ‘in character’ and player should not have any knowledge the character does not have), in others a character is a tool of a player (more like playing a computer game then immersing oneself in the character’s life).

A game master is responsible for creating the story, all the nonplayer characters, the conflicts… Basically, everything. In a way, a game master should entertain the player by giving her some difficulty but not too much. Because too much is put on a game master’s shoulders, game masters often burn out and people don’t want that role.

A processor is responsible for resulting the conflicts; what happens if the possibilities diverge. In some systems a processor is implemented by the mechanics; in others, this role is in the hands of a person (in most cases, game master).

The flow goes like this: game master creates the reality, player performs actions on that reality and in case of a conflict a processor determines who wins.

This game

The flow in the game

The prototypist creates a sketch of the mission; of the story. All the engineers enter the sketch (start playing the mission). Prototypist tries to color the sketch in areas interesting to him (defines what happens). Engineers delete the parts of the sketch which are not colored yet and color the canvas by themselves (explain what they want to achieve). No one can touch colored things (things confirmed by a conflict). Everything which is not colored can be changed by anyone.
In cases two people want to color the same place, the processor determines who has a right to do it.
Note that the final picture is a collaborative result of an prototypist and all engineers.



An prototypist is a subset of a traditional game master’s role. Prototypist’s main function is to create a sketch before the mission, prepared the ecosystem in which the mission takes place, prepare some named NPCs with the motivation and create a “default outcome” - what would happen every player characters would not enter the situation.
Then, of course, a prototypist should run the whole reality animating those parts of it where the player characters are doing stuff. You don’t even have to follow your own script; it’s just something which helps you.
An prototypist should not try to win everything; let engineers create the story. You should make them fight for the outcomes they desire, but most of all try to keep the story consistent with itself. Let others create the narrative. Do not be invested in any story outcome. Just try making sure the story actually makes any sense (harder than it looks).
Also, remember, that you are the one who sets the statistics of the stuff not controlled by the engineerrs. So, for example, if there is that goblin army trying to get to the village and you would like the engineers to resolve it peacefully (not aggressively), give enemy forces massive statistics and introduce a hut of a friendly wizard who could help. Of course, if the engineers sneak into the hut to steal the massive “artifact of doom and decay” to boost them in combat against the goblins, let them. Let them make their own story. You can follow it up later with the wizard trying to hire them to find “those horrible thieves who stole my artifact”. Would be fun to see how they are going to solve that ;-).


- creating the sketch
- creating everything not controlled by engineers
- animating everything not controlled by engineers (including some things created by them)
- setting the statistics and difficulty levels
- being able to create anything at every moment


- do not try to win everything; you are the strongest party
- do try to win some things; it is your story too (also, they will have to creatively try to get back on track)
- prepare the sketch before the mission. Make sure there exists a way for the engineers to be invested in that story.
- animate whole world
- what is crucial: you do not have to know everything. Things will be retroactively applied anyway.
- Be generous; you don’t remember everything, so don’t force others to. If one of engineers is playing Indiana Jones don’t ask “did you remember to bring the rope?”. Of course Indiana Jones would bring the rope. Also, if a character loves caves, it is unlikely for the character not to have a source of light. Let other people create stuff as they want to if there exists a plausible explanation how could this happen; remember this also fleshes those other characters and makes them competent.


There should be one prototypist in a mission. It is possible to have more than one, though it is unusual.



In traditional terms, engineer is a player with some powers of a game master and some tools letting the engineer shield the most important story threads.
Engineer's main function is to be active and have intentions. Those do not have to be sensible intentions; but if a engineer is sitting declaring things “yeah, I’m burning this house for no reason at all; I just want to see what happens” then that engineer is not doing her job properly.
Engineer’s main role is to try to weave her own narrative and her own story thread - her vision on what should happen in this mission - into the sketch created by an prototypist. Engineers can be cooperative or they can have a competing visions of what should happen; that’s okay, that’s what conflicts are for.
An engineer should create a character, flesh it, add some background and story and play it like that character should act. But in the same time a engineer has her own intention - she doesn’t have to declare the conflicts like the character would. For example, an engineer can say “I would like that Prince to fall in love with my Eve because this would be a problem for our enemies” even if her character, Eve, loves living in the shadows and hates being looked at and courted by royalty. So a engineer is a force changing the sketch (the whole picture, actually) and a character is one of the tools to do it - but not the only one.
An engineer is able to retroactively create facts from the past the character. For example, she can declare “I was studying stuff with a close friend who lives in the city”. And thus she can create a friendly nonplayer character who will be for prototypist to animate later.
An engineer can generate everything plausible. For example, if Eve (the character) is on the yacht and someone is drowning the engineer should not ask “is there a life buoy?” It’s a yacht; of course there should be one. Just say “I’m grabbing the life buoy and throwing it to save the drowning person”. In case the prototypist does not like something he will call a conflict. Be bold, not timid.
Engineers know everything they know. Their characters know only what the characters know. engineers can talk with each other sitting at the table even if the characters are in separate places. It is not a problem because if a character acts on the knowledge she doesn’t have (by accident or on purpose) an prototypist can call a conflict.


- create a character, her backstory, parts of the world connected to that character and her statistics
- animate a character
- generate anything what is plausible in those circumstances - objects, people, weather, legends…
- Fate points and negative status to protect important story threads. You should win most conflicts on every role-playing session against the prototypist. Some lost conflicts you can deflect so you will not lose those threads and entities you are the most invested in.


- Fall in love with your version of the story. Try to make it happen. Fight for it against other engineers and against an prototypist.
- Be flexible; you will not win everything. Focus on what you want to happen and preserve those threads the most.
- Play to the strengths of your character. Make sure your character has exploitable weaknesses too.
- Make an interesting character. Help the prototypist weave your character into this sketch.
- You are one of engineers, not a single one. Don’t be the single hero.
- Generate things as you wish. Go for interesting stuff. Be bold - if someone doesn’t want you to do something, that’s what conflict is for.
- Be proactive. Have intentions. Know what you want to achieve.
- Try to interpret successes and failures in interesting ways; things which make story more exciting.
- Do not actively undermine the consistency of the story. A submarine in the desert? Just… don’t.
- Remember that the prototypist is also your collaborator. He is your opponent, not your enemy.


There should be between one and five engineers. From my personal experience, two or three engineers is the best number. One means that the story may not be complex enough; more than three may cause the prototypist to get lost and some engineers to be bored.



if there is a conflict, something needs to resolve it. Enter the processor. A predictable (probabilistically predictable) entity dedicated solely to resolving conflicts – that is, answering a question “did vision X prevail or vision Y prevail”. What actually happened.


- “Yes” or “No”.


- Must be final and binary; we went X direction or we went Y direction. Caroline won or Eve won.
- Must be auditable; it must be possible to predict the probability of success or failure before the processor makes a decision. It must be possible to prove the decision could have happened as it did.


In this system, processor must be implemented by transparent mechanics. The decision of the processor is final – no person can override the result of mechanics. Every person can call a conflict. Only things confirmed by a processor are “colored” - impossible to change by anyone.

O ile nie zaznaczono inaczej, treść tej strony objęta jest licencją Creative Commons Attribution-ShareAlike 3.0 License