Gamable Stories and Some Tea

I wanted to make a tiny mini example of it to accompany this article, but I didn't and I won't anymore. Whatever. If I can't find time to do that I won't ever release this article, so let's do without it.

Some of you might have read my previous article on this subject. It's about a heuristic videogame AI architecture I was designing to solve a specific problem in a specific project, but which I later identified as an interesting structural pattern that could be used to do more than what I initially planned it to do. Here I'll be going deeper into those while also explaining a new, clean and evolved architecture I created out of that first. It's not the most efficient code-wise, but its meant to increase performance of the work done by humans instead.

Systems

In the “hiding in the room” example from the first article I talked about how it was only later, after looking into the implementation details of the initial concept, that I came to notice that I was using a rather common and fairly simple pattern present in many Complex Systems to generate results of the kind we perceive as “complex behavior”.

A good and easily accessible introductory video on the subject of Complex System is this one from the University of Bristol, called "Ants, Bees and Brains". It can be found on Youtube.

For here on, whenever I use the term System – uppercase like this – I mean it in the sense of a Complex System as the Virtuality (mechanics, simulation of how Reality works or representation of Reality in function) inside the Videogame (entertainment simulation/software or ES) world and when I say Experience I mean as the holistic combination of Virtuality, Reality (where the human Players exist) and Fiction (aesthetics, context, pre-determined plot, depiction of what reality looks like or representation of Reality in form) into the complete Complex System that combines Player, Mechanics, Dynamics and Aesthetics.

If I say "system" – lowercase – I probably mean "architecture" or "scheme" or "heuristic" or "method" in a development/design/programming sense.

So, let's get going. I trimmed a lot of my initial sketch for this article so things can seem abrupt at times but bear with me that it'll all tie in the end.

Action and Reaction

After revisiting the system (architecture) many times over for a long while, I eventually started simplifying unnecessary distinctions and made everything much cleaner (for myself and, hopefully, for others when I try to explain it), some things are seen from a different point of view and have different, more practical and straight-forward names now than they had then.

The core concept of the updated version of the system (and the pattern it uses) is the “Actions and Reactions” axiom (which in my original code implementation of the heuristic are still called “Tasks”). Everything in this system is based on the concept of Action and Reaction.

"Action. Reaction. Cause and Effect." -Matrix Reloaded

Tasks, as I first called them in my initial version, are now Actions, and Actions are chosen for execution by an Utility-Based Decision system (that part haven't changed, but I'll get into the subject of Computations and Decisions soon). Each Task has it own internal rules (modularity is key) about how it works, what it demands from the situation and from the Agent in form of Resources to be executed (environmental conditions, plot conditions and narrative structure, physical body, intellectual capacity, knowledge, equipment, emotional willingness, ammunition/materials, etc). When the Utility-Based Decision wants to evaluate what Tasks should be performed next, if any, it asks the Tasks' classes to calculate their own priorities and then picks from the highest rated combination (it can multitask, like "run and reload and talk" or "climb and talk" at the same time, or do only one thing that used all resources, such as "swim underwater").

That allows for a good deal of modularity and flexibility as to how each Task works and how they're prioritized. Any new Task can have it's own computations and rules, based on whatever systemic or arbitrary means injected by the designer. This also means a "scripted event" can be created and forced by answering with an arbitrarily high priority value, which might be absolute or just very strong, still allowing for extreme life-or-death situations to be able to overcome it in importance, or use any other kind of computation. There's room for all.

When you create, say, a procedural world generator, there will usually be a need for hand-made "landmarks" that serve to break the mold pattern of "repetitive randomness" so the world looks more unique at certain spots. So, a "scripted event" is exactly that: a "handmade landmark" amidst the sea of procedurally generated Events. In the sense I mean them here, as part of the system (and also the System) I'm talking about, a "scripted event" is more like "plot chunk" or "scripted Event chain". So the "event" in "scripted event" does not mean the same as uppercase Event, but a "molecule" made of multiple Events, where each event is an "atom", which I'll explain better later.

As the architecture started with the idea of Tasks being given to Agents by the world, by the designer, by the plot and also by the Player's actions, it didn't take long until each task Tasks began to have lists of other follow-up Tasks it spawns around once completed or failed, for the Agents performing the Task itself and for other Agents involved in the situation in various direct and indirect ways, as Targets, as Observers/Witnesses or as those that are told the Events later on.

The Tasks that come linked as a follow-up result of other Tasks is what I called in my new updated version of the system, as Reactions.

Not much have changed about how any of it works, nor how the code is implemented (maybe it should be made to better reflect this new understanding of the system), but the general interpretation of it from outside the code did change, making it easier to reason with and to communicate ideas with the team. After all a Task is too vague on one side and too rigid on the other (which makes sense when talking about Agents but doesn't really mean much in a Systems context), but a "Reaction" carries much more contextual information as to what purpose it's fulfilling in the System, while not being filtered by the idea of something being necessarily done by an Agent, as calling something a "Task" does.

Both Actions and Reaction are the same thing, the difference in terms is only a relative one. It makes no difference in the code but it helps with reasoning about the design.

To calculate their priorities, the Tasks can access information about the Agent, about the environment and about other data pertinent to the situation in order to inform the computation of how important they are for that specific Agent. That information can represent many things about the Agent: his alert state, his health level, his fatigue, his mood, his optimism or lack thereof, his political views, etc. Anything the System requires to function, and anything that defines an Agent can be quantified as Data and can go into the equation.

That’s where the modularity of the system lies: Tasks can take care of themselves. New Tasks can be created without affecting the Agent and without directly affecting how other Tasks work. But, of course, as every Task is both an Action in itself and a Reaction to a previous Action, the addition of a new one to the System will consequentially create new chains and connections, making for interesting situations and, on the design side, leading to revisions of the lists of Reactions each Action should lead to.

So far, here’s how the system of Actions and Reactions works for Agents, with the Utility-Based Decision being the Computation method I choose to use for them:

1) The Decision system rates and picks one Task from the Agent’s task list (“to-do list”), using the Agent’s Data to inform the decision;

2) The Task is executed (Action);

3) The Action then creates new Tasks (possible Reactions) for the Agents involved directly or indirectly in the Event;

4) The Decision system of each Agent rates and picks a new Task from the updated task list, among which the newly created Tasks (possible Reactions) are located;

5) The (Re)Action is executed and creates new Tasks and the cycle keeps on repeating.

Take a while to consider the similarities of that System to one composed of Cellular Automata. That's exactly what it's all about. Every System works with States and Rules for how that State updates, which's exactly like Cellular Automata, which's exactly like Games, which are exactly like everything else.

From Artificial Intelligence to Artificial Emotions

If you're acquainted with the concept of AI for Videogames, you're already aware that it has less to do with Computational Intelligence, Machine Learning and Magic and more to do with, as almost everything else when it comes to Videogames, "illusionism".

No, that's a very lousy and boring explanation.

So, instead, I asked an actual specialist on the subject, Dave Mark from Intrinsic Algorithm, for something better:

"Game AI is what allows designers to express themselves through the characters – showing the vision of who/what that char is. Therefore, the best AI is neither rigidly scripted nor random. It feels like an autonomous character but one that serves ends."

– Dave Mark 

Notice that I mentioned above that "anything the System requires can be quantified into Data". That same sentence still carries the same local meaning if the term "System" is swapped by "Game" or, better yet, "Story".

“Action is the pulse of any good story, but the character is the heart. If the action has no consequence to the character, the story loses heart.”

– Linda Yezak

The most interesting groups of Data about the Agents for me since I implemented that system is their Personality, Mood and Relationship components. If you look again and the skeleton I used in the previous article, you'll be able to spot those component groups in there:

When I made this picture, the Relationships data was hidden inside the Personality component, but I later decided to split them apart.

Many Tasks will consider those key Data components to inform the calculation of their priorities for the Agent. It's rather simple math in most cases, you multiply stuff and that's it. An example would be the following, which's very simplified and not exactly how I doing it in my own code, but in the end that's basically what it comes down to:

ScaredMood += Weight * Health * Insecurity * Weight * Emotional_Volatility * Weight

You can model the Personality Traits of your Personality component in any way the experience you're designing requires. For our horror project we're using a combination of general Trait Theories like Big-Five and 16PF. But remember that simplicity is always important. First because it helps your design and second because the simpler it is, the more charicatural your Characters can be, which makes it easier for player to get to "know" them. But also, increasing the precision of the model leads to more nuanced Personalities, which can be also good on it's own.

From a technical standpoint, Moods are analogous to "multiple personalities" in the sense that they have different values for each personality Trait than what's considered the "normal" personality of the Character. For example, a given Character could have one value for acting rationally versus emotionally, or for acting egoistically versus being altruist, and then, once deep into the Scared_Mood, have those values considerably shifted from what his/her normal behavior is. A good balance can create a believable or even dark Character, useful for many genres, while other combinations of values can create a comical Character like, say, one that always acts fearless but is the first to freak out when real danger appears.

