Duality of Play and System
I am Artificer, the designer of Misfortune: Dramatic Roleplaying. I am not much anything in the scene of RPGs, so my word needs to be taken at face value. I do not claim to know the best way to create games, nor do I think that I’m above everyone else by writing this post.
This theory, and the subsequent method to create RPGs, is the result of me trying to break the norms of roleplaying with Misfortune and accidentally creating a game with amazing internal consistency. This is me trying to replicate what I did then, for my first full game that I managed to finish, lay out, and release.
This method is done with tabletop RPGs in mind, but the creators of board games and video games may benefit from it, too.
The main argument of this post is simple:
When playing an RPG, there is a poorly understood duality of Play and System, understanding of which allows you to be a better game designer.
When you play a given Tabletop Roleplaying game, you’re omnipresently being pushed towards a certain kind of playing. By and large, this feature of game design is underutilized and poorly understood.
Bridging the gap people have between design and Play is the thing I aim to do. People talk about Systems enough, so I don’t need to restate their importance. However, I believe that the System should work as a way to contextualize Play, rather than being regarded as completely separate things.
What is a Roleplaying Game?
The game the designer perceives is very different from the game the player does.
The first and foremost thing when designing an RPG is to understand what an RPG is. The common definition of it being a ruleset that allows for collaborative storytelling within its rules is not actually entirely accurate. The game the designer perceives is very different from the game the player does.
The ‘game’ part of a roleplaying game is basically a fuzzy ground between the play and the system. The play is the act of people talking together and narrating the story, and the system is the mechanics at work which are imposed on the play.
The game is realized when the system is superimposed on the play, defining itself by the players’ interpretations of the rules. This is an important concept to understand. The end result of the game is when the act of playing and the system are working together.
Rules / mechanics in RPGs are very different from rules and mechanics from other types of games. Instead of the rules being ingrained to the play itself, the rules are imposed on top of the narration to give structure to it.
In board games, where there is no arbitration or negotiation whether something is possible or not, unless a rule is unclear (which is bad, most of the time). Usually all possible approaches have been defined, and you are limited to follow those constraints. In RPGs, the constraints are pre-emptively or retroactively imposed on the narration of the player, leaving room for fuzzy thought, errors of logic and bending the rules to make the collaborative story more interesting.
Play, the core of RPGs
Play is arguably the most important part any RPG experience. Play is the act of being together with the group and roleplaying. This part of the process of roleplaying games is usually rather ubiquitous, unless the core gameplay of the game is somehow fundamentally different.
This fundamental difference shows us that even the most basic thing in our gameplay experience, the Play, can be modified when the rules are superimposed. Without rules, the default way is to either tell stories completely collaboratively, or by assigning one player as the narrator / game master and everyone else controlling a single character or a group.
How can this be fundamentally changed, then? It's by imposing restrictions or liberties to the parties at play, like tokens that anyone can use to modify a thing another player said, or by imposing limits on how actions are made by the players.
In SOF, this core play is fundamentally changed by the fact that players cannot dictate the actions their characters make, only the programmed protocols their characters have. This means that they are naturally compelled to do some things, and cannot do actions outside of that. At least in the beginning of the game.
System, the limit of imagination
System is the mechanics of the game, both individual and combined, that affects play in a profound level. Its primary function is to limit the gameplay in a way that it delivers the intended playing experience to the players.
The System is also the product that you’re trying to create, and is thus of special importance. However, the System is the vessel to deliver the intended gameplay experience, thus it is always subservient to the game itself.
Limiting the players’ imagination doesn’t sound like an inherently good thing, but in the context of RPGs, it’s often necessary and beneficial. Humor me this: imagine a new fantasy creature. I reckon it’s not easy to do. But if I limit your imagination, it will become much easier. Now imagine a new fantasy creature that has some aspect of a bat in it. For most people, doing this latter one is much easier, and it often results in more interesting results. Having limitations allows the players to embrace the limits that exist and go wild with them.
By creating limitations, the creativity of roleplaying is both boosted and made quicker, creating a much more smoother gameplay that has less stuttering and overt thinking. This should be the function of all mechanics in a system, not to expand the available options, but to limit them in a way that serves the gameplay. Having too much choice can make players feel like everything is the same or the abundance of options might paralyze them.
Game, the end result
When the product you make (System) is superimposed on the act of roleplaying (Play), you create the functional effect of playing your Game, and the main point of this theory and post is to make you realize the importance in making these distinctions.
The act of playing a game is always a combination of Play and System, and we can get enjoyment from it in various different ways. Thus understanding your game on a deeper level, meaning analyzing how the System affects Play and the Game, is a thing that will both help you develop the game faster and more efficiently, and also make the end result better.
The act of writing RPGs is in my experience - both by reading and talking with designers and designing myself - a process that is not very well defined. It’s chaotic and impulsive with very little methodology at play, thus very inefficient. I aim to uproot that inefficiency by giving you something to work with, and something to follow.
Taking the Game into account, rather than trying to fervently focus on the System, personally to me feels like the path to better game design. It might sound obvious, but it’s not usually given much thought. All the adjustments to the System are done retroactively after playtesting, without almost any kind of pre-emptive measures or foresight taken into account. That's how it feels like to me, at least.
Hierarchy of the Game
Achieving a certain gameplay experience is not simple or easy. You must have a lot of prerequisite conditions to achieve that, meaning every single aspect of the game must work at least serviceably to create the feeling and experience you want to employ. This incidentally also lines up how a given player or reader of the system will see the game.
Every preceding part is necessary to make the next one work, which in turn is required to make the next one work. However, this is only the perspective of the player.
This hierarchy also shows how the Play and System are fundamentally separated. Mechanics represent the System, and Gameplay represents Play. The interesting parts of the design process are in the fuzzy middle ground, but these extremes are still very important.
Mechanics are the basic building blocks of the System. They are the the most defining aspect of any given game, as the mechanics are the defining aspect in all aspects following it in the hierarchy.
Mechanics are also the part of the game which players interact with. All the other parts of the game design process are uniquely important to the designer, or alternatively someone who wants to modify the playing experience for their own group.
However, while their importance as a building block cannot be overstated, they are also the least reliant on other things. They are thus infinitely malleable, as long as a mechanic serves the same functions, it can ultimately be replaced by another.
Dynamics are the amalgamation of several mechanics that create either an isolated section of the game (Combat systems are the most common ones here) or a connection between two mechanics that meaningfully affects each other. Like if armor is used as damage reduction, it affects the damage you take meaningfully. Or if there is a mechanic to dodge incoming damage, it meaningfully affects your hit points, without being effectively the same mechanic (like hit points and damage).
Dynamics are the first step into deeper gameplay experience, and they are often both understood and explained with common sense. Killing monsters awards experience, and experience allows characters to become stronger. This incentivises players to kill monsters. Obvious enough. But without proper restrictions, this might lead to players breeding powerful monsters and killing them with traps or other contraptions to gain infinite experience points.
Game feel defines the abstract feelings while playing a game. This is affected heavily by dynamics and how randomization is used in the rules. A game that uses large pools of dice makes the players feel powerful, where as using ‘big dice’ like d20s and d100s taps into the feelings we get from gambling. A game with fragile characters feels more tactical and pushes the players to play more tactically, where as a game with tons of hit points that don’t affect your performance welcomes playing riskily.
Game Feel affects the experience of playing heavily, and slight adjustments to the System can change it radically. Fine-tuning the Game Feel of your game is really important to getting the most out of it.
The game’s identity is an amalgamation of all things preceding it and answers the question: “What are the game’s most identifying aspects”. This means defining the things that make the game what it is. Most often this is achieved by singling out mechanics or dynamics (features) as either Primary or Secondary, the former defining the game’s innate identity and the secondary ones creating the framework for Primary ones to be effective.
The amount of Secondary features also defines the game’s apparent weight. A game with few secondary features is often identified as a lighter game, and a game with many secondary features is often identified as a heavier game. The amount of Primary features does not affect the game’s weight, however, any given game should not have more than a handful of Primary features, lest the game becomes disjointed and incoherent.
Gameplay is the act of Play while engaged with the System. This is all the steps before being applied into the real world, outside of the System. You may think that this is completely impenetrable and impossible to have any control over, but I want to contest that idea. The gameplay is fundamentally defined by how the game itself works and how the game is presented. A dark fantasy game defined as dark fantasy will stay as dark fantasy as long as the illusion of its presence is not broken, and the players are invested to it.
Unlike the other parts of the game, you add the actual presentation to the mix. The writing style, the art, the layout. It all works in service to creating the right illusion about the game, and the System works as something to reinforce and keep the illusion up to the players.
Naturally, you cannot escape the deliberate ruination of the game’s themes due to people, but you can minimize the chance of that happening accidentally. Do not think about the edge cases of people who don’t want to play the game or want to use it to subvert itself, that is not the audience you want to take into account. Instead, focus on delivering the perfect experience for anyone who has the chance to become the perfect group for the game.
Hierarchy of the Design
As a designer, the way you perceive a game should be effectively reversed. While the hierarchy the player perceives is relevant, this designing method turns it upside down for your own convenience. This leaves the best parts of the design upfront, and by the time you come down to the part where you start writing the bulk of the game, you already know how the mechanics should work. This creates an ease of creation, and cuts off any unnecessary bloat that would otherwise plague the game.
This is the design triangle that we will be working with for now on. Flipping it upside down is mostly just a trick to make you understand the process of reversing the hierarchy, even though technically we could’ve just started from the top.
Nonetheless, now that you have been introduced to the different parts of this hierarchy, flipping it upside down is a simple task. I tend to think of this reversed hierarchy as a thing to keep in balance. Balancing the gameplay in isolation is really easy, and every step until mechanics becomes more and more difficult to balance.
Before we get to the step-by-step method to designing the game, I must interject with the importance of abstract thinking. This method relies heavily on thinking about your game and system on an abstract level before writing down any mechanics. This abstract thinking allows you to flexibly adjust your features without writing excessively and thus allows you to experiment with different approaches to problems.
This constant experimentation is instrumental to creating coherent and multi-purpose mechanics. Keeping things abstract allows you to make connections that would otherwise be difficult or even impossible to make.
Gameplay as the origin point
As a designer, starting from the gameplay instead of mechanics yields a lot of benefits. It creates a vision for the game right away, and it also guides you through the entire process of designing the game.
In practise, this means you start imagining how your game would be played, and jot down some key features you want to include in the game first and foremost. Answer these questions as well as you can:
- What is the primary emotion you want to elicit from your players?
- How much control do you want the players to have over their surroundings?
- Is there a Game Master or an equivalent player?
- How much power do players have over each others’ characters (Including the GM)?
- What kind of situations will player characters find themselves in often?
You should write down any relevant information that comes up in this phase. The game is still in quite the malleable state, so anything written down as of now isn’t final. This is simply to have a red thread to follow in the rest of the design.
Identity that defines
After coming up with the desired gameplay experience for the game, you need to answer the question of identity. What of these gameplay features are absolutely necessary for this game to feel like the game it is supposed to be? What is the game focusing on?
Write down a one-sentence definition for the game’s primary goal, and then write down 1 - 5 ideas for primary features for your game. These will guide you through the rest of the design process, as they will be your focus with expense of everything else. These primary ideas should thus be the most defining and unique aspects of the game, not simply neat things you want to have in the game.
Do note that the central resolution mechanic usually is not a primary mechanic, even if it feels like it due to its importance. It is then defined as a separate thing, neither a primary or a secondary mechanic.
“SOF is a game about playing inhumane robots and discovering humanity through gameplay”
- Make sure that the players feel like the character is inhumane
- Enforce humanity as an axis in gameplay
- Have ways to affect the humanity your character has
Game Feel, the texture of the Game
Game Feel is difficult to pin down at this point, so it is important that you come up with some kind of guideline for what kind of feel you want to achieve. Try out different ways to randomize your game, think whether you need to randomize the game, try out fiddling different dice and tokens, and just get a feel for what seems right.
Think about the moment-to-moment gameplay you outlined in the first step, and reflect your game’s identity to it, use it to give you some guidance on the matter. Don’t commit to anything yet, but get a feel for how the gameplay should feel, and note how many steps you should take to resolve each question asked.
Fine-tuning the game feel is very much an imprecise art, but it’s important to keep it in mind.
Dynamics and the Spheres of Gameplay
Dynamics are an important part of the game to pin down, because they will work as your framework to start creating the System i.e the mechanics. You can approach that question in any way you want, but the way I will promote is using Spheres of Gameplay.
Spheres of Gameplay are sectioned off parts of your game that revolve on a single thing. Combat is often a sphere of gameplay, downtime can be a sphere, and even character creation can often be classified as a sphere. However, there is a limited amount of spheres you can have. Each sphere of Gameplay should have at least one Primary feature as the centerpiece of it. This means your amount of Primary features limits the amount of spheres you have. No Primary feature should usually be the centerpiece of multiple spheres (with maybe the exception of character creation), unless it is a part of many.
Singularity, Duality, Triality
A sphere of gameplay might have more than one primary feature driving it. Often this is about balancing two or three primary features in accordance to everything else.
Singularity is the focus on a single feature. This means all other features in the sphere should be somewhat linked to this single feature either directly or indirectly. In a game where you play as divine beings, this could be your character’s domain, for example. Or in a class-based game, this can be your class. The choices you make in that sphere are somehow connected to this single feature. A singularity can often function like a duality due to features sometimes being innately dualistic.
Duality is the focus on the balance of two features. At its minimum, this can mean that there are no secondary features, simply the balance of these two. This can be like trying to balance between honor and vice, or to balance offence and defence.
Triality is the balance of three things. This can easily carry an entire sphere, and is surprisingly quite common. The most common type of triality is in character creation, where you balance versatility, offensive capability and defensive capability. This can also be balancing movement, offence and defence in a combat situation.
Structuring a Sphere
The sphere has the inner layer, which consists of the primary features within it, and the outer layer, that consists of the secondary features within it. Within it, there are arrows that connect features to each other if it can nullify the other. This can be like grappling being able to nullify movement or movement being able to nullify melee combat.
When you have made these connections, look at the number of arrows coming from each feature. Are there secondary features that can nullify more than primary ones? Maybe those features should be primary features, or maybe they’re overpowered. Keep this in mind as you go forward.
Additionally, make connections between the spheres. What is the most central one that affects the other spheres the most? And what affects that? Keep this in mind.
A single sphere can encompass the entire gameplay of a game, or it can be only one of many. Regardless of their number, the spheres you have are extremely important when going to the next phase of designing.
Review, review, iterate, review
After all this, we would be ready to start writing the mechanics and system proper. However, this process, all these steps you have gone through, have been the very first draft of the game. This first draft is often subpar and might have things you simply don’t like. So now it’s time to rectify this.
Start from the beginning. Do the spheres of gameplay that you wrote reflect that gameplay goal that you had in mind? If not, which is in the wrong?
Do the spheres reflect the game’s identity and feel? Were some parts of the identity less central than you hoped, or were they less central than you assumed?
Are you satisfied with this draft of the game? Review all your notes, and make changes in it until it all makes sense. Start from the beginning, so if features do not fit the spheres but you want them to, retrofit them to the previous sections.
Once you’re satisfied, it’s time to proceed to mechanics and the System.
Mechanics and the System
After all these steps, we arrive at the mechanics. If you haven’t taken one already, now is a good time to take a break and let the game sit for a while.
Drafting your mechanics
When you start building your mechanics, it’s important to start without worrying about numbers. Just write about the concrete conclusions of what the mechanics aim to carry, how they affect each other. This drafting of mechanics is important, because you can get a feel for how the game works before you need to think about balancing the numbers. If you can’t express the mechanical underpinnings of your game without the use of numbers, numbers won’t help you a lot.
Start with your spheres of gameplay. You can technically start anywhere, because the spheres are mostly contained, but I usually like to start with the part the game is focused on, whatever it is. Exploration? Combat? Social Intrigue? Spaceship racing? You know best what you want your game to be.
Take a primary feature for that sphere, and describe it without numbers. Describe how it affects the features around it, describe how it works in isolation of numbers. Then simply follow the path by explaining all the other primary features for that sphere and then the secondary ones. If you feel like some secondary features work better as sub-features to the primary ones, write them as such.
After finishing everything in the sphere, read it through. Does the text explain the mechanics in sufficient detail? If you had dice and knew what you did with them, would the mechanics make sense? If the answer is yes, move to the next sphere.
Do this for every sphere until you’ve gone through all of them, then connect the spheres in a way that explains the most autonomous sphere first and the most reliant sphere last. This creates the outline for your game’s physical layout.
Crunching the numbers
Then, it is time to crunch the numbers. This is the part you’ve probably been waiting for, the quintessential part of making a game for many. And, well, to making a System, it is technically the most important part. It must be treated with due respect.
All this preparation has been done so now, at this point, you don’t really need to do much. This is supposed to be the difficult part of the design, but it should not be. At this point, you already know what you’re supposed to do. You have laid out the game’s most important aspects to the writing, and now you only need to apply the numbers to it.
I ask you to return to part 3 of the hierarchy: Game Feel. Now that you know how your mechanics work, fiddle with dice, tokens and cards once again. Just fiddle with them while thinking about your game. Roll them a bit, count things. Choosing the central resolution mechanic for your game is now much easier than before. Think about the amount of influence you want your players have over the central resolution mechanic, look at your features for it and try things out.
From that point on, the design work is basically done because you’ve done most of the work already. Write the numbers, reference your notes for the previous things in the hierarchy. Reuse the numbers and mechanics as much as you can, and apply until the game is finished.
Rinse, repeat, edit and rewrite.
The point of this post is to help people understand the value of thinking about the game on a lateral level. I am currently making a game called Red Roulette with the guidance I gained from this method, and I will review its design process in a post once it's done.
The entire purpose of the design triangle and its reversal is to work as a visual reference for a simple concept: as a designer, you should think about the Game, not the System. I've written posts and essays where I've stated that "mechanics are meaningless", because what isn't important is how the mechanic does it, but what it takes in and what it puts out. Thus, the individual mechanic has no weight to the functional core of the game. Of course, different mechanics feel different, but those are a matter of preference and feel, not about functional necessity. It was a harsh way of saying it, but what I try to help people realize with this post is that as long as you know what you're trying to accomplish, making something to accomplish that is manageable.
By promoting abstract thinking in game design, where you look before you leap, I aim to show people the benefits of doing less work to achieve better results. You don't need a hundred playtesters if you understand the game. By creating the connections within the game before writing it, you are free to explore connections on a deeper level without needing to constantly be checking whether an interaction breaks something else. Of course, sometimes a feature might blindside you during playtesting, but you can avoid many nasty surprises if you prepare the game in a way that allows you to see them beforehand.
I thank you for reading, and I hope this helps in your endeavors.