Moirai is a system that governs a social simulation experience from initialization, through the simulation, to its end. Previous social simulation experiences have usually utilized bespoke glue code that chains together the diferent aspects of running a social simulation, utilizing simulation either before play, during play, or after play. diferent initialization passes and simulation modules to enable a range of experiences that have not been shown before. This paper presents the syntax and semantics of the Moirai Domain Specific Language, and demonstrates how it can be used to create a variety of complex simulation-driven narratives inspired by case-studies from previously existing media.
In Greek mythology the Moirai were the the sisters of fate – Clotho, Lachesis, Atropos. In this paper, we discuss Moirai a system that governs a social simulation experience from initialization (Clotho or “spinner” the one who presided over birth), through the simulation (Lachesis or to stopping simulation (Atropos or “unturnable” the one who severed the string of life). Moirai uses a Domain Specific Language (DSL) that enables a user to set up a social simulation experience, covering a wide range of possible experiences.
Previous social simulation experiences have usually utilized bespoke glue code that chains together the diferences have utilized social simulation at diferent times of the experience: • Before Play – to set up the experience • During Play – to provide the simulation as the experience • After
Play – to provide an epilogue with all previous experiences (to our knowledge) using at most two of these aspects. Furthermore, these experiences have generally progressed in this one direction, with no branching or looping, limiting the types of experience possible.
Moirai is capable of chaining together diferent initialization passes, simulation modules, and filtering of nEvelop-O (A. Summerville) CEUR
CEUR
Workshop Proceedings (CEUR-WS.org) population which enables a range of experiences that have not been shown before. Of course, to not overstate our claim, the previous experiences have been authored (at some level) with Turing complete languages, so there is nothing inherently possible with Moirai that could not also be achieved in those languages. However, by providing a DSL that elevates certain operations the authoring
Moirai is a system intended to be used in conjunction
with social simulations. By social simulation systems, we
refer to computer processes that simulate individual
enti[
Likewise, the social simulation engines Comme il Faut
and Ensemble [
The work outlined in this paper explores the use of end, under a broader view of “social simulation” as any CEUR
ceur-ws.org
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License simulation at diferent parts of an experience. To this
rule driven process during which characters grow and
dissolve diferent relationships, the authors take
inspiration from a number of experiences that have utilized
varying levels of simulation. Friends at the Table – an
actual play podcast that uses games as the substrate to
tell an audio play – have used multiple games as setup for
longer arcs. In the simplest examples, for their Marielda
arc [
One aspect of social simulations that Moirai operationalizes is the use of diferent rulesets. Existing simulations often use diferent rulesets at various points of simulation.
For instance, the rules that govern the history generation
in the simulation-heavy Dwarf Fortress [
Toward this end, Moirai provides the functionality to
load in, add, and remove diferent rulesets, while
keeping the simulated entities in place. By rulesets, we refer
to specifications that dictate what behaviors simulated
entities can engage in, any preconditions those
behaviors may have, postconditions for how simulated
entities might be afected by taking the behavior, etc.
Furthermore, inspired by how Tabletop Role-Playing Games
(TTRPG) communities build of of existing rulesets with
new modules, it is possible to load in multiple ruleset
modules at once. For instance, if there existed a generic
high school simulation module, it could be mixed with a
supernatural horror module to create mixed-genre
simulations in the vein of Bufy the Vampire Slayer [
The specifics of Moirai can be broken down into four unloads the given ruleset files and removes them main properties: (1) the loading/unloading of ruleset files from the current rulesets (i.e., files which dictate what is able to transpire within the simulation), (2) the creation and filtering of simulated entities (i.e., the characters, locations, and other elements driven by the simulation), (3) the running of simulations (i.e., having the simulated entities change based on the possibilities specified by the rulesets), and (4) the control lfow governing these operations (i.e., repetition and selection of the aforementioned afordances). These four properties will now be discussed in further detail.
All of the operations leave the simulated entities in place throughout the adding, removing, and swapping of rulesets. The only major consideration to this is that the simulated entities should have consistent attributes and hooks across the modules. For instance, if our “high school” ruleset treated “degree of talkativeness” as a scalar variable referred to as extroversion, and the “supernatural horror” ruleset treated it as a ternary value of introvert/normal/extrovert, then the two modules wouldn’t realize these two variables are referring to to the same notion, leading to the modules failing to fully leverage their full potential synergy.
In the next section we will discuss Moirai’s operations for handling entity creation, filtering, and removal.
restoring entities in VARIABLE restores entities that were previously stored in the variable named VARIABLE • OPTION: keeping all (characters|locations) keeps all entities of the given class. The | symbol in this context represents an OR selection between the symbols in the parentheses (and does in all subsequent operation explanations). • OPTION: keeping entities where is STATUS keeps entities that have the STATUS property • OPTION: keeping entities where in PATTERN/ARITY keeps entities that have are in the PATTERN that has arity of ARITY. This is to disambiguate between patterns with the same name but diferent #’s of entities (e.g., the patterns lovers/2 and lovers/3 referring to couples and thruples, respectively) • OPTION: keeping entities where (in ↪ PATTERN1/ARITY1 | RELATIONSHIP) ↪ with entity (is STATUS | in ↪ PATTERN2/ARITY2) All social simulation based experiences share the commonality that there are entities that are being simulated.
Although in theory anything can be a simulated entity, to
provide the reader a frame of reference simulated entities
are often locations (e.g., a dining room in a home), and
the creatures and things that populate them (e.g., a dining
table, a person working on it, a cat napping beneath it,
etc.). These entities might have been authored to
provide a known starting point (e.g., Prom Week, Princess
Maker [
Toward enabling social simulation modalities that ex- been kept plore new use cases, Moirai enables entities to be initialized, filtered, stored, and restored. In conjunction with • OPTION: the ability to swap simulation rulesets, this allows for ssatvaesshtihnegenrteistitesitnhaStThAaSvHe not been kept in the diferent story patterns to be possible, as opposed to just variable STASH changing the rulesets alone. To the authors’ knowledge, • OPTION: the only existing social simulation experience to do any- saving kept as STASH thing of this form is Dwarf Fortress which creates a new saves the entities that have been kept in the varidwarf expedition at the start of Fortress mode. able STASH
Entity creation and management in handled with a
single operation “initialize”, though its execution can Moirai assumes that the given simulation engine has
be customized through eight options. The syntax and relationships which connect simulated entities (most
explanation of these operations and options in Moirai likely a given, since a social simulation without
relaare: tionships would be relatively boring) and the ability to
define arbitrary patterns (e.g., the love triangle pattern
• initialize INITIALIZATION+ [:OPTION]+ between three characters labelled RivalA, RivalB, and
initializes entities according to the INITIALIZA- Target where RivalA and RivalB both love Target, or the
TION files (which may be either deterministically unrequited love pattern between two characters, Source
authored or procedurally generated) with OP- and Target, where Source loves Target, but Target does
TIONs on what to do with the existing entities (if not love Source, etc.). These patterns can be viewed
any) through the lens of story sifting [
The options to filter can be at the unary level (an entity has a given attribute), the binary level (an entity is in a given relationship with another entity), or at the -ary level (an entity is found in a given pattern with other entities), with the higher levels allowing to match the other entities against other statuses or patterns or just looking at entities that are already kept.
To give a concrete example of why this might be useful,
let’s imagine a simulation focused on a wedding (such
as Father of the Bride [
After initialization (or perhaps re-initialization), the actual simulation of the wedding itself needs to play out, which we will discuss in the next section.
Moirai assumes that the given simulation engine can take one step at a time, and in between steps, the engine can be queried to find not only if a given set of conditions is true, but also the counts of how many entities for which the conditions are true. There exists a single operation for this (just as with initialization) with a number of options: • run (NUM STEPS | until CONDITIONS) either runs the simulation a set number NUM of STEPS steps or until a given set of conditions is found to be true (where a condition, we’ll soon see, equates to a set of queries on the simulation). STEPS can either be the keyword step (which is assumed to be smallest atomic step size) or a given unit of length (assuming the simulation keeps track of time at diferent levels) (e.g., days, weeks, months, years, centuries, millenia) • CONDITIONS := CONDITION (or CONDITION)+
other words it is a number of clauses (CONDITION) each of which consists of queries that are logically connected via and, all of which are connected via or • CONDITION := QUERY (, QUERY)+
via logical and (denoted as a comma “,”) • QUERY := COUNT entities CONDITION |
NUM STEPS
COUNT := NUM | NUM+ | (<|>|<=|>=|==)
↪ NUM
NUM := [
entities that are found in a given PATTERN, the number of entities found with (or without) a given STATUS, the number of entities found with (or without) a given RELATIONSHIP, or the number of STEPS (as discussed above). The CONDITIONs At this stage, we might want to move to a funeral specific ruleset; However, we can imagine that we would want our simulation to be able to handle a range of diferent large life events separately (e.g., it could look for both weddings and funerals). Putting this together (along with a fixed maximum duration for good measure), we would have: run until 2 entities in pattern ↪ getting_married/2 or 1 entities is recently_deceased, 1+ entities in pattern discovered_body/2 or 20 years
As we can see, Moirai enables the simulation to run until a set of conditions is true, but we are missing the ifnal piece: handling diferent scenarios in diferent manners given those conditions. Putting it all together, we have the final set of operations for Moirai, the control lfow operations.
The control flow operations of Moirai follow the standard suite of operations (e.g., if, else if, else, while, etc.). The only major departure is that Moirai lacks many opera- run until 2 entities getting_married/2 or tions commonly found in most languages (e.g., arbitrary 1 entities is recently_deceased, 1+ boolean comparisons, arithmetic, assignment), which ↪ entities in pattern lends a specific flavor to its handling of the control flow ↪ discovered_loved_ones_body/2 operations. We note that the astute reader might have or 20 years;
tial if statement (and subsequent block of code that runs, delimited by curly braces), optionally followed by some number of else if (optionally elif or elsif) statements, with an optional final else. The CONDITIONS are a disjunction of conjunctions as defined as above. A STATEMENT is one of the operations (either previously discussed or a control flow operation) in Moirai. The * symbol represents that zero or more of this set of symbols can be seen. The ? symbol means this symbol my appear either zero or one time. • while (CONDITIONS|ITERATION (<|<=) NUM) ↪ {STATEMENT+} ITERATION := (iterations|i)
• yield
ing program (perhaps to accept user input), but picking up exactly where it left of when Moirai is told to run again. • choose [ (NUM : {STATEMENT+})+ ]
inner code blocks to run. NUM is the weight associated with the given block of statements, used to bias the selection away from a uniform distribution.
These control flow operations allow Moirai to chain together arbitrary sequences of the operations. For instance, let’s return to the previous wedding / funeral example. The diferent events would have their own rulesets and initialization steps, so we need to be able run the correct simulations: ↪ ... } else {
... Now, let’s say that we wanted this whole thing to run until 5 such events had occurred, it would be as simple as wrapping all of the above in the following block: while iterations < 5 {
...
Moirai enables many diferent possible modalities of simulations, and in the following section we will discuss diferent case studies, first progressing though how existing experiences could be implemented with Moirai before moving on to other possibilities inspired by non-social simulation based literature, film, and video games.
News
These three categories make up the main delineations in how social simulation has been used up to this point.
We note that experiences can use social simulation in multiple categories – e.g., Dwarf Fortress uses it as both substrate (history generation) and experience (fortress mode); However, it is common for an experience to use it in only one mode – nearly every “social simulation” game uses it solely as experience (e.g., The Sims, Prom Week, Tokimeki Memorial, Princes Maker, etc.). For a visual representation of this continuum see figure 1. We will now examine how these experiences would be set up in Moirai. 4.1.1. Social Simulation as Substrate The simplest example is an experience that uses it solely as substrate. In this way, the world is initialized, it runs, and then stops – at which point the simulation is used as content for some (elided here) downstream process: load simulation.lachesis; initialize world.clotho; run 200 steps; 4.1.2. Social Simulation as Experience In the following sections we will first discuss how social Not quite as simple is something that uses social simulasimulation has been utilized historically in a variety of tion solely as a precursor to the core experience, but in experiences. For these cases, we will provide a demon- large part it looks much the same: stration of how it could be implemented via Moirai. We will then discuss more complex use cases of Moirai and the kinds of experience that it can enable. load simulation.lachesis; initialize world.clotho; while is simulation_still_running { run 1 step; yield; }
To begin, we will first examine a number of diferent In this case, the simulation runs only one step at a
social simulation experiences, and their use of social sim- time before yielding to the driving experience to make
ulation. To provide some vocabulary, we will examine the game play out as it should.
social simulation in various roles:
• Substrate – Social simulation that is used before 4.1.3. Social Simulation as Performance
the play experience to provide the “world” that Finally, we come to simulation as performance. However,
the player experiences. Examples include: Dwarf we will note that it looks (and is) identical to simulation
Fortress, Thousand Threads [
Fortress, Prom Week, and Princess Maker run 200 steps; • Performance – Social simulation is used after play (if any exists) as a means of providing con- The only diference comes from the framing experience tent to the player (or audience member) to receive. – does the player interact with the simulated world or Examples include: Sheldon County, Cozy Mystery are they simply a passive audience member? Simulation as Substrate
Simulation as Experience
Simulation as Performance
The Sims
Princess Maker Tokimeki Memorial
Prom Week Bad News
Dwarf Fortress
Bad News
Sheldon County
Proposed Stand By Me experience
Proposed Back to the Future experience Simulation Before Play
Simulation During Play
Simulation After Play 4.1.4. Previous Complex Experiences As noted in figure 1 there are two noted experiences that use social simulation in various modes – Dwarf Fortress and Bad News – and we will know show how Moirai could be used to drive these experiences.
Dwarf Fortress uses social simulation at a broad level for history generation before transitioning into a more ifne-grained moment-to-moment simulation following a dwarven expedition to create the titular mountain fortress. In Moirai this would look like: //Substrate load history_generation.lachesis; initialize world.clotho; run 250 years; //Experience load dwarf_simulation.lachesis; initialize fortress.clotho; while is simulation_still_running { run 1 step; yield; }
This is just the concatenation of simulation as substrate and experience. Bad News used social simulation as both the substrate that the player explored and as performance for an epilogue where the player got to see how life panned out for the characters they encountered in their play through. In Moirai: //Substrate load small_town.lachesis; initialize small_town.clotho; run 140 years; //Experience: Player explores simulated world yield; //Performance run 40 years;
Bad News used the same simulation code and the exact same world constructed via simulation for its epilogue, so there is no need for anything other than running during the “performance” portion. In the next section, we will explore a variety of more complex permutations of simulations that are enabled by Moirai’s features.
In the following sections we will discuss a number of diferent design patterns that Moirai enables. We will detail the types of experience that the pattern enables and show sample code. 4.2.1. Coarse Simulation to Fine Simulation –
Murder Mystery/RomCom initialize manor.clotho :keeping entities ↪ where in have_motive/2 :keeping entities where in relationship/2 ↪ with entity in kept; run until 1 character is murdered; Similarly, a romantic comedy like My Best Friend’s Wedding might look like: //Coarse history generation We will start with the simplest mode of combining simu- load modern.lachesis; lations into an experience, which is similar to the pattern initialize modern.clotho; found in Dwarf Fortress in which various levels of sim- run until 3+ characters in pattern ulation are chained together. The key diference here ↪ marriage_love_triangle/3; is that characters will carry over between the simula- //Once a love triangle pops up and 2 are tions; in Dwarf Fortress simulation begins coarsely, with ↪ getting married to each other, move to creation-myth style exploits of gods and other fantasti- ↪ the wedding cal characters who—though not explicitly present in the load wedding.lachesis; ifner-grained fortress-mode simulation—provide raw ma- initialize wedding.clotho :keeping entities terial for paintings, songs, and other simulated cultural ↪ where in love_triangle/3 artifacts. :keeping entities where in family_of/2 with
A large number of tropes in various forms of media ↪ entity in getting_married/2
often assume some sort of shared backstory and history :keeping entities where in good_friend/2
for the characters that occurred before the portrayed ↪ with entity in getting_married/2;
narrative, but carries over and informs the narrative. run until 1+ characters in
For instance, a closed room murder mystery such as ↪ romantic_misunderstanding/2;
Murder on the Orient Express or Gosford Park relies In both cases there is a coarse-grained simulation that
on the characters having intertwined histories such runs until some conditions are met, then characters are
that a large number of characters will have motive ifltered based on their relationships to each other, and
for the murder, but the narrative ostensibly occurs then the final fine-grained simulation occurs until some
after that history has occurred. Similarly, a romantic culminating event has occurred.
comedy such as My Best Friend’s Wedding [
:keeping entities where is main_character; run until 1+ characters in episode_completed; 4.2.4. Full Continuum Usage – Stand By Me } run 30 years; yield; //Player sees the changes initialize fifties.clotho :restoring fifties_world;
One final usage is using social simulation across the full spectrum of before, during, and after play. While this is not as complex as the previous examples, perhaps, it } is still an example of social simulation that is enabled by Moirai used in a way that has not been implemented
This assumes that there is still substrate that is gener- in other experiences (to the authors’ knowledge). The
ated as history, but it is certainly conceivable for that por- touchstone for this usage is something like the film Stand
tion to be removed and replaced with a purely authored By Me. In Stand By Me, the characters have a shared
initial world state. Although the proposed experience history, the narrative unfolds and relationships are tested
above is not identical to the plot of Back to the Future, it and changes occur, and then the epilogue discusses the
strikes a similar tone. Here, ten years of “forties world” lives that the characters had after the main events of the
is simulated as substrate and then recorded as “fities story. In Moirai we would envision it as:
world” for safe keeping. The player is given a week to
experience and influence the entities of fities world, and //Coarse history generation
then the simulation is run for another thirty years (bring- load history.lachesis;
ing us to the eighties), to see how these entities ended up. initialize setting.clotho;
The experience then returns to the stored “fities world”, run 2 years;
allowing the player to make diferent choices, and see load main_event.lachesis;
what impact those diferent choices have on the lives of while iterations < 7 { // Play for 1 week
the characters thirty years later as compared to their pre- yield; //Player interacts
vious week-long romp in the fities. As authored above run 1 day;
this process can repeat indefinitely, or until some in-game }
goal criteria is achieved (e.g., ensuring two high-school load epilogue.lachesis;
sweethearts remain in love as they grow older). run 25 years;
4.2.3. Episodic Structure – The Odyssey
Another pattern common in various forms of media is
where a core cast of characters encounters diferent
scenarios in an episodic structure. This dates back to at least
the Odyssey [
:keeping entities where is main_character; run until 1+ characters in episode_completed; load episode2.lachesis; initialize episode2.clotho
:keeping entities where is main_character; run until 1+ characters in episode_completed; load episode3.lachesis;
In many ways, this is very much like a combination of Bad News (history and epilogue generation) and Dwarf Fortress (history generation and active simulation).
This paper introduces Moirai, a Domain Specific Language which facilitates the creation of interactive experiences that leverage social simulation systems. In particular, it is intended to be used for experiences in which simulated narrative content is used before, during, and after play. Through a demonstration of case-studies— Moirai encodings of popular narratives from literature, iflm, television, and non-simulation games—the authors have shown the versatility of the system, and its capacity for enabling new types of simulation-driven playable experiences that mirror popular tropes and narrative genres in other forms of media.
Natural future work for this project includes building out one or more of these case studies into an actual playable experience. Doing so will enable Moirai to be evaluated on its merits both as an authoring assistant and on the quality of the produced experience. This in turn may lead to further insights for language features that could be added to Moirai, leading to greater ease of use and more varied narrative output.