These variables are exposed for the Designer to define on a per-case basis, how much it should affect the Characters involved. Let's use the example of a Red Dragon appearing, his presence causes everybody to get scared, so the Designer can tweak the weights accordingly, and even have something in the Dragon's class to update those values based on other variables. Similarly, an inspiring Cleric or Paladin would raise other Character's morale with his presence.

So, if the Data of the Characters define their Actions, and that Data can quantify their Personality, their Mood and their Relationships, what it means is that the Personality, the Mood and the Relationships of the Characters will affect their Emotions which, in turn, will define their behavior (which is made of their Actions).

I hope it all makes sense.

That's how the System works, which'll also how it supposed works in Reality mostly (not with the same math formulas, obviously). And if that's how it mostly works in Reality, that's how it's presented in Fiction, as Fiction represents Reality in Form. Virtuality (or Virtualization), which means Virtual Systems (the canvas where Games are painted), represents Reality in Form and in Function. Which's to say, if we can simulate how things in Reality work, we can also simulate how things in Fiction work, as Fiction is made to look like Reality.

Systems, Games and Stories

A Character, as I’m using the term here, means two things. First, from a technical programming point of view, it’s an Agent that has components for Personality, Mood, Relationship and Knowledge Data. Second, from a literary point of view, it’s simply a character, person or otherwise, of a Story.

Hereafter I’ll make no distinction between both nor will I differentiate what I’m talking about when I use the word Character. It’s an Agent from the System and a Character from the Story. Both in one. Both at once. No distinction.



I also consider here that everything is a System, any sequence of Events within the possibilities of that System is a Story, and the engagement of an Agent, internal or external to the System, in the biased manipulation of Events towards a desired outcome – a desired path or Event in the System – is a Game. If an Agent, internal or external, is poking the System to see what happens but isn't biased to any specific outcome, the System is acting as a Toy. If there's a bias, the System is acting as a Game. If a supposed Agent is not manipulating or interfering, it's not an Agent but an Observer instead.



Here's where the cellular automata example pops up again.

The key here is that, the case of the Game, “manipulation” does not equal “absolute control”. If there's absolute control (1.0), there are no forces impeding the desired outcome (0.0), so it can't be a Game when a different outcome is not possible. The same is true if there's only one outcome, or if for any other reason there's no control (0.0), which makes external elements to only be Observers but not Agents.

If a person has absolute control of the decisions that dictate which Events happen – what Reaction follows each Action –, that person is telling a Story, not gaming a System. It's not the same to state that there is no System in there, as most stories follow some Rules of plausibility and consistence within the worlds they are told, the the author of the Story might as well comply to some of those Rules in order to come up with a Story at least consistent, believable and acceptable for the audience.

While the acts of telling Stories and playing Games can be quite similar at times despite differences in how hard or soft the Rules of the System can be for which, the act of reading a Story, however, is a quite different experience from any of those, and mostly consists of combinations of amusement, curiosity and impotent hope towards the System's outcomes, accompanied by the suspension-of-disbelief necessary to ignore the fact that nothing different could have happened after the author has already decided on what chains of Events will take place. The Observer can, however, theorize on what could have been done differently in order to change the outcomes, even if actually doing so is not possible after the fact (of the author writing them as such).

In truth, something different could have "happened" (in the Fictional sense of the word), but the decision model used to decide what Effects and what Reactions will take place has already been applied and defined by the writer in an earlier, yet open State of the System.

