Thinker
2019-05-22, 09:56 AM
I have been thinking a lot about what makes for a good RPG from a design perspective. This led me to developing a layer-model for roleplaying games that attempts to address the primary ways that they work from a design perspective. Before moving on to the meat of my post, I want to point out that a model is just that - a model and will not include every scenario that someone can come up with. It is also descriptive about what can be observed in RPGs and not prescriptive about what must be included in RPGs. And, while someone could use it as a how-to guide for development milestones, it is not intended to serve as such.
Why is this useful?
There are many reasons to want to model RPG design and to apply the model to RPGs.
Understanding the game – By reading a game’s rules with an eye toward the layers in the model, it becomes easier to comprehend what the game is attempting to accomplish and how the rules promote those goals. This can also lead to identifying where the game falls short of its goals.
Making judgements while playing the game – By filtering a rule, action, or scenario into the appropriate layer, it becomes easier to make a judgement about that event. Naturally, the game should follow the game’s concept. If it does that, make sure that it matches with expected game actions. Once that is taken care of, check if there are any subsystems that it might interact with or with any insights that the GM or the Players already have in-game.
Troubleshooting a system – Some games don’t work properly to accomplish what they promise. Sometimes, most of a game works well, but there is a component that fails to meet expectations or is difficult to work with. By understanding the game’s layers, it becomes possible to fix those flaws and understand the impact that the solution will have throughout the rest of the game.
Customization – As a gaming group understands the game better, they may want to customize the rules to fit their group better. This becomes easier when the effect of those changes can be seen and visualized across layers.
Building on to a framework – Some other game developers or playing groups may decide that they like a game, but they want to expand on some of its details. This might be by adding new subsystems, adding new actions, or expanding on those subsystems and actions. This becomes easier to accomplish when the designers can see where their changes fit into the game.
Setting tailoring – A system that is applied to a different setting than was originally intended must undergo some tailoring to fit that setting. Generic systems are typically easier to tailor than others.
Creating a game system – While models are not intended to be prescriptive and do not expect to fit all games, they can be useful as a measuring stick for developing a roleplaying game from scratch. Understanding how an in-development game matches up with a model can help to identify weaknesses and how to resolve them.
Alright, get on with it
The CASIP Model is used to understand the layers of a roleplaying game as a method to understand how the game works. Here, layers refer to a progression of ideas that one could follow from the most basic concepts of the game to how it works in-play. The layers are:
Concept – What the game is about
Action – How to resolve actions in the game
Subsystems – The process to resolve actions related to an overarching theme such as tactical combat, thievery, downtime, etc.
Insight – The collective information about the game as the gaming group understands it
Play – How everything works together in actual-play with GMs and Players responding to Knowledge
That's it?
For a more in-depth look at CASIP, please see the table in the spoilers below.
Layer
Description
Concept
The Concept is why the game was made, who it was made for, and what it is attempting to emulate (if anything). At this layer, we can observe a game’s genre and tone – is this game about spy thrillers, heroic adventurers, dystopic struggles, or is it generic? It can also be used to understand how much the gameplay is influenced by storytelling elements and how much it attempts to simulate specific actions.
This is also where game components are decided upon – how rules-heavy the game is intended to be, the roles of the participants (GMs, players, referees, etc.), or whether the game is intended to be cooperative or competitive or both at different times. Some games even eschew the role of GM or referee altogether.
The Concept Layer lays out setting information that will be relevant to gameplay. If the game is applied to other settings, every layer of the game may be impacted. It includes what roles the player’s characters will take on during play.
Every other layer typically ties back to the concept in some way. Components of the game that do not tie in to the concept can feel out of place.
Action
The Action layer determines what the participants do to resolve success for a task. This layer also describes what normal thresholds for success are and may define more granular successes like full successes, partial successes, partial failures, total failures, advantage, etc.
At the Action Layer, the game also determines what Statistics (ability modifiers, BAB, etc.) are required for each character, meta-currencies (like Action Points or XP), and basic character options are available to all characters (like Skills).
Some games may allow for different Action options between Players, the GM, and/or NPCs. In some cases, the GM is given unlimited options while in others, there is a specific menu that must be selected from.
Action should support what the game is about, or at least not contradict it.
Subsystems
Subsystems flow from the game’s Concept in that they reinforce what the game is about. They describe how a character in the game is supposed to achieve aspects of the fiction presented in the Concept. Subsystems typically add rules to the Action to make it fit the subsystem’s goals and might add stats, meta-currencies, or options as well. Subsystems may also alter the Action mechanics to better-fit the rest of the mechanics of the subsystem. In many games, only a few subsystems are well-defined based on the game’s Concept, while others attempt to present a wide-range of fleshed-out Subsystems. Some subsystems interact with others, but this is not a requirement. Examples:
Downtime – describes how characters can make use of non-adventure time or what happens between adventures. Includes things like recovery (physical and mental), fencing stolen goods, recruiting followers, paying homage to a god, etc.
Factions – describes what actions factions take and how they progress their goals, and how they interact with the player characters.
Supplication – describes how a character could gain power or effects from deals with more powerful beings
Thievery – describes how characters might attempt to lie, cheat, con, steal, extort, burgle, or use other underhanded methods to achieve their objectives
Subsystems also include all statistics and character options that are required to interact with them. For example, a Spellcasting Subsystem may add dozens of Spells for a player to choose from.
One of the pitfalls common to Subsystems is that one Subsystem may take on all aspects of another to the point where the other Subsystem is obsolete or requires more resources to engage in. Another common failing is inconsistency between subsystems, where one subsystem allows one outcome, but another subsystem provides a better one while dealing with similar topics. The more subsystems a game adds, the more complex it becomes, and leaves itself open to unintended consequences or abuse.
Insight
The Insight Layer deals with all details, facts, lies, and rumors that are involved in the game. Within this layer are two main types of information: Public Insight and Private Insight.
Public Insight is concerned with everything that is free for anyone to find out about the world or the characters. Private Insight is made up of the things that not everyone knows – GM notes, the layout of a dungeon, a character’s secret past, etc. Some Private Knowledge may be shared between only some of the players or the GM and a player. Often, things that are Private Insight will become Public Insight at some point.
Some games also attempt to divide Player Insight from Character Insight, penalizing players for taking actions that their characters wouldn’t normally know about.
The game develops situations as a result of the Insights changing. Situations can escalate as tensions rise or deescalate as they fall.
Insight is updated to reflect the outcome of the various Subsystems. Normally, this is the result of the GM and players interpreting the outcome to develop a new situation. Knowledge is then used to feed into the Actions that the game participants can take.
Play
Play describes what actually happens while engaging the game. The players make their actions based on the actions and descriptions of the GM. Mechanics as described in the rules often diverge from what players do in the moment.
So, what do you folks think? Is this useful to you? Agree? Disagree?
Why is this useful?
There are many reasons to want to model RPG design and to apply the model to RPGs.
Understanding the game – By reading a game’s rules with an eye toward the layers in the model, it becomes easier to comprehend what the game is attempting to accomplish and how the rules promote those goals. This can also lead to identifying where the game falls short of its goals.
Making judgements while playing the game – By filtering a rule, action, or scenario into the appropriate layer, it becomes easier to make a judgement about that event. Naturally, the game should follow the game’s concept. If it does that, make sure that it matches with expected game actions. Once that is taken care of, check if there are any subsystems that it might interact with or with any insights that the GM or the Players already have in-game.
Troubleshooting a system – Some games don’t work properly to accomplish what they promise. Sometimes, most of a game works well, but there is a component that fails to meet expectations or is difficult to work with. By understanding the game’s layers, it becomes possible to fix those flaws and understand the impact that the solution will have throughout the rest of the game.
Customization – As a gaming group understands the game better, they may want to customize the rules to fit their group better. This becomes easier when the effect of those changes can be seen and visualized across layers.
Building on to a framework – Some other game developers or playing groups may decide that they like a game, but they want to expand on some of its details. This might be by adding new subsystems, adding new actions, or expanding on those subsystems and actions. This becomes easier to accomplish when the designers can see where their changes fit into the game.
Setting tailoring – A system that is applied to a different setting than was originally intended must undergo some tailoring to fit that setting. Generic systems are typically easier to tailor than others.
Creating a game system – While models are not intended to be prescriptive and do not expect to fit all games, they can be useful as a measuring stick for developing a roleplaying game from scratch. Understanding how an in-development game matches up with a model can help to identify weaknesses and how to resolve them.
Alright, get on with it
The CASIP Model is used to understand the layers of a roleplaying game as a method to understand how the game works. Here, layers refer to a progression of ideas that one could follow from the most basic concepts of the game to how it works in-play. The layers are:
Concept – What the game is about
Action – How to resolve actions in the game
Subsystems – The process to resolve actions related to an overarching theme such as tactical combat, thievery, downtime, etc.
Insight – The collective information about the game as the gaming group understands it
Play – How everything works together in actual-play with GMs and Players responding to Knowledge
That's it?
For a more in-depth look at CASIP, please see the table in the spoilers below.
Layer
Description
Concept
The Concept is why the game was made, who it was made for, and what it is attempting to emulate (if anything). At this layer, we can observe a game’s genre and tone – is this game about spy thrillers, heroic adventurers, dystopic struggles, or is it generic? It can also be used to understand how much the gameplay is influenced by storytelling elements and how much it attempts to simulate specific actions.
This is also where game components are decided upon – how rules-heavy the game is intended to be, the roles of the participants (GMs, players, referees, etc.), or whether the game is intended to be cooperative or competitive or both at different times. Some games even eschew the role of GM or referee altogether.
The Concept Layer lays out setting information that will be relevant to gameplay. If the game is applied to other settings, every layer of the game may be impacted. It includes what roles the player’s characters will take on during play.
Every other layer typically ties back to the concept in some way. Components of the game that do not tie in to the concept can feel out of place.
Action
The Action layer determines what the participants do to resolve success for a task. This layer also describes what normal thresholds for success are and may define more granular successes like full successes, partial successes, partial failures, total failures, advantage, etc.
At the Action Layer, the game also determines what Statistics (ability modifiers, BAB, etc.) are required for each character, meta-currencies (like Action Points or XP), and basic character options are available to all characters (like Skills).
Some games may allow for different Action options between Players, the GM, and/or NPCs. In some cases, the GM is given unlimited options while in others, there is a specific menu that must be selected from.
Action should support what the game is about, or at least not contradict it.
Subsystems
Subsystems flow from the game’s Concept in that they reinforce what the game is about. They describe how a character in the game is supposed to achieve aspects of the fiction presented in the Concept. Subsystems typically add rules to the Action to make it fit the subsystem’s goals and might add stats, meta-currencies, or options as well. Subsystems may also alter the Action mechanics to better-fit the rest of the mechanics of the subsystem. In many games, only a few subsystems are well-defined based on the game’s Concept, while others attempt to present a wide-range of fleshed-out Subsystems. Some subsystems interact with others, but this is not a requirement. Examples:
Downtime – describes how characters can make use of non-adventure time or what happens between adventures. Includes things like recovery (physical and mental), fencing stolen goods, recruiting followers, paying homage to a god, etc.
Factions – describes what actions factions take and how they progress their goals, and how they interact with the player characters.
Supplication – describes how a character could gain power or effects from deals with more powerful beings
Thievery – describes how characters might attempt to lie, cheat, con, steal, extort, burgle, or use other underhanded methods to achieve their objectives
Subsystems also include all statistics and character options that are required to interact with them. For example, a Spellcasting Subsystem may add dozens of Spells for a player to choose from.
One of the pitfalls common to Subsystems is that one Subsystem may take on all aspects of another to the point where the other Subsystem is obsolete or requires more resources to engage in. Another common failing is inconsistency between subsystems, where one subsystem allows one outcome, but another subsystem provides a better one while dealing with similar topics. The more subsystems a game adds, the more complex it becomes, and leaves itself open to unintended consequences or abuse.
Insight
The Insight Layer deals with all details, facts, lies, and rumors that are involved in the game. Within this layer are two main types of information: Public Insight and Private Insight.
Public Insight is concerned with everything that is free for anyone to find out about the world or the characters. Private Insight is made up of the things that not everyone knows – GM notes, the layout of a dungeon, a character’s secret past, etc. Some Private Knowledge may be shared between only some of the players or the GM and a player. Often, things that are Private Insight will become Public Insight at some point.
Some games also attempt to divide Player Insight from Character Insight, penalizing players for taking actions that their characters wouldn’t normally know about.
The game develops situations as a result of the Insights changing. Situations can escalate as tensions rise or deescalate as they fall.
Insight is updated to reflect the outcome of the various Subsystems. Normally, this is the result of the GM and players interpreting the outcome to develop a new situation. Knowledge is then used to feed into the Actions that the game participants can take.
Play
Play describes what actually happens while engaging the game. The players make their actions based on the actions and descriptions of the GM. Mechanics as described in the rules often diverge from what players do in the moment.
So, what do you folks think? Is this useful to you? Agree? Disagree?