Fulfilling your game’s needs pays off

From the very start, I set out to make Balance a rather small game that focused on what it was trying to do and ignore many of the complicated moving parts that are required to make a large-scale, fully fleshed out games. RPGs are very suitable for that sort of stuff, because unlike video games, they are interpreted by living, thinking creatures, that can fill in the gaps when they feel the need to. With that in mind, I went with a very simple mechanical system – originally it started as a simplified version of my other game, but as I focused more and more on tightly intertwining flavour and mechanics, it became even less of that, to the point where it’s not just its own little thing, loosely related to the original in the way it does some things. This bit of context is important in order to understand the following bit.

As a systems engineer, I like to define objects and give them properties that mechanics can use. I’ll break down the process:

What is a character? Stripping away any custom world’s context, a character is basically a person. Thus a human. Thus a sapient animal. Thus a sapient, sentient being. Thus a sapient, sentient pile of living matter.

Well, that’s it, we can’t go any lower than matter, unless we just break that down unnecessarily much. So, what IS matter in our game? Well, I’d like to measure it, so I’ll give it a (sample) stat – Endurance? Sure, as good as any, besides I’m not interested in simple matter, so it’ll probably change. living matter probably needs some additional ways to be described though, doesn’t it? The thing that separates living beings from inanimate objects is that they do stuff. At the very very core level, yes they are more complex because organic matter, and yes their absolute #1 key feature is that they reproduce… but really, as a designer, I’m interested in this distinction – living beings do things on their own. So basically, I need another stat to represent their ability to do things – say, Agility. To be agile means being able to move on your own in the first place, so it works for me. (Of course things are a bit arbitrary and subject to individual interpretation from designer to designer, but my goal here is to abstract complex systems into simply quantifiable data, so any models that work are good for me.) Now we’re up to define sentient living beings, and I didn’t have to think too much about that because to be sentient means to possess Intelligence – a stat very commonly found in most RPGs. Already, we have a framework that will work for most things – anywhere from people to beasts, monsters, etc. But, being interested in answer what a person is, according to the game, I have to add sapience to the mix. One could very reasonably argue that it’s simply a product of higher intelligence, and I won’t refute that point, but from a systems perspective I’d like to differentiate it, so I’ll add what humans have but other creatures don’t – Wisdom.

This is the kind of framework I employ when codifying how characters work in a game. Obviously, a full character is more than a pile of stats – they have a story to them, a name, different likes and dislikes, a personality, things they can do well and things they suck at, etc. But any time I want to examine what happens to a character, I need a physical representation of their being in order to understand what will be affected, and how – or by how much. So, following along this train of thought and asking a few other questions, I arrive at the six stats characters have in Chimborazo – Strength, Agility, Intelligence, Dexterity, Willpower, and Intuition. This really isn’t the topic of this article, but it helps illustrate everything else. Finally going back to Balance, as I mentioned, originally it started out as a simplified version of Chimborazo’s engine. Stats were among the many systems that both made the cut to be in the game and were simplified to reduce complexity. Which is how I arrived at the three stats that Balance characters have – Strength, Agility, and Intelligence.

With the knowledge that I wanted to keep numbers low, I set out to make different classes based on them, such that they would cater to different types of players and allow me to have something to offer for every player psychographic profile. While my study on these profiles is not yet (or may not ever be?) 100% complete, a focus on each of these stats explores one of each of the three primary axes of gameplay, so theoretically it still covers what every player might want in order to have fun. (It gets even better when they are put in groups of two, one Primary and one Secondary, allowing for ever greater flexibility among gameplay options, but there’s some time until we get to that bit.) Early on in the design process, when I was making the cornerstones around which the game will resolve, before the pillars of gameplay were set as they are at the moment, I knew I needed a Strength-focused class, an Agility-focused classes, and an Intelligence-focused class, precisely for the reasons outline earlier – players NEED these things in order to identify with their character, they need a type of gameplay experience that suits their approach to gaming and will allow them problem-solve the way they want to approach things.