Consider a movie. Had the author accounted for different variables (Data) and worked with a different end for the Story (desired Outcome, or simply put, Goal) in mind, things could have "happened" differently. The roads between Reality (the Author and the Audience), Virtuality (ideas and knowledge inside the Writer's mind and interpretations in the Audience's mind) and Fiction (the chains of Events that take place) have long been turned 1-way, meaning that the Fiction can come out into Reality (by means of a Real audience reading it), but cannot be affected by them anymore (the Real audience can't change the Fiction). Or at least shouldn't, but rules can be broken sometimes. In the case of Videogames, the computer-assisted Virtuality can work as a bridge between Reality (Players) and Fiction (the Story), allowing the former to still manipulate the later. That's the biggest strength of Entertainment Software.

This is also a random hint I'll drop here: if you want to play one really awesome Game with one of the deepest Systems you'll ever see: write a novel!

No sarcasm here, I'm being serious. It's also one very Hardcore™ experience short of parachuting in the deep jungle, desert, freezing mountain or open sea with only a bottle of water and a knife and attempt to find your way back to, well, somewhere.

“Writing a novel is a terrible experience, during which the hair often falls out and the teeth decay. I'm always irritated by people who imply that writing fiction is an escape from reality. It is a plunge into reality and it's very shocking to the system.”

– Flannery O'Connor

But dictating Events in not the only way to have fun with a System. There are important act possible for an internal or external Agent when it comes to Systems: Toying and Gaming. Apart from differences in cognitive engagement and the ability to affect Outcomes, the core difference between Toying and Gaming versus Observing is that, in the first two cases, different Outcomes are actually possible.

If anyone here saw me saying "gameplay or didn't happen", what I mean is that, for something to "have happened" it requires the possibility of "not happening" to begin with. This is a personal view and maybe not a very important thing to consider, but thinking this way informs my Game Design decisions and leads me to arrive at the kind of stuff I'm talking about in this article.

To differentiate those kinds of Events and possibilities, I call written Stories (arbitrarily pre-defined chains of Events) by the term Fiction, toy-able and gamable Systems by the term Virtuality, and us, real people that manipulate or interact with those Virtual Systems by the term of Reality.

Those are all different layers of the same thing. Unless a Game is entirely abstract, there will be a connection to Fiction in it in one form or another. Also, for any given System to become a Game, or even a Toy, it needs Players to interact with it, which means there can be no Game that's no connected to Reality.

The result of it all is that there will always be a part of the System that the Game Designer has no control over, which's the Reality layer. And it's fine not to control everything, especially people. Actually, it's totally not fine to want to control people. Games are unpredictable by their nature. It's not a bug, it's a feature!

A Game Designer's job is not only to design the System and create or not Goals to turn it into a Game, nor simply dictate what Events make up the Fiction layer and seal it away from interference of forces from the layers of Virtuality or Reality, but to consider that, the System created in Virtuality is only one part of an yet bigger System, composed of things not entirely inside his control.

Why does it matter? Well, first, because you cannot have a Game made out of Fiction alone, and second, because the Player is an Agent you cannot program, and a set of preexisting Game-Mechanics you cannot tweak nor entirely predict, but which your Game has to take into consideration in order to work in the end. After all, it cannot be a Game without a Player.

Being an Agent, the Player can also execute Actions, and to allow interesting manipulation of the System, those Actions have to cause Reactions. The set of Actions you give your Player will define in which ways he/she can manipulate your System's Outcomes, which defines in which ways she can manipulate your Story.

Other Agents, however, are under control of the Designer. That's not to say that the only form of control is absolute control, but to control the System that rules the Agent is to Control the Agent. And as I have stated before: an Agent and a Character are the same thing.

What I mean to get to here is that controlling the System and controlling the Story are also the same thing. The Agents control the Story, and we control the Agents. The cool part is that the definition of a Gamable Story is that the Player can also control the Story and the Characters.

An interesting thing here is that you can also add storytelling theory and genre conventions into the mix. Your ScaredMood formula can pull and extra variable from a PlotMood singleton in which you can draw a curve that says everyone is more scared and irrational the closer the story comes to the end, or whatever your story needs. The same can go directly into the Tasks' priority calculations, making one Action more likely to happen in the first act, another in the second, another in the third, then lower it after it happens so it doesn't repeat often, or basically anything else that crosses your mind.

This is a soft force to direct the story. You don't have to make forced scripted events and cutscenes and manually cause them to happen. You can simply develop a funnel that increases the likelihood of something you want to happen at some point, to happen. Other tool is, as I mentioned in the previous article, is to not write scenes defining everything too strictly. You don't have to define each character is bitten by a zombie, and who argues about killing him or letting him leave. All these roles can be variables instead of constants, and as soon as somebody is bitten, the Action of the zombie bitting them spawns the collective scene that assigns the roles around based on which Characters personalities and moods fit them best at the precise moment. This is an example of a dynamic "landmark event" to spice up the procedural stuff.

Players, on the other hand, can manipulate the System by performing Actions that they believe will ultimately lead to their desired Outcomes. In other words, they play a Game.

Character Development

A very important thing to consider regarding the Mood aspect of a Character is the implicit characteristic that it changes.

The very reason why the our system was designed and programmed with a Mood component is that I didn't want to only have a static Personality group of Data for a Character’s behavior forever. I also didn't want Moods to be universally equal between Characters and, because of that, each Character’s version of the same Mood has different characteristics.

Follow me here. Some people might be more focused and smart when they’re nervous and the situation pushes their limits, while others might not handle some kinds of emotional pressure well and screw things up should them lose their temper. Similarly, some people might become more social and sharing when they’re sad, while others prefer to be left alone until they get over what’s bothering them, and others yet will just attempt to pretend they’re happy and everything is fine for the same of looking good.

Now, the emotional reaction of a person for a given situation is also affected by whom is present. One might, for example, not want to show emotional weakness in public or in front of a rival. Some people might also have an aura of hope and will that spread to others, motivating everyone and so on. For that kind of effect, Tasks also use Data from the Character’s Relationship components and from Group Dynamics objects when calculating their priorities.

But Moods aren’t necessarily the only changes that can happen to a Character. Sometimes people change too, not only temporarily but permanently, therefore we also want to definitely alter a Character’s Personality when important Events occurs. Also, for any basic system with social simulation, we also want to change how Characters like each other whenever something happens.

Moods change. Personalities change. Characters change. Relationships change. People change.

Change is Luv! Change is Lyf!

Now, this is what I arrived at when I was trying to figure out how to explain this system in the article I was planning to write. This, in my opinion, is yet more important than the system I’ve just talked about, and the reason is that, if I had this before, it wouldn't have been so hard to create that system in the first place. It would have been a far, far simpler and straightforward task. and aren't we trying to make complex tasks simpler?

Yes, Artificial Intelligence and Artificial Personality are cool stuff.

Yes, any kind of small step in the direction of Gamable Stories, which is what I hope our system does, is important.

But this is what I think is the most important, and this is what made me decide to actually write this article down. I believe it’s meant to be shared.

I mentioned earlier that I, once again, where doing something as a tailored solution for one specific problem (like in the previous article with the “intelligent world” system) only to later come to the acknowledgement that I was making uninformed use something more basic with so much more potential if further explored. That’s how I reached this point with a system that was initially meant only for some cool stealth AI, by starting with a specific, concrete solution and finding what abstraction it was made of, to later apply that in the solutions of other problems.

Concretes are knowledge. Abstractions are intelligence. Let's go abstract:

All those Components of the architecture, the Personality, Mood, Relationships... are Data. That’s why I’ve been using the term “Data” all over the article.

Data changes.

It’s rather simple and obvious of course. Nothing new to see here. Yes, there isn’t.

The things is, I didn’t see it like that at first. When I re-organized and cleaned the system I went on to rename some stuff and separated the concept of Tasks for what Actions they represent and what Data changes they bring. Initially I had them all inside the monolithical “Task” concept.

In the re-design, I separated Actions from the Data changes, which I now had isolated enough to give them a name: Effects. By making the distinction and splitting the components, I was now able to re-structure some pillars of the system.

Remember when I said that “Characters” are the same thing from a programming and from a literary point of view? It’s the same thing here again. What I was calling Effects is, plain and simple, changes in Data.

For every Action, now, there are Reactions and Effects.So I drew the new model of the system:



Reactions, as previously seen, are Actions that happen in response to another Action.

Effects, as I has them in mind, are the changes in Mood, Relationships and Personality. It’s when a Character hits another (ha! Videogame violence!), their Relationship and their Moods are updated (changes in Data).

At first, “Effects” sounded like a pretty good part of my my specific solution for this specific design problem – one of creating Gameable Stories –, better than what I had before as it increases modularity allowing for the creation of more combinations with less effort on the programming side. And that was my line of thought:

“Every Action has a Reaction. Every Reaction is also an Action, which causes another Reaction. Yes, that’s what the system was about when I first designed and implemented it. Good thing I still get it.”

“Actions and Reactions form a chain. An Action is also an Event. A chain of Actions and Reactions is a also chain of Events. And a chain of Events is a Story. Every Action has more than one possible Reaction. In a written Story, the Writer decides on a specific Reaction, and a specific sequence of Events. In a Game, a Player decides on a specific Reaction, and the system decides on the next Reaction, and a chain of Events forms itself naturally. Much like in Reality. A “Conversation” as Chris Crawford calls it.”

“Gameable Story! Awesome!”

“Oh, wait. Every Action also has an Effect. Of course! If something bad happens to John, he gets sad. If Mary does something bad to John, John gets mad at Mary. They might not do anything about it initially, but those things affect other Actions later on. Effects!”

“Every Action has many possible Reactions and many possible Effects!”

“Oh, wait again... Sometimes Actions happen as a Reaction to an Effect to, in an indirect form to one or many other Actions. If Mary gets too nervous as Effects of multiple Actions, and she happens to have a heart problem, Mary might have a heart attack. What do I call it? Well, if it happens as a result to a change, it must be a Trigger, obviously. That’s it: Trigger.”

“Alright! Actions cause Reactions and Effects. Actions can be caused by Actions or Triggers.”

And so, ignoring the Agent, the Data and the Utility-Based Decision, I drew the skeleton of any single Action (or Event) in it’s most basic form, so I could later, use it to make a huge daunting list of Actions and their repercussions to feed the system with the necessary content to each story our game wants to “tell”, as long as many generic stuff that might apply to many settings and themes:



“It really can’t get any more simpler than this!”, I though.

Then when I first wanted to write an article to talk about it, I tried to find a nice, cool example of some dramatic emotional scene from a movie or something to explain how it would work if it was running in our system. Much like I initially planned to remake scenes from something to create a “tech demo”. Also because, as part of my initial plan, I wanted to schematize scenes from movies and TV series as a form of finding out interesting Actions and Reactions, and to better develop the tricks that help redirecting the Plot and Scripted Scenes to happen. To repeat the analogy from the first article (or was it in a comment?): “a fully procedural plot is as boring as a fully procedural map, you need to scatter around some handmade landmarks to spice up the landscape.”

The Patterns

Somehow, at some point, I came up with this:



I bet you thought the “video-game violence” joke was without a reason!

The most important part of this example, mind you, is that none of the Artificial Personality content is there. The only Data being considered are Health and Ammo, and the only Effects are TakeDamage(Target) and UseAmmo(Self). The main Action being modelled is Shoot(), and its only possible direct Reactions inside that tiny system are Reload(Self), TakeCover(Target) and ShootBack(Target). The only Triggers are If(Health==0) and If(Ammo==0), with StopShooting() and Die() being indirect Reactions related to them.

Putting a human Player in place of the Agent and giving her the desired Outcome (Goal) of killing the Target – making him perform the Die() Action – will (obviously for the human mind) attempt to do so by making use of the Shoot() Action, since it’s a given verb accessible by the game’s input methods. The player, without completely conscious knowledge of the inner workings of the System, will take a course of action that at some point leads to the desired outcome, be it directly (through an Action-Reaction path) or indirectly (through an Action-Effect-Trigger-Reaction path).

Looking at it from a Videogame AI perspective, drawn as a map it seems like something that can be achieved by using a Planner or maybe even simple path-finding algorithm within that System ("I'm here and I want to get here, this is the path"). Looking at it from a Ludology perspective, it's the Player gaming the System, i.e. “playing the Game”. From a Narratology perspective, it's a Character doing something that seems to make sense.

As it must have already caught your attention, this time I referenced the Actions, Effects and Events of the example system using generic programming syntax(). There’s a very important reason for that.

Some of the readers, at this point, must have already come to the conclusion that everything this scheme is modelling is perfectly representable by UML, and UML already exists, so there's nothing new here. That’s precisely the reason why I choose this specific “shooter-game” example instead of anything else. That it looks like nothing beyond a simple UML scheme, and that there’s no difficulty to represent that same, simplistic system in UML form.

To put everyone in the obvious perspective I’m trying to highlight here: that system has nothing we haven’t already done multiple times and nothing we are not capable of doing pretty much effortlessly using programming logic. There’s nothing new there. There’s no secret or dark magic. We’ve been doing that more many, many years already.

Now, for your consideration:



Needless to say. This is one very simple and very small Story. Maybe also a bad Story.

Small, because it’s made of only two Events directly connected: one Action and one direct Reaction. Simple, because there are no Effects, no Data and no Decisions. It's just Shot()-leads-to-Die() and nothing in between. Bad, because none of the “Characters” of that Story, namely the Agent and the Target, fit the systemic definition of Character I previously assumed, and because the requirements of said definition (Personality, Mood, Relationships and Knowledge) can’t be approximated by Audience Interpretation. It doesn't explain why the Agent shot the Target, because there's no previous Action before that to give us a clue. There's no Mood. If only the story said the Agent was furious, or even cold-blooded, or the Target was scared, or maybe laughing, the reader could use that limited information to imagine something more about the situation, and that would have been a better Story than it’s now.

The reason that Story is as such, is because that’s a very simple and small System, meant to be used as an example. A bigger System will generate a bigger Stories, and a bigger number of distinct ones. A better System will generate better Stories.

The TEA Notation

If you read the previous article, you might have noticed the the original purpose of this system was to simulate physical conflict, like shooting, running to cover, searching a room, grabbing, searching for a medkit. Clearly, the system is meant for simulating Actions and Reactions in a very literal sense of the words. But somehow I had been so lured by my own “Gamable Story” solution that I missed it and never made the connection, even if the system was initially meant for that.

Remembering it now led me to finally notice something that was right in front of me, right at the core of what I was building. I realized that, this “Actions and Reactions” system could let us do lots of things we have already been doing for a really long time!



And so, to simplify the whole thing further and make it easier to draw using pen and paper (for when that awesome new idea comes to you while you’re in the shower), I simplified the terms into single letters – Action (signifying any Event) becomes A, Effect (signifying any change in Data) becomes E, and Trigger becomes T. Also, for a readability purposes, I swapped the spots of Actions and Triggers, and rotated the model in a more euclidean-friendly format. This is the result:



Earlier (heh, last year) I Tweeted about making a Game Design molecule of Space Invaders. This is basically what the Tweet consisted of:

Picked bad colors then... Black, Blue and Red are much better and avoid colorblind issues.

Now, this isn't the exact way to represent Space Invaders using the TEA notation (if I could call it a thing), and was mostly meant as a fun teaser for this article. It is, however, a "Flat Map" of the core game using the so-so notation. It’s a representation of the entire flow of possibilities laid together as a Player would have it in his mind (and as an A.I. Planner would possibly have use for, this is one for the A.I. specialists out there, which I insist I am not).

The ideal initial documentation of any game’s system in TEA Notation would be to define each “Atom” of the system in separate, each at the layer it’s meant to work, demonstrating only the direct relationships with other Triggers, Effects, Actions and Reactions.

This is exactly what I was initially using to document the Actions, Reactions and Effects contents for my initial system. The difference is that by simplifying and standardizing the concept as a “notation” helps its use in anything else related to Videogame systems, even if the underlying programming of the Videogame doesn’t perfectly reflect the notation in the form of components, or in other words, if the UML of the system and the TEA notation of the system don’t look much alike.

Still using to the Space invaders example, this would be a better representation of the game's systems (excluding some minor stuff I omitted for simplification, like reactions to input, basic player movement and scoring):

The practical purposes of using this are few but interesting ones:

a) In it's Flat Map form, it helps visualizing the entire System together, with possible usage for game balance and QA, some improvements and tools. Visualization of values, heatmaps, flow indicators... everything could find some useful application.

