Mechanics: Discussion – Skill Checks In Summary

Alright, there seems to be some mild interest in explaining the way the skill system works. Let’s go for that. I’ll try to possibly simply explain the implementation and the reasoning behind the whole system.

Let’s start with the simplest thing. The skill system is used exclusively for comparing the PC’s skills (s) to a target number (tₙ).

If s ⩾ tₙ, the PC succeeds. There’s no die roll involved; hence there’s no randomness to the checks, and, given the same situation, the outcome is always a success. However, there’s a bit more to the alternative, including a bit more randomness.

Specifically, while I didn’t want randomness in the case of success to dissuade any potential for save-scumming, I did decide for failed checks to sometimes have different outcomes. The idea is that sometimes a failed check might become a misdirection (this doesn’t happen in all cases, just for some checks where this is coded in) with pₘ = 0.1(tₙ-s). A misdirection presents in a way that mimics how success would be signalled but instead gives some other, incorrect information. Comparatively, a simple failure will instead signal uncertainty.

Next, in most cases, when a check happens, experience is assigned to the skill in question using the formula r × pow(2, tₙ-s), where r is a base rate (we’ll get back to this later). The pow(a, b) function is exponentiation of a to the power b (just in case you somehow don’t know). Thus, the PC gains more EXP by taking on more difficult checks, particularly gaining significantly more experience by failing them. Additionally, the experience needed for any specific skill level rises linearly. However, the higher the PCs skill gets, the less experience the PC can acquire from using it, meaning that attaining higher levels requires exponentially more effort — a welcome side effect of the calculations.

As an aside to the above calculations, all skills can be seen as real values in the range of 0 to 4 (what you see in the interface as ★ to ★★★★★). Their continuous nature becomes important later on as well.

That’s easy enough, but it is somewhat predictable. In particular, the success portion. In the end, this means that given no other considerations, getting your skill high enough is everything you need to pass a check. Unless, of course, we start applying some modifiers. And in this case, the modifiers are… practically a copy of how the base rate for experience gain is calculated. I realise once I wrote it that it’s more than enough to satisfy my needs in that regard as well.

What happened is that I started with a system capable of giving me a base rate for experience gain for a given type of action that awards experience. From there, I implemented a concept present in the design work for the game from very early on: some resources (mood and stamina in particular) affect experience gain. I’ll go back to speaking about skills now, but it’s important to note that this system’s source lies elsewhere, even if, by this point, the implementation of it for skills is far more advanced.

Before we delve into the exact mechanics, let’s discuss why a game needs a skill modifier system. At base, it’s trivial to hold player character attributes within some data structure and retrieve them as needed. But this approach quickly falls apart if you also need to apply conditional modifiers to those attributes and track them in various ways (i.e. some changes can be merely conditional, others have temporal bounds). The only reasonable solution is to have some transformation between the base attribute and the value of the attribute relevant at the moment when it is checked (during a skill check, in this case, duh).

So, speaking otherwise. The values of s and tₙ are not actually raw skill values (the former for the PCs skill and the latter for the NPCs skill, if applicable); instead, they are transformed according to a set of conditional modifiers. We’ll call this set m, but the important thing is that it contains tuples (rₙ, aₙ, bₙ, cₙ), where r is a rule governing when the modifier is applicable, and the other three values are the actual modifier, split up into parts.

Then, we get our transformed skill s’ according to this simple formula:

s’ = min(max(-1, (s + a) × b + c), 5)

Where:

a = 0 + ∑ₙ[rₙ]aₙ
b = 1 + ∑ₙ[rₙ]bₙ
c = 0 + ∑ₙ[rₙ]cₙ

Note that the square brackets here denote the Iverson bracket… right, as if that tells you anything. Essentially, [rₙ] is 1 if rₙ is true, or 0 otherwise.

Defining the final value in this fashion has three critical benefits:

• Firstly, because all modifiers are expressed as only these three component values, there is no ambiguity about how different modifiers interact;
• Secondly, all bonuses are commutative, meaning the order in which they are applied doesn’t matter;
• Thirdly, clamping the value with a lower and upper bound prevents any snowballing effects stemming from the experience calculations.

The last thing I’d like to touch upon is the implementation of the rule. To optimise the process, I divided the rule into two components. Firstly, a contextual set-logic check is performed to see if the modifiers match the provided tags. This is used to pre-select elements from the m set according to factors such as:

• affected skill category,
• affected skill,
• check type.

Once the preselection concludes, the second component of each rule fires, further pruning the selection. This touches upon different factors, such as:

• NPC traits,
• other skills,
• resources,
• resources,
• temporary conditions.

As a specific example, on any Emotion Affect skill check directed at an NPC (first selection), if the NPC is a fashionista (second selection), the check is modified with a value dependant on how stylish the PC’s clothing is.

Of course, a different game might need to define the modifiers within a similar system in a very different way.

While the PC and the NPCs have different defined sets of conditions, and in both cases, some of these conditions peek at the other character to resolve, they work identically in terms of calculations.

This approach gives a higher degree of player agency to the game, as the player can now actively manipulate checks in their favour (while still avoiding randomness). By coming to know the characters and utilising their resources correctly, they can hedge the odds in their favour.