Matrix Automatons

I've recently done a deep dive into Engle Matrix games (read more here, join the new discord here), and it's reinvigorated my interest in theorizing about solo gaming and making my games flow smoother. 

I typically get some writers block and burn out of many of the more narratively oriented solo games I've played, and what's really worked for me is procedural gaming (hex crawls, combat focused games, etc). But I've also missed some of the tactical depth that comes from OSR gaming in a group in my solo plays, since most oracular systems don't really emphasize strategy and tactics in play over narrative development and using tropes to drive play, and often the hexcrawls I play can lack some of the factional and deep interplay that gets lost in more combat focused play.

I think Engle games can fill in the void here with it's argument structures and narratively defined tactical play, where a given argument mixed with a few dice rolls and some logic can push the game forward (check this post here for a good conversion of Matrix rules to OSR style)  However I think that the rules for matrix development, extracted from Chris Engle's original 1988 article, and it's follow-up, can provide a framework with which to mostly, if not entirely, replace the narrative meta-structure presented with most gm emulators with what I'm calling "matrix automatons". 

Think of these "matrix automatons" as elements you can use to fill in your world and interact with from a player character perspective, without the need for a narrative framing to necessarily push play. You can create any category that can contain these automatons, such as Insitutions, NPCs, Locations, etc. Within a given category, you create the automaton as described in the original Engle article (and illustration in the follow-up one with examples) giving in a name, an upper section containing a phrase that describes it, and a lower section containing problems it has that the player character can hook onto and modify each turn. I propose the following structure for a given automaton:

[Category]. [Name]. 

[Description]. 

[Dynamic Problem List: [[Name] exhibits [property] because [reason]. 1, 2...n.] 

Let's say for example I create an NPC, Jack of the Beanstalk:

NPC. Jack of the Beanstalk. 

Farmboy with a giant beanstalk. 

1. Jack exhibits greed of the giant treasure because he is poor having sold his last cow for the beans. 

2. He exhibits fear of the giant because he fears the giant will take his life.

Let's break this down piece by piece:

1. Category: Define what type of entity this is. NPCs are the most obvious, but an Institution can have problems it's dealing with, as can a Location. Even Items can fit the bill, being interactable. Schools of Thought and Movements could even work, if a bit of a stretch - define their tenants and reasonings, and keep them linked with something tangible a PC can interact with - practitioners, texts, etc. In the example, Jack is an NPC.

2. Name: Names matter. Names can be descriptive and provide depth for a character and their motivations. They can provide cultural cues, change how someone is treated and reacted to. Sometimes, they're just a name, but the act of you remembering it (don't look it up and cheat!) can endear them ever so slightly more to you than before - or make them more angry since this was the tenth time you forgot their name, seriously?! In the example, Jack of the Beanstalk is known for his beanstalk. It's likely people have heard about him due to his beanstalk. Whether he likes the fame, how he feels about it is an interesting question you can interact with him about, just asking him a few close ended questions - and this can lead to uncovering a new problem.

3. Description: Keep these simple. They shouldn't really lean emotionally one way or another, this is what the problem list is for. This is the 1 line summary of what this person would be described as, in as neutral a way as possible. "Farmboy with a beanstalk", "Soldier with the Phalanx Army", "Inquisitor for the High Temple". Treat this as an [Else] Statement. In a given situation, if you go through all the problems in the list and none are directly affected, then default to what their role in the world expects of them. Farmboys aren't soldiers who aren't inquisitors. Fall onto stereotypes here, because any specifics not defined by a problem are stereotypical. In Jack's case, he is defined by his beanstalk, and how this affects his life is an interesting avenue I'd probably pursue.

4. Problems: Start with a couple of obvious ones given an element's description and how they are introduced to you in the story. Oftentimes, NPCs rolled off tables only are rolled because they interact with the PC in the first place. The primary property for the NPC then is how they interact with the PC. Are the PC's being hunted by the NPC - "NPC hunts PC because PC is a fugitive from the law". If an element is encountered as a totally random encounter, it will likely be defined by a reaction roll "NPC is hostile/neutral/friendly to PC" and unless the PC further interacts with it vanishes from existence. If  the PC interacts with it, then using close ended questions to see if and how it opens up/presents more information in a non-NPC element to the PC is warranted. In the case of Jack, he is a well known character I'm ripping off of so I laid out his problems up front, though more can be added through asking questions of him as the PC.

Note: Property and Reason are separated because what is externally observed - the Property - might not have an apparent logic - the Reason - behind it without further investigation or questioning. 

a. Property: This is the externally observed behavior/nature of an entity. An NPC can be greedy, afraid of something, etc. A city can be filled with slums, smoky, clean and bright, filled with street hawkers, contain suspicious folk. An item can be lustrous, old, ragged. All of these are observed elements without the reasoning behind the external appearance not being obvious.

b. Reason: This is the logic behind a given property. It may be obvious or may need to be uncovered through questions. It is possibly this could be erroneous if problems are assumed to be from the perspective of the PC instead of a narrator. It could even be left blank until discovered. An NPC can be greedy because they are poor, they covet wealth due to stature, they like shiny things. Cities can have slums due to mismanagement, having corruption that results in destitute citizens, etc. Items can be lustrous because of magic properties, because it was freshly polished, because it was made of ancient dwarven metal. 

How I see these automations being used is that asking questions about problems and trying to affect them is the primary goal of the PC in the game. Trying to figure out the reason behind an external property, and asking more questions and creating arguments for solutions that could be achieved is the core of the gameplay. Ideally, more problems and entities should be generated by the act of asking questions, which are further defined with their own matrices, and so on as the player using the vehicle of the PC to interact with discrete elements of the world eventually fleshes out the world to multiple moving parts and creates story from within these interactions. These automatons would also serve as algorithms that allow you to run down a list to see how an element would react to an action a PC would take on the world, running through problems that might be affected and defaulting to the base description should the problem list be exhausted to determine "reaction" of an entity to an action.