b) It can be used by Designers without technical knowledge of programming express and document core ideas in a clear manner for programmers and other team members to implement, without diving into the technical aspects of the system. Details still have to be explained by other means, such as which speed the bullets in space invades should travel.

c) The inherent distinction between Triggers, Effects and Actions helps sustaining a clear programming architecture that reflects the game’s structure, even if in the code itself they’re only method calls and not exactly components, or if the code doesn’t differentiate between Data components and functionality components. The notation not only does differentiate those, but also categorize components for what purpose they fulfill in the system.

c) Its modular characteristic opens paths for the the creation of default solutions for game mechanics, allowing designers to re-use patterns in order to speed-up design and focus on the important and distinct characteristics of the specific game. Who knows, maybe in the future it'll be much simpler to do stuff like this.

d) Its modular characteristic also open paths for the creation of default technical implementations of game mechanics, maybe in a node-based architecture, a specific engine or middleware, or an open-source library of Actions. This would put a huge amount of content in the system, which means a huge amount of possibilities from AI Characters.

But, going back to the all-important subject at beginning of this article, the most important thing right now, is that we can model Systems, we can model Games, and we can model Stories, adding the conclusion here at the end that, we can do all those things using the same means, and we already have them. We always had.

We can model stuff in a Flow-Chart format. It’s not the notation itself that’s the key here, not the orientation of the elements even though it’s meant to help readability, not the memory-friendly “TEA” name, but the core Atom that forms the base of this notation: Actions, Reactions, Triggers and Effects. And the "molecules" of scripted events we can inject with them.

If, once tested and tried by enough people with enough different design problems, it turns out as I hope to be capable of modelling virtually any game system, which's what I hope for, what it means is that if you can represent something in that format, you can design and implement a game out of it. And if you can represent anything in that format, you can make a game out of anything.

I still defend that yes, if we keep searching for a way we can make Gamable Stories. Not only that: maybe we can make them almost in the same way we can make a dude Shoot() another dude.

RPG Solo – A Very Cool "Genre" To Play

A few months ago I found this website called RPG Solo. It's basically a virtual GM with a general purpose open system you can use to play RPGs by yourself, using the hints and tips from the GM to guide your adventures.

Instead of playing an actual RPG adventure as we know it, and put myself as a PC, I experimented with using it as an assistance for writing Fiction. When you don't know where to start or what to write about because there's just too much freedom, restrictions are probably the solution you're looking for.

This is a short story I wrote using it just to test the idea, and also to support another article I'm writing now that will link here. The following excerpt is from said article:

You don't have to follow all their rules and actually put yourself in the position of a PC, but simple write around and dictate (yep) NPCs Actions, Events and Effects until you lose the next idea, where you can use the randomization to inspire you going forward, or when you simply decide to leave an outcome to be decided by a dice roll, simply to make things more interesting.

The blue text are outputs from the virtual GM, everything else is my textual interpretation and adaptation of the ideas. (Please don't mind the "quality" of the Story, I'm not a Writer.)

I recommend going to the RPG Solo website and trying it for yourself. It's very fun!

---

Sidereal Impasse

Bio-scanner.
Oppose.
Below average map.
Cheap alien artifact.
NPC negative.
Med-pack.

The setting is occupied gate involving high quality anti-gravity generator and burning observatory. Your quest is to return stolen technology to the swarm staging area. Trying to stop you is the demonic assassin skilled in planetary cartography. You are currently at the industrial research station.

— "Here we are..."

— "Shut up, monster!" screams Mrs. Ferreira. The ferocious words come out inevitably punctuated by the lack of oxygen amidst the vapor leaking from the Engine's pipes, and from her swollen vocal cords. She has been screaming for hours.

Screaming with her crew, not with the woman in front of her. "If it's even a woman!" she thinks. A quick reading with the Bio-Scanner would be able to answer the pertaining question in the back of her mind.

But she doesn't have much time to think about that or to go looking for the Bio-Scanner in the tools room. The young Andreas' arm is bleeding, pumping out dark red blood. Mrs. Ferreira is an engineer, not a medic, but she can tell that the color and pressure of that blood means no good.

She needs the Med-Pack, not the Bio-Scanner. Not yet.

As a matter of fact, the Bio-Scanner isn't even the second thing she needs. The first engine is collapsing, leaking vapor from the cooling systems everywhere. The main control system of the ship should be shutting the engine off to prevent overload. Should, but isn't.

The Universal Orientation System of the biggest Industrial Research Station of the human colonies, commonly called by the crew as "The Map", is right now, for lack of a more suitable word, lost. "The Map" is lost. The most advanced Orientation System ever put in a non-military space-station, completely useless.

— "Such a bitter irony, isn't it?" commented young Andreas earlier that day, before the woman the emergency crew rescued from an escape-pod two days later teared his arm open with that weird cutting artifact she's now pointing at Mrs. Ferreira.

Andreas is unconscious, bleeding to death, and the first engine is about to explode any moment now, yet the Bio-Scanner is still there, in Mrs. Ferreira's mind. What in the word is this woman?

— "Yes, here we are. We're all on the same boat!" replies Mrs. Ferreira in a serious tone, trying to talk the woman-shaped thing into some logic that could, only maybe, open up some advantageous possibility later. "Later, as if I had time for that...", her engineer brain still trying to make long-term decisions even in an urgent situation like this one.

— "Ship!" the woman replies with an unsettling semblance of tranquility, "It's a ship, not a boat. As an Engineer, you should be able to tell the difference."

Mrs. Ferreira presses her jaw in disconcert. The monster is trying to get into her mind.

— "Do you think that's a joke? If the first engine explodes, we all die!" she shouts promptly trying to disguise her anger into a semblance and tone of pondered seriousness. "I won't lose focus that easily if that's what you're thinking!" she almost says out loud, but still manages to separate her thoughts from her words, "Not at this crucial moment!".

— "If you don't let me pass and stabilize him, I cannot go back to the engine to stabilize it."

Mrs. Ferreira keeps talking while trying to ignore her fears that this demon cannot be reasoned with. But she has to try, losing hope won't do any good. "If he dies, we all die!"

