Interfacing Game Mechanics

Intro

This post is mainly meant for our team members, who have been increasingly tasked with creating side quests in the past. For the ones to come in the future and the ones we have on board right now, I wanted to explain some concepts that drive my thinking when designing game content.

In the past, I have explained most of these concepts in a disconnected manner distributed over multiple chats, partially even in direct messages, making it difficult to reread my thoughts on this. This resource aims to provide a more cohesive resource for looking up my overall design strategy for constructing a gameplay system out of interacting sub-systems. It might also be an interesting behind-the-scenes post for our players, so I decided to turn it into a Patreon post.

Complex Gameplay Systems

So, what exactly will be the content of this post? I want to elaborate on the core ideas I use to create gameplay systems and game content using those systems in a way that creates complex, interconnected gameplay.

Interfaces

Most programmers know functional interfaces as something that defines a contract between an implementation of a concept and the things that want to use it. In particular, they allow for the creation of decoupled systems that only know about the interface but not about the various other systems that also use it.

In game design, abstracting away implementation details isn't really the important part, as we aren't focusing on the functional aspect. What is important, however, is using interfaces to decouple systems.

If you represent a complex system as a graph, then in the following we can roughly idenntify components that have a many nodes that are connected to each other as a sub-system (e.g. Combat System). "Many" is of course not quite a precise mathematical definition, but this is less about a concise mathematical characterization and more about a qualitatice characterization.

0. An interface in this context would then be a node that connects one sub-system to another.

To become more concrete, let's start with a very simple example of a common interface: Resources. Let's look at a very simple system with two sub-systems, a Shop system and a Quest system, as well as two resource types.

The most common example of a resource is probably Money. Since we have a Shop system, we might consider Items as another resource type. A quest might provide a resource as a reward or require it to progress. Likewise, the Shop system requires Money to buy Items and gives Money when you sell Items. This already opens up a lot of space for various interesting dynamics and how independent quests can influence each other. Let's look at the following game that uses only the game mechanics from our very simple concept.

 This game has two Quests, A and B, the Money resource Gold, an Item I, and an NPC Vendor functioning as the only Shop. A and B both pose some sort of challenge to the player - in a more detailed game, this could, for example, be Combat or bypassing an obstacle, etc. In both cases, this challenge can be interacted with some resource, maybe by skipping it entirely or making it easier. In Star Knightess Aura, Item I could, for example, be a Bomb the player can use to destroy a Rock Obstacle, or to kill a boss monster in Combat.

This results in a design where solving a quest is not a puzzle in a vacuum, but rather an interconnected puzzle. One could try to solve the challenges of A and B without the aid of any extra resources. Or one can solve A first, obtain the money, buy Item I and use it to solve B. Likewise, one could solve B first, obtain the Gold and then solve A.

The most important part of this approach is that it increases the possible playthrough paths for the player with each additional piece of content. And this gives us the core take-away from this Interface-based design strategy:

1. Through Interfaces, Gameplay complexity can be scaled up indefinitely through the addition of interacting content rather than adding additional high-level gameplay mechanics.

And this is the core take-away of this way of thinking in terms of gameplay interfaces. Rather than adding additional high-level systems, complexity can be achieved through the complex interaction of concrete content.

For example, if there is a Combat system, there might be a boss that also drops Item I, giving another way for approaching Quest B. Or by killing enemies which drop Gold, one might hunt the necessary money to either solve A or buy Item I to solve B.

In general, gameplay interfaces can be anything that two subsystems can manipulate without needing to know each other. Another example could be Skills, or in the case of SKA, Corruption. In fact, a system itself, can also be a gameplay interface. For example, a Shop might only unlock an Item if a specific Quest has been completed.

Levels of Abstraction

We briefly touched upon this in the previous section. When looking at a game, we have several levels that we can consider.

• High-Level Concept: The different interacting subsystems.

• Concrete Concept: Concrete instances of the subsystems with concrete interactions.

• Playthrough: A concrete playthrough of a player playing a Concrete Concept.

