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.
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.
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.
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.
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.
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.”
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.
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.
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)