Mrs. Ferreira is bluffing and hoping it sticks. She's not worried about her own old and achieved life, and would certainly give it up to save young Andreas, and certainly yet, she would proudly die to kill this traitor all in the same day. She doesn't care for the cost of the International Research Station either, she only works for the Corporation because they fund her research. But the lives of the crew, which are many, clearly out-weight the life of young Andreas alone.

"Even if he dies, I still have to save everyone else!" she thinks, and that simple thought of it scares her. As Chief of Enginery for twenty years, Mrs. Ferreira have always been responsible for many lives in the station, as any error committed by her or those under her orders would put everyone in danger.

"Of course she won't fall for this bluff..." thinks Mrs. Ferreira. "It's such an obvious situation and I'm clearly the one in disadvantage here".

Assist.

The woman looks down on the unconscious young Andreas. "Alright!"

The Engineer can’t really believe her ears.

— "I’ll fix the boy. You fix the engine" says the woman with the tone of who's definitively settling a deal.

— "You 'fix' him?", Mrs. Ferreira can't hide her disgust for the choice of words, "Do you think I’m stupid or what?". She can't tell if she's acting out of anger or simply being pragmatic in her distrust of the murderous demon, but quickly writes the question out of her mind as it doesn't really matter right now. "I'm not letting you alone here with him and go fix the Engine while you kill him and escape!", she concludes from her own words it was both, after all.

— "Where would I escape to? As you said yourself: we're all on the same boat, dear engineer" talks the woman so calmly it seems she's even oblivious to the current state of affairs, "This kid wasted enough of my time by attacking me and now the last escape pod has already been used."

The detached, condescending words make the engineer's blood boil again. She's ready to shout, jump, attack the monster and fight to the death. Nothing else matters. "Wait," a thought stops her muscles now ready to do anything that comes out of it, "she means it?" Mrs. Ferreira ponders in surprise. "It's unbelievable! The bluff worked!?".

Before Mrs. Ferreira has time to work out the certainity of those those thoughts, the woman lowers the artifact she's been pointing at her all this while and starts regulating something in it. Mrs. Ferreira stands confused for a few seconds. "Should I attack her now? It could be my only chance! Or maybe it could be throwing my only chance away".

— "So are you letting me pass or not?", her words seem to come before her though settles, "I have to bring the Med-Packs to stabilize him right now!", urges her, trying to keep following the path of diplomacy since it's already been taken anyway.

The woman crouches and points the device at young Andreas again. "There's no need for that. I got it sorted."

This time not only she can't sort if the time is for words or actions, but her entire body is frozen with shock. A scream wants to come out of her lungs but the air stops dead at her throat, and what follows only deepens her despair.

A red flash comes from the device and the light involves the entire room, accompanied by a weird loud noise that quickly fades away, bringing together all other noises with it.

"The fucking bitch killed him in could blood!", her thought's mixed between the sudden emotional shock and the necessary means to fix the situation with the Engine. "And I believed this monster's words once again!" thinks Mrs. Ferreira, already feeling guilty for what has unfolded.

The sudden flash of light is so bright she feels dizzy for a while. Her pupils forcibly shrinking with the disproportionate increase of light in comparison to the dim darkness she slowly got accustomed to after all these years. Everything went black for a couple seconds.

— "This will do!" the calm voice of the mysterious woman breaks the sudden deafness caused by the noise, "The wound is sutured and he won't bleed to death anymore."

Mrs. Ferreira's vision is only coming back again, everything is so blurry she can barely make up the general shapes of the woman and young Andreas in front of her.

— "I did my part of the deal. He's fixed!"

As her eyes re-adapt back to the emergency lights of the I.R. Station and the words from the strange woman reach her ears, Mrs. Ferreira looks in disbelief while still trying to understand what had just happened.

— "Now you fix the engine!"

Fear Of The Unknown, Part 3

Continuing were the Part 2 of this series left, here well talk about the presence and imminence of horrors.

Presence

“Panic is the sudden realization that everything around you is alive.”

― William S. Burroughs, Ghost of Chance

Unknown Presence

Sometimes it's not that we don't know what something looks like, but that we don't know where it is, and that can be a frightening experience. On the contrary, keeping our eyes on the threat makes us feel more secure about it. By looking at the source of terror we have a steady stream of information coming from it about when (imminence), if (intention) and how (nature) it will try to do anything that puts us in danger. If it moves, we'll know right away and react on time. If we don't have access to that information source, we cannot reliably evaluate the situation, and our minds will try to make up for that, again, extrapolating the limited information we have.

The feeling of being hunted, being preyed upon, being conspired against. Unknown presence goes beyond the simple spatial meaning of the word and ties closely to the notion of intention. More generally it's hiding itself entirely, but it could be concealing a weapon (unknown intention) or disguising it's nature (uncanny image) and the principle is still the same: that if it's hiding something, it's up to something bad.

In the more literal sense, the unknown presence most often tied with an unknown imminence. If something is possibly preying on you, it can attack you from anywhere (presence) any time (imminence). For that reason, the line between unknown presence and unknown imminence can be very blurry at times. But the feeling of being preyed upon – which is the most obvious use of this tool – elicited by our natura survival instincts (Player-Mechanics) is not the only form of unknown presence, there are other ways in which not knowing the location of a threat can be used to keep players on their toes.

Example of unknown presence:

Slender - The Arrival launch trailer:

Slenderman: you never know where Slenderman is, not until it's too late.

When the situation is inverted, and the player is the one sneaking around, it's also of extreme importance to know the whereabouts of the threats one's trying to remain concealed from. Acting undetected is a situation where more than anything else, information equals power. The presence of threats and the presence of the Virtual Player-Character are very connected things, as the fear generated by not knowing the presence of a threat is caused by being unsure about how to avoid it.

By providing extra-sensorial sources of information (motion scanners, x-ray vision, understanding the alarm state, visualizing the foe's cone of vision...), Stealth Fantasy titles empower players with everything they need to overcome the puzzles presented.

Clear light and shadow delimitations convey to the player where the binary safety and danger spaces meet each other, enemies are set up to contrast with the environment and walk in repetitive and predicting paths (known presence), and flashlights portray the angle and range of their vision.

In our specific case, where our focus of study is trying to understand how the Dynamics of fear emerge from the Mechanics of imperfect information – Fear of the Unknown –, what we have to look for is how the lack of that power affects the informee's (Real) mind-state when present in a context of (Virtual) danger and (Fictional) horror.

So let's see what that perfect information does for the player first, ignoring for now whatever are the Aesthetics used for providing that information. When given perfect information in a stealth-action situation, the players are able to understand the borders that divide safety and danger, the limits of the space they can use and the amount of risk they're subjecting themselves to at any given moment.

As an abstract and independent Game Mechanic, avoiding a saw blade and avoiding a line of sight are no different (not until the player fails at it). Both are about staying in safe space, avoiding dangerous space and making your time in risky space as short as possible.

The balance between safety, risk and danger, between safe space and unsafe space is the core point of stealth, concealment and, in our case, fear of the unknown presence. When the player doesn't have perfect information, the line between safety, risk and danger become blurred (vague) and the player can't be sure anymore about how much is the balance between safety and danger is in the situation. That specific feeling is the basis of everything we're studying here. One of it's more aligned interpretations of Fear Of The Unknown is the sense of unmeasurable risk.

The less information one has to act upon, the more thrilling that act feels. It can be either exciting or stressful depending on the Mechanics (using "excitement" and "stress" very lousily to categorize many things here, "fear" falling the side of stressful ones). When you're willingly taking a gamble for the fun of it it's more exciting than when you're forced to compromise planning and safety to fit a rushed ticking clock. Imposing a time for the player's action usually results in a more stressing version of the thrill.

But when the free will ("player agency") is not about time, but about space (or resources), a different thing happens and the weight of responsibility kicks in and suddenly being in control of one's own fate is the very source of stress – that's what makes Video-Games such a perfect format for Horror, as only this format can mimic life not only in Form (Fiction) but in Function (Virtuality). When you already checked every side route and realize the path that progresses the game is the only route left to take, to venture through the Unknown, that's scary.

If the player can simply blindly trust the designer/writer that nothing bad will actually happen in the Real or Virtual layers of the experience, and can simply keep going forward into unknown territory recklessly, the weight of that responsibility is gone. What happens is that again, there are no unmeasurable risks to be taken if all the risks are considered under a known threshold of "balance" that assures Virtual safety, even if Fictional danger still takes place – up to discussion if Plot Armor and Fictional danger can actually coexist, but since it's a pure-Fiction philosophic discussion I don't think it's worth pursuing.

The same is true for assured Virtual danger, in case of successive failure that turns fear into frustration by taking the unknown imminence factor away by rendering players cynical to the possibilities of success. Without hope there can be no fear. If the players stop caring about what will happen next – whatever be the cause for it – then you cannot threat them with unforeseen consequences anymore.

Note that it's an aspect directly related to the player's experience and is very dependent on who your target audience is, what expectations they have, if they have an understanding of game balance and so on. Some times it still clicks, some times it fails miserably.

This puts us back in the "Survival Horror vs. Power Fantasy" spectrum and it's Game Design directives: should the player be informed for sure where the line between safety and danger lies? There's no one right answer, it always depends on what the design is trying to accomplish. When Fear of the Unknown is the goal, it makes sense to cripple the information given to the audience.

Vague Presence

Limited information, the word vague means for us here, and such is the vague presence. Not so little information to fall into the (unknown but acknowledged) unknown, but not enough to render the player sure (even if wrong, in which at the point of discovery of the error it'd become uncanny) of said presence. That way we can consider any evidence of presence, existing or not, to be of vague nature.

The vague presence is what can be described as "the unproven evidence of a threatening presence".

Common sense says if you can't see or hear it right now, you don't know where it is, which would be a case of unknown presence. But specially in the case of Video-Games as they are currently, just hearing it or just encountering other evidences of a presence, and some times even actually seeing it are often not an assurance. There are at least two main sources for that:

1) In the realm of Virtuality everything is possible, and laws of Reality don't necessarily apply. Players minimum experience with Video-Games know that smoke-and-mirrors design is easily achievable and very common in the Entertainment Software medium, and that many of the stuff that supposedly should be an evidence of presence of a threat is nothing more than a "poltergeist script" that can't do much more than a few loud noises and barks; and

2) The Horror and Suspense genres of Fiction come with clichés and tropes known to the audience, which give them a very good idea of what to expect from a Mystery, Suspense or Horror story.

