Chimborazo design structure
This post takes a look at how Chimborazo RPG is structured mechanically. I prefer to introduce myself as a systems engineer rather than a game designer, and this is the reason why. Even though I am designing a game, I feel like the mechanics and the provided structure are the actual “game” part and if they are well executed, they can be re-skinned with basically any flavour (a.k.a. lore, setting, etc). This is not to say that Chimborazo is a universal game, of course, since there are many parts designed specifically with setting in mind, but it’s important to differentiate between the cases when mechanics are dressed to look like lore (because the game needs to be flavourful) and when lore is disassembled into mechanics (because they have to be built for it). In this exercise and most future design articles in general, I will be stripping the Chimborazo flavour from the content as much as possible and exploring the structure of the game’s underlying systems, while trying to provide context about why they exist and how they link to the setting.
- the core gameplay can be fine-tuned to produce the desired experience and is easy to balance and patch post-factum, making future releases integrate easily with older ones
- problematic systems can be reworked or taken out without affecting anything else
- new features can be installed anywhere without messing things up, making it perfect for supplements
(talk about what an acting unit is, etc.) There are several steps that are necessary in order to make such a core and I like to observe them by working backwards from the desired outcome, reverse-engineering what happens in order to produce a result:
- Action resolves in success or failure. This is the output.
- We need a way to determine how that action is going to resolve.
- The player picks an action available to their character. This is the input.
I keep getting sidetracked, but the explanation of the problem brings us one step closer to understanding the reason why a certain solution was implemented. And while we’re rambling, I want to make a general point about game design – it’s not something particularly hard. If you have been doing it for a while, you have a certain “toolbox” with which to solve problems. The only discernible skill you need after developing these tools is the ability to identify problems and choose which tool you are going to use in the particular situation. Many of the next posts will be on that subject, but for now I will try to stick to the topic at hand.
Which is constants. In this case, straight up words. Non-numerical descriptors which always have the exact same meaning, regardless of when or where you find them. I call them “tags” and they are the effects that you will see in Chimborazo – properties that define the values of everything. Tags vary in their nature, but most often they determine what something does. Unlike the numerical values, which are primarily found in a character’s “stats”, these are less about how powerful a certain aspect is, but rather what it is exactly. This will become more clear in the article that goes in-depth into the tags system, with more concrete examples that will help establish how they are used. The two best parts of the this system are that 1) they preserve the original source of the effect and eliminate the problem I talked above and 2) they are really flexible and allow for great customisation by DMs and players that might want to houserule or tune anything to their liking… or straight up introduce another setting over the same system.
I mentioned stats, so I’m going to cover that quickly. This is another cornerstone of the processing core, however I’m not going to go into too much detail in this particular post. I found nothing wrong with the way most games do stats, so I am sticking to a classical interpretation (with, of course, different actual stats because it’s a different game). Point is, they are always in the form of integers and represent another universal constant that the engine uses to perform calculations. On the back end, stats are the bulk of requirements that have to be met as a prerequisite in order to access skills, while on the front end they comprise most of the skill’s power and actual impact. Speaking of impact, here is another way to show how stats and tags work together – in most cases, the former provides vertical power and the latter horizontal power in the form of effects.
I suppose that’s about enough for stats and tags. In their separate articles I will explore how I stopped on these particular configurations for them, but I want to mention that there were lots of options explored until I settled on this model. The biggest problem was to streamline everything into as few mechanical blocks as possible. It’s not very difficult to have a weight value attached to each item, or durability values, or unique spell effects… but I find that all those things can be standardised under one system without losing functionality, which means that the game has lost complexity without losing depth. Which is what I think every game should be striving to do.
Next up are “skills”. They cover everything, from actions to passive abilities. Moves, hits, speech, performances, knowledge of languages, social interactions, everything is a skill. Simply put, all actions are skills. And before you get confused, I am referring to player actions here. Whenever you want your character to do something, you pick a skill for them to use. They are called skills specifically because all of the character’s abilities come in the form of “skill trees” which they opt into. Their abilities are both active, a.k.a. things they can do, as well as passive, a.k.a. things they are able to do. Subtle differences galore.
But let’s talk about why I have unified everything into the skill system. Since it’s all about roleplaying, the single thing that a player has to be able to do is pick an action (appropriate for the situation or not, that’s left to the player’s discretion) as a way for their character to react to the situation they are in (or actively being presented). I am a big believer since all player decisions represent the same thing (a reaction by the character), they should be under the same system. That’s not to say these things aren’t broken down by type further, but in this overview we are looking at the major mechanical blocks, and all skills have the exact same template, regardless what they are for. That’s also not to say that characters can’t be proactive – I understand the way I described things here makes them look like an all-reactive system, but we have to face the fact that proactivity is extremely rare. Once an initial stimulus is introduces into an environment, everything else is technically a reaction to a reaction to a reaction… you get the point. Then these reactions can be proactive in their own way, if they provoke a reaction, though that doesn’t always have to be the case.
Together, these three major systems (stats, tags and skills) comprise the majority of Chimborazo and the entirety of its functional mechanical core, a.k.a. the game engine. In the future, when I refer to “game engine”, it will be precisely to this configuration of interactions. At the end we will look at an example of how they work together, but the basics are as follows – bluntly put, your character is a lump of stats that interacts with the world based on the skills they have access to. Mechanics and properties are handled by the tags system. Every other mechanical block interacts with one or more parts of the engine (usually all three, since they are so interconnected and vital to gameplay, but not always). For instance, item mechanics care primarily about tags, since that’s how all items are defined – however some of them might have stat requirements or augment certain stats, while others can give the characters a particular skill in rare cases. And of course, certain skills straight up require specific items.
The reason I am mentioning all this is because it’s important to understand what the goals of a system like this are. Chimborazo, like the vast majority of RPGs out there, is a game about simulation. Each one has its own degree of abstraction of course, and cares about realism to a certain distinct point, however almost all of them are about simulation, and this is important to understand. These games, mine included, take a certain object and make rules how it behaves in different environments. To that end, it’s all about simulating the expected behaviour this object would have and the outcomes of actions by and to it, with the expectancy that the same action will end in almost the same result every time. I say almost because there is a certain degree of variance, in almost all games, which actually simulates reality quite well since we can’t rely on controlled conditions without very careful and specific setup. An object might be anything from a character to a certain item or spell. The way I define “object” in RPGs is “anything the game cares about”, a.k.a. everything that has rules written for it, how it works, behaves and interacts with other objects. It’s getting increasingly likely that I address how I use terminology, in a follow up post.
In Chimborazo, I am attempting to introduce a high degree of realism into the simulation. The thing I care about is enabling the player to have full control over their fictional character, which in terms of game mechanics means the ability to react to any situation the way they want to. The way I see it, the fantasy of roleplaying is to tell the story of your character through who they are and the experiences that shape them. In writing we learn that without conflict there is no story, which I largely agree with… perhaps including the small caveat that there is no interesting story. So in the end since conflict drives everything, the thing that matters is the ability to resolve conflict. As you can see from the introduction, everything is based largely around the ability to produce outcomes to situations, a.k.a. handling conflict. One might say that this is done through the fabled design term “resolution mechanics”, however I often find that the specific way your produce a valid output is less important than the way you get there.
EXPAND since conflict drives everything, all you need to do is be able to resolve conflict.
EXPAND this is for simulation games