Introductory semantics in game design and writing.

When you've been working both with game design and writing, you'll notice a pattern repeating itself. It's the "principle of procedural semantic introduction to unknown elements." A convoluted term (which I just made up) for a complex problem, but I'll cook it down to something digestible. At the core, it is about introducing an unknown element, through something that is already familiar to the user. Whether the unknown element is a strange new character in a written narrative, or a new mechanic in a game, the way they must be introduced - in the mind of the user - is actually the same.

And here's today's listen-while-reading:

What game mechanics and stories have in common, is that we must always begin with what is familiar. To understand is to perceive patterns, and introduction of unfamiliar elements, which root in the familiar, is a way to allow these patterns to emerge in the mind of the users. I'll begin with a theoretical example from my experience as a writer, to give you a better understanding:

Semantics in storytelling:

If we are to start with the familiar in a fictional place, we often start with the self, the narrator - our perspective into the story. W are self-aware by nature, so we will automatically relate to the perspective of the narrator, being our new "self" in the context of the story. I'll elaborate:

We typically have a main character whom we make understandable through their observations about the world around them, and their own emotional state in relation to what they think about. These are observations we can carry out on ourselves as well, so we quickly get a baseline to stand on in the narrative.

Next we must concern ourselves with the immediate environment, or other characters. Whether we prioritize one thing or the other (what character/part of the environment we start with), depends on what is the "least strange." Strange is really the keyword here, because it is a subjective measurement - and so it depends on the reader's initial worldview. If the environment is based on aesthetics that are commonly understood, it will be very easy to reference its visual and emotional (as observed by the narrator) foundation.

Obligatory breakup of article goes here.

When it comes to characters in fiction, we must evaluate them much in the same way: Observe which character is the closest to the classical image of "homo sapiens," then start with that. If you begin by describing the strangest characters (or the strangest of its attributes), your readers might get confused or misinterpret how they are supposed to feel about the character in question. This happens if you do not preface something weird with something relatable.

It is also very important to consider what you want to give the most weight in your story. If your environment is wildly different from anything you've seen before, and it plays a big role in your story, it is important that you introduce it as early as possible, when it is present for the first time (you might start someplace that isn't said environment). First impressions become our mental plateau, from which we must move out into the world.

Semantics in game design:

But how does all of this apply to games? The key differences between the two formats are: Games are visual, have audio and can be interacted with. However, they have one really important thing in common: The user!

Perception is everything, it is how we make sense of the world. Both in narrative writing and in video game design, we are handling the perception of the users - new information must be treated the same way, regardless of format.

If we are to translate that into something tangible, in relation to game design, it all comes down to interactions. A game mechanic is simply a way for the user to interact with the system in a certain way. Each time a new type of interaction comes into play, it is vital that we consider how it comes into play. There are a handful of steps that you need to consider, before you start throwing new mechanics at people, to prevent them from giving up in frustration:

This could be your users!

Does the game exist in an already well-established genre?

This is the first question we'll have to ask ourselves. If we aren't reinventing the wheel, we can always assume that the most basic interactions are already easily tangible to most of your users. We all know what "tower defense" implies at its base-level. You should still have some form of general introduction to this baseline - where to find the towers, how to build them etc. but breeze through these parts as fast as possible.

What mechanics are in play?

Here we'll begin to isolate what mechanics come into play. Remember what I said about mechanics being methods of interaction! It is very important that a new mechanic is introduced on its own, and that it is the mechanic most commonly used, which you introduce first. Every time you introduce a new mechanic, it should always be an isolated instance at first. 

What does the user already know?

To round that back into storytelling, the most optimal way you can introduce new mechanics, is to make the new mechanic play off of an old one. Consider what the user already knows, through what you've told them. Once you are aware of what they know, use that knowledge to understand what new mechanic is the closest related to the user's current understanding, to find out what they will have an easiest time understanding next. Note that this approach should be used carefully, it works best in very complex systems (where everything is introduced very rapidly), but it might not be fun to sit through in simpler environments!

Does any of your mechanics synergize?

Sometimes you have mechanics that synergize, interact with one another in an emergent fashion. If you have two mechanics that work on their own, but also can dynamically work with each other, you have three interactions - functionally, there are actually three mechanics. You will also have to teach about this interaction in an isolated environment, preferably by extension of the introduction of the other, new mechanic. So first you'll introduce the new mechanic - and then right after, you'll introduce how it synergizes with an already known mechanic.

How to even do this in real life:

After this mouthful the question beckons: How do I make sure my design adheres to these principles, during production?

I personally like to make a big map of all of the system's mechanics - every interaction that exists - and make arrows from one element to another, that each represents a semantic relation, which these two elements have in common. Do it as early as possible to keep it simple. This map will help you understand what mechanics make up the foundation of possible interactions within your system, which are the ones you should prioritize first.

But what's the use of this method?

If you map semantic relations in your system, you can begin to design new mechanics to deliberately exhibit more relations to current elements, than you would perhaps otherwise have considered. The map will allow you to see how the minds of the users unfold into your system. This, in turn, will allow you to gauge the best possible time to introduce something new, based on the current knowledge of the user.

Think of each element in the map as an "understood mechanic." When a mechanic is understood, all of its arrows pointing out to other mechanics, are effectively "activated" or "lit up." The more arrows that point to a yet-unknown mechanic, the easier it will be for the user to understand this mechanic, when you introduce it.

Leveraging this knowledge can allow you to build very complex systems, which is especially prevalent in simulators and advanced strategic games. Designing for these types of products can be a big challenge, but using this method should really help you get a long way.