The combination of these two aspects makes otherwise strange and otherworldly things and events to be taken as normal within the Virtual and Fictional world of a Video-Game. Players know that art horror and terror will try to scare them. Players know weird things are expected to happen in Weird Fiction, that's why they're reading/watching/playing it to begin with.

Those are aspects that supposedly should fall into the uncanny presence category in the realm of Reality, but under the rules, tropes and common trends of Horror Art in general and specially Video-Games, they're wide acceptance as "natural" things render the known and the uncanny into territory reserved to the vague.

Important to make here is a quick distinction between "emergent unknownness", when the player simply doesn't have track of the threat's whereabouts – as studied in the unknown presence section –, and "scripted unknownness", when false evidences (poltergeist scripts) are given to the player. This section refers essentially to the latter.

Giving clues about the presence of a threat but holding back visual confirmation allows the player's mind to imagine the proximity of a terror by completing the information puzzle, while still being unsure of it's actual presence (vague). This works both ways, some times for making the uncertainty frightening and some times for causing the player too see clearly through the smoke-and-mirrors design and stop caring about the fake threat that just wants to scare the Real Player-Character (the player) but not to hurt the Virtual and Fictional Player-Character (the avatar and the character).

It's a tool that works well for many types of players, being specially effective when they're not much under the effects of Medium Awareness. For the most seasoned and self-aware players, the smoke-and-mirror design can lose all it's magic at the first realization of nothing being actually there (presence) and all that's going on is a combination script and audio tricks from which no Virtual (read "Real" inside the Virtual world) consequences can arise. Also, if there are Fictional-only "consequences", those are already decided in the player's fate by the interventionist god writers and there's nothing the Real Player-Character can do to stop them from happening, the players might ask "why worry about those anyway? whatever will be, will be".

Ultimately, the goal is to make the Fictional world feel Virtual and the Virtual world feel Real. However the designer can pull that, and it works, that's great. Also, not having much experience with video games can do wonder for the first experiences you get to play. There is an audience segment that is just getting to know the hobby, that don't have the same burden of knowledge most of us do, with fresh and unspoiled minds to what's possible, and we can and should totally target them too in some of our works.

I remember back in school, my friends speculating about who or what takes the dead zombie bodies away in the first Resident Evil while you're in another room. Such a mystery remains unsolved.

When used correctly, the vague presence is a very powerful form of the Closed Door device, which makes complete sense because the Closed Door device is also a form of vagueness and unknownness: a missing link of information that the player's mind will extrapolate (Player Mechanics), rendering the whole experience (Fictional, Virtual and Real) closer to feeling Real (Dynamics) than if the complete information was simply given, which would fail to create immersion (Dynamics).

I know some of you might dislike the "immersion" word due to conflicts about what it means in terms of depth and nature, caused by the common confusion with Cognitive Immersion (which's what I mean), Sensorial Immersion (The Matrix), Deep Immersion (not knowing it's The Matrix) and Liquid Immersion (ha!).

While the use of the vague presence can be to make it seem like there's "something" around (and how it can fail if not used with care), the best effects come from the application where it goes beyond adding a something to the existing Virtual world, but when it adds a Fictional world to the something.

And here's a question: the extrapolated portion of the Virtual world, created by the player's mind to fill the information gaps and give consistence to the rules, is it Fictional, Virtual or Real? The fact that it's hard to define only hints at how powerful it ultimately is. It goes beyond Video-Games, being present in Film, Comics, and Literature. It's what makes all Fiction feel Real, and it's the best goal to look for when using any tool.

Example of vague presence:

I saw something... It is right there... in the outside.

What worked a decade ago doesn't necessarily work today, but the principle still remains and can be adjusted to fit todays savvy player's perceptions in order to weed out the designer's hand and give the Virtual world a sense of natural and seamless continuity that really feels like it goes beyond the play-field.

Again, it wouldn't be fun if it wasn't challenging.

Uncanny Presence

Other case of seemingly uncanny presence turned into vague presence in the realm of Video-Games is the relationship of the uncanny with the idea of disguise. At the heart of it, that's what the uncanny is and why it scares us: something disguising itself as something else is always creepy and dangerous. It cannot have good intentions.

The line between the idea of something disguising itself and of something disguised by design is another blurry spot when it comes to things that happen on the bridge between Real and Fictional (it is, the Virtual). In which case, while the uncanny image is seemingly natural in aspect and keeps things clear, something trying to disguise it's own presence is a product of its behavior as opposed to it's nature and can be looked at as either vague or uncanny, all depending on how the player perceives it.

True uncanny information is not supposed to make sense. In fact, it makes too much sense for things that cannot be. Some times to be more than one thing (as in the "doll or human" uncanny image case).

Needless to repeat, once stablished by the medium that the Virtual rules and the Fictional rules are not the same (Ludo-Narrative Dissonance), there's no such thing as "impossible" anymore, and the otherwise uncanny can sometimes become the "normal", some times even when the really weird things happen.

But the uncanny is never alone, is always comes after the known and subverts it, and that's why it still works. As mentioned in the first part of this series, the uncanny is many times viewed in media as a form of "plot twist", but it's not necessarily the only form of it.

For those reasons, a common use of the uncanny presence in the Virtual world of Video-Games is the "ghostly appearance", when the player sees something that isn't really there. A ghostly appearance can have many different Fictional explanations, from actual ghosts, to visions, to hallucinations and so on, but Virtually they're the same thing. First the players sees something or someone spatially positioned play area, which's sufficient information to conclude it's there (known presence), then latter comes the realization it's not actually there, or has never been, and the previous information is proven wrong (uncanny).

Coming from the "plot twist" connections of the tool, it's one that works better the first few times it's pulled, before it becomes a "known absence" or "known false presence" for the informee, which can make it either fail as a form of uncanny presence, but also gives the design a new opening to subvert the current status of information back by making the "false" appearances be real the next time around, reestablishing the uncanny presence.

Example of uncanny presence as ghostly appearance in Video-Games:

First Encounter Assault Reckon:

Point-man sees Alma multiple times through the game, usually as a ghostly appearance, but sometimes she is true, either in spatial presence or as an invader of the Fictional character's psyche.

If "weird stuff happens in Horror Fiction" and "Video-Games usually break consistency rules" are unavoidable tropes, it only means "normality" and "rules" aren't forms of the known that work well to be simply subverted into the uncanny. But information is limitless and there's always a new jumped-to conclusion to twist.

Using uncanny image effectively is certainly easier than to do so with uncanny presence, that's because Fictional and Virtual image are essentially the same thing, but presence can be more dissonant between worlds layers. The lack of Mechanics in Fiction (specially the uncontrollable forces that are Player-Mechanics) makes everything easy and allows the designer to pull many forms of uncanny presence by using them exclusively in the Fictional world as, with anything Fictional, it's no different (nor harder) than using the same things in any other art-form capable of portraying Fiction.

Example of uncanny presence in Fiction:

The Village (2004) (Spoilers)

