Dev Perspective (Mechanical vs Practical)

My last write up was really hard to write (I kept re-evaluating the way I was explaining that concept and thus rewriting that whole thing over and over. LoL! 🤣) but this one, I think, is going to be a little easier. It is something that is really important to bear in mind during game design imo.

This is what I call the "mechanical" vs the "practical" function within game design. You can also think of this as "back end" vs "front end" - in short, it's really about what's going on behind the scenes in the code vs what the player is seeing and perceiving.

We use the mechanical and practical as tools to communicate our intent to the player in various ways.

The problem is that we don't *always* want the player to know what's going on behind the scene (pay no attention to that man behind the curtain!) but sometimes, actually, we do want to communicate that intent - at least to a degree or in part to improve the player's experience.

And if that communication fails (we don't communicate well or don't communicate something we really should), it can create an unsatisfying player experience because they misunderstand what the game is trying to do.

The visible function isn't in alignment with the mechanical function and the player is not interpreting this positively.

So I wanted to talk a little about my thoughts behind mechanical vs practical.

Communication

First, I just want to note that when it comes to communication between the dev and player, we have multiple levels to sift through.

• Mechanical function (what the code is actually doing)
• Developer intent (what I intend to happen and what I intend the player to see and what I intend them to take from that)
• Visible/Practical function (what the player actually physically sees)
• Player Perception (what the player concludes from what they see)

We want these things to be in harmony and we have multiple ways to try to communicate and ensure there is harmony.

We can communicate...

Diegetically - diegesis means through the narrative and setting. When something is diegetic it means that it's happening in the world and that characters perceive. If I put a door knock sound effect in when someone knocks on a door. That SFX is diegetic; the character is aware of it because it's happening in the narrative.

Extra-Diegetically - You'll see this called non-diegetic, meta-diegetic, etc. It's just the opposite of diegesis. With games, this can be the UI for example - the UI doesn't exist in the game world and the characters aren't aware of it. If I add a bell chime SFX every time the player unlocks a glossary entry, that sound is extra-diegetic; the characters do not hear it and aren't aware of it. It's just for the player.

Mechanical Functionality

First, let me just define "Mechanical Function" a little more clearly - this is just how I see it of course, and is the language I use.

When I talk about the "mechanical" or "back end" functionality, I'm talking about the *actual* execution of the game code. IE what the code is doing behind the scenes.

Players can't usually see the mechanical functionality in absence of extra-diegetic game mechanics. Like a flowchart or an affinity meter.

Without these things, the player you don't see what's happening behind the scenes. You don't see the variables being set and the scores going up or the jump to a new branch. But it's happening.

Practical Function

Practical functionality is, for me, is the visible function. The sort of practical output that the player engages with. The front end experience. 

A choice may look like the above - behind the scenes.

But that's not what the player sees. They see the UI and they don't see the full function of the code.

When the player clicks a choice, they get some new text. They don't see the score happening (unless I show them), nor do they get a look at *how much* new content they're getting or *how much* content they are missing.

Or if there are additional mechanics at play that direct them to various branches or areas of the story.

Again, this is pretty normal and part of the way the game has to function. But again...

It's all about harmony...

These two things work in conjunction to create a smooth experience. 

Remember, the mechanical and the practical are used to communicate developer intent so the player's perception of the story and game are in alignment with what we want them to be.

When a player encounters this "front end" version of the game, it's like a veil that conceals what the game is actually doing. And players draw conclusions about what they think is going on behind the scenes.

What happens if the mechanical function is so concealed that the player has a misconception of what is happening and a misconception of what I intend them to experience?

This happens quite a lot. And sometimes it's not a big while other times it leads to a player completely misunderstanding the story structure or the purpose of the choice. And it can lead to people being dissatisfied with their experience.

One place I feel like this happens a lot is where choices and branching are concerned. Remember, this is the game play of visual novels so it's where a lot of the breakdown will naturally happen.

A really simple example of a situation where this might occur is when the player unlocks a hidden story branch (or misses unlocking one.) 

What is a hidden story branch? It's just branching that occurs outside a choice. A choice is an event that signals to the player a branch is occurring right there in that spot. But branching can occur anywhere, particularly if we are calling back to previous choice much earlier in the game.

From the front end experience, the player will have no way of knowing the story just branched. For them, it reads smoothly and cohesively so they don't see that branch happen.

Which is what we want but imagine if a story is made up of 90% hidden branches that you don't even know are happening. It would give the impression of a very linear story even though that isn't accurate.

Absent something like a flowchart, everything progresses as if the branch never happened. The visible functionality makes it seem like there was no branch. And that is the player's perception.

From a "mechanical" standpoint, there was a branch, though. 

If I intend the player to be excited about the branching and to want to explore the variations, I have to communicate that this happening somehow.

A Specific Example of Bad Communication

So this is an example from my first game where I feel I didn't communicate my intent well and some players came away from this moment feeling like I had set up a "fake" choice that didn't actually do anything.

In Changeling, my first game, the player encounters this choice. Of course, all they see is the UI - no scores or anything like that.

Now here is a visual of what is actually happening at this choice:

It's a lot. Kind of a lot is happening. You can see that if you choose "three", you die. Instantly.

If you choose seven, you continue the story.

But look at what happens with "four" - basically, there is a bit of a "saving roll" that happens behind the scene and if your "tragedy points" are low enough, you are saved from lots and lots of death.

But if your tragedy is too high, you encounter only bad this. Behind the scenes it looks like this:

The problem is the way this looks to the player.

In the story if you choose seven drops - you drink seven drops of a potion and the story continues on. If you choose four drops and pass the status check...right before you drink, another character signals to you that it's the wrong choice. 

You change your answer to seven...drink seven drops and the story continues.

But without knowing that there was a literal saving roll that prevented death, the player this just looks like a fake out choice where "four" was never actually an option because you were always going to change the answer to seven.

And that was the exact impression multiple players got.

For me, this was a learning experience. There's a lot going on mechanically with status checks and saving rolls and hidden branches...but the player sees none of that and just feels like their choice was invalidated.

Looking back, I can think of several ways I could have arranged this differently to communicate better. Or, really, a flowchart would have helped (I wanted to do them for Changeling but really didn't know how at the time.)

The point is that this is an example where a lot more was going on behind the scenes than what came across the player. And, in this case, it created a wrong (and negative) perception of that moment to the player because my *intent* was not fully communicated and therefore, player perception of what was happening...was wrong.

This sort of thing is really easy to do wrong. It's just one aspect of game design that we don't always get right.

Choices and branching is a lot of where this kind of thing happens. Very often players don't understand what the choices are doing or what they are meant to do. Or what the developers intends to have them do.

Conclusion

The point is that everything we encounter in visual novels has a mechanical function that is happening behind the scenes. Every choice you make is *doing something*.

That is not always going to be communicated to the player because part of the experience is not necessarily having a crystal clear view into the cogs and gears that make the game go. 

But there are times when developers might want to communicate more about what is happening because we don't want the player distracted by what they think the game is or isn't doing. Because leaving the player in the dark might be detrimental to their experience.

We want the mechanical and the practical to be in harmony with our intent and what the player perceives about it.

So one thing I try to ask myself is whether or not the practical outcome illustrates what I'm actually trying to achieve - or if the practical outcome is communicating the opposite of what I want.

This is often difficult because "perception" is a personal thing.

But it is just another aspect of game design.