More madness inspired by this: https://lizardmandiaries.blogspot.com/2022/10/matrix-automatons-solo-gaming-process.html
Avant-Garde Multiplayer Narrative Generator Edition:
Each player creates an entity they control, another player must give that entity a problem.
Once each player has an entity with a problem, game turns begin!
Players take turns to:
Gives another player’s entity a new problem (optional).
Attempt an action to solve one of their entities' problems.
When a player presents an action, the other player/s in the game may provide a counter argument why that action is not successful.
If there are no counter arguments to an action, it is successful.
If there are more than 2 players, all players can present a counter argument to the action. The active player picks the counter argument that takes place.
Whenever an action is countered by another player, the player who countered the action creates a new entity under their control (relating to the events of the countered action). The player whose action was countered may give that entity a problem.
Alternatively, the countering player must provide a new problem for the action attempting entity (related to why their action was not successful) and the countered player may give a new problem to one of the countering players entities (also related to the unsuccessful action).
Regardless of whether it is successful or not, all actions take place in the game world as an event.
All players take their turns in an order, a collective narrative will be made in the process.
An entity leaves the game if they have no problems.
When an entity leaves the game they are no longer under the control of any player.
The game ends when all of the entities have left the game (by having their problems solved).
Some might say that the player who does this first wins...
Lone Wolf Solo Edition:
Start with an entity with at least one problem.
Entity attempts to solve a problem through an action.
Regardless whether it's successful or not, an action creates an event - log event.
Use method of choice to determine success or failure of an action. I use: https://www.drivethrurpg.com/product/363342/Kontext-Spiel-d6
A successful action creates at least one new entity with at least one problem, and/or gives an existing entity at least one new problem.
An unsuccessful action creates a new problem for the entity attempting it.
After resolving an action add to/remove from entity problem lists as required.
Re-order the dynamic problem lists so the entity’s most pressing problem is at the top of the list.
An entity is considered "active' if it has any problems.
All active entities attempt an action in turns in the order they were created.
An entity is considered "inactive" if it has no problems. It does not act.
Play until you are bored.
Grognard Old School Player/s and Referee Edition (Beta):
One player is the referee, the other player/s are not.
The non referee player/s each create an entity with at least one problem. That is their Player Character that they control within the game world.
Each player takes it in turns to attempt to solve one of their Player Character’s problems through an action.
Note: Player Characters are notorious for attempting actions that appear to have little relevance to solving their problems, let alone anything resembling a correlation. Referees are advised to let such actions take place regardless.
The referee is responsible for all other aspects of the game! This process is detailed below!
Regardless whether it's successful or not, an action creates an event - log event.
Use method of choice to determine success or failure of an action. I use: https://www.drivethrurpg.com/product/363342/Kontext-Spiel-d6
A successful action creates at least one new entity with at least one problem, and/or gives an existing entity at least one new problem.
An unsuccessful action creates a new problem for the entity attempting it.
After resolving an action add to/remove from entity problem lists as required.
Re-order the dynamic problem lists so the entity’s most pressing problem is at the top of the list.
A Non Player Character entity is considered "active' if it has any problems.
All active entities attempt an action in turns in the order they were created.
A Non Player Character entity is considered "inactive" if it has no problems. It does not act.
Player Characters can attempt actions even when they have no problems. This will hopefully generate more problems for them .
Play until you are bored.
Definitions:
Entity: Some active force in the game world. An entity can be a person, a place, a setting, a god, an item, an atmosphere, a weather effect, anything at all. An entity just needs the capacity to have an impact on the game world.
Problem: Something that stops the game world being perfect and ideal for an entity.
Action: An argument presented by a player as to why something happens in the game world to resolve a problem for an entity.
Counter Argument: An argument presented by a player as to why an action is not successful.
Event: Things that happen in the game world because of both successful and unsuccessful actions. It is recommended to record events so everyone can remember what has transpired in the game world! The time scale and scope of the events of the game are dependent on the actions attempted by the entities.
Suggested Templates:
(These are HIGHLY and PASSIONATELY suggested to make the game more playable).
Entity:
Entity Type/category.
Entity Name and title/class/profession/etc.
Single sentence description outlining the entity’s essence.
Problems:
(Problem that exists for entity) because (reason for the entity’s problem).
(Problem that exists for entity) because (reason for the entity’s problem).
etc..
Problem:
(Problem that exists for entity) because (reason for the entity’s problem).
Action:
(Action happens) because of (reasons).
or
(Action resolves problem) because of (reasons).
Counter Argument:
(Action) is not successful because of (reasons).
Event Log:
Turn #: (Action resolving problem happened) because of (reasons). Or, (Action) did not not happen because of (reasons) (Make sure you mention the entities involved!).
Notes:
All of the above is very much Inspired by this post: https://ankleshot-woes.blogspot.com/2022/10/matrix-automatons.html
I've tried to come up with something similar to this, except ideally problems would somehow be generated during gameplay using the matrix game argument format. My take was that the player would first propose an action to achieve their objective, then the referee/generator (for solo) would argue against the character being able to perform the action, with the rationale being based on the predetermined themes of the scenario, which you would then interpret into an actual event/location/etc. in the game world. With this method you would prepare the scenario like a matrix game, where each character gets objectives, and also establish general themes/concerns as the focus of the game (for instance the concerns for exploring a cavern could be getting lost, darkness, hostile inhabitants, etc., which you would use to create specific problems based on the in-game circumstances), which would you would choose based on the kind of game you want to play.
ReplyDeleteYeah that's similar to how I see the "Player and Referee" version of the game playing out. My thought was that when the player started the game, their characters problem would be so large and broad that the first action they take would never be a success. That failure begins to generate the referee's entities which are the other components of the game (setting, npcs, monsters, treasures, etc, etc)
DeleteAfter playing a little bit solo with this methodology, I've found it works best for me if the problems are in the form of "quests" or definite courses of action to take to solve the problem, rather than static obstacles that block your progress. For instance in my game I came across a cave passage blocked by an impenetrable fungal wall; the wall is the initial problem, but then I rolled on a generator and interpreted that the ancient tribe which used to live in the area worshiped a fungus god, and that the wall could be removed by performing a ceremony of theirs, which I then further rolled to determine that I could learn how to conduct the ceremony by performing a séance and communicating with the ancients, and so on. Instead of the player blindly coming up with an action, there is a more concrete course of action to take, which still enables open-ended problem solving. I'm not sure if this is just what you intended anyway; I think this works well specifically for solo since it takes most of the generation process out of the player's hands, and lets you focus on the problem solving and character action.
ReplyDeleteGlad to hear you have been trying it out "definite courses of action to take to solve the problem" is the way it should be done. This makes the "automaton" component work much better - when its very obvious what an entity will do. This was very much my intention!
Delete