The "ones we don't mention" exist. Then they don't really exist. Then they actually show up on the screen. But the character that "sees" them is blind, so maybe they're only in her imagination. Or maybe it's not just in her mind and it is actually there... is it? This is a tricky example to truly replicate in the Virtual world, as you can dictate a Fictional-Character's mind, but not a Real-Player's one.

Isaac's mind is disturbed and he keeps seeing his dead girlfriend. At all times, the Real player is aware of it, but for Fictional Isaac the hallucinations are very real the moment they happen. Some times, there's a Virtual aspect to it, when the girlfriend's actions is in fact Isaac's, another Fictional character or a Virtual enemy, in which case a Quick-Time Event tells the player what's happening.

Clearly the great goal and the most interesting challenge is to perfectly blend the Fictional and Virtual world, making everything that "happens" to do so in both, and feel as Real as possible to the player. But when design is somehow constrained out of that option (for whatever reason it might be), the Fictional uncanny presence stills adds to the experience, and should still be employed given the opportunity.

Some times, simple but clever tactics can be employed to achieve the effect of blending worlds, without going to extremes. Making what happens in the Fictional character's mind to exist as real in the Virtual world is a way of doing that. Other options are to use the software to read' the player's reactions to appearances and judge if he treats them as real or not, and go for the opposite in order to subvert his expectations.

Example of Fictional and Virtual uncanny presence brought together by clever design:

In Dead Space 3, co-op player's are transported to different versions of the Virtual reality, by hallucinations fueled by each Fictional character's own internal demons, and each Real player sees a different situation developing in their screen, while still faced with real Virtual conflicts.

Imminence

Unknown Imminence

Fear of unknown imminence is the fear of the unknown future. More than just the consequences of a risky action, but the unforeseen and unexpected event that's out of one's control or when you know something will happen, just don't know when and you cannot impede it.

Following the norm of analyzing the most common forms first, we can observe that usually in Horror Video-Games, what the players don't know in this case is the moment something will jump out or make a loud noise with the purpose of startling them. The "jump-scare". There are other forms of jump-scare usage that don't necessarily involve something jumping at the player (floors collapsing bellow the avatar are another common appearance) but the forms of holding and releasing information are the same.

The use of this tool is most common in Horror Video-Game segments that strive for startling the (Real) player. This is done by submitting the player to a core loop of anticipation, surprise and relief, of which the first one (anticipation) usually compromises most of the play time, followed in time by the third one (relief), while the second one (surprise) starts and ends very quickly.

Sometimes when this tool is used it does so while wasting the potential of an otherwise powerful moment of reveal, spending it into a mere jump-scare when the information being revealed could have had a greater shock and more lasting impact if not obfuscated by the quick-come-quick-go startling effect. There's a physiological limit to how much emotional response the human body can sustain at any time, it's not like our blood could be completely diluted by Corticotropin (we'd literally die of fear way before that), and there's also a psychological limit of how much each layer of consciousness can focus at any given time and more urgent matters will overshadow more delicate ones. The Real adrenalin pump of a jump-scare is immediate, and can easily take away the precious attention a shocking Fictional moment might require from the player to understand the depths of the horrors he's in contact with.

This is a tool that's very easy to make use of, and that's effective for what it proposes to accomplish, but that quickly falls into the traps of losing all it's positive effects when combined with the Genre Savvy Player-Mechanics. The biggest downside of the jump-scare design tool is that the Dynamics that arise from those Mechanics can fall into the meta-game category, or in other words, into a Real-world game detached from the Virtual and Fictional worlds.

Once the player is focused on a loop of Unknown Imminence (anticipation, surprise and relief), it leads to him/her to fear the possibility not being prepared for it when it happens. Exactly what happens or what jumps out of where isn't really important to the player. It's all about being or not being prepared for when it happens. The player then engages – consciously or not – in a self-imposed Meta-Game of either: a) trying not to be caught by surprise by the game; or b) overplaying his surprise with jumps and screams.

The player starts to "fear" (anticipate) being startled by the Video-Game (Real piece of Software) instead of being scared in the Video-Game (Virtual and Fictional world). By the point the player is meta-gaming, he's not in the Fictional and Virtual slices of the Video-Game's world anymore. That's an important distinction to make, and it's equally important to define what the design is aiming for. Both are valid design goals, what matters is if the design achieves what it's actually trying to.

While jump-scare design can raise your heartbeat and pump adrenaline in your system, it's not exactly the same as Fear, and not the same as fear inside the Virtual and Fictional world, but instead of Apprehension in the Real world about the Video-Game as an entertainment product and disconnected from the Virtual and Fictional world inside the Video-Game. Apprehension can become Paranoia but it's also not exactly the same as Fear – unless, or course, you have Hormephobia, then that's a different story.

I want to point out the fact that it seems very clearly to me, that horror movies seem to have a lot more acceptance from usage of jump-scares than Video-Games do: jump-scares in movies are "cool" and "scary" while in Video-Games they're boring, lame, lazy and cheap. I guess that tells a bit about the difference in audiences and audience expectations, which in my opinion is good that Video-Game audiences put the bar higher and don't accept lazy design. I won't dive much into that, just leave it here for consideration, but also add to the note that horror novels and other written stories don't have that card in their repertoire, and their strength lies in other, more immersive and elaborate tools.

But not everything about surprise and jump-scares is flawed. They work as, though very short-term, fear catalysts because the human mind allows it. Humans, in general, worry too much about things that will never happen, and about things that already happened; some do so to a degree bigger than others.

Once you get surprised and see what just "jumped" at you, the shift from unknown to known is too fast and brings too much information at once. This is what we call a shock. Despite the very visceral and immediate carried information about intention that it's something attacking you – which initially works regardless if it's correct or incorrect information, but that we as a fit species also adapt to and quickly learn if it's just trying to scare us instead –, it also carries the revelation that we did not have sufficient information about it coming to happen prior to the moment.

This causes the fear of unknown future (Paranoia) to now be boosted with fear of unknown past. Yes "fear of the past" and "unknown past" are both illogical sentences, but that's because "worrying about the past" is also illogical yet humans do so. Neurotransmitters simply defy logic, and exploiting these openings remains an effective strategy of Game Design until the audience adapts and develops immunity to such strategy.

Sometimes, the fear of unknown past can come alone. That's when a jump-scare is not preceded by Paranoia (the future version) which means that the player is not expecting it. It can be good or bad depending on the player. The potential to break immersion and pull the player into the meta-game is the same or greater, it'll depend on how self-aware the moment will be for player. If the the player thinks "the 'Game scared me", or "the 'Game got me" (even worse, this means the meta-game is already going on), it's a failure; if the player thinks about the moment within the Video-Game's world, it's a success. That is, unless it's the design goal anyway.

Being scared by a Video-Game and being scared by the world of a Video-Game are very different things, the former only involves the Real dimension of the Player, the latter encompasses the entire Player-Character construct in the Real, Virtual and Fictional dimensions.

It's important to note that not every shock classifies as a jump-scare. But the usage of cliché jump-scare sound effects and similar tricks can bridge the gap and degrade a shocking moment into a jump-scare even if it doesn't classify at first. It's like screaming, swearing or pulling the troll or nazi cards in a discussion: even if you might be initially right, you're acting like people that are wrong do (i.e. being emotional), therefore you're wrong regardless. Over-playing a shocking revealing moment into a mere jump-scare throws lost of good work and potential down the drain can be a huge waste.

Scared players.

While it's true that some players like to pretend to be surprised, immersed and scared by anything and some just blame the consumer instead of the designer for when it doesn't work, I prefer to think it's always our fault when it fails. Making Video-Games is a hard game, and that's a good thing: it wouldn't be fun if it wasn't challenging.

Use at your own discretion.

Vague Imminence

As with all the vague packagings looked at so far, the vague imminence is the event in which the informee is teased with a possibility of something happening and an approximation of the idea about how close it's getting. It's still not known, but not certain either.

Contrary to the unknown imminence, this is not the kind of suspense where you cannot see it coming (even though in practice the opposite is most times true, because clichés and patterns are predictable in nature) and, more importantly, what's coming. That's the key point that differentiates the vague imminence and the unknown imminence: you know what is about to happen, but not sure if it will, and what precise moment.

This tool is very commonly used in Fiction media, specially effective in film with it's visual and cut language, and the characteristic of Fiction of being able to give the audience information that the characters – or the enemies – lack.

Example of Fictional vague imminence:

In the classical shower scene of Psycho (1960), the audience (Real) has information the character (Fictional) doesn't. The approaching moment fuels the audience's fear of the imminent events.

In the also famous kitchen scene in Jurassic Park (1993), this time the audience has information the antagonist deinonychus lack. At any moment now, the ferocious hunters could spot the kids. 

Clearly signature of Spielberg's style, the vague imminence is present in many of his films.

The uncertainty of the outcome combined with the acknowledgement of what the result of such suspense, and how close (imminent) it is to be fulfilled, is the source of the audience's fear.

