Chimborazo design structure

While this looks fairly simple, it’s not. Or rather, I made it not be, because I need to know exactly what happens during each of these steps. You will notice that they are fairly broad and without delving deeper, we can’t even begin to answer the questions poised here. Most game mechanics tend to revolve around the 2nd step and for a good reason – determining the resolution of actions is actually the majority of the mechanical work in a RPG. This is where logical and numerical operations tend to happen and so naturally it is the focus of Chimborazo’s core. So, what’s actually necessary in order to perform these operations? A bunch of things, really, but the most important parts when making mathematical operations are constants.

Without constants, there really is no way to know what’s going on, and we specifically set out to design a system that can process anything, a.k.a. turn any input into a binary output. Why binary? Well, just above I explicitly said that an action resolves in either success or failure. Is that interesting enough? Maybe it is, maybe it isn’t. Many many games offer a wide range of outputs, from partial success and failures to critical hits and utter fumbles. Which is actually a good thing if you think about it, because when done right this is additional depth… which is cool and all, except only when it doesn’t come at the cost of additional complexity. But more on that in another post. My main argument here is that first and foremost, before we start piling things on top of a system, we should have a working one. The simplest form of output is binary, so that’s what we’re doing. Also, I strongly believe that binary outcome can be converted into nuanced one later without changing anything mechanically (simply by introducing more rules to process the same mechanics).

Back to constants. The primary thing to consider here is the definition for a constant – a non-varying value. Many people think only of integers when it comes to constants, however that doesn’t have to be the case every time. In mathematics, you can perform operations with x even without knowing what it is, as long as x never changes (a.k.a. it’s value doesn’t vary). When exploring this route, my natural question as a game designer was “Is there a difference between a letter and a word?” I would argue there isn’t. Magic: the Gathering seems to function quite well with their “keywords” and this is the type of thing I’m going for here, except I’m calling them Tags because they define properties rather abilities.

Why can’t we work only with numbers? Very early in the design process I encountered a problem – numbers are universal, but if you assign a numerical value to everything, you can’t trace things back to their source. Simple example – let’s say that your character’s Strength gives you +1 to the damage you do with a claymore once you hit. Your mastery of swords gives you +2. It’s a “fine” weapon so for whatever stupid reason, this gives you +1. You’re fighting somebody allergic to claymores, that’s another +1. You end up with +5 to your damage roll. Now try to work backwards from knowing somebody has +5 to their roll – what does that mean? Are they so damn good with a claymore that they got a +5? Or is it the most legendary claymore to ever exist, which (for some reason) gives it +4 and then you have enough Strength for +1 but no discernible skills? You could go and check each source, but that’s unnecessarily complicated. This is a basic principle of game design – don’t represent different things the same way. At least of my game design. To that end, you can’t simply assign numerical values to everything if you want to make a good game. I strongly believe that the game state should be easily legible and immediately identifiable.

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