In the previous example, Quest A and B were on the Concrete Concept level for the High-Level Concept of a Quest system. And the possible Playthroughs a player can make on the Concrete Concept roughly corresponds to the number of paths in the Concrete Concept. So again, for our previous example, we have:

• Solving Quest A -> solving Quest B (Never simplying the challenge)

• Solving Quest B -> solving Quest A (Never simplying the challenge)

• Solving Quest A -> using the Gold to buy Item I -> solving Quest B using Item I

• Solving Quest B -> using Gold to solve Quest A

Generally speaking, if we assume that decision-making is fun (which isn't true for everyone, but let's focus here on the people for whom it is) then

2. More Playtrough paths = More decision-making = More fun

and the goal of a Concrete Concept is to have as many Playthrough paths as possible.

Generalizing Interfaces

While thinking in terms of Interfaces is a good start, it is not always enough to provide the desired effect of interconnected gameplay complexity. We also need to think about the quality of the Interfaces. As mentioned before, in the end, Interfaces are also largely a matter of perspective and our Quest system could also be used as an Interface system.

However, if anything can be an Interface, we can also just consider every single object an Interface and then go: "Yay, highly scalable game complexity!" So clearly, just applying this "view" by itself doesn't create interesting and complex gameplay dynamics. The core issue is that if we have a specific Interface for pretty much every interaction, then we cannot substitute them with each other, which decreases the Playthrough space for the player - and that is according to our last section what we want to prevent.

Let's look at a different but also very simple system and start with the High-Level Concept to practice thinking in terms of abstraction levels.

We consider a simple detection system. Enemies can detect us. Skills and Items may allow us to reduce their line of sight. Note that in SKA only Skills can do it in the current content but as we will see later, it would be trivial to add an item that could also interact with enemy line of sight! Whether that will happen is another question entirely.

I wanted to discuss this example as in a previous discussion our assistant writer Absurdity brought up the example of how Baldur's Gate 3 deals with size manipulation in order to enter holes or similar in order to progress and I thought about how that's on the higher level concept not too dissimilar of how line of sight can be manipulated in SKA.

This example demonstrates a usage of Interface structure that leads to a rather convoluted logic that doesn't scale with the addition of new content. Here we have the two ingame skills Shadowcloak I and II, as well as a fictional potion which also reduces line of sight by 1 unit. Enemy 1 can be bypassed by any configuration of sneak skills/items, while Enemy 2 requires 2 line of sight reductions or the more powerful Shadowcloak II. As we can see, we have quite a lot of lines because every object forms its own interface including even the combination of Shadowcloak I and Potion of Shroud!

One way to move to a more scalable design, is to generalize the gameplay interfaces by adding a new general Interface and turning the actual skills and items in the context of this design to non-Interfaces. If we bundle the differen ways of manipulating Enemy Line of Sight into a single, more general Interface, we get the High-Level Concept:

And for the Concrete Concept we would obtain:

Each object can now state how much Line of Sight it reduces and each Enemy can simply state how much Line of Sight is necessary for it to be bypassed. In-game the different Line of Sights would be achieved through enemy positioning and patrol behavior on the map.

And new items and skills that interact with this can be easily added without needing to interfere with the individual enemies - after all, the enemies no longer know about skills and items, they only know about Line of Sight. Another possibility would enemies that could debuff the player through a skill increasing Line of Sight! In that case, the arrow between Enemy and Line of Sight would become bidirectional.

Let's combine the above into an actionable take-away:

3. Common Interfaces can be combined by identifying a resource that is manipulated by all of them and then substituting the set of Interfaces with that resource.

Finally, keep in mind that Skills and Items were turned into non-Interfaces in this particular system. However, if we expand our view, they can become Interfaces again, connecting to a different set of subsystems. To conclude this section, let's expand the Concrete Concept with a Shop system for buying and selling items and a Trainer system for learning skills.

Conclusion

I'm not sure how useful this post is for the player-side as these are neither magical techniques to somehow procure fun-gameplay, nor are they really deep insights. What mostly happened here is a way to apply interface concepts from software engineering to gameplay design.