The difference in tangibility of the imminent danger created with the vague information contrasts with the effect of paranoia created by the unknown counterpart. The context created by the source of danger helps pulling the audience into the Fictional world (as long as plot armor doesn't go to far to build disbelief), avoiding the effects of meta-scariness characteristic of the jump-scare tool employed by the unknown imminence.

By this point you must all have already notice the trend of stealth-action situations directly tied to most of what the tool is about. This is a truly powerful combination, specially when it gets across the line where Fiction ends and Virtuality starts. The stream of adrenalin caused by the act of sneaking around is a strong, Real addition to Fictional Aesthetics of the horror atmosphere and the Virtual danger of getting caught by the enemies in the Video-Game's world. What results from the combination of all those factors is a thrilling experiential product only Reality can surpass.

Example of Virtual vague imminence:

Even with full top-down view and super powers, the unpredictability (unknown imminence) of randomized patrol paths, added to the knowledge about how close it is to happen, make this game a very thrilling stealth-action experience.

Uncanny Imminence

Across the analog path that goes from unknown to known lays the vague, many variations of it, and there's a form of Suspense that works exactly by moving along that path, from the unknown and towards the known. At some point it gets so close to known that it becomes uncanny in nature.

I like to call it "bold suspense", because it's a very confident tool of horror design. When the subject of horror is a tangible thing, it uses known or uncanny image and presence throwing away many tools and leverages given by the most powerful assets of unknown horror design and goes all out on the confidence that the subject is all that frightening in and of itself once the tricks are all dropped. It's also a staple of the climax pacing event, which eventually all horror and mystery lead to.

That form of suspense is what we could call "dramatic pause". First, it doesn't have to be a literal interpretation of a binary pause, but rather a form of delaying the outcome of the horrific situation. There are multiple small variations of how to pull it, like the "waiting horror" that stands on there, which deals with uncanny intention (and other natures of uncanny packaging) to delay the threat's move, and the "slow moving horror", which slowly get's closer and closer to the victim character/agent.

The "waiting horror" has a direct link to our primal survival instincts (Player-Mechanics), by mimicking the behavior of wild predators, in the preparation for a  deadly lunge and in the creepy act of stalking a prey. It also increases the sense of danger to have a pragmatic predator opposed to a mindless one.

Packs of wolves and hyenas derive many of it's efficiency at survival by minimizing their own risks, making them able to catch preys stronger than themselves, otherwise impossible at a direct confrontation. Like wolves and other canines, vultures also calmly follow their preys for days, beating them in an endurance contest, patiently waiting for them to extinguish their energies in other to maximize the effectiveness of the attack, only committing when the success is guaranteed.

Similarly, the "slow moving horror" hints our instincts (Player-Mechanics) into the dreadful acknowledgement that the predator has it all under control, while also capitalizing in the "ticking clock" embedded Mechanic and the Dynamics it creates.

That's another example of the importance of keeping Player-Mechanics (which happen in the Real world) in mind when design horror.

Ability to strategize and confidence to act calmly make any predator a much more deadly encounter, and this is something we know at an unconscious (and irrational) level. If the rest of the experience does it's best to remain immersive.

I won't get deep into this subject here but, in my humble opinion, "immersion" is what happens when your mind is too busy playing the game / reading the book / watching the movie to remember it's one. Different people in different moods have different amounts of parallel mind processing capacity. As long as an experience can exceed that capacity and nothing too wrong and obvious forces it's way into the priorities, all the Real-world thoughts will be filtered out of the most conscious layers of the mind, and that's how immersion is sustained.

Don't let your players have spare resources laying around so that they can be used to see things you don't want to be seen, and don't let said things climb the priority queue. Keep your players too busy in the Virtual and Fictional worlds to afford thinking about the Real one, and they won't. How much is "busy enough" varies from player to player, some are so used to the most basic things that they become second nature. Some can be engaged enough (sometimes even overwhelmed by) just holding forward and looking around, while others can be rocket-jumping through the stage and not even think about it while they do so.

Examples of uncanny imminence:

Creepy bastard.

It's true that slow enemies are a compromise of balance design in horror games of early generations due to the limitations control schemes, but with them came many positive side effects lost in today's games due to advancements in technology (as mentioned in the vague image section of the Part 2 of this series). But the thing is, we don't necessarily have to lose those tools, just try to understand them and find ways to make them work in today's and future's context.

I bet you didn't expect to see Rayman in a horror-related article, but those players certainly did expect what was coming at them, slow and steady. The closer it gets, the more the players panic and end up screwing up something they'd easily solve by staying calm.

In the Rayman example above, the two-dimensional side-scroller view allows the players to measure the approximation of the creepy slow-moving hands with precision and the closer they get, the closer the initially vague imminence moves towards the known, painting the whole moment into the realm of uncanny.

The most important characteristic of the uncanny imminence (Mechanics) is the eerie atmosphere it gives to the scene (Dynamics), as it's the reason why we make use of the tool to begin with. Being so, it's use in horror goes beyond the simple aspect of using the "dramatic pause" device in combination with known presence and known image counterparts. The effects of any of these tools can be leveraged by the combinations of others, as in the next example:

The uncanny imminence of the slow approximation and uncanny presence of coming out of the TV and of teleporting around at times are combined to increase the effects of both, giving a final result that's better the sum of its parts.

The video above is also a good example of not failing into that trap of the use of jump-scares possibly undermining the shock effect of a climax moment. If the scene started with Sadako (she's not called that in this remake) jumping "boo" out of the TV, that would have the audience jump momentarily, but the lasting effect of the scene could have been reduced into "that moment with the jump-scare".

Known Imminence

The known is similar to the uncanny but with – or rather, without – a twist: it's inevitable. When caused by emergent Mechanics, the known and the uncanny imminence can be two future possibilities of the same present, as the player might have a chance of turning things around to impede the events. The possibility space of a Virtual world when compared to the rigid nature of Fiction, makes it complex to define the differences between what will definitely happen and what can be impeded in the last moment.

Spielberg creeps into the examples again...

In the Jaws scene above, the known nature of the shark and today's audience awareness of the genre of Suspense in the medium of film certainly make the effects of uncanny imminence fade to a big extent (nobody said it's magical or will be trivial to use) into known territory (the audience can predict what's coming and there's no twist), but the composition of the scene fits the principle of the tool.

An attempt to create the same scene in Virtual form would bring the situation onto the line between known and uncanny, as it'd be on the player's responsibility to hit the shot that will save him from that situation, with the possibilities premature success or failure, where design tricks to avoid both can always compromise the perception of fairness and the immersive potential of the moment.

Anyway, the uncanny imminence of the shark is not the only imminence factor in the scene. It's the sinking ship, the last safe spot against the predator for which water is home, the true protagonist of the inevitable. Sure, killing the shark solves the real problem, but the ship is going down and nothing can stop it.

If uncanny imminence is "bold suspense", the known imminence is "bold anticipation". It's the core difference between disarming a bomb and running away from the blast that defines the difference between the uncanny imminence and the known imminence tools, and it's the difference between seeing the bomb's clock ticking down or not that separates the known and the unknown. It's the knowledge of the inevitable outcome.

If you've seen this sequence from Mission: Impossible 3, you might remember how this drone is portrayed as an unstoppable force of destruction, slowly maneuvering around to come back unleashing the next attack, with the aura of "inevitable" created by the known imminence.

Conclusion

Fear Of The Unknown is a Dynamic, the result of ripple-effects created by the combination of the Player-Mechanics of deep ingrown human and animal psyche that exist to increase our chances of survival in the face of danger, known or unknown, Game-Mechanics that wake those instincts up to work in a simulation of Virtual danger, and Fictional Aesthetics that contextualize the cognitive connections of those instincts at work to create the negative space for our minds to fill, bringing Virtuality and Fiction into Reality.

Each subject of information (image, presence, imminence, nature and intention), each information packaging and twisting (unknown, vague, known and uncanny) and each dimension of the Video-Game's narrative (Reality, Virtuality and Fiction) have their own characteristics, pros and cons, and functions in the system (Mechanics, Dynamics and Aesthetics) that makes the all-important player experience possible.

All those factors, beyond creating the Fear Of The Unknown also contribute to the reduction of cognitive idleness, to get rid of opportunities in the players brains to look behind the curtains and spoil the magic of the media.

Finally we reach the end of this series that took the span of three months to come out. I wish it would have been better, but hope it was inspiring to some of you smarter than me to come up with more polished and effective tools we can use to increase the quality of our designs.

I'm currently finishing a big presentation of the internal pitch of our soon-to-be-announced horror project, which also involves the A.I. system I've talked about in a previous article – and which I plan to release a kind of "tech demo" soon. Investors' meeting next week's Saturday, wish me luck! :)

Boo!!!