Thus, the Ranger class was born. Taking the very popular fantasy of a bow-wielding elf as the baseline, the Ranger was the epitome of Agility in all their aspects – ranged and melee, his attacks were quick and not the most impactful, but could “crit” (or at least the way Balance does “lots of damage if X”), they were not very durable but agile (doh) and evasive, etc. etc. I alluded to this in the Warrior article, but there are very widely used tropes and fantasies in gaming, and they are such for a reason. Through pop culture and previous games, they have been ingrained in player’s hearts and minds, and they honestly EXPECT your game to have them. The Ranger not so much as the melee fighter and wizard, but still, relatively core to that sort of stuff. I didn’t have a Super-Cool-Theme™ for them when I started out, but I put them in the game because I needed an AGI class.

Of course, things quickly evolved beyond the Ranger. As I settled on the concept of the four pillars of gameplay and started mapping out the class and path distribution table, as I grouped stats two by two with a Primary and Secondary one, I ended up not with an AGI class but with an “AGI str” class (Agility being Primary, Strength being Secondary, in this case). For the longest time it could have gone either way between “AGI str” and “AGI int”, but in the end it turned out that they were the Combat AGI-based class, so it had to be STR as secondary. Thus, the Hunter was born. Purely out of mechanical need to have them in the game. Since then, I had to do a bit of fleshing out and give them more of an identity as agents of the Order. One of their paths had to explore that classic bow-wielding agile guy, as already established, but I had a completely blank slate for the other. Ultimately, I re-skinned the core Ranger identity as the Hunter’s dark path (and dubbed it Lone Ranger to match), gave them a more “survivalist” look, and moved on to the white canvas that was their remaining light path.

For the longest time I had no idea what to do with it, then in an “alternate universe Balance RPG” where I was exploring a different take on the classes altogether, I had defined the Hunter not as such, but as Assassin, and they were the “AGI int” class. Under that premise, I was trying to work out what an “assassin light path” would look like, and my mind jumped to bounty hunter. That still had a bit of “dark” vibe to it though, because they usually do it for the money thus ultimately in their self-interest, so I started exploring more of a “detective” approach, where the focus of this path were on the INT side of the class, yet to keep it withing the main AGI frame they were more focused on “western sheriff” kind of detective, where hunting down the criminal was as much a part of the job as any, and being quick on the draw is what the deciding factor often would be. With that frame of mind, at one point I was asking myself whether or not it would make more sense for a “rules enforcer” type of detective to ALSO be relatively STR-focused, and ultimately that made me realise that in the original version of the game, the Hunter was an “AGI str” class and that made a lot of sense for a “light path hunter”. I still dubbed them “detective”, and in turned that gave birth to another piece of “soft mechanics” – the invisible scaling.

Invisible scaling is when a path incentivises you to branch out of your class’ Primary and Secondary stats because skills in that path scale with your missing stat (in the case of Hunter, they start with 0 INT). Of course, it won’t be ALL skills there, but just enough to warrant at least being interested in picking up some INT points later on. Generally speaking though, it’s not about the actual mechanic of “skill scaling”, but rather that this path will lead you to a style of gameplay that’s alluding to or even mimicking the type of gameplay that classes focused on that stat provide and explore more in-depth. I’m very glad it turned out this way, because it allowed me to solve the last remaining problem related to player types – while there are 4 different options for pillar of gameplay per stat, and there are three stats per pillar, as I mentioned in the Warrior article, approaching the game from a class flavour standpoint is the most limiting, because it kind of locked you into one of two pillars of gameplay, and more or less into one stat. This way though, I can have each class explore all three stats – two of them through simply scaling with them, and the third through invisible scaling.

In a way, the mechanical necessity of simply having the Hunter where I needed to have them allowed me to solve a problem I didn’t think needed solving in the first place, and in a very elegant way. Once I had that frame of design, I went back and applied it to all classes, which in turn eliminated many of the possible variations I had for their paths, along me to make choices and settle down on the final design more easily.

For additional context, refer to the Balance class design intro

<< Previous article: WarriorNext article: Witch >>

Leave a Reply

Your email address will not be published. Required fields are marked *