# Curating Simulated Storyworlds — Chapter 11: Hennepin > NOTE: THIS IS A MARKDOWN CONVERSION INTENDED FOR LLM CONSUMPTION. > IF YOU ARE A HUMAN BEING, READ THE PDF INSTEAD: > https://jamesryan.computer/papers/2018_ryan_curating_simulated_storyworlds.pdf > > The PDF is the canonical document, typeset with every figure and table. This file > is a plain-text conversion of the LaTeX source, published HERE so that software agents > can read the thesis without parsing a PDF. It is lossy and is not meant for humans. > > This file is chapter 11 of 14 only: Hennepin (~32,000 words). > See below for links to markdown conversions of the individual chapters. > > **Structure.** Sections are `##`/`###`/`####` headings. Cross-references are resolved to > their numbers ("Section 3.1.1", "Chapter 5"), so a heading can be searched for directly. > Citations are inline bracketed keys such as `[ryan2017grimes]`; every key used in the text > has an entry in the bibliography, formatted as `- **[key]** Author. Title. Venue, Year.` > Footnotes appear inline as `[Note: ...]`. > > **Conversion limits.** Figures and most complex tables appear as `[Figure omitted]` or > `[Table omitted]`. Code fences carry no language tag. A few diacritics in author names > were simplified from the Latin-1 source. > > **All files.** > > Index (this list, plus the abstract; small): https://jamesryan.computer/thesis/index.md > Whole thesis in one file (large, ~1.6 MB): https://jamesryan.computer/thesis/full.md > > By chapter: > - 01. Introduction (~4,600 words, ~30 KB) — https://jamesryan.computer/thesis/01-introduction.md > - 02. Defining Emergent Narrative (~6,900 words, ~47 KB) — https://jamesryan.computer/thesis/02-defining-emergent-narrative.md > - 03. The Pleasure of Emergent Narrative (~21,000 words, ~135 KB) — https://jamesryan.computer/thesis/03-the-pleasure-of-emergent-narrative.md > - 04. The Pain of Emergent Narrative (~41,000 words, ~268 KB) — https://jamesryan.computer/thesis/04-the-pain-of-emergent-narrative.md > - 05. Refining Emergent Narrative (~11,000 words, ~73 KB) — https://jamesryan.computer/thesis/05-refining-emergent-narrative.md > - 06. James Ryan Generator (~2,800 words, ~16 KB) — https://jamesryan.computer/thesis/06-james-ryan-generator.md > - 07. World (~20,000 words, ~129 KB) — https://jamesryan.computer/thesis/07-world.md > - 08. Case Study: Diol/Diel/Dial (~9,300 words, ~59 KB) — https://jamesryan.computer/thesis/08-case-study-diol-diel-dial.md > - 09. Talk of the Town (~25,000 words, ~162 KB) — https://jamesryan.computer/thesis/09-talk-of-the-town.md > - 10. Case Study: Bad News (~22,000 words, ~132 KB) — https://jamesryan.computer/thesis/10-case-study-bad-news.md > - 11. Hennepin (~32,000 words, ~209 KB) — https://jamesryan.computer/thesis/11-hennepin.md > - 12. Looking Ahead: Sheldon County (~11,000 words, ~75 KB) — https://jamesryan.computer/thesis/12-looking-ahead-sheldon-county.md > - 13. Conclusion (~2,700 words, ~17 KB) — https://jamesryan.computer/thesis/13-conclusion.md > - 14. Bibliography (~29,000 words, ~233 KB) — https://jamesryan.computer/thesis/14-bibliography.md > *The construction of the system is inevitable.* — Sheldon Klein Toward the end of my development work on *Talk of the Town*, I became interested in the idea of automatically identifying the kinds of narratively potent emergent scenarios that undergird each *Bad News* performance. This would mean *automatic story sifting*, as opposed to the manual procedure that I carry out in my capacity as wizard in that piece. Since my method for doing this myself relied on livecoding queries to a simulation instance, it seemed like I could simply have the automatic story sifter utilize the same code sequences that I construct on the fly during a performance. Of course, my sifting process is generally exploratory and improvisational, as the examples in Section 10.3 illustrated, but I figured that I could start by crafting functions for identifying recurring scenario types that I frequently excavate, such as cases of *unrequited love* or *love triangles*. Later on, I could explore the development of *sifting heuristics* that the automatic story sifter could use to search for material that is intriguing or pleasurable—this could work something like Doug Lenat's system *AM* [lenat1976artificial], which carries out heuristic exploration of a possibility space to automatically discover interesting or aesthetically pleasing mathematical concepts. As a first move in my investigation of automatic story sifting, I wrote up little functions that could be used to search over a town's history to identify particular scenarios that tend to emerge in *Talk of the Town* towns. For example, here is some Python code that can be used to automatically excavate cases of unrequited love (and package them up as objects of an ‘UnrequitedLove‘ class, whose definition is not included here): ``` def excavate_unrequited_love_cases(town): """Sift for cases of unrequited love.""" unrequited_love_cases = [] for lover in town.residents: for loved in lover.loves: if lover not in loved.loves: unrequited_love_cases.append( UnrequitedLove( lover=lover, loved=loved ) ) return unrequited_love_cases ``` In this code, the attribute ‘loves‘ resolves to a list containing all the other characters with whom one is in love, where being in love is operationalized as holding a spark value above a certain threshold. As the listing expresses, the function would not just excavate a single case of unrequited love, but every single case in the town's history. Here is another function that sifts through this accumulated history for cases of a more specific phenomenon, the love triangle: ``` def excavate_love_triangles(town): """Sift for love triangles.""" love_triangles = [] for a in town.residents: for b in a.loves: for c in b.loves: if a in c.loves: if a not in b.loves: if b not in c.loves: if c not in a.loves: love_triangle.append( LoveTriangle( a=a, b=b, c=c ) ) return love_triangles ``` This function finds all cases of character triads ${a, b, c}$, such that $a$ is in love with $b$, $b$ is in love with $c$, $c$ is in love with $a$, and none of the love is reciprocated. This was fairly interesting, and it was pretty easy to craft functions like these, but much of the intrigue in *Talk of the Town*, and in turn in *Bad News*, concerns the *stacking* and *interlocking* of multiple emergent scenarios. For example, let us reconsider Adam Summerville's favorite scenario to emerge in the simulation, which I quoted in Section 9.3: > My favorite situation to arise from the simulation was something like a Shakespearean tragedy, set in small town America. The deceased was the scion of a family that had run one of the two bars in the town, with a history nearly as long of that of the town itself, and he was in love with the daughter of the owner of the other bar in town. The two bar-owning families had hated each other for generations, but the two children of the families were able to get past that and fall in love. For this to happen, only to have tragedy befall their star-crossed love feels like Bad News was cribbing from one of my favorite movies, “Scotland, PA”—a retelling of Macbeth in a fast food restaurant in the 1970's. I will always be amazed by the kinds of emergent stories that Bad News is capable of generating. [Note: Personal communication, June 14, 2018.] How would the automatic story sifter excavate this material? My sense was that a good approach would be to break down such a situation into its component scenarios and then craft functions so that each of those scenarios could be recognized. From here, the next step would be to specify how instances of the component scenarios interlock to produce the targeted higher-order structure. If it were equipped with a capacity to both sift for the components and reason about the interlocking of instances of each, the automatic story sifter could excavate examples like Adam's by finding cases that satisfy the interlocking criteria. Let us work through this in a detailed example. First, what are the components of Adam's example? At its foundation is a bitter rivalry between two long-established family businesses, which could be decomposed into a more specific explanation such as this: there are two businesses that have existed in the town for a long time, the businesses are family-owned, the businesses are in competition, and the family members that run the businesses do not like one another. To start, here is a function for sifting out long-running businesses: ``` def excavate_town_institutions(town): """Sift for cases of long-running businesses.""" # Operationalize ‘long-running' by number of years threshold = 40 town_institutions = [] for business in town.businesses: if town.year - business.founded >= threshold: town_institutions.append( TownInstitution( business=business ) ) return town_institutions ``` This allows the sifter to excavate long-running businesses, but it also needs to know which ones are family businesses. One way to operationalize this is to say that a family business is one whose owner was preceded by an owner of the same family. The following code captures this: ``` def is_family_business(business): """Return whether the given business is family-owned.""" owner = business.owner.person previous_owner = business.owner.preceded_by.person if previous_owner in owner.extended_family: return True return False ``` Of course, this notion could have been operationalized differently. We could instead only accept circumstances in which every owner of the business was related to the previous one, or we could say that the business must be passed from parent to child each time, or what have you. In my view, it is probably best to equip the automatic story sifter with liberal policies, since that increases the chance of excavating usable material. As for the notion of two businesses being in competition, this could be operationalized by them being of the same type (e.g., ‘bar‘), but a richer (and also more inclusive) policy might instead look at whether the businesses have services in common: ``` def competitors(business, other_business): """Return whether the given businesses are in competition.""" business_services = set(business.services) other_services = set(other_business.services) if business_services & other_services: # Set overlap, thus common service(s) return True return False ``` Finally, the sifter requires means by which animosity between the families may be detected. While a strict notion might require something like extreme disdain between each and every member of the respective families, a liberal (but still reasonable) policy might simply require animosity between the respective business owners. Here is a function that captures the latter by operationalizing animosity using *Talk of the Town*'s existing ‘enmity‘ relation: ``` def animosity(character, other): """Return whether there is mutual animosity between the given characters.""" if character in other.enemies: if other in character.enemies: return True return False ``` Now, to sift for bitter rivalries between family businesses, which is the foundation of Adam's example, the sifter can simply search for cases of interlocking between each of the component scenarios. Given the above code examples, it may do this automatically by using a function such as this: ``` def excavate_family_business_rivalries(town): """Sift for cases of bitter rivalries between long-running family businesses.""" family_business_rivalries = [] town_institutions = excavate_town_institutions(town) for business in town_institutions: if not is_family_business(business): continue for competitor in town_institutions: if not is_family_business(competitor): continue if not competitors(business, competitor): continue owner = business.owner.person other_owner = competitor.owner.person if animosity(owner, other_owner): family_business_rivalries.append( FamilyBusinessRivalry( rivals=(business, competitor) ) ) return family_business_rivalries ``` Finally, at the heart of Adam's scenario is a case of forbidden love between members of the rival families. In his specific example, one is the owner of one of the businesses and the other is the daughter of the rival owner. While we could certainly detect such specifics, it is again probably a better idea to be more indiscriminate, so as to increase the likelihood of successful sifting. Here is code that the automatic story sifter could use to excavate forbidden love of the type that is central to Adam's example: ``` def excavate_forbidden_love(town): """Sift for cases of forbidden love between members of hostile families that operate long-running rival businesses.""" forbidden_love_cases = [] family_business_rivalries = ( excavate_family_business_rivalries(town) ) for rivalry in family_business_rivalries: business, competitor = rivalry.rivals first_family = ( business.owner.person.immediate_family ) second_family = ( competitor.owner.person.immediate_family ) for lover in first_family: for loved in lover.loves: if loved in second_family: if lover in loved.loves: forbidden_love_cases.append( ForbiddenLove( lovers=(lover, loved), rivalry=rivalry ) ) return forbidden_love_cases ``` In this code, only members of the rival business owners' *immediate* families are eligible for forbidden love, because here too liberal a definition (such as extended family) could potentially lead to the excavation of false positives, such as lovers who are actually related to both families (through in-laws or distant cousins). In any event, defining such *sifting patterns* (see Section 5.4) requires iteration and testing to make sure that the patterns are liberal enough to lead to the successful excavation of material in most storyworlds, but not so indiscriminate as to admit cases that do not actually instantiate the targeted scenario. The ultimate goal of the story sifter is to excavate narratively potent material, and in the above code examples, such extracted material is packaged into objects of scenario-specific classes, such as ‘ForbiddenLove‘. Rather than package up all the material that may be relevant to a scenario, the sifter includes only the critical components that underpin it—for example, the two lovers and family-business rivalry that inhibits their love. As the code examples also illustrate, such packages of material—let us call them *nuggets*—may be referenced in the sifting patterns that are used to sift out other material. As such, nuggets may be used to compose the material of other nuggets, such as with the ‘ForbiddenLove‘ class's ‘rivalry‘ keyword argument (which expects an object of the class ‘FamilyBusinessRivalry‘). [Note: Here, I am using Python terminology simply because the above code examples are in that programming language. Of course, these are basic concepts and implementations may vary wildly—indeed, any programming language or computational framework could be utilized. With these examples, my goal is to elucidate story sifting at some level of detail, so that is why I use code listings and terminology.] While not all of the relevant material is packaged up, the critical components can work as hooks into the chronicle that may be utilized to extract other additional material. For example, the components of a ‘ForbiddenLove‘ nugget can work as hooks by which the owners of the rival businesses and the relationships between those owners and the lovers could in turn be extracted. In the fall of 2016, I developed an automatic story sifter that worked according to the principals that I have just outlined, but it led me to a painful realization about *Talk of the Town*: the simulation's representation of character actions is too abstract for actual emergent stories to obtain. The system could extract intriguing nuggets, such as cases of forbidden love, but the point of story sifting is to hand off the excavated material to a *narrativizer* module that actually constructs a narrative artifact out of that material. As abstract scenarios, the extracted *Talk of the Town* nuggets made narrativization an extremely difficult challenge. For example, if a narrativizer was to tell a story of forbidden love, given a nugget capturing such a scenario, how would it do it? It could inspect the chronicle for data capturing the history of each business, but there would not be much intrigue there: the history of a business in *Talk of the Town* is essentially a series of names and dates capturing who owned it and who worked there and for how long. Certainly the narrativizer would want to tell the story of how the lovers fell in love and how the owners became enemies, but the data capturing such concerns is a series of abstract social interactions: > - ‘January 13, 1973: social interaction at Zilencio [lovers meet]‘ - ‘Feburary 22, 1973: social interaction at Zilencio [attraction grows]‘ - ‘April 6, 1973: social interaction at Horswill Farm Park [attraction grows]‘ - ‘October 9, 1973: social interaction at Lessard's Lounge [attraction grows]‘ - ‘...‘ - ‘March 11, 1975: social interaction at Zilencio [lovers fall in love]‘ - ‘August 21, 1975: social interaction at Zilencio [lovers fall more in love]‘ - ‘...‘ There is some minor intrigue here—for instance, Zilencio being an important place for the lovers—and the system could exploit that, but to tell an actual story that recounts such abstract concerns would require the narrativizer to essentially carry out all of the invention that is required in top-down story generation. Of course, this is exactly the narrativization task that Ben carries out in his capacity as *Bad News* actor. As I showed in Section 10.3, in our curation set-up I manually excavate narratively potent nuggets and deliver these to him via chat, and he then augments them to build stories that he imparts to the player conversationally. For *Bad News*, this abstractness is actually an appeal, since Ben would not have time to internalize a detailed emergent story, and moreover it would difficult to avoid contradicting one because that would require the memorization of myriad details. So while operationalizing Ben's narrativization process would make for a very interesting project, it would be an especially daunting one due to the abstractness of *Talk of the Town*'s generated material. [Note: One prospect for a *Talk of the Town* automatic story sifter is to serve as a *Bad News* wizard's assistant: the system could excavate nuggets for use by the wizard, to save on the time and energy of excavation by livecoding. Such a system would be especially useful for wizards who are not me (and thus not as familiar with the *Talk of the Town* codebase), such as Jonathan Lessard (working in his Montreal troupe with actor Noah Drew) and anyone who would play the ‘home version' of the game that we have discussed [samuel2016crafting, p. 383]. As I noted above, Adam Summerville is interested in developing the latter as one of his first research projects at Cal Poly Pamona, where he is now a professor. If he does find the time and energy to develop the project, I imagine an automatic story sifter will be a central component of the framework.] As I was exploring the prospect of narrativizing *Talk of the Town*'s abstract material, I recalled a critique that I had received in an anonymous review of a paper on the system's social simulation [ryan2016sbg]. Here is an excerpt from Reviewer #2's feedback on my original submission: > The relationship between two characters is modelled by two numbers: platonic affinity and romantic affinity. In such a simple two-factor model, most of what makes relationships interesting has been lost. [...] the *reason* for the relationship to be in the state it is has been lost. E.g. Smith hates Jones *because* he ripped him off. [...] it just updates the relationship deterministically based on the stats of the two characters. It would be impossible in this model for X to remember the reason why he hates Y because there was no action to begin with that prompted this hatred. [Note: Anonymous personal communication, June 6, 2016.] The reviewer had pinpointed the very problem that I was encountering in my attempt to narrativize the material excavated by my automatic story sifter. [Note: To be fair, as I emphasize in that paper [ryan2016sbg], *Talk of the Town*'s social simulation was designed to be extremely lightweight in order to save memory and computation for the heavyweight modeling of character knowledge phenomena that is the hallmark of the system. In the case of *Bad News*, we need the system to create the next town in a few minutes or less, and a richer social simulation would likely preclude that, considering the number of characters in the storyworld. Indeed, as I will explain shortly, in *Hennepin* it may take many hours for a storyworld's history to be simulated, but I am specifically targeting second-order experiences that can work under that constraint. For example, in *Sheldon County*, the subject of the next chapter, an entire non-interactive media experience (a generated podcast) is produced all at once following the creation of a *Hennepin* storyworld. This introduces a latency on the order of a day between a potential experiencer deciding to experience the work and her actual engagement of it, but this is not a major problem given that the entire experience is produced at once, in full.] Moreover, while the critique captured that character relationships are too abstract, the more troubling issue is that *all character activity* in *Talk of the Town* is too abstract for narrativization. The only fine-grained actions that characters take are social interactions (abstractly construed), going to a place (as part of the routine modeling), being at work, being at home, being on an errand, and a few others. Of course, there are a series of major life events that are modeled—marriage, divorce, birth, death, business founding, home construction, and a few more—but these are also fairly abstract. For example, when a house is constructed, there is no duration to that action, but rather it just suddenly transpires all at once. It may involve some component actions, like contracting an architect and builders who are working at the construction firm that day being recorded as having worked on the job, but still this is fairly abstract. More troublingly still, none of these events are particularly interesting—rather than providing narrative intrigue, they are meant to drive the evolution of the town's infrastructure. Finally, the only activity that is modeled at high granularity is the mechanics underpinning the simulation of character knowledge phenomena, but due to the nature of what beliefs are formed about—largely benign appearance features, such as the size of a character's nose—little intrigue is yielded by this subsystem either. In total, while I was thrilled with the shape that *Bad News* had taken, I had become disenchanted with the prospect of using *Talk of the Town* as the simulation engine in a fully automatic work of curationist emergent narrative, which is what I wanted to build next. As such, I decided to develop a new simulation engine, and I wanted it to work like a combination between *Talk of the Town* and *Comme il Faut* [mccoy2014social], which is the AI system that undergirds *Prom Week* [mccoy2011prom,mccoy2013prom,samuel2015playing]. In *Comme il Faut*, characters reason over the state of the storyworld to decide which *fine-grained actions* they want to take on a given timestep; the actions authored for *Prom Week* include examples such as ‘flirt‘, ‘insult‘, and ‘ask out‘. As such, my idea was to build a new engine that would again model the history of a storyworld, since that is a hallmark of my practice, but in that period characters would now take fine-grained actions. So rather than, for example, two characters Michael and Noah having an abstract social interaction on the night of October 5th, 1982, at the Law Offices of Mateas and Wardrip-Fruin, the two might ‘reminisce‘ at that time and place. Critically, these fine-grained actions would evolve relationships, so that a case of forbidden love, to revisit the example from above, would emerge out of a history of concrete character interactions. Likewise, I wanted actions to also serve as the primary drivers of the evolution of the storyworld itself—this would enable the generation of concrete action sequences that could be sifted to support feasible automatic narrativization into recounted emergent stories. My initial plan for doing this work involved the integration of *Talk of the Town* and *Ensemble* [samuel2015ensemble], which is a successor to *Comme il Faut* that democratizes its technology so that *Prom Week*-style ‘social physics' may be utilized in other projects. Here is how I outlined this plan in my original thesis proposal (which featured a temporary renaming of *Talk of the Town* to *Talk/Town*): > We are now working to integrate the Ensemble Engine with *Talk/Town*, which will enable us to use its authoring tool to quickly specify rules for agent decision making. In an extension to the system that we are currently developing, agents will also use these decision procedures to select finer-grained social actions to take (*e.g.*, *flirt*, *insult*, *confide*, *reminisce*) on simulated timesteps. [ryan2016situated, p. 11] While eventually I decided to develop my own approach to modeling character actions, the methodology of the *Comme il Faut* and *Ensemble* tradition remained a major influence. For those that are familiar with both projects, I think ‘*Talk of the Town* meets *Prom Week*' is a good descriptor for the simulation engine that would eventually culminate from this refined approach. [Note: During the initial period of exploration into the integration of *Talk of the Town* and *Ensemble*, then undergraduate Joyce Scalettar was an important collaborator who sketched out valuable designs for potential emergent action structures. Even though I did not end up taking that technical approach, her work was important to the trajectory of the project.] *Hennepin* is a simulation engine that models an American county over the course of its history, with particular attention to the lives of the characters who live there. It departs from my earlier simulation engines, *World* and *Talk of the Town*, by modeling its storyworlds with much more detail. Instead of abstract social interactions and monolithic life events, its generated histories are constituted in accumulations of concrete character actions that are modeled at roughly the level of granularity of *Prom Week*'s social actions. Due to the way that action selection works—this is explained in Section 11.2.7—character actions may contingently unlock subsequent character actions, which enables both the emergence of concrete storylines and the identification of instances later on. [Note: This method also enables the emergence of (improbably) interlocked storylines, which is the aesthetic hallmark of this simulation engine.] While *Hennepin*'s architecture is fully implemented, I have not yet completed a second-order media experience that is driven by it; I am currently developing one in the form of *Sheldon County*, the subject of the next chapter. Thus, while in the chapters on *World* and *Talk of the Town* I could describe static versions of the simulation engines that were used to drive completed experiences, this is currently not possible with *Hennepin*. Due to the nature of feedback between the development of a simulation engine and an experience that it is meant to enable, *Hennepin* will almost certainly change in the future, but in this chapter I will describe it in its current state (at the time of this dissertation being filed). Before proceeding, I should clarify my approach to evaluation. Because much is in flux, it is not possible to appraise *Hennepin* like I did my earlier simulation engines: through the lens of a completed second-order media experience. In lieu of such appraisal, in this chapter I will situate *Hennepin* against related technical work. For clarity, I discuss this related work in a distributed manner, throughout the chapter, as the pertinent concepts arise in my discussion. Finally: *Hennepin* is named for the county in which I grew up—Hennepin County, Minnesota—and this system is being reported for the first time here. ## Modeling Each *Hennepin* storyworld is modeled as an American county that is populated by several hundred characters (at any time), who purchase and subdivide land, start towns, establish businesses, construct buildings, produce artifacts, interact with one another, and contemplate on their lives. To develop this simulation engine, I started with the *Talk of the Town* codebase and modified certain elements according to the design goals that I outlined in the opening of this chapter, namely my desire to model fine-grained character actions. As such, much of the code from my earlier engine remains as a technical substrate, which means I have already explained some of *Hennepin*'s modeling. In this section, I will describe new features that are introduced with this engine and will point back to my earlier descriptions of components that have been directly inherited from *Talk of the Town* (and, in some cases, *World*). ### Time As in its predecessor *Talk of the Town*, time in a *Hennepin* storyworld proceeds by *day* and *night* timesteps, not all of which are actually simulated. While there is no explicit modeling of time within a timestep, character actions occur one at a time, and so there is an implied temporal ordering of simulated events. ### Characters *Hennepin* characters are generally modeled in the same way as *Talk of the Town* characters, though with some modifications that reflect my growing inclination toward a notion of character *believability* that borrows more from media tropes than from social science. I will tell the story of that evolution in Section 11.1.2, since it is particularly exemplified by the model of character personality that I have adopted in this system. #### Name Character *names* are generated using essentially the same procedure that is used in *Talk of the Town*, which I outlined in Section 9.1.2. As I noted there, a favorite detail of mine concerns the utilization of historical data that specifies the relative frequencies of the most common baby names through American history. Again, an additional forenames corpus is also drawn from in rare cases. This is the very corpus that drove *James Ryan Generator*—it is a thread knit through the entire history of my computational practice. *Hennepin* differs from its predecessor in terms of the naming procedure by incorporating new concerns into the probabilities that determine whether a child will be named for a family member, or given a hyphenated surname. Here, the new character personality traits and value systems, each of which I will describe shortly, are at play. For example, high scores for the trait ‘dutifulness‘ and for the value ‘tradition‘ will increase the likelihood of naming a child for a family member. #### Appearance The modeling of character *appearance* is likewise inherited outright from *Talk of the Town*, and so this aspect of *Hennepin* has already been explained at length in Section 9.1.2. As I discussed in that section, the curiously detailed modeling in this subsystem originated in the design of *Talk of the Town* (2015), a videogame in which character appearance was going to be central. While I do not envision appearance being particularly important in *Sheldon County*, I did not see the point of abandoning this aspect of the codebase, since the modeling is very lightweight and character appearance could conceivably be useful. #### Personality In developing *Hennepin*, I decided to overhaul the modeling of character *personality* that had been intact since *World* by adopting a 50-trait typology that was developed somewhat recently by Tarn Adams for *Dwarf Fortress* [dwarf]. This design decision exemplifies a shift in inclination toward a notion of character believability that is more influenced by media tropes than by social science. In this section, I will tell the story of this personal evolution, which transpired gradually over the course of my tenure as a PhD student at UC Santa Cruz. [Note: To jump to technical details about character personality in *Hennepin*, skip to the end of this subsection.] As I explained in Sections 7.2.2 and Section 9.1.2, my earlier simulation engines utilized the five-factor (‘Big Five') model of personality [mccrae1992introduction,wiggins1996five]. This utilization originated in a period of initial development work on *World* that preceded my time at UC Santa Cruz. After I arrived at the Expressive Intelligence Studio, I discovered that my coadvisor Michael Mateas is a critic of the Big Five as a model of character personality in procedural narrative. The crux of his critique is that the personality space that it yields is too low-dimensional to encompass the variety of characters we encounter in media. Here, I quote from Michael's own dissertation: > Suppose we want to build James Bond using [a model of personality]. First, we would think about characters in the abstract. What general theory captures the notion of character? How might this general theory be parameterized (perhaps through infusions of “knowledge”) to select specific characters? To inform the work, we might look at the dimensions of personality as described by various personality models in psychology (e.g. introvert–extrovert, thinking–feeling, intuitive–sensing, judging–perceiving). Once a generic architecture has been built, we could then define different characters by setting the right personality knobs. The problem is, how many of these personality knobs are needed to “tune in” a large number of characters? How many personality knobs need to be turned, and how many degrees of freedom does each knob need, in order to allow the creation of Bugs Bunny, Hamlet, The Terminator, Bambi? The differences between these characters seem to far outweigh any similarities. [mateas2002interactive, p. 11] Though this line of argument is compelling, especially when it is delivered in person, I initially pushed back against the idea of abandoning the Big Five in my own work. As I have articulated above, I viewed my work—especially on *World*—as being an exploration of authentic human experience. I was targeting the emotional experience of doing genealogical research, reading a generational narrative, hearing someone's personal testimony, living out a life, having deathbed regrets. With these aims, I had no use for Bugs Bunny or Bambi or The Terminator. Since the Big Five is a developed account of human personality, I thought it would make a good model for the kinds of characters that I sought to develop. Moreover, since there is extensive research on how the Big Five model correlates to a huge variety of human phenomena, it made modeling the causal factors for such phenomena (as rooted in personality) an easy matter of operationalization. For instance, as I noted in Section 7.2.2, I could model the formation of friendship (as factored by personality) in a matter of minutes by looking up a paper and rendering its findings in code. Over time, however, I came to terms with a simple fact: I was making media. Of course, I knew this all along, but I had not developed artistic aims for my practice accordingly. My simulated worlds are tiny and abstract—everything, even space and time, works differently in these worlds than in the real world—and though the little computer people that live in them may have had a capacity to evoke a kind of authentic human experience, this was more likely an effect of *believability* than of realism. Here is another quote from Michael's thesis: > Believable agents are the union of AI-based autonomous agents and the personality-rich, emotive characters that appear in the dramatic arts (e.g. theater, cinema). “Believability” is a term used by character artists to describe a property of compelling characters, namely, that of engaging in internally consistent, lifelike and readable behavior in such a manner as to support an audience in suspending disbelief and entering the internal world of the character. This is not the same as realism. Characters are *not* simulations of people, exhibiting behavior indistinguishable from humans under some controlled laboratory condition. Rather, characters are *artistic abstractions* of people, whose behavior, motivations, and internal life have been simplified and exaggerated in just such a way as to engage the audience in the artist's vision. [mateas2002interactive, p. 8] For me, this distinction connects back to my discussion of simulation in Section 4.1.5. One way of characterizing my earlier approach to my simulation practice is that I viewed my style as being representational, when in fact it would be more aptly described as *impressionistic*. My characters are artistic abstractions of people. At the same time I was reimagining my simulation practice as being primarily an effort in media creation—and, moreover, having impressionistic qualities rather than more concrete representational ones—with Ben Samuel and Adam Summerville, I was performing *Bad News* somewhat frequently. While this project provided a lot of authorial knowledge on how to do story sifting, as I discussed in the opening of this chapter, it also lent insight in terms of character modeling. As an actor tasked with playing any character that might emerge in a *Talk of the Town* storyworld, Ben had to develop methods for rendering Big Five personality models in fully embodied portrayals. While his character performances are marvelous, and while he has been gracious in his appraisal of the personality modeling of *Talk of the Town*, I felt that the simulation engine was not giving him a lot of material with which to work. Because it includes only five traits and models the distribution of values for those traits according to reports of such distributions among real people, *Talk of the Town* tends to produce characters with neutral personalities. As Ben elucidates in his own dissertation [samuel2016crafting, pp. 370–371], his techniques for modulating posture, voice, and other performance dimensions hinge in large part on a character's strongest traits. As such, characters with no strong traits offer little direction for how they should be played, and characters having a single extreme trait are defined rather one-dimensionally. Moreover, when it came to how personality might drive behavior in more specific domains—at work, in romantic affairs, among family—Ben was faced with the challenge of reasoning about the entirety of human phenomena in terms of only five abstract factors. As a gifted actor, he could fill in the gaps improvisationally to maintain believability, but his task was harder than it had to be, and I certainly could not trust fully computational characters to maneuver so adeptly. Because the impetus for this new simulation engine was to ramp up the simulation granularity—to model fine-grained character actions—I could no longer rely on an abstract personality model being good enough to support abstract character behavior. Thus, in my personal journey with personality modeling, I had come to internalize the essence of Michael Mateas's critique of the Big Five model: it has too few dimensions to account, computationally, for the variety of character phenomena we find in media. It should be noted, however, that this is not the extent of his critique. In fact, Michael is questioning the plausibility of using character personality models in a general sense. As he explains in his own dissertation (and elsewhere [mateas1997oz]), Michael operates in the intellectual and technical tradition of the Oz Project [bates1992nature,bates1992virtual], which espoused a direct approach to character authoring that precludes the latency inherent in a personality model. At its most concrete, this approach entails the direct authoring of a pattern of character *behaviors*, so that the character's personality (and moreover its every facet) is expressed through concrete behavior in the simulated storyworld. This is how character authoring worked in the Oz Project, as enabled by the Hap agent language developed by that group, as Michael explains: > Hap provides mechanisms that support writing behaviors for characters. A behavior is a chunk of activity; such behaviors can be high-level (a behavior for “having fun”), or low-level (a behavior for moving the character's body when they open a door). If you wanted to build James Bond in Hap, you would identify high-level goals (motivations) that make James Bond who he is. Then you would think of the multiple ways (behaviors) that James Bond might use to accomplish these high level goals. These multiple behaviors probably themselves have subgoals. Any given behavior is only appropriate under certain conditions (what's recently happened, how Bond is feeling, what's happening right now in the world, etc.); these conditions are captured within each behavior. At every level of description, James Bondness can be infused into the character. From how Bond thinks, to how Bond walks, the artist has the control to create the character consistent with their vision. [mateas1997oz, pp. 11] This mode of character authoring also characterizes the ABL agent language that was used by Michael and Andrew Stern in the creation of *Facade* and the later *IMMERSE* project, which was a larger collaboration that included several other cocreators at UC Santa Cruz and BBN Technologies [ferguson2015immerse,shapiro2013creating,shapiro2015composing,shapiro2015aesthetic]. [Note: ABL is a descendant of Hap whose fundamental design change was to support the authoring for *joint behaviors*: compositions of interlocking individual agent behaviors, structured around the conceptual pattern of the *dramatic beat* [mateas2002towards,mateas2002behavior,mateas2004behavior]. In Section 11.2.7, I discuss how the essence of joint behaviors has made its way into *Hennepin* through an intellectual and technical tradition that connects back to ABL via the mediating force of another AI system, *Comme il Faut* [mccoy2014social]. An additional note: interestingly, the Oz approach to character authoring is also, more broadly, an approach to character representation itself. An Oz character is not just driven by a collection of authored behaviors, but moreover it *is* that collection of authored behaviors (along with some instantial assets by which the character may be represented visually, in the case of a graphical world).] Is this how personality works in *Hennepin*, then? Do I author character behaviors directly, rather than latently through the mechanism of a personality model? No, I do not. As a student of Michael Mateas, who was himself a student of its figurehead Joe Bates, I also operate in the intellectual and technical tradition of the Oz Project—but I believe that my practice would actually be undermined were I to attempt to author character behaviors in this direct manner. There are two reasons for this, each of which connects back to the *aesthetics of emergent narrative* that I articulated in Chapter 3. First, in pursuit of the *aesthetics of the unathored*, the *aesthetics of the ephemeral*, and the *aesthetics of the actual*, I am reluctant to do anything but procedurally generate characters. If I were to create *Hennepin* characters through a process of directly authoring the sets of behaviors that constitute those characters—how Grace and Trip were created for *Facade*, for instance, modulo considerations of joint behaviors [mateas2007writing]—then each *Hennepin* storyworld would have the same characters. This would undermine the aesthetics of the unauthored, since lovingly handcrafted characters, though potentially more believable and more compelling, are not unauthored. [Note: Of course, there is a spectrum here, and Hap and ABL characters are certainly not on the far end of it where, for example, the static characters of novels might reside. Though such characters rely on authored behavior patterns to act, they are still dynamic entities that behave emergently (in ways that could even surprise their authors). In this sense, such characters are to some degree procedurally generated. But they persist across runtime instances, and this is the critical distinction under discussion here.] Relatedly, such an approach would compromise the aesthetics of the ephemeral, which characterizes worlds that have never existed before and will never exist again. If you turn off a simulated world and turn on the next one only to find the same characters living in both, then there is no meaningful ephemerality (in the sense of the notion that is under discussion here). [Note: Again, we can introduce nuance here: all interactive media—no, *all experience*—is ephemeral, thus these aesthetics are implicit in all human phenomena. But this quickly devolves into pedantry.] Finally, recall that the aesthetics of the actual stands in opposition to the trappings of fiction, particularly in terms of the notion of a simulacrum. As I note in the next chapter, a prelude to each *Sheldon County* pilot episode contains this segment: > Each episode in this series will be procedurally generated according to the particular characters and stories that have emerged in your county. These characters that you will come to know are not simulacra. They are not impoverished representations of real persons. They do not exist more perfectly in the mind of a human author. As I have noted above, I contend that the characters of fiction are in this sense a kind of simulacrum: they exist more perfectly in the minds of their authors. But when characters are procedurally generated, they only exist in the worlds that bear them, and they do not stand for anything else—they are *actual*. The second reason for my deviation from the Oz Project tradition of direct character authoring is more practical: my simulated storyworlds are relatively massive in terms of the number of characters, so even if I were willing to abandon the procedural generation of characters, it would be infeasible for me to manually author so many examples. As I have articulated in detail above, I create worlds with many characters to support the *aesthetics of the vast*, and moreover as a way to overcome some of the pitfalls of emergent narrative that were identified in Chapter 4. Thus, for my practice, the avoidance of direct character authoring is both an artistic choice and a practical one. Of course, I have already divulged my disenchantment with the Big Five personality model, so where is the middle ground between that and something like the Oz approach to character authoring? [Note: Interestingly, Michael positions the Oz approach itself at the center of a continuum between top-down approaches driven by, for example, personality models, and the bottom-up approaches of artificial life that might rely on evolutionary computation or neural networks [mateas1997oz, p. 10].] It would have to be one in which characters are represented according to abstract patterns that may be composed at runtime, which themselves may be used to generate character behaviors. This was the case in my utilization of the Big Five personality model in *World* and *Talk of the Town*, but I did not find it to be rich enough. As such, my solution has been to simply use a richer personality model, by which I mean one with more traits, and whose traits are more evocative. In *Hennepin*, I utilize the personality model that is being used in the current version of the *Dwarf Fortress* [dwarf]. [Note: At the time of writing, this is ‘v0.44.09‘. I will note also that I adapt this model with its creators' permission (personal communication, April 17, 2017).] This typology was developed by its cocreators Tarn and Zach Adams over the course of multiple iterations that appeared in earlier versions of the game, each of which is documented on a fan-maintained Wiki [dfpersonality028,dfpersonality031,dfpersonality034,dfpersonality]. Like me, the Adams brothers also began with the Big Five traits, but instead they used the expanded *NEO PI-R model*, which unpacks the five factors into a set of thirty total traits that are more specific [costa1992revised,dfpersonality028]. As Tarn told me recently in conversation, he and his brother found that the personality models found in psychology are too generous to support fundamental kinds of narrative intrigue. [Note: Personal communication, March 23, 2018.] For example, the Adamses sought a model whose possibility space would encompass conventionally evil characters, but psychologists tend to refrain from crafting personality tests that may conclude that a respondent is evil. To rectify this gap, the *Dwarf Fortress* creators turned, intriguingly, to the writings of Thomas Aquinas [aquinas1702summa] (and others) to expand their model. Here is how Tarn explained this process in a recent personal communication: > In the earliest versions of Dwarf Fortress, dwarves were distinguished by a number of boolean traits and indexed preferences. Do they like the outdoors? Are they scared of spiders? What are their favorite foods? When we first felt the need to distinguish broader personality facets for the dwarves numerically, it was natural to hunt around for an existing system that looked like it had enough resolution for our purposes. The version of the Big Five [...] with 30 facets seemed promising, but it soon became clear that it was designed for real people rather than characters in a story. Characters in stories can be complex, but they often have clearer virtues and flaws. It's also okay and sometimes desirable to judge them on reasonably stark terms, and highlighting them in these terms is important if the player is to understand what's going on, especially in a game without a pre-authored narrative [...] This led us to St. Thomas and Summa Theologica, in part, as well as a number of dramatic character archetype classifications and so forth (these were all internet searches, and sourcing was not important, so I don't remember the specifics of the web dive.) The Big Five system still had a lot to offer, so we formed a very non-academic, non-theological amalgam of the various systems we'd encountered, trying to keep the facets as independent as possible. This succeeded in making the results more satisfying. [Note: Personality communication, May 3, 2018.] The fifty traits in *Dwarf Fortress*'s personality model [dfpersonality] are as follows: > ‘abstract inclined‘, ‘activity level‘, ‘altruism‘, ‘ambition‘, ‘anger propensity‘, ‘anxiety propensity‘, ‘art inclined‘, ‘assertiveness‘, ‘bashful‘, ‘bravery‘, ‘cheer propensity‘, ‘close minded‘, ‘confidence‘, ‘cruelty‘, ‘curious‘, ‘depression propensity‘, ‘discord‘, ‘disdain advice‘, ‘dutifulness‘, ‘emotionally obsessive‘, ‘envy propensity‘, ‘excitement seeking‘, ‘friendliness‘, ‘gratitude‘, ‘greed‘, ‘gregariousness‘, ‘hate propensity‘, ‘hopeful‘, ‘humor‘, ‘imagination‘, ‘immoderation‘, ‘immodesty‘, ‘love propensity‘, ‘lust propensity‘, ‘orderliness‘, ‘perfectionist‘, ‘perseverance‘, ‘politeness‘, ‘pride‘, ‘privacy‘, ‘single minded‘, ‘stress vulnerability‘, ‘swayed by emotions‘, ‘thoughtlessness‘, ‘tolerant‘, ‘trust‘, ‘vanity‘, ‘vengeful‘, ‘violent‘, and ‘wastefulness‘. While Tarn fits each trait to a scale spanning between ‘0‘ and ‘100‘, I use an adapted scale that spans from ‘-50‘ to ‘50‘. Following Adams, I informally quantize this range in the following way (for authorial scaffolding): > - ‘50‘ to ‘41‘: ‘extremely high‘ - ‘40‘ to ‘26‘: ‘very high‘ - ‘25‘ to ‘11‘: ‘high‘ - ‘10‘ to ‘-10‘: ‘neutral‘ - ‘-11‘ to ‘-25‘: ‘low‘ - ‘-26‘ to ‘-40‘: ‘very low‘ - ‘-41‘ to ‘-50‘: ‘extremely low‘ One benefit of using the *Dwarf Fortress* personality model is that its creators have written glosses for each of the quantized value ranges of each trait, aside from the neutral range. These glosses specify how a character's behavior may be driven according to her degree of activation for a trait, and conveniently they are available on a fan-maintained Wiki [dfpersonality]. For example, here are the glosses for the trait ‘friendliness‘ (fit to my adapted value range): > - ‘50‘ to ‘41‘: *is quite a bold flatterer, extremely friendly but just a little insufferable* - ‘40‘ to ‘26‘: *is very friendly and always tries to say nice things to others* - ‘25‘ to ‘11‘: *is a friendly individual* - ‘-11‘ to ‘-25‘: *is somewhat quarrelsome* - ‘-26‘ to ‘-40‘: *is unfriendly and disagreeable* - ‘-41‘ to ‘-50‘: *is a dyed-in-the-wool quarreler, never missing a chance to lash out in verbal hostility* As I note below in Section 11.2.7, the Adams brothers' trait glosses (and the traits themselves) provide authorial scaffolding that in my project has worked to facilitate the process of defining character actions. For instance, one authoring pattern has worked according to the following process: read a gloss for an extreme trait quantization (either positive or negative), think of a discrete character action that would express that kind of extremeness in my simulation domain, and author an action accordingly (whose preconditions depend on a character's value for that trait falling in the extreme range). Thus, for example, a *Hennepin* character possessing extreme ‘vanity‘ may perform the action ‘admire-reflection-in-mirror‘. Even if I authored just one action for each trait polar extreme, that would still result in one hundred character actions. Of course, actions may also be authored for other trait value ranges, though they may be less salient than the ones authored for extreme ranges. Beyond facilitating the process of action authoring (by authorial scaffolding), this pattern leads to potent actions that satisfy one of Richard Evans's desiderata for procedural character personality: > The second major requirement is that each personality trait has a distinct and obvious effect on autonomous behaviour. If you create a character that is a foul-mouthed extrovert, and leave him to his own devices, he should go out meeting new people and swearing at them. Further, the way he autonomously manifests his personality should be transparent to the player: the player shouldn't have to take careful notes of every action the character does for many days, compile them in a spreadsheet, in order to notice that this character is 11.3% ruder. Manifestation of personality has to be obvious in individual behaviour without recourse to statistical patterns. [evans2011representing, p. 35] [Note: In developing *Versu*, Evans and collaborator Emily Short operated under a core design goal of authoring actions that vividly express personality [evans2014versu, p. 118]. This project was preceded by *The Sims 3* [sims3], in which Evans also pursued this aim [evans2010modeling].] Additionally, multiple actions could express the same extreme trait in different social contexts: thus, a character possessing acute ‘cruelty‘ might ‘ridicule-a- family-member‘ at home, ‘scold-an-inferior‘ at work, or ‘berate-an-employee‘ at a store while on an errand. Moreover, there is a massive combinatorial space suggested by the potential interaction of traits, and accordingly I have also authored actions by considering how two extreme traits could interact in ways that character behavior might express. Though I have not created one, I can imagine a powerful authoring assistant that would suggest which actions to author by simply combining the glosses for two different trait ranges—this would be similar to the author-assistance visualizations that aided Jacob Garbe and Aaron Reed in the crafting of procedural content for *The Ice-Bound Concordance* [garbe2014author,reed2014ice]. [Note: This visualization framework was developed in collaboration with Melanie Dickinson, who was then an undergraduate at UC Santa Cruz, but it was intended specifically to aid the authoring work on the project that was carried out exclusively by Garbe and Reed.] It is worth comparing *Hennepin*'s modeling of character personality to that of *The Sims 3* [sims3], a videogame on which Richard Evans served as AI lead. In the game, each character (“Sim”) is attributed up to five personality traits, from a total collection of eighty; example traits include ‘inappropriate‘, ‘grumpy‘, ‘over-emotional‘, ‘slob‘, and ‘kleptomaniac‘ [evans2010modeling]. As in *Hennepin*, traits may gate certain actions, according to authored condition logic, and additionally they can work as “adverbial modifiers” [evans2010modeling, n.p.] that alter how a Sim performs a common action. For example, a clumsy character is likely to trip while performing ‘walk‘, while a workaholic may pull out her phone in carrying out ‘wait‘. In *Hennepin*, I have likewise authored personality-driven variants on common actions—for instance, a character with low ‘ambition‘ might perform ‘slack-off-at-work‘, while someone with the opposite trait value could ‘work-hard-at-work‘. While characters in *Hennepin* are assigned values for all fifty traits, a given character is only likely to possess a handful of extreme trait values. Since neutral trait values are generally ignored (aside from being inherited by offspring), a *Hennepin* personality profile actually functions quite similarly to the eighty-pick-five profiles that are attributed to characters in *The Sims 3*—that is, since only extreme traits are important, each *Hennepin* personality profile effectively comprises on the order of five or so traits. Finally, while Sims choose what to do in accordance with explicitly modeled *motives*, in *Hennepin* such motives are implied in the condition logic for character actions. For instance, while in *The Sims 3* a mean-spirited Sim's motive to torment others will figure in the system's utility-based procedure for action selection [evans2010modeling], in *Hennepin* a cruel character will likewise be more likely to torment others, but simply by virtue of the condition logic on such actions necessitating an extreme trait value for ‘cruel‘. [Note: This distinction is rooted primarily in the disparity in the number of characters modeled in the systems' respective storyworlds: in *Hennepin*, worlds are populated by upward of a thousand characters over the course of simulated centuries, while a given *Sims 3* town is populated by a few dozen Sims for a much shorter duration of story time. As I discuss below, due to the number of characters—and especially the detail with which each is modeled and simulated—it is not feasible for me to score all candidate actions during action selection. As such, there would not be much sense in building out a full-fledged motives system, since it would likely not end up figuring much into action selection. That being said, I do model character aspirations, though these currently do not figure into action selection.] The generation of a personality profile for a given character works according to the same principles used in *World* and *Talk of the Town*. A character's personality is built up one trait at a time, and whether a given trait will be inherited from a parent depends on heritability probabilities specified for each trait. (Of course, characters without parents cannot inherit any trait values.) If it is determined that a trait will be inherited by a child, the child takes after one of the parents, selected randomly, but with some variation. This works by utilizing a pseudorandom number generator whose outputs fit a normal distribution, given a mean and standard deviation. Specifically, the inherited value for that trait—the trait value of the parent from whom the trait will be inherited—is used as the mean and a trait-specific *heritability noise factor* (specified in a configuration file) is used as the standard deviation. If it is determined that a trait will not be inherited by a character—for instance, because she has no parents—then the same normal-distribution pseudorandom number generator is used, but instead according to a *trait population mean* and a *trait population standard deviation*. All trait values are automatically constrained to fall between ‘-50‘ and ‘50‘. In earlier work, I strove for realism in my modeling of character personality, but over time I began to wish for a more evocative framework that could better yield narrative intrigue. While this was partly a function of encountering inadequacies in the storyworlds produced by my simulation engines, it was also due in large part to the influence of my coadvisor Michael Mateas, and the larger intellectual and technical tradition to which we both belong. In the Oz Project, Joe Bates and his collaborators aimed to build autonomous characters that worked not like human beings, but like the characters we encounter in media. As such, its core directive was to seek inspiration primarily from the *character arts* [thomas1981disney], as opposed to the social sciences or other fields of human study [bates1992nature,bates1992integrating,bates1992virtual,reilly1995art]. [Note: Though seminal in this regard, the Oz Project was not the only group that found inspiration in the character arts. Likeminded contemporaneous efforts include the *Petz* and *Babyz* videogame series produced by PF Magic (which included Andrew Stern) [frank1997socially,stern1998virtual,stern1999virtual], Millennium Entertainment's *Creatures* series [grand1997creatures], and several more [johnson1995wavesworld,blumberg1997old,mateas1997oz,hayes1998interactive,stern1999ai]. In the late 1990s, these practitioners converged yearly on the nascent International Conference on Autonomous Agents, which in 2002 merged with two other conferences to form the International Conference on Autonomous Agents and Multi-Agent Systems, causing the expressive tradition rooted in the character arts to lose its academic home. For a great overview of this period, see the contemporaneous reviews of Clark Elliot [elliott1998autonomous] and Michael Mateas [mateas1997oz] or the annotated bibliography of Barbara Hayes-Roth and Patrick Doyle [hayes1998animate]. Later, at the 2002 AAAI Spring Symposium on Artificial Intelligence and Interactive Entertainment, there was an interesting debate on the relative merits of realism and believability [gordon2002virtual]. Finally, as Rob Zubek notes [zubek2005hierarchical, p. 10], the latter notion relates to Masahiro Mori's notion of the *uncanny valley* [mori1970uncanny]—the famous English phrase being due to Jasia Reichardt's translation [reichardt1978robots]—since caricature is a good method for avoiding the valley.] While my technical method for character modeling does not resemble those which underpin the Oz Project and later work by Michael Mateas and collaborators, in *Hennepin* my approach is now couched in the same intellectual tradition. I still seek to generate stories with heart, about authentic human experience, but for now I plan to do this with characters who work more like the ones we find in media. It is possible that later on I will view this move as swinging the pendulum too far toward the other side, but for now I am content and excited. [Note: I should note that these two approaches—operationalizing ideas from the social sciences about how people work and modeling character tropes found in media—are not mutually incompatible. For example, in his collaborative work on *CiF* and *Prom Week*, Josh McCoy (who has the same academic lineage as me) has done a nice job of managing an admixture of inspiration from the social sciences (Goffman's *dramaturgical analysis* [goffman1959presentation]) and media tropes [mccoy2012all]. More immediately, the very personality model I just described pulls its traits in this way from distinct cultural purviews, and other aspects of *Hennepin*'s architecture and authored procedural content are still influenced by the social sciences (as the next section will show). My pendulum swing thus brings me closer to the other side, but not all the way. In a recent conversation, I was surprised to hear from Michael Mateas that behind the scenes in the Oz Project, there was actually more emphasis on realistic agent modeling than the group's papers suggest. To me, it seems that a mixture of these concerns is not only natural, but perhaps also inevitable when it comes to the task of actually building autonomous characters.] #### Value System *Hennepin* characters form and dynamically reconstruct *value systems* that capture opinions about what is important in life. Like the personality model described in the last section, my value typology was also designed by Tarn and Zach Adams for *Dwarf Fortress* (and is likewise used with his permission). Unlike his personality model, this system (called the ‘beliefs' system [dfpersonality]) is just starting to be incorporated into the game in a significant way. [Note: Personal communication, March 23, 2018.] As Adams told me recently in a personal communication, the development of this model was more haphazard: > we found we needed to separate the more elemental personality from later learned intellectual values; this process is newer and has been less rigorous. We just wrote down a list of several values without attempting to be exhaustive; we assumed any philosophical system we added later would eliminate our simple work here, and the seeds of this change have been planted with the game's philosophical knowledge ‘forest' (which is also simple, but in some ways orthogonal to the existing value set; what we'll end up with is still a mystery to me). [Note: Personality communication, May 3, 2018.] Though its development may have been relatively hasty, I find the Adams brothers' model to be quite inclusive, and also dramatically potent—as I noted in the last section, such potential provides critical authorial scaffolding for action authoring. What follows are the thirty-four elements in this model, each of which I call a *value* (again, in *Dwarf Fortress* these are termed ‘beliefs'): > ‘artwork‘, ‘commerce‘, ‘competition‘, ‘cooperation‘, ‘craftsmanship‘, ‘cunning‘, ‘decorum‘, ‘diversity‘, ‘eloquence‘, ‘fairness‘, ‘family‘, ‘friendship‘, ‘hard work‘, ‘harmony‘, ‘independence‘, ‘introspection‘, ‘knowledge‘, ‘law‘, ‘leisure time‘, ‘loyalty‘, ‘martial prowess‘, ‘merriment‘, ‘nature‘, ‘peace‘, ‘perseverance‘, ‘power‘, ‘romance‘, ‘sacrifice‘, ‘self control‘, ‘skill‘, ‘stoicism‘, ‘tradition‘, ‘tranquility‘, ‘truth‘ As in the *Hennepin* personality model, I use a numeric scale spanning from ‘-50‘ to ‘50‘, in this case to represent a particular character's opinion about the value. In this way, a score of ‘-50‘ for ‘decorum‘, for example, represents a case of a character who does not value decorum in the slightest. Alternatively, on the other end of the spectrum, a character with a score of ‘50‘ would value decorum to the utmost. Here, I use same quantization scheme as before: > - ‘50‘ to ‘41‘: ‘extremely high‘ - ‘40‘ to ‘26‘: ‘very high‘ - ‘25‘ to ‘11‘: ‘high‘ - ‘10‘ to ‘-10‘: ‘neutral‘ - ‘-11‘ to ‘-25‘: ‘low‘ - ‘-26‘ to ‘-40‘: ‘very low‘ - ‘-41‘ to ‘-50‘: ‘extremely low‘ Just as they did for their personality model, the Adams brothers have written glosses for each value that specify how a character's behavior may be driven according to her degree of fervor for that value. Conveniently, these glosses are available on the same fan-maintained Wiki [dfpersonality]. As an example, here are the glosses for the value ‘decorum‘: > - ‘50‘ to ‘41‘: *views decorum as a high ideal and is deeply offended by those that fail to maintain it* - ‘40‘ to ‘26‘: *greatly respects those that observe decorum and maintain their dignity* - ‘25‘ to ‘11‘: *values decorum, dignity and proper behavior* - ‘10‘ to ‘-10‘: *doesn't care very much about decorum* - ‘-11‘ to ‘-25‘: *finds maintaining decorum a silly, fumbling waste of time* - ‘-26‘ to ‘-40‘: *sees those that attempt to maintain dignified and proper behavior as vain and offensive* - ‘-41‘ to ‘-50‘: *is affronted by the whole notion of maintaining decorum and finds so-called dignified people disgusting* As I will explain below, one of my authoring patterns for specifying action definitions involves reading the extreme variants of these glosses and imagining what kind of action a *Hennepin* character with such an opinion would take. Beyond providing authorial scaffolding that facilitates the process of creating new action definitions, this pattern is powerful because it leads to character actions that are not only believable, but moreover vividly manifest a character's opinions on life. Again, this accords with Richard Evans's call for character behaviors that express who those characters are [evans2011representing]. Critically, character values also drive character *aspirations*, a notion that I will explain in the next section. For example, a character who believes strongly in both ‘law‘ and ‘power‘ may form the aspiration of wanting to become a police officer. Lastly, I would like to note related work, by Sasha Azad and Chris Martens, that has resulted in a system in which characters cultivate and propagate opinions [azad2018addressing]. #### Aspirations In *Hennepin*, characters may form *aspirations* about what they would like to accomplish in life. As I will explain below in Section 11.2.8, aspirations are defined to include conditional triggers that, if fired for a given character, cause her to form the aspiration. Generally, these conditions depend on the character's personality and also her value system. In turn, another trigger captures what must be true about the storyworld for the aspiration to be fulfilled. This component of *Hennepin* is inspired by the character goals of *Universe* [lebowitz1983creating,lebowitz1984creating] and the *wants and fears* system of *The Sims 2* [maxis2004sims,brown2006power,sims2aspirations]. #### Knowledge Whereas the rich modeling of character *knowledge* is the hallmark of *Talk of the Town*, character actions are the central concern in *Hennepin*. As such, I elected to start over from scratch to develop a more lightweight approach to simulating character knowledge in this engine, since I now find *Talk of the Town*'s modeling of such phenomena to be both somewhat bloated (from a computational standpoint) and somewhat burdensome (from an authorial standpoint). In *Hennepin*, characters form knowledge about what has happened in the past, as opposed to beliefs about other people and places. This is a course correction meant to rectify what I now perceive to be a blunder in *Talk of the Town*'s knowledge modeling: the subject of character beliefs are too boring to be narratively potent. For example, while the image of an entire town collectively harboring false beliefs about a reclusive character's hair color may be amusing, it would be difficult to construct an engaging story recounting these circumstances. As I will explain in more detail in Section 11.2.9, a *Hennepin* character's collected knowledge of the world is structured as a collection of *knols*, each of which represents knowledge of some action that occurred in the past. A ‘knol' is a term meaning ‘unit of knowledge' that was coined by workers at Google in 2007 [strategic2008knol]. Each *Hennepin* knol maintains a list of its *sources*, which are all the actions that imparted knowledge about the subject of the knol (more on this later). The system also keeps track of knols that a character has forgotten, but in this system characters do not misremember (as a simplifying measure). Additionally, knols are indexed according to tags that capture characteristics of a remembered action. For example, a tag ‘embarrassing‘ may be attached to a knol about something embarrassing that happened to a character, which allows the system to retrieve it accordingly if some other action calls for such a knol (for example, an action ‘cringe-over-embarrassing-memory‘). [Note: This is inspired by the tagging of past actions recorded in the *social facts database* of *Comme il Faut* [mccoy2014social, p. 101], the AI engine that drives *Prom Week* [mccoy2011prom,mccoy2013prom].] Finally, characters build up simple probabilistic models about the locations of other characters that rely on known past locations. This allows one to track someone else down in the case of an emergency, for example, as I will explain in Section 11.2.9. #### Miscellaneous Attributes As in *Talk of the Town*, characters in *Hennepin* are also modeled according to several additional miscellaneous attributes, including *sex*, *sexuality*, *fertility*, and *memory*, the latter of which is again modeled as a floating-point value that decreases over time, this case making forgetting more likely. Likewise, the system also tracks character-specific data pertaining to a number of concerns including social relationships, romantic history, work history, residential history, and more. ### Other Entities In addition to characters, *Hennepin* models a county (the storyworld), along with its towns, plats, parcels, lots, roadways, buildings, homes, businesses, artifacts, and statutes. I will briefly describe each of these in this section. #### Counties A *county* in *Hennepin* is modeled as a square grid platted according to the procedures of the United States Public Land Survey System [white1983history]. Each county comprises four *survey townships*, two on top and two on bottom. A survey township is itself a grid that spans six miles by six miles and is composed of 36 square-mile portions called *sections*. [Note: A survey township is not to be confused with a township, which is a type of municipality in many states. Often, townships are coextensive with survey townships, but the latter were typically platted prior to any actual municipality being established there.] A section is a 640-acre portion of land that is composed of four *quarter sections*, each of which has an extent of 160 acres. A quarter section is the classical slice of American land, since it was the portion that was given away by the United States General Land Office, according to the Homestead Act of 1862, to white settlers as an enticement to bring them west to till the now vacated lands that had been formerly possessed by various Native American groups [porterfield2004homestead]. [Note: Beginning in 1866, land grants became available for certain people of color as well, though to an extent this was nominal since institutional policies made it difficult for such citizens to actually make use of the program [oliver2013black]. Such institutionalized racism was a factor in keeping a majority of black Americans in the southeast portion of the country until the so-called *Great Migration* of the twentieth century [hahn2003nation].] When a quarter section was claimed as a homestead, the claimant would typically build a farmhouse in the middle of the plot, which is the origin of the Americanism “back forty”, denoting a remote part of the farm located behind one's house [linklater2009measuring]. As I will discuss below, in *Hennepin* the Homestead Act is loosely modeled by generated characters coming to the county to claim quarter sections and establish farmsteads. Initially, however, the county is represented as a grid of townships, each being represented as a grid of sections, and subdivision only occurs as character actions demand. While I am now exploring the integration into this project of an earlier terrain generator that I originally developed for an abandoned extension to *World*, as mentioned above, the counties currently do not model terrain. #### Parcels, Lots, Roadways Each portion of land in a county is called a *parcel*, which is a generalized notion that extends the earlier modeling of tracts and lots in *Talk of the Town*. Parcels vary in size as land is subdivided according to character actions. For instance, a character might offer to purchase half of another character's parcel, in which case that portion of land will be subdivided into two halves. Such breaking down may occur repeatedly over time, as in the real world, to create dynamics of settlement density where more populated areas are bounded by rural areas constituted in large parcels (likely used for farms). The smallest unit of land modeled in *Hennepin* is the *lot*, which is a *square chain*, meaning it spans 66 feet on each side. Parcels are composed of one or more lots, and a lot is the unit of land on which a building may be constructed. At any point during the simulation, a character will be located either in a building on a lot, or on a lot itself. Thus, if a character is out in the middle of a secluded parcel, technically she will be positioned on one of its lots. In this way, lots work like the *tiles* that compose a *Dwarf Fortress* world [dftiles], for instance, though *Hennepin*'s lots are much larger in size. Each county's lot grid comprises 921,600 lots in total. Whereas in *Talk of the Town* each *roadway* system was instantiated chunk by chunk on a predetermined grid, in *Hennepin* these emerge naturalistically as interconnections between buildings are needed. To request roadway access, a character performs an action that results in a request being submitted either in writing or in person to officers in the county courthouse. The roadway path is then determined by a simple *A** procedure [russell2016artificial, pp. 96–101] that searches in the space of possible paths on the grid of parcel perimeters, according to some simple heuristics (namely to prefer straighter paths). An actual roadway is then constructed piece by piece by county laborers, who perform actions like ‘pave-section-of-road‘. As I note below in Section 11.3, while such actions may appear to be benign, they could actually tie in with other systems to yield significant narrative intrigue. For instance, characters may bury artifacts on lots, and an action like ‘pave-section-of-road‘ could have the effect of unearthing such objects. Generally, a major goal in developing this system is to hook infrastructural modeling into other systems so that the former may actually produce narrative intrigue. #### Towns While the initial characters who move into a county will live in an unincorporated area, over time characters may establish *towns*, which are physically represented as collections of parcels. The formation of a town will often coincide with the platting of a *townsite*, which is a subdivision of a section (square mile) into an aesthetically pleasing arrangement of small *town lots*, planned roadways, and a town square. When a character purchases a section and subdivides it according to a townsite plat, she forms a land company that sells those lots to other characters who would like to live there. The modeling of municipal evolution in *Hennepin* represents a return to the *settlement* phenomena of *World*. I decided to model the larger area of a county—rather than a town only, as in *Talk of the Town*—in part because I wanted more space so that emergent character activity could become reified in the storyworld topography itself. This provides for narrative intrigue associated with a number of media tropes, such as the *town rivalry* and the *utopian settlement*. As for the latter, characters may collaborate to establish towns that are rooted in shared principals—for instance, a group of characters who all believe in ‘law‘ and all despise ‘merriment‘ may establish a town based on those shared values (more on this example below). #### Buildings In *Hennepin*, a *building* may be constructed on top of a lot as a result of character actions pertaining to that construction. Unlike in *Talk of the Town*, a building and a business that is headquartered there are decoupled as separate modeled entities. In every other way, a building is modeled following my previous simulation engine. #### Homes, Businesses, Vocations The *homes* and *businesses* of *Hennepin* are modeled just as they in *Talk of the Town*, except that the latter are now decoupled from the buildings in which they are situated, as I just noted. Additionally, whereas in the earlier system a business was modeled as either requiring a tract or a lot to operate, businesses in *Hennepin* are defined according to more specific size constraints that they place on the land on which they will operate. For instance, a farm requires considerable acreage, whereas a drug store may be established on a single lot. #### Artifacts Characters may perform actions that cause physical *artifacts* to exist in the storyworld. This system is an offshoot of the modeling of character actions, so I will hold off on explaining how it works until later, in Section 11.2.11. #### Statutes One system that is meant to support interesting feedback loops (between storyworld and emergent events) concerns character-defined *statutes* that may change how the storyworld works in a certain jurisdiction. Statutes are proposed and voted on by characters at county or town hall meetings, and they generally pertain to the prohibition of certain kinds of character activity. For instance, in the example town that I introduced above—founded on the common principals of law and no merriment—the characters might decide to ban alcohol there. As a result, drinking actions would become illegal and the police officers in the town would have a new social affordance of performing arrest actions on characters who are known to have broken that law. I will revisit this example in Section 11.3. ## Simulation Now that I have explained the basics of *Hennepin*'s entity modeling, in this section I will outline its simulation procedures. At a high level, the workflow here is the same as that of its predecessors *World* and *Talk of the Town*: create an empty world, have some initial characters move into it, and then proceed from there, timestep by timestep, simulating storyworld phenomena by executing a recurring simulation loop. By this configuration, there are two distinct modes of simulation, one pertaining to the initial setup of a storyworld and the other to its evolution over time. I will describe both of these in turn. ### Setting Up a County Each *Hennepin* storyworld begins with the same essential scenario, which resembles that of *Talk of the Town*: it is the summer of 1839 and there is an empty American county that has already been platted by the United States land office. Rather than a set of initial characters automatically moving into the storyworld right at the onset, in *Hennepin* time proceeds with it being empty, until a first character decides to move there according to one of several probabilistic rules that pertain to: drifters coming through the county, homesteaders claiming land there, and characters arriving to start other kinds of businesses. As with my earlier simulation engines, adult characters who are generated outside the storyworld undergo a retcon procedure that abstractly simulates a backstory. #### A More Nuanced Evolution Whereas in *Talk of the Town* the opening of a new employee position could cause the spontaneous arrival of a new character to take that job, in *Hennepin* jobs are filled more naturalistically. Specifically, when a job opens, the employer will make the opening known by word of mouth or by artifacts, such as job postings, that encode information about there being an open position. In this way, an employer may post about an opening at county gathering spots, and drifters passing through the county may decide to apply for a position and stay in the county. As such, the evolution of a *Hennepin* county occurs by characters taking fine-grained actions in the storyworld, with new characters coming into (or through) the county only as probabilistic rules trigger such arrivals. Finally, as in *Talk of the Town*, the storyworld may be seeded, which means a county and its exact history will be reproduced when a seed is reused. In the case of *Sheldon County*, this could potentially support the practice of *seed sharing*, where listeners share seeds that they have found to produce interesting podcasts. This practice is popular among the *Dwarf Fortress* player community [dfseedarchive]. ### Simulation Loop Once a county has been established, its history is simulated until a specified termination date, in the style of *Talk of the Town*; in the case of *Sheldon County*, I have not yet specified an end date. [Note: Unlike *Bad News*, which takes place at the time of the termination date—in that case, the summer of 1979—*Sheldon County* has no diegetic frame story, which means it does not take place at any time. As such, the termination date is simply a matter of when the accumulation of actions constituting the history of a storyworld should end. Each podcast will recount events from different periods in a storyworld's history.] As with *World* and *Talk of the Town*, time progresses in *Hennepin* according to the execution of a simulation loop that recurs each timestep. As in *Talk of the Town*, not every timestep is actually simulated. On a timestep that is simulated, an *action manager* carries out its general procedure for *action selection*, whereby everyone in the county may take action. In other cases, if characters urgently need to take a *queued action*—such as giving birth on a preordained due date—then only those characters take action on the timestep. Figure 11.1 shows an example of the kind of raw console output that is displayed on screen as this procedure is underway; as such, it gives an example of the kinds of actions that characters may take. In the following sections, I will explain all the various phenomena that are simulated over the course of a *Hennepin* simulation loop. Generally, the specific procedures that handled certain phenomena in my earlier engines, such as the procedures for handling births and deaths, are now handled by the action manager. That is, whereas top-down probabilities used to trigger certain critical events, now such events are reformulated as fine-grained character actions and occur through the basic functionality of the action manager (to be explained in Section 11.2.7). [Figure omitted] ### Infrastructural Evolution Whereas in my earlier systems I hardcoded specific procedures for evolving the *infrastructure* of a storyworld—*World*'s settlement activities and ship passages and *Talk of the Town*'s business operations—in *Hennepin* this evolution is handled by the general mechanism of character action selection. For instance, a road is built when: a character requests roadway access to her home, a county official processes the request, another county official plans the roadway, a county work crew travels to the planned location, and the work crew actually constructs the roadway segments. This procedure thus occurs emergently according to the coordination of a number of fine-grained character actions, each of which may dynamically incur various other effects, making roadway construction itself an emergent possibility space. This is how all character phenomena works in *Hennepin*, including the more benign phenomena that undergird the bureaucratic and infrastructural concerns of a county. As such, it is not really possible to describe how these phenomena are modeled in the way that I did for the earlier simulation engines. Instead, my description of character actions in Section 11.2.7 may be taken as providing this explanation in a general way. ### Character Routines Character routines work exactly like in *Talk of the Town*, except that characters with queued actions (about which more soon) are sent to the location where that action is to be taken, if that is specified. While I will explain more about action queues below, the general idea is that the action manager may schedule future actions for characters—for example, ‘attend-party‘—and such scheduling may record a specific location at which the action must be taken. For example, if someone is to attend a character's birthday party at the latter's home on a specific date, the system handling character routines will automatically move the character to that location at the beginning of the corresponding timestep. [Note: In his feedback on an earlier draft of this thesis, Noah Wardrip-Fruin commented on the routine system: “I understand not modeling characters moving around the world. But it would be great if ‘you won't believe what happened to me on the way here' was still possible” (personal communication, August 10, 2018). This is an interesting idea, and it could be accomplished by queueing transitional actions whereby a traveling character moves to intermediate locations in the county that are along the way to an ultimate destination.] #### Being There Initially, I had characters take the action of actually going to a place where a scheduled action is be taken, but it led to thousands and thousands of boring actions constituted in characters heading to various locations at the beginning of a timestep. By this refined approach, characters simply begin a timestep at the places at which they need to be. To me, this evokes the crafting of scenes in narrative media, where no effort is taken to establish how everyone got to the location of that scene—it just starts, and everyone is already there. Unlike *Talk of the Town*, characters may move between locations during a timestep; this is handled by action effects (more on that below). ### Character Relationships While *Hennepin* disposes of *Talk of the Town*'s abstract modeling of social interaction, the notions of *charge* and *spark* (see Section 9.2.5) are still inherited. As I will explain in the next section, however, updates to charge and spark values occur according to character actions. Specifically, a charge or spark update is now simply one kind of action effect, which means different actions will affect these affinities in different ways. As such, the system can explore the concrete history of a relationship, which was not possible in my earlier simulation engines. For example, the origins of an enmity could be reasoned about in terms of the specific character interactions that bred the contempt. Moreover, charge and spark values may be referenced in action preconditions, thereby gating certain kinds of actions depending on how characters feel about one another. #### Discrete Relationships Even though the evolution of charge and spark values works differently, discrete character relationships are still formed in the same way: as specified charge and spark thresholds are crossed, discrete relationships such as a ‘friend‘ or ‘enemy‘ are instantiated. Finally, *Hennepin* also still tracks a number of other social relationships, including: specific familial relations, such as ‘sister‘ or ‘cousin‘; occupational relations, like ‘coworker‘ or ‘boss‘; and residential connections, including ‘neighbor‘ and ‘former neighbor‘. ### Character Values While it less clear whether or to what extent personality changes over time in the real world, *value systems* clearly change in the course of a life, sometimes by acute shifts. In *Hennepin*, l wanted to model this kind of change because I feel that it yields narrative potential—for instance, a character arc, transpiring over the course of the person's existence in a storyworld, could be undergirded in part by shifting beliefs about what is really important in life. [Note: In his feedback on an earlier draft of this thesis, Noah Wardrip-Fruin commented, “Reading the descriptions of extreme Hennepin values, I can already find narrative intrigue starting. If a character were portrayed as feeling that way, I would start wondering, ‘How did they get that way?'{”} Indeed!] Moreover, if such change generally paralleled shifts in the (broadly construed) American value system that have occurred over course of this country's history, a basic verisimilitude would be imbued in *Hennepin*'s storyworld modeling. In this way, there are distinct appeals to modeling change over time both within characters and within a storyworld. #### Planned Antecedents To model such change, I decided to return to the *incrementation model* that I had implemented in *World*'s subsystem that simulates character knowledge phenomena, which was the subject of Section 7.3.16. In the discussion section of my paper on that work, I actually proposed that the approach could be extended to more concrete sociocultural considerations (citation inserted for clarity): > This notion of using diegetically evolved vectors [...] suggests a more generalized approach that evolves sociocultural considerations beyond language. [...] Instead of operationalizing linguistic theories, this proposed integration could operationalize theories about general sociocultural transmission and evolution, e.g., the influential work of [Luigi Cavalli-Sforza and Marcus W. Feldman] [cavalli1981cultural]. [ryan2016diegetically, p. 7] Indeed, from the beginning, I had been interested in exploring the evolution of other kinds of sociocultural phenomena, but I never got around to it in *World*. One idea that Peter Mawhorter and I discussed at that time was to evolve vectors whose entries would map to specific cultural practices, for example, clothing preferences—in this way, a community's preference for pointy shoes might gradually evolve into a preference for curled shoes as bit flips propagated over time. Later, in *Talk of the Town*, I became interested in the prospect of applying its modeling of character knowledge (beliefs about what is true) to sociocultural concerns (beliefs about what is important). In text that did not make the cut of our paper on that system [ryan2015toward], I proposed an integration with the *Chimeria* system of Fox Harrell and collaborators (citation inserted for clarity): > Here, let us consider *Chimeria*, an AI system that richly models social-group membership according to specifications of those groups that come from hand-authored *domain epistemologies* [harrell2014chimeria]. In an application of the system called *Chimeria: Gatekeeper*, the underlying domain epistemology defines the attributes that are prototypically associated with two races in a fantasy world. For instance, this epistemology specifies (among other things) that members of the first race like rough-spun garments, while members of the other race prefer fine clothing. As the system stands today, agents in *Chimeria* applications inherit from a single hand-authored domain epistemology that is static and cannot change according to events that may occur in the simulation. One can imagine, however, an integration of this system and ours by which the components of a domain epistemology are represented in our system as belief facets. By this integration, epistemologies would be instantiated at the level of the individual agent (which is more intuitive) and would be built up according to observed agent behavior in the simulation. That is, the component of a character's instantiated epistemology corresponding, e.g., to clothing preferences among members of some race in the game would get built up incrementally according to evidence that the character encounters as she goes about the world. Components of epistemologies could likewise propagate, deteriorate, and terminate just as knowledge does in *Talk of the Town*. [Figure omitted] I never got to this work in *Talk of the Town* either, but finally in *Hennepin* I am exploring the evolution of sociocultural concerns for the first time. Here, I think that the resulting system is more interesting than *World*'s language system, because in this case the subject phenomenon (character value systems) is represented using a concrete representation scheme (values are strings), as opposed to the abstract language vectors that I utilized in the earlier work. #### Incrementation Model In a *Hennepin* storyworld, character values change over time by an incrementation model that works similarly to the operationalization of William Labov's theory of language change that was utilized in *World*; this process is illustrated in Figure 11.2. Since I already explained the latter system at length in Section 7.3.16, I will not go into too much depth here. When a child is born in a *Hennepin* county, she inherits a value system from her parents in the same way that a personality profile is inherited: for each value, a parent is randomly selected, and the child takes after that parent by adopting the same value score, but with some mutation. Throughout her late teens and twenties, a character proceeds to modify her values over time under the influence of the historical era at hand, as well as the influence of her peers (particularly influential characters who may try to persuade her in some direction by performing certain actions). Finally, when a character reaches her early thirties, she stops updating her value system and instead maintains it, potentially passing it on to the next generation, per the incrementation model. #### Zeitgeist Anchors Rather than *World*'s random mutation (modeled as the flipping of arbitrary bits), here there is an external modulating force that guides the process. As the storyworld's historical era changes, a normal distribution modeling predominant character values shifts—this is modeled as the mean shifting, though the variance could also shift to generate different spreads. Specifically, for each of the thirty-four character values that were listed above, I authored definitions for normal distributions that are each associated with an era (represented as a date range). This authored procedural data captures that, for instance, in American history, at a macro level, ‘decorum‘ has become less valued over time while ‘diversity‘ has become more valued. [Note: Here, I am simply being guided by my intuitions, since I do not see a point in actually doing research to operationalize a theory. The details of how this works are not especially important, since the narrative potential of this system—which is ultimately what I seek—will be produced simply by having character values change over time (both within a character and across a storyworld), especially as a result of concrete actions by influential characters.] As time progresses, a new normal distribution takes hold, which has two effects. First, its mean acts as an anchor that draws the developing opinions of adolescents toward it—thus, if a teenager's evaluation of ‘diversity‘ is ‘3‘, but the anchor is ‘13‘, she may probabilistically adapt her belief to shift toward the anchor (thereby increasing it, in this case). Second, if a new adult is generated to move to the town, her value system is instantiated by sampling from each of the active normal distributions. #### Persuasion Additionally, there is another way that values can change: persuasion. As I will note at various points later on, characters may perform actions whereby a particular value is extolled or denounced. If a character who is still reformulating her value system is the recipient of such an action, she may shift her opinion of that value in the corresponding direction, depending on social concerns such as her affinity for the speaker. [Note: The phenomenon of persuasion is also modeled in *Dwarf Fortress* [dwarf], as an entry in a fan-maintained Wiki explains: “Beliefs can be changed through successful arguments. In adventure mode, this can be used to change the core beliefs of your adventurer (and by proxy some of your needs). Since you can argue for beliefs you don't actually hold, you can convince a person of a belief you want to hold, and then get into another argument over said belief, and acquiesce to their position” [dfpersonality, n.p.]. Someone should utilize this module in a scholarship simulation.] ### Character Actions The fundamental unit of simulation in *Hennepin* is the *character action*. Everything that happens in a storyworld is constituted in discrete character actions that are gated by preconditions and that have associated effects that bring about changes to the storyworld. In this section, I will explain this system in detail. #### Action Definitions An *action definition* is a collection of authored procedural content that defines a *prospective action* that may be taken by a *Hennepin* character at some time, at which point a concrete *action* of that type is instantiated. Each action definition contains specifications for the following components: - **Name.** A unique name that captures the type of action that the definition specifies. Example names for actions that I have authored include ‘chit-chat‘, ‘address-warmly‘, ‘ridicule‘, ‘have-a-drink-at-work‘, ‘write- a-poem‘, and ‘gaze-upon-the-stars‘. The system does not reason over these names, which means they are meant only for human consumption. As these examples illustrate, the actions that I have authored are generally granular and tailored to specific social contexts. [Note: Condition logic enforces that actions are taken only in the appropriate contexts.] To connect to a distinction that Richard Evans has spoken about [evans2010modeling], the granularity here is closer to *The Sims 3* [sims3], which features actions such as ‘compliment-home‘ and ‘worry-about-relationship‘, than to *The Sims* [maxis2000sims] or *The Sims 2* [maxis2004sims], whose actions are on the order of ‘talk‘ and ‘joke‘. - **Role definitions.** A list containing *role definitions* for all the *roles* that are associated with this action, one of which must be an *initiator* role. While an action is always initiated by a single character, additional characters and other entities may be incorporated into the action by being cast in one of its roles. For example, in the definition for ‘ridicule‘, the following roles are defined: ‘insulter‘, ‘insulted‘, and ‘observer‘. As I just mentioned, roles may be filled by entities beyond characters, such as homes, businesses, artifacts, values, or even other actions. For example, the action ‘gossip‘ has a role called ‘past-action‘, which is filled by a past action that is the subject of a character's gossip. I will explain more about role definitions in the following section. - **Preconditions.** A set of *preconditions* that must be satisfied in order for the action to be taken at some point. Preconditions are evaluated with respect to a candidate *binding*, which specifies a set of candidate entities to be cast in an action's roles. For example, a candidate binding for ‘ridicule‘ might look like this: ‘{insulter: Meehan, insulted: Klein, observer: Schank, observer: Dehn}‘. A precondition, then, specifies constraints on who may be cast in what roles at what times. As an example of a ‘ridicule‘ precondition, ‘insulter.personality.cruel >= 25‘ requires that a character must be particularly cruel in order to ridicule someone. In this case, the *action manager*, described in Section 11.2.7, would evaluate this precondition by using the candidate binding, where the character ‘Meehan‘ is bound to the role ‘insulter‘. Another precondition might depend on the relationship between the insulter and insulted, for example, ‘insulter.charge(insulted) < 0‘, in which case the character ‘Klein‘ would be bound to the role ‘insulted‘ to evaluate the condition. More broadly, a precondition may specify anything about any modeled aspect of the storyworld. At a technical level, my authored preconditions are Python *lambda expressions* [vanrossum2010python, p. 58] that have access to both the candidate binding and the storyworld state. [Note: Lambda expressions are statements in the *lambda calculus*, a formalism that was introduced by Alonzo Church in a 1932 paper titled “A Set of Postulates on the Foundation of Logic” [church1932set,cardone2006history]. Among Church's students were Alan Turing and Stephen Cole Kleene, the latter of whom advised Robert Constable, who advised Joe Bates, who coadvised Michael Mateas, who coadvised me.] Here is an actual code snippet defining a precondition for the action ‘cringe-over-embarrassing-memory‘ (‘c‘ is bound to a data structure for the candidate binding in which individual role bindings may be accessed by dot notation): ``` lambda c: c.cringer.associates( action=c.past_action, tag=‘embarrassment' ) ``` Lastly, I would like to note an authoring pattern whereby a precondition is simply a specified probability, which allows for an author to turn down the chance of an action occurring even when all its binary preconditions hold. For example, take this precondition: ``` lambda c: random.random() < 0.5 ``` With this condition in place, an action that would otherwise be taken has only a 50% chance of being taken. This can be used to turn down the frequency of actions that should occur less often. - **Effect definitions.** If an action is taken, a set of associated *effects* may be executed to update the state of the storyworld; in this way, actions change the world. In the action definition, an author specifies a series of *effect definitions* that couple *triggers* and *effects*. A trigger is a condition that specifies the contexts in which an effect may be executed, and the effect specifies how exactly the storyworld will be changed if the rule fires. As such, action effects in *Hennepin* are *conditional*, which means they are not strictly executed when an action occurs, but instead the effect trigger is evaluated, and only if those conditions hold are the actual effects executed. The trigger conditions work just like preconditions, which means they may specify anything about the storyworld and operate over an action's bindings. [Note: To be precise, action preconditions operate over candidate bindings, while effect triggers operate over instantiated bindings, since by then the action has already been taken.] Like the conditions, effects are defined as Python lambda expressions, but instead of returning ‘True‘ or ‘False‘, they call functions or methods whose execution changes the world. Specifically, an effect is defined as a dictionary that couples the trigger conditions and the actual effect. Note that such structures are similar to *production rules*, like the ones that are used in Sheldon Klein's murder-mystery generator and *Comme il Faut*, as I discussed in Section 4.1.3. Here is a code snippet that defines an effect of ‘ridicule‘ that causes the character who is ridiculed to lower her charge toward the person who has just ridiculed her: ``` { "conditions": lambda c: c.me is c.insulted, "effect": lambda c: c.me.update_charge( c.insulter, -5 ) } ``` One authoring pattern is to conditionalize an effect on a character's personality profile, which means the same action will affect characters differently, depending on variation across their personalities. This works in the style of Richard Evans's modeling of personality traits as conditionals—for example, a ‘thrill seeking‘ trait being represented by a rule of the form *If I perform a risky action $$ Excitement* [evans2011representing, p. 37]. Here is an example effect definition that follows this pattern to specify that cruel characters are impressed by cruel acts (and thus increase charge toward the culprits): ``` { "conditions": lambda c: ( c.me is not c.insulted and c.me.personality.cruelty >= 25 ), "effect": lambda c: c.me.update_charge( c.insulter, 5 ) } ``` - **Salience definitions.** Each action that a character knows about will have an associated *salience* value that captures how notable the action is to that person. Salience affects the likelihood of remembering an action, propagating knowledge about an action, and taking actions that cast past actions in their roles. For example, a character is more likely to remember giving birth to a child than drawing a picture in school, and this is captured by the former having a higher salience. Likewise, characters are more likely to gossip about an attempted arson than a character admiring the sunset. Moreover, it would probably not even make sense to gossip about someone admiring the sunset, because its salience is low—to capture this, the ‘gossip‘ action definition might say that its ‘past-action‘ role can only cast past actions whose saliences exceed some threshold. [Note: This would be captured by a precondition along the lines of ‘gossiper.salience( past_action) > 50‘).] Critically, action saliences are also conditional, which captures the intuition that an action may be more notable to some characters than others. For example, the salience definitions for the action ‘give-birth‘ specify that while the action will be fairly salient to anyone who hears about it, it will be *extremely* salient to the mother who gave birth. Salience definitions resemble the production rules specified in effect definitions, except that that the right-hand side specifies a *salience increment*, rather than an effect. Here are two salience rules that capture that a ‘ridicule‘ action is more notable to the character being insulted than to the one doing the insulting: ``` [ { "conditions": lambda c: c.me is c.insulted, "value": 750 }, { "conditions": lambda c: c.me is c.insulter, "value": 200 } ] ``` Here, the ‘value‘ component specifies a salience increment on an arbitrary scale. As I will explain below, when a character experiences or hears about an action, its salience to her is incremented according to all of the salience rules that fire. In this way, if an event becomes the talk of the town (county), it will become more salient to everyone simply because they will keep hearing about it. Action saliences decay from the passing of time, and forgetting happens when a low salience threshold is crossed. To be clear, saliences are specifically attached to the knols that collect knowledge about an action. - **Special.** Certain prospective actions are not included in the pool that is used by the action manager for typical action selection—these are called *special actions*. Generally, special actions are contingent on earlier actions having already been taken, which means it would not make sense for a character to spontaneously take one. For example, the special action ‘construct-frame-for-building‘ can only be taken if the action ‘lay- foundation-for-building‘ was already taken. It may seem like this contingency relation could simply be expressed in the precondition logic for ‘construct-frame-for-building‘, but this would not work because the same action bindings must be used for ‘lay-foundation-for-building‘. To solve this problem, I have developed an authoring pattern whereby the effects of one action may cause a special action to be *queued* with a set of prespecified bindings. For example, one effect of ‘construct-frame-for-building‘ is that a special action is queued for the builder, with prespecified bindings that cast the same building in the ‘building‘ role (so that the character does not spontaneously decide to build a frame on some other foundation laid by another character). I will explain exactly how action queueing works below. - **Cooldown.** Finally, some actions should not be taken multiple times during some duration, and the system is able to enforce such concerns by utilizing the *cooldown* component of an action definition. This component is specified as the number of timesteps until the action may be taken again. [Note: More precisely, a cooldown declaration for an action will have an associated set of bindings, which means the initiator cannot take that action again *with the same bindings* until the cooldown is lifted. More precisely still, the associated bindings will be a set of *minimal bindings*, meaning *optional roles* are not included. I will explain what these concepts mean below, but this is not a very important detail.] Generally, I utilize this authorial affordance to combat repetitive action, though it could also be to enforce normative social behavior. An example value that I have authored is a 30-timestep cooldown on the action ‘gaze-upon-the-stars‘, which I specified because characters were constantly taking the action, even multiple times on the same timestep. #### Role Definitions As I noted in the last section, character actions are associated with *roles* that are filled by characters or other entities in a storyworld. As such, a critical component of an action definition is a collection of *role definitions* that define all of the roles that may be cast in that action. In the opening of this chapter, I mentioned that *Hennepin* is deeply inspired by two earlier systems that were developed in the Expressive Intelligence Studio: *Comme il Faut* (*CiF*) [mccoy2014social], which is the AI system that undergirds *Prom Week* [mccoy2011prom,mccoy2013prom,samuel2015playing], and *Ensemble* [samuel2015ensemble], a successor to *CiF* that carries on this *social-physics tradition*. [Note: The social-physics tradition centers on the notion of character ‘social exchanges', which are patterns of social interaction that are defined by authored procedural content. In *CiF*, social exchanges were originally called ‘social games', but the name was changed as that term came to be associated with online games that are integrated into social platforms [kultima2017social]. In the context of this tradition, the term was actually first used by Michael Mateas and Andrew Stern in their work on *Facade*. In that project, ‘social game' refers to a proceduralized pattern of social interaction whereby the player performs *discourse acts* that modulate a numeric score that is associated with the social game [mateas2005structuring, pp. 94]. For example, the *affinity game* tracks whose side the player is taking—Grace's or Trip's—by maintaining a score that is modulated as the player performs discourse acts over the course of gameplay. The term is actually adapted from Eric Berne's *transactional analysis*, a framework that applied game theory to social psychology, resulting in the identification of patterns of human interaction that Berne calls *games* [berne1968games]. When Josh McCoy began working with Michael Mateas, after the latter arrived at UC Santa Cruz from Georgia Tech, they refined the notion of a social game under the inspiration of Erving Goffman's *dramaturgical analysis* [goffman1959presentation], which McCoy had already studied as an undergraduate at Earlham College [mccoy2004simulations]. This initial reformulation is the subject of the first two papers on what would become the *CiF* project [mccoy2009enabling,mccoy2009computation], and its subsequent development spans from two other early papers [mccoy2010authoring,mccoy2010comme] to the solidified notion as it is recounted in an extensive series of later works [mccoy2011comme,mccoy2011prom,mccoy2013prom,mateas2013architecture,mccoy2014social,samuel2015playing], including the *Prom Week* core team's respective dissertations [mccoy2012all,treanor2013investigating,samuel2016crafting,reed2017changeful]. Finally, more recent offshoots of this work include the *Immerse* project [shapiro2013creating,shapiro2015composing,ferguson2015immerse] and the aforementioned *Ensemble* project, which itself splintered into separate initiatives that were informally (but affectionately) referred to as ‘*Ensemble* west' [samuel2015ensemble], based at UC Santa Cruz, and ‘*Ensemble* east' [treanor2015social,treanor2016framework], based at American University (where Mike Treanor, Josh McCoy, and Anne Sullivan were each based for a period).] In *CiF*, there is an implicit notion of a role in that each action (called a *social exchange*) has an *initiator* and a *responder*, and some actions may also incorporate or otherwise reference a third character, called the *other*. *Ensemble* still requires an initiator and a responder, but it extends *CiF* by allowing for any number of additional characters [samuel2015ensemble, p. 25–26]. These additional characters do not directly participate in the social exchange, but they may be referenced in its preconditions and effects. With *Hennepin*, I sought to extend this development further to make an even more flexible role schema. First, while work in this tradition specifically concerns social interactions (naturally), I am also interested in modeling the internal lives of characters, as I have expressed throughout this dissertation. As such, my schema does not require an action to have a recipient (as with the ‘responder' role of *CiF* and *Ensemble*). For instance, the aforementioned ‘cringe-over-embarrassing-memory‘ occurs within a character, and as such it has no recipient. Next, in the tradition of *Talk of the Town*'s simulation of character knowledge phenomena, I wanted actions to be *observable* by other characters, and moreover I wanted actions to have potentially many participants. As such, my schema allows for action definitions that incorporate an arbitrary number of active, physically present participants. Finally, I wanted my schema to support actions that incorporate entities that are not characters—for instance, in ‘cringe-over-embarrassing-memory‘, a past action is the subject of embarrassment, while ‘write-a-poem‘ involves a poem artifact that is produced by the action. In the end, my desire for an extremely flexible role schema is what caused me to abandon my plan to integrate *Talk of the Town* and *Ensemble*, a decision that led to the development of this entirely new simulation engine. In *Hennepin*, a role is defined compositionally according to its attributes, and these attributes drive and constrain the action manager's procedure for selecting candidate action bindings during action selection (as I will explain shortly). The following attributes are at an author's disposal in defining an action role: - **Action.** This is not an attribute, but rather the particular action definition that the role is associated with. Roles are defined within an action definition, and thus with regard to a specific *action*. - **Name.** This is likewise not an attribute, but instead a *name* that is attached to a role definition for human legibility. Example names include ‘admirer‘, ‘hugger‘, and ‘insulter‘. - **Initiator.** When this attribute is present, an entity that is cast in this role will serve as the *initiator* of the corresponding action. This notion is inherited from the social-physics tradition. When the action manager is handling action selection for a given character, it is specifically reasoning over actions for which that character may be cast in an initiator role. - **Recipient.** A role with this attribute casts a *recipient* of the action. Like the ‘initiator' attribute, this one is also inherited from the social-physics tradition, though I have renamed ‘responder' according to my preference for this term. [Note: In the social-physics tradition, character actions are ‘social exchanges' in which an initiating character proposes an action that a recipient either accepts or rejects, and this decision determines which effects will be triggered. As such, in this work the term ‘responder' makes sense, but in my scheme the recipient of an action does not necessarily actively participate in it.] There is nothing particularly special about a recipient role, except that the system records that an entity cast in one is a recipient, which can be an important type of information at the curation stage. - **Bystander.** This attribute specifies that the role is cast by a *bystander* to an action. Bystanders are cast probabilistically from a pool of nearby characters, and they may witness actions (to form memories about them) and be referenced in action effects, but they do not actively participate in the action. For instance, a bystander who witnesses a character ridiculing someone else may lower their charge for the offending party (or raise it if the offended party is an enemy, or whatever else an author may wish to specify). - **Hearer.** A role with the special *hearer* attribute is cast by a character who learns about an action after the fact. This attribute exists to allow for an author to specify different effects for people who hear about something secondhand. For instance, a character who only hears about a ‘ridicule‘ action may be less repulsed than one who witnesses it firsthand. - **Character.** This attribute specifies whether a character must be cast in this role, which guides the action manager's formation of the entity pool that is sampled to form candidate action bindings. - **Action.** If this attribute is present, the role can only be filled by another action. Again, this guides the action manager's binding process. - **Location.** This specifies that a location (county, parcel, lot, building, etc.) must be cast in the role. - **Value.** A value must be cast in the case of this attribute being present. Example actions that cast values include ‘extol-value‘, ‘denounce-value‘, ‘agree-about-value‘, and ‘disagree-about-value‘. For instance, two characters with conflicting extreme opinions on the value ‘tradition‘ might participate in the latter action. - **Artifact.** Some actions have roles that cast artifacts, such as ‘examine- artifact‘, which characters use to examine an existing artifact, and ‘draw-a- picture-of-action‘, whereby a character creates a new artifact (a picture) that recounts an action (for example, a house burning down). The latter action extends my exploration in *Talk of the Town* of artifacts that transmit knowledge—this was explained back in Section 9.2.11—in that by examining that picture, a character would learn about the house burning down. - **Symbol.** It can sometimes be useful to define roles that should be filled by arbitrary types, such as a string or a number. For example, in the action ‘come-up-with-name-for-town‘, the proposed name for a new town is simply a string, and so the corresponding role would have this *symbol* attribute. In such a case, however, the action manager will have no way of knowing how to construct a pool of candidate bindings, which means such a pool needs to be explicitly defined in the action definition. This is done by specifying a *candidate-pool directive*, which is defined as arbitrary code that returns a list of objects, which is then treated as the pool of candidates for that role. For instance, here is the candidate-pool directive for the action ‘berate-employee‘ (this lambda expression takes the initiating character as its argument ‘i‘, since it precedes there being any candidate binding): ``` "binding pool directives": { "employee": lambda i: [ p for p in i.location.people_here_now if p.routine.occasion("work") ] } ``` - **Absent.** This attribute specifies whether an entity cast in the role must be physically present at the location of the action; this guides the action manager's formation of a candidate pool for bindings. For example, in the action ‘talk-behind-someones-back‘, the character who is being gossiped about should not be physically present, in which case this attribute would be included in the corresponding role definition. - **Build.** If this attribute is activated, the role will be cast by something that does not exist yet. This is used in cases where an action produces something new—for example, in the action ‘write-a-poem‘, a poem artifact is produced by the action, and the corresponding role definition makes use of this attribute. While usually such roles will be cast by newly created artifacts, that is not always the case. In the action ‘give-birth‘, for instance, a new character is created to fill the associated ‘newborn‘ role. In order for the action manager to actually construct the appropriate entity, the action definition must contain an associated *build recipe*. This is defined as arbitrary code that returns an object, which is then cast in the role. - **Minimum number cast.** An author may specify that a role is optional in the sense that an action can still occur without any entity being cast in the role. This is defined by setting this attribute to 0, which makes for an *optional role*. In turn, it may also be set to other values in cases where that makes sense. For example, the action ‘make-the-whole-group-laugh‘ requires at least four recipients to be cast, since otherwise a group is not being made to laugh. - **Maximum number cast.** Likewise, an author may specify a *maximum* number of entities to be cast in a role. Typically, I define bystander roles to have a fairly low number, since this saves on computation and it is not believable, for instance, to have dozens of bystanders looking upon an innocuous action like ‘chit-chat‘. - **Chance.** Once the specified minimum number of entities have already been cast (but before the maximum number has been met), a *chance* value specifies the likelihood of casting additional entities in that role. This essentially models a notion of how likely an event is to be witnessed—for example, the chance would be much higher for a bystander role of the action ‘start-fight‘, as opposed to ‘chit-chat‘. #### Action Selection In *Hennepin*, a module called the *action manager* carries out action selection, and it does so according to a simple operating principal: to maintain believability, characters need only to *refrain* from taking actions they would *not* believably take, which means it is rarely necessary to take the most fitting action. In this way, with regard to believability, the system attempts to produce *satisficing*, as opposed to *optimal*, character activity. This distinction originates with Herb Simon's seminal 1956 paper “Rational Choice and the Structure of the Environment”: > The central problem of this paper has been to construct a simple mechanism of choice that would suffice for the behavior of an organism confronted with multiple goals. Since the organism, like those of the real world, has neither the senses nor the wits to discover an “optimal” path—even assuming the concept of optimal to be clearly defined—we are concerned only with finding a choice mechanism that will lead it to pursue a “satisficing” path, a path that will permit satisfaction at some specified level of all of its needs. [simon1956rational, p. 136] In the case of this project, the action manager has one need: produce believable character activity. This principal specifically manifests in a policy for action selection whereby: prospective actions are randomly targeted, candidate bindings for those actions are randomly assembled, and if the preconditions hold for any such candidate binding, the action is taken immediately. Though I figured that it would hinder believability, I tried this approach as a first attempt because I was worried about the computational burden of having hundreds of characters decide between potentially thousands of actions—and potentially millions of bindings—thousands of times over the course of a storyworld's history. [Note: Another system that simulates on the order of thousands of characters is the recent indie game *Project Highrise*. Though it models characters in less detail than I do here, the game's simulation works in real time, and so its creator Rob Zubek also makes concessions to work under competing design and computational constraints, as he explains in a book chapter titled “1000 NPCs at 60 FPS” [zubek2017npcs].] As I have mentioned above, I envision such a history resulting in an accumulation comprising on the order of a few million character actions. Due to the size of a *Hennepin* storyworld (in terms of the number of entities that may be cast in action roles), even selecting an optimal binding for a single predetermined action could take a very long time. In the social-physics tradition, during *volition formation*, the system selects the most optimal action by evaluating thousands of social rules for every possible action and every possible binding. This approach is feasible when the storyworld contains only a dozen or so characters—as in *Prom Week* [mccoy2011prom,mccoy2013prom], *Mismanor* [sullivan2011extending,sullivan2012design,sullivan2012grail], and the kind of experiences that are envisioned in the *Ensemble* project, such as Ben Samuel's *Writing Buddy* [samuel2016design] and recent prototypes developed by Mike Treanor and collaborators [treanor2016framework,samuel2018playable]—but it is probably not feasible in a *Hennepin* storyworld. While I knew I would have to take a satisficing approach, I figured that randomly selecting viable actions would produce strange character activity—to my surprise and good fortune, this was not the case. Through testing, both by myself and with others, I found that believability did not seem to be hindered as long as characters did not take actions that were totally unreasonable in the circumstances. Given that this is what action preconditions specify—their purpose is to outright preclude actions that characters should not take—believability was thus not hindered. Even if a more fitting action is available but not taken, humans will tend to unconsciously narrate reasons for why the character did what they did (and did not do what they did not do)—thus, by targeting this tendency, I had utilized the design pattern of *apophenia hacking*, a notion that I introduced in Section 9.3. [Note: Indeed, this move appears to be in line with the apophenia hacking that Matt Brown has promulgated in the context of *The Sims 2* [brown2006power], which I noted above.] I am glad that I tried the most basic approach first, since otherwise I would have likely crafted up a selection policy that would do more reasoning (and thus require a lot more computation). This is an example supporting the idea that the simplest approach should always be tried first, even if it seems unreasonable, because such an approach will provide the greatest payoff if it does happen to work [ameisen2018always]. Here is a very high-level sketch of the action manager's procedure for action selection, which I will describe in more detail momentarily: ``` randomly select character from actors pool if character has (semi)urgent queued action, target if successful, execute action and move on otherwise, target randomly selected action evaluate initiator preconditions randomly assemble minimal bindings evaluate required-role preconditions for each optional role randomly select binding evaluate optional-role preconditions if successful, execute action and move on ``` On each timestep that will be simulated, every character in the county is added into an *actors pool*. Next, the action manager randomly selects a character from the pool and attempts to settle on bindings for an action that the character will take as an initiator. First, the manager checks whether the character already has a (semi)urgent action queued up, a notion that I will explain shortly. If she does have an action queued up, the manager targets it with the specified bindings—if this is successful (all preconditions hold), the character takes that action and the manager selects a new character from the actors pool. [Note: If there are multiple queued actions, the one with the highest priority is targeted.] Assuming the character does not have a queued action, the manager randomly selects a prospective action from the pool of generic actions (i.e., special actions are not considered). Next, the manager evaluates the initiator preconditions for that prospective action. While I did not mention this above, the preconditions in an action definition are actually split into three groups: *initiator preconditions*, *required-role preconditions*, and *optional-role preconditions*. This separation is meant to reduce computational burden, since it results in preconditions being evaluated only as they become relevant in the process of assembling a set of candidate bindings. The initiator preconditions do not have access to the rest of the candidate bindings (because they have not yet been assembled), which means they only specify what must hold for the initiator and the storyworld at large. Most often, initiator preconditions operate on a character's personality profile, so that certain actions may only be taken by characters with certain profiles, which results in character actions that express the personalities of their initiators. If the initiator preconditions hold, the action manager proceeds to randomly assemble a candidate set of *minimal bindings*—that is, bindings for only the required roles in the action definition. A required role is one whose specified minimum number to be cast is greater than zero (excluding roles with a ‘build‘ attribute). To randomly assemble a binding, the manager first builds a *candidate pool* for each of the required roles by operating over the definitions for those roles. For instance, if a role definition includes the ‘character‘ attribute but lacks the ‘absent‘ attribute, then the manager will add all the nearby characters (co-located with the initiator) into the pool. Alternatively, if the action definition includes a candidate-pool directive for that role, that is used instead to construct the pool. Once all of the pools have been selected, the ordering of their elements is shuffled (to prevent repetitive binding) and a *Cartesian product* of the pools is constructed, which will contain every possible minimal binding. [Note: To be clear, this is not actually constructed and stored in memory, but rather each instance in the product is generated in a lazy manner.] From here, the system attempts to target each minimal binding one by one, in each case evaluating them against the action definition's required-role preconditions. Required-role preconditions operate only over the bindings of required roles in an action definition. If these preconditions hold for any minimal binding, the action will be executed, but first the manager attempts to also fill the optional roles. To cast entities in the optional roles included an action definition, the system again constructs candidate pools for each (again ignoring roles with a ‘build‘ attribute). Now, instead of forming a Cartesian product of the pools, the manager simply attempts to fill each optional role one at a time (until the maximum number to be cast in that role is reached, or the pool runs out). In attempting to cast an entity into one of these optional roles, the manager evaluates the action definition's optional-role preconditions, which may operate over an entire set of candidate bindings. Once each optional role has been cast or all the pools have been exhausted, optional role binding has been completed. At this point, the manager has successfully assembled a viable set of bindings, and so the action may be taken by the initiating character. Had every set of minimal bindings violated the required-role preconditions, the action manager would have *backtracked* [russell2016artificial, p. 84] to move on to another candidate action, again by randomly selecting from a pool containing all the generic actions (minus any for which targeting has already failed). Alternatively, a prospective action will also be abandoned if the initiator preconditions do not hold. If the action pool is exhausted for some character, she will not take any action at this time, and in turn she is removed from the actors pool. When this happens, it means that every set of minimal bindings was considered, but none of them were viable. Once an action and bindings has been selected for a character, she takes that action, which leads to a concrete realization of it and the execution of a number of effects, as I will explain in the next section. Depending on a few concerns, the character may or may not be removed from the actors pool. First, if the character has a queued urgent action, she will remain in the actors pool. If this is not the case, a probabilistic trigger determines whether the character will remain in the pool—this probability depends on the character's ‘activity_level‘ personality trait, which makes more active characters act more often. An authorial affordance of this procedure enables the designation of some characters as being more important than others, which could be modeled by simply turning up the likelihood of remaining in the actors pool for the central characters. In this way, a subset of characters would act more often, and the rest of the characters in a county would constitute a kind of backdrop. I do not take this measure because I want every character to be important during the simulation, though I do plan to do such homing at the level of curation, in *Sheldon County*. #### Concrete Actions Once a prospective action and bindings have been selected for an initiating character, the action is taken and a representation of it (as a past action) is stored in the chronicle. The following kinds of data are stored to represent a past action for reasoning later on (both during the simulation and curation phase): - **Number.** As each action occurs, it is attributed am *action number* corresponding to its position in the chronological order of all actions. This captures the ground truth of the temporal ordering of simulated events, which is obviously useful information in the curation phase. - **Name.** This is inherited from the name field of the corresponding action definition, which allows for reasoning about an action's type. - **Timestep.** The timestep on which the action occurred. - **Location.** The location at which an action occurred. - **Causes.** The earlier actions that caused this action to occur, by contingently unlocking it or explicitly triggering it. Contingent unlocking may be identified in a few different ways. First, when an action binds a role with the ‘action‘ attribute, the action bound to that role can be recorded as having caused the one at hand. For a given action, each such bound action is added to this list. Additionally, if an action explicitly triggered this one, through an effect of the former causing the latter to be queued, it will also be added into the list (more on this soon). This is how causal bookkeeping (see Section 5.4) works in *Hennepin*—though subtle, this is the most important aspect of the entire simulation engine, since it greatly facilitates story sifting in *Sheldon County*. [Note: As Ian Horswill noted in his feedback on an earlier draft of this thesis, Stacy Marsella and Jonathan Gratch's *Ema* project employs a similar mechanism for what I call causal bookkeeping [gratch2004technical]. In this system, an agent generates causal interpretations for event sequences in order to produce corresponding emotions in a way that operationalizes *appraisal theory* [scherer2001appraisal]. For instance, in light of an unfortunate event, an agent will trace backward along the causal chain preceding the event to assign blame; if the agent itself to blame, it “feels” guilt, but if someone else is to blame, it responds with anger. One difference here is that causal bookkeeping in this system is subjective: agents themselves carry out the procedure by operating over beliefs about the world and other considerations, including the intentions of other agents [gratch2004technical, p. 75]. In my approach, causal bookkeeping is carried out by an omniscient agent, and as such the causal records produced thereby reflect a ground truth for the simulated world. Nonetheless, I find the subjective treatment of the process to be quite interesting.] - **Caused.** Subsequent actions that were caused by this action, either due to contingent unlocking or explicit triggering. As an action adds past actions into its ‘causes‘ record, it is in turn added into the ‘caused‘ listings associated with those past actions. This is the other half of causal bookkeeping. - **Bindings.** All of an action's bindings, with each entry coupling a role and the entity cast in that role. - **Initiator.** The character who took this action, that is, the entity bound to the role with an ‘initiator‘ attribute. An action can only have one initiator in *Hennepin*, as a simplifying measure. I could specify a new role attribute for a secondary initiator, but I have not found a use case for that as of yet. If I do, however, it will be easy to specify—by simply adding a new role attribute—and this is a core appeal of my compositional role definitions. [Note: Indeed, the individual attributes in the schema were added over time as new ones became needed or desired.] - **Recipients.** The recipients of an action are all of the characters who are bound to roles that have the ‘recipient‘ attribute. As such, an action can have multiple recipients; this is another departure from *Ensemble*. - **Bystanders.** The bystanders to an action are all the characters who are bound to roles that have the ‘bystander‘ attribute. As I noted above, bystanders to an action witness it, but do not actively participate in it. When someone is a bystander, everyone else involved in the action knows it. I could also specify a new role attribute indicating a secret observer, if I encountered a use case for doing so. - **Nucleus.** The initiator and the recipients of an action compose its *nucleus*, which are the active participants in an action. Sometimes it is useful to isolate these particular entities. - **Participants.** An action's *participants* comprise its initiator, recipients, and bystanders, but not any absent characters or non-character entities. To be clear, these are not the active participants in an action, but rather all of the characters who were present and participated in any way (including simply witnessing). #### Building Entities If any of an action's roles have the ‘build‘ attribute, the action manager follows the associated build recipes to construct the entities that will be cast in that role. For example, in the action ‘write-a-poem‘, a poem artifact is built, while in ‘give-birth‘, a new character (the newborn) is generated. When such an entity is built, it is added into the action's bindings accordingly. #### Action Effects Once a concrete action has been instantiated, its effects are conditionally *executed*. As I explained above, effects are defined as production rules that couple conditions (on the left side) and arbitrary code that will be executed if the conditions hold (on the right side). To trigger these rules, the action manager takes every participant in the action (including bystanders) and evaluates each rule—if a rule is triggered, the code capturing its actual effect is executed. Additionally, the action manager does this for any actions that are *relayed* by the action that has just transpired. For example, when a ‘gossip‘ action casts a past action in its ‘past-action‘ role (this being the past action being imparted of the gossip), the effects of that past action (which is being relayed by virtue of the ‘gossip‘ action) will also be triggered. This could cause someone hearing about a ‘ridicule‘ action to lower their charge toward the offending party, for instance. Critically, if the character already knows about the relayed action, its effects will not be executed again. [Note: This was not in place originally, and it led to the effects of some actions being far too intense. For instance, if a character was ‘ridiculed‘ by someone else, each time they thought of the action or heard about it later on, the effect of it would be executed just as it had when it was first experienced, which meant the insulted character's charge for the insulter would drop to extremely negative values. Ideally, the system would decay the strength of an effect each time it is executed, but there is unfortunately no general way of modeling this, since effects are defined as arbitrary code. I thought about defining secondary and tertiary effects for cases of an action's effects being triggered for the second and third time, but I decided that the authorial burden would be too immense.] One critical authoring pattern is to define an effect whereby code is executed that leads to the *queueing* of a subsequent action as a kind of explicit triggering of a potential subsequent action by this one; I will discuss this below. #### Memories, Knowledge Propagation, and Salience Updates In Section 11.2.9, I will describe how actions trigger updates to character knowledge, but for now I will briefly summarize. When an action occurs, its participants and other witnesses form a memory about the action. Later, this knowledge may be propagated by performing actions that reference the earlier action. Likewise, characters may perform actions that create artifacts that encode knowledge about earlier actions—for example, ‘draw-a-picture-of-action‘—and by examining such artifacts characters learn about the events they recount. Finally, learning about an action, or hearing or thinking about one that is already known, boosts its salience to the beholder. #### Fulfilling Aspirations As I will explain in more detail in Section 11.2.8, actions may cause character aspirations to be fulfilled. Whenever an action occurs, the *aspiration manager* uses it to evaluate every aspiration trigger for all aspirations that are held by living characters; if a given one fires, the corresponding aspiration has been fulfilled. For instance, if a character aspires to become a police officer, a ‘hire‘ action that represents the hiring for that position would fulfill the aspiration. #### Action Queues Perhaps the most critical aspect of *Hennepin* is its modeling of actions that explicitly enable the potential emergence of future actions—this is handled by a mechanism for *queueing* future actions along with preassembled bindings. That is, each character has an associated *action queue* that indexes all her queued actions. While it would be possible to simply rely on the precondition logic in action definitions to handle the unlocking of future actions according to past ones, it is easier from an authorial standpoint (and more efficient from a computational standpoint) to store the causal potential as the earlier action transpires. For example, if a character takes the action ‘lay-foundation-for-building‘, this contingently unlocks a subsequent ‘construct-frame-for-building‘ action. This could be modeled by including a precondition in the action definition for ‘construct-frame-for-building‘ that requires that an earlier ‘lay-foundation- for-building‘ occurred, but then this precondition will be evaluated constantly as characters who have no business constructing a frame (because they have not already laid a foundation) attempt to take the action (due to the action manager's policy of random targeting). Moreover, the ‘construct-frame-for-building‘ action should maintain bindings from the earlier ‘lay-foundation-for-building‘, namely the entity bound to the ‘building‘ role. This could be accomplished in tandem with the approach of using condition logic by specifying a candidate-pool directive that says to look at the ‘building‘ binding for an earlier ‘lay-foundation- for-building‘ action, but this would mean retrieving information that could have easily been stored when the earlier action transpired—especially considering that the earlier action was almost certain to lead to the subsequent one. Another strong use case for queueing actions pertains to character reactions that should occur immediately after a precipitating action transpires. For instance, if a character performs the action ‘start-fight‘, then either the initiator or recipient should do something next in response. If such a response were not queued, the initiator might be removed from the actors pool, or worse, the action manager may randomly select an inappropriate action for one of the participants to take next (for instance, ‘gaze-upon-the-stars‘). [Note: Actually, I kind of like the image of a fight being instigated and one of its participants responding by gazing upward contemplatively.] Subsequent actions are queued as part of the execution of the effects of the precipitating action. Specifically, a method of the action manager is called that requires information of the following type: - **Trigger.** The action that will have precipitated the queued action (if it does ultimately occur) is called its *trigger*. When a queued action is taken, the trigger will be automatically added into the concrete action's ‘causes‘ record. This is causal bookkeeping, discussed at length in Section 5.4. - **Action name.** The name of the queued action. - **Bindings.** Partial or complete bindings for the queued action; if partial bindings are supplied, the action manager will attempt to bind the additional ones when the queued action is eventually targeted. One special kind of binding concerns a *null initiator*, whereby an action is queued that is not actually taken by a character. An example such action is ‘burn-to-the-ground‘, which is queued when a building is set on fire. When such an action is queued, the null initiator is added into the actors pool, and the actions may be targeted in the case that the null initiator is selected to act. When the null initiator has no actions queued, it does not appear in the actor pool. This is a similar concept to Chris Crawford's notion of *Fate* being a character [crawford2012chris, pp. 209–226]. [Note: In *The Sims 3* [sims3], towns are interestingly modeled to form desires (for instance, pertaining to gender ratio) and take actions in pursuit of them [evans2010modeling].] - **Urgent.** An *urgent* queued action will be taken on the current timestep, and a character who queues an urgent action will be kept in the actors pool (or added back into it). If an urgent action cannot be taken (due to its preconditions not holding or to the remaining roles not having viable bindings), that is an authoring error. An action should never be queued as urgent if it cannot be immediately taken, since that it is the operational meaning of ‘urgent' in this sense. - **Semiurgent.** Whenever it is a character's turn to act, the action manager will always target any *semiurgent* actions in her queue, but having one in the queue does not force the character back into the actor pool (as with urgent queued actions). An example semiurgent action is ‘break-up-fight‘: if a character decides to break up a fight, she should attempt to do so on her next chance to act this timestep, but it is fine if the timestep ends without her getting a chance to do so. To be clear, the distinction between urgent, semiurgent, and nonurgent queued actions is as follows: - *Urgent.* If an urgent action is in a character's queue, she is forced into the actors pool and she will not stop acting—and thus the timestep will not terminate—until the action is taken. Whenever the character gets a chance to act, the action manager targets the urgent action. - *Semiurgent.* If it is a character's turn to act and she has a semiurgent action in her queue, the action manager targets it. However, having a semiurgent action does not force a character to remain in (or re-enter) the actors pool, which means the action may or may not be taken on the current timestep. - *Nonurgent.* If a queued action is not marked urgent or semiurgent, the action manager may probabilistically target it on a given timestep. As such, it is not guaranteed to be targeted at any point, let alone the current timestep. This probabilistic trigger considers the character's ‘activity_level‘ personality trait, which means more active characters tend to dip into their action queues more often. Often, nonurgent queueing occurs for special actions, which can only be taken if they are queued. An example action that is queued nonurgently is ‘contemplate-serial-mistreatment‘, in which a character recalls three past actions by which a specific other character mistreated her. This action is queued on the occurrence of a third such action, but it is more potent to have it occur some time later, rather than immediately (i.e., urgently or semiurgently). As such, it is queued nonurgently. - **Priority.** The *priority* of a queued action specifies exactly how urgent it is, according to a numeric score on an arbitrary scale. For example, ‘escape-burning-building‘ should have a higher priority then ‘retort‘, otherwise a character in a burning building would attempt to retort before escaping to safety. Priority modeling is commonly used in systems with action queues, especially in game AI (e.g., [cutumisu2009architecture,zubek2010needs,allbeck2010carosa,ingebretson2014concurrent,shapiro2015aesthetic]). To be clear, in *Hennepin*, queued actions are prioritized by urgency and then secondarily by priority. - **Location.** A queued action may be specified such that it can only be taken at a certain location. For example, ‘construct-frame-for-building‘ will require the character to be at the lot on which the building is being erected. - **Date.** Likewise, a queued action may only be viable on some particular future day. For example, if a character plans a birthday party and invites her friends, those who accept the invitation will make a plan (queue an action) to go to the location of the party on the specified date. Of course, it would not make sense to go to the party at a different time, though that could be humorous, and in fact such a humorous effect could be intentionally targeted—for example, if a character is scatterbrained, the action manager could intentionally queue her action on the wrong date, or instead schedule an ‘arrive-at-party-on-wrong-date‘ action for the wrong date. - **Time of day.** Sometimes an action only makes sense at a certain time of day. For example, ‘set-fire-to-building‘ and other criminal actions are probably better suited for nighttime. As I explained above, *Hennepin* models day and night timesteps, so these are the two options here. - **Duration.** Some queued actions may become stale if they are not taken soon enough, and such expiration can be modeled by specifying the *duration* (in terms of the number of timesteps) that a scheduled action should stay in the queue. When a queued action expires, it is removed from the queue. - **Abandonment conditions.** The *abandonment conditions*, if triggered, cause a queued action to be removed from a character's action queue. Whenever a queued action is about to be targeted, the action manager first evaluates its abandonment conditions, which if triggered will dequeue the action (causing the manager to target a different one instead). These are especially useful for urgent actions that become unavailable upon the storyworld changing in some way, since otherwise the action manager will hopelessly keep targeting the action, even though its preconditions cannot possibly hold. [Note: When this happens, the action manager instead targets a random generic action for the character and keeps her in the actor pool, but once the pool dwindles down to just her, the simulation reduces to her doing the same generic actions over and over again. I keep this is in there essentially as a visual cue for an authoring error—since the incessant repetition of an action is visually striking in my console output during world generation—but it does produce some amusing scenes. For instance, before I had authored many generic actions, one character could not take his urgent queued action and in fact could only perform ‘crack-a-joke‘, which led to him cracking literally millions of jokes before I manually interrupted the simulation execution. The image of a man nervously cracking millions of jokes is uncanny. In an ironic variant on this scene, a character named Nellie Ancell incessantly performed ‘extol-virtues-of-value‘ with regard to the importance of ‘self-control‘.] Here are example abandonment conditions for the action ‘fight-back‘ (specifying to drop the queued action if the character who instigated the fight is no longer near her opponent): ``` abandonment_conditions=lambda c: ( not c.instigator.is_at(c.opponent.location) ) ``` - **Expiration codes and kill codes.** One authoring pattern is to queue multiple candidate variants of the same kind of response all at once, with the idea that only the appropriate one will actually be selected. For example, a recipient of a ‘start-fight‘ action may respond by performing either ‘fight-back‘, ‘flee-from-fight‘, or ‘talk-it-out‘, where the specific appropriate response will depend on the character's personality profile. For instance, these actions could be driven by, and could be used to express, a high ‘violent‘ trait, a low ‘bravery‘ trait, or a ‘high‘ assertiveness trait, respectively. [Note: As I mentioned in Section 11.1.2, one of my major authoring patterns so far is to author actions that are meant to express strong personality traits. Specifically, I scroll through the fifty traits and, for each, think about what kind of actions someone would do if that trait manifested in an extreme way (in either direction). For example, for characters with extremely high ‘vanity‘, I authored an action ‘admire-reflection-in-mirror‘. Such an action is pointless with regard to how it changes the storyworld, but it does a great job of expressing what a character who takes the action is like, which meets Richard Evans's call for actions that vividly express personality [evans2011representing]. This is where the dramatic charge of the Adams brothers' personality typology is especially appreciated, since their traits are so much more evocative than the Big Five—for example, compare ‘agreeableness‘ with ‘vengeful‘. I am also utilizing this authoring pattern for character values, in which the resulting actions are meant to express a strong conviction about some particular issue, such as a ‘hard work‘ or ‘diversity‘.] The queueing of this responses can easily be conditionalized, since queuing behavior is defined on the right-hand side of the conditional action effect rules. As such, the personality trait values that I have just mentioned could be referenced in conditions that are attached to the effects that would queue the particular response action that corresponds to that personality profile. In this way, only a violent character would queue ‘fight-back‘ and only a character lacking bravery would queue ‘flee-from-fight‘. [Note: This example works in the style of Richard Evans's modeling of personality traits as conditionals [evans2011representing], whereby a core manifestation of personality is in character *reactions*, as opposed to actions. In *Hennepin*, both kinds of personality expression are at work.] But what if a character was both violent and not brave? She would queue both of these actions, and because these would likely be urgent, she would probably take both of them. This could be interesting in that it expresses a case of competing traits with regard to this social context, but in many cases it would not make sense to take multiple response actions that are meant to each be variants on the same archetypal response situation, such as how to respond to a fight being instigated. This is where *expiration codes* and *kill codes* come in handy. When an action is executed, each of its kill codes are retrieved by the action manager, which then proceeds to dequeue any queued action whose expiration code matches the kill code. In the case of the fight response, the action manager could queue each with the same expiration code and same kill code—for instance, attribute the expiration code ‘99‘ to each, and also specify a value for their kill codes as ‘[99]‘. Now, when ‘fight-back‘, for instance, happens to be selected by the violent character who is not brave, the kill code ‘99‘ will be used to dequeue the queued ‘flee-from-fight‘ action. In cases like this, I simply use the location in memory of the object representing the trigger action (in this case, ‘start-fight‘), since that is guaranteed to be unique. I have also used this pattern for more complex coordination, where codes propagate across causal graphs, so that collateral nodes in the graph can cancel one another. For example, a character may attempt to track another character down in order to tell that person something urgent—for instance, that her house is burning down. In this case, two actions are queued at once: ‘search-for-person‘ and ‘report-urgent-situation‘, the latter of which requires the two characters to be co-located. When ‘search-for-person‘ is executed, it in turn causes the character to queue four more actions: three ‘go-to‘ actions by which the character heads to a location where she might find the target character, and ‘give-up-search‘, which is taken after the ‘go-to‘ actions are executed, since it has a lower priority than them. Once ‘give-up-search‘ is executed, the action manager needs to kill the urgent ‘report-urgent-situation‘ queued action, since the target character was not reached (and the urgent action will cause the timestep to never terminate). In order to do this, ‘give-up-search‘'s kill codes must contain ‘report-urgent-situation‘'s expiration code, and this requires the expiration code to be propagated across the causal graph (because ‘give-up-search‘ is a niece/nephew of ‘report-urgent-situation‘). Specifically, ‘search-for-person‘ must pass on the expiration code to ‘give-up- search‘. While this is a relatively simple case, the same approach could be used to propagate codes across more complex causal structures, and indeed this pattern supports powerful coordination between queued actions. #### Action Causality and Causal Bookkeeping Briefly, I would to summarize how causal bookkeeping works in *Hennepin*. As I explained at length in Section 5.4, causal bookkeeping is a technique by which a simulation (or some secondary system) records causal relations between emergent events as they transpire. Critically, this depends on an explicit and simplified modeling of causality—one that specifically models *contingency* relations—which is atypical of character simulations. Generally, action selection in such a simulation relies on the state of the storyworld, rather than explicit reasoning about past events; while this may produce rich character activity, the emergent causal structure that links past events can become too complex to support narration. When the state of the storyworld causes every action and is altered as an effect of each of those actions, then a causal structure resembling a dense lattice obtains: every action was caused by nearly every earlier action and caused nearly every later action. In this way, causality for a given action is distributed sparsely across the set of all preceding actions. While this is likely realistic, it is not how causality works in narrative, where narrower and more comprehensible structures obtain instead. As such, for a simulation to be *narratable*—for it to facilitate a curation procedure by which actual emergent narrative may be produced (see Section 4.2.1)—the narrow causal structures of narrative must be identifiable. I call such structures *emergent contingency structures*, following the *contingency* causal relation identified by narratologist Mark Alan Powell: as opposed to weaker *possibility* and *probability* causal links, contingency obtains when an event clearly causes a later one (in a way that legible to humans). As I also mentioned earlier, the philosopher Abraham Wolf likewise identifies these three links, and additionally a forth one: *chance* [wolf1912philosophy, pp. 329–330]. Of course, chance is not a causal event relation, because an event that emerges by chance does not have any explicit relation to earlier events. [Note: Though see my next footnote.] In *Hennepin*, action causality may work according to all four of these notions. First, an action may be deemed to emerge by *chance* when the definition of its action type includes no preconditions. [Note: This is not especially precise, since a series of earlier actions would have led to the character who takes the action coming to even exist in the first place, for instance. But is my every action caused (according to a possibility relation) by my birth? And then in turn is my every action caused by my mother's birth? And was that not due to a butterfly flapping its wings, and in turn that butterfly being born, and so on and so forth, etc., and so forth. In a sensitive dynamical system, everything causes everything else, and this produces the kind of dense lattice structure that I have argued is antithetical to narration. Nonetheless, it is fair to argue that nothing can actually occur by chance—that seems to be the case—but I think in this context it is more useful to clumsily conceive of chance actions.] Next, an action makes a later one *possible* when its effects change the storyworld such that the latter action's preconditions become satisfied. Third, because of the action manager's satisficing policy, as opposed to an optimal one that would model utility or some other notion of fittingness, the *probability* relation is not really at play in the system, but there are arguable cases. An extension of the authoring pattern of defining a precondition that is simply a probability, such as ‘random.random() < 0.5‘, is to pack in a binary condition as well, resulting in examples like this: ``` lambda c: ( ( c.insulter.hates(c.insulted) and random.random() < 0.7 ) or ( c.insulter.dislikes(c.insulted) and random.random() < 0.3 ) ) ``` All other things being equal, these preconditions provide for a 70% chance of the action being taken if the prospective ‘insulter‘ character hates the candidate ‘insulted‘ character, as opposed to a 30% chance if the former only dislikes the latter. As such, the earlier action that led to a change in the former's charge toward the latter (such that the threshold for hating was eclipsed) could be said to have made this action more probable. Finally, the creme de la creme: *contingency*. [Note: Again, a contingency relation between events obtains when the former explicitly causes the latter, in a way that can be explained simply.] As I have already explained above, contingency relations in *Hennepin* may be obtain in two ways. First, if an action casts an earlier action in any role—such as a ‘gossip‘ action casting an earlier action in its ‘past_action‘ role—the later one is treated as having been contingent on the one that it references. Indeed, how could a character have gossiped about some event had that event not occurred? This a stronger relation than possibility—it is an example of contingency. Next, if an executed action effect causes a later action to be queued (regardless of whether the actions' initiators are the same character), the potential for contingency obtains, and the system tracks this by recording that the earlier action is the ‘trigger‘ of the queued action. If the queued action is ultimately taken later on, then the system will record the contingency relation between the trigger and that action. In both cases, *contingent unlocking*—described at length in Section 5.4—is at work. [Figure omitted] Contingency relations are stored in the ‘causes‘ and ‘caused‘ list attributes of concrete actions, which allows the system to traverse both backward and forward across causal links, which in total work to compose directed acyclic graphs (since the ‘causes‘ and ‘caused‘ lists may each contain multiple actions). This is an *emergent contingency structure*, and it is identified by the procedure of *causal bookkeeping* that I have just explained. [Note: These terms were defined in Section 5.4.] Figure 11.3 illustrates an excerpt from an actual emergent contingency structure that obtained in a *Hennepin* storyworld. As I will explain in the next chapter, this kind of causal bookkeeping makes story sifting a simple matter of retrieval: given some anchor event—what William Labov calls the ‘most reportable event' [labov2006narrative], as I explained in Section 4.1.1—retrieve the emergent contingency structure in which it is embedded by chaining forward and backward until causal termination. For example, in the case of the revenge story shown in Figure 11.3, a story sifter might identify ‘die-in-a-fire‘ as a most reportable event—for instance, by me specifying actions that are inherently *tellable* [norrick2005dark] according to Roger Schank's notion of *absolute interests* [schank1979interestingness]—and then work backward to retrieve all of the events that caused it. This is an operationalization of William Labov's procedure for *narrative pre-construction*, which I also explained in Section 4.1.1. Alternatively, the story sifter could work back to the primogenitor of the contingency structure and then recursively retrieve all of its descendants, which may result in a larger structure that also contains collateral relations to the most reportable event. In any case, such a structure may serve as material that the sifter can pass on to a narrativizer, which can use it to build a narrative artifact recounting a story centered on the anchor event. #### Supporting the Aesthetics of Emergent Narrative Earlier in this dissertation, I noted that the development of emergent contingency structures over simulated time suggests to me the image of a plantlike growth climbing up out of a backdrop of noise. With regard to *Hennepin*, contingent unlocking drives the plantlike growth and the massive accumulation of commonplace actions—actions caused only according to chance, possibility, or probability—are like the spongy detritus out of which the foliage sprouts. In this way, while contingent actions are the most interesting ones—constituting the skeleton of what may be constructed into an emergent story—commonplace ones provide a backdrop of everyday life that contextualizes the contingent actions. [Note: I plan for a storyworld's history to comprise on the order of a few million commonplace actions, and several thousand intriguing ones. The magnitude of total actions can be (roughly) controlled by two authorial levers: the probability of a timestep being simulated and the probability of a character remaining in the actors pool after taking an action.] Without this backdrop, the emergent stories resemble nonfiction (see Section 3.1.1) to a lesser degree, and additionally the analogy to worldbuilding (Section 3.1.3) weakens. Moreover, this admixture of everyday occurrence makes the events recounted in an emergent story stand out more—indeed, some characters may never even participate in an interesting event, but instead will carry out a life of monotonous daily existence. In this sense, the backdrop works as a backbone that props up much of the *aesthetics of emergent narrative* that I defined in Section 3.2: namely, the *aesthetics of the actual*, *aesthetics of a larger context*, *aesthetics of the vast*, and *aesthetics of the improbable*. However, as I have made clear by now, a simulation itself cannot yield these aesthetics, but rather it can enable them at the level of a full-fledged media experience. In my continuing work on *Sheldon County*, I am attempting the capture these potentials, as generated by the underlying *Hennepin*, so that the aesthetics of emergent narrative may characterize the project's procedurally generated podcasts. If I am successful in this endeavor, the pleasure of emergent narrative will obtain in that project. ### Character Aspirations *Hennepin* characters may form *aspirations* specifying what they would like to do in life—for example, a player may aspire to have a child, or found a business, or become a police officer. This system is handled by a module called the *aspiration manager*. Aspirations are defined as a kind of procedural content, and each definition contains the following components: - **Name.** A human-readable name for the aspiration—for example, ‘become a police officer‘ or ‘get married‘. - **Trigger conditions.** A specification of preconditions that, if triggered, will cause a character to *form* an aspiration. At a technical level, this is defined as a Python lambda expression that takes a character as its only argument. Generally, trigger conditions operate over a character's value system, since beliefs about what is important in life contribute to the determination of what one aspires to do in life. As an example, the aspiration ‘become a police officer‘ may be triggered if a given character has a high appraisal of the values ‘power‘ and ‘law‘. Unlike action selection, aspiration formation occurs more periodically, on the order of twice a year. - **Fulfillment conditions.** These conditions define the left-hand side of a fulfillment rule that, if fired, causes the aspiration to be *fulfilled* for the character. This is a Python lambda expression that takes an action as its sole argument. Whenever an action occurs, the aspiration manager uses it to evaluate the fulfillment conditions for every active character aspiration. #### Forming and Fulfilling Aspirations When it is time for the aspiration manager to carry out the procedure for aspiration formation, every character in the storyworld is used to evaluate the trigger conditions for every authored aspiration; in the case that one triggers, that character will form that aspiration. As I have noted, whenever an action occurs, the aspiration manager uses it to evaluate the fulfillment conditions of every held aspiration; if any of these trigger, the corresponding aspirations are fulfilled. It may seem like the manager could simply check whether the *initiator*'s aspirations are fulfilled, but this is not the case, because a character's aspirations may need to be fulfilled by actions that others initiate. For example, if a character aspires to become a police officer, fulfillment will have to come in the form of a ‘hire‘ action performed by an employee of the police station (likely the police chief). #### Inspiration: *The Sims 2 * *Hennepin*'s modeling of character aspirations is inspired by the *fears and wants* system of *The Sims 2* [maxis2004sims,brown2006power,sims2aspirations]. In that game, characters have fears and aspirations that are represented as tree data structures that specify event sequences by which certain fears or aspirations may be realized. For instance, a teen character may aspire to have her first kiss, and so the event sequence would include events like meeting, becoming romantically interested in, and eventually kissing another character. As gameplay proceeds, the system parses the ongoing event stream to check for partial completions of the sequences specified in the aspiration trees. To my understanding, this entails the evaluation of fulfillment triggers that are attached to the nodes of the aspiration trees. If at any point a node is triggered, the system may nudge the simulation toward the event that would lead to the emergence of the next node in that branch of the tree. Once a given sequence culminates, the system triggers content that will showcase a kind of story constituted in the fulfillment of the character's aspiration. ### Character Knowledge Character knowledge in *Hennepin* pertains almost exclusively to *actions*. When an action transpires, all of its participants (including bystanders) form a memory about it, by instantiating a corresponding *knol* whose sole source is the action itself. As I explained in Section 11.1.2, a ‘knol' is a unit of knowledge that pertains to a specific individual action. #### Knowledge Propagation In the case that an action relays other actions, knowledge about those actions will be built up as well. If a character has never heard about the relayed action, a new knol is constructed, and the action that has just transpired (the one that relayed the action to which the new knol corresponds) is recorded as the sole initial source of the knol. Alternatively, if a character has already heard about the relayed action, her knol for that action will add the relaying action as a source. If the character had forgotten that relayed action since first learning about it, by this transpiring she will remember it again. In this way, participants in actions form memories about them, and that knowledge may be propagated later on by actions that relay the first one. While earlier I gave the example of knowledge about an action propagating by a ‘gossip‘ action for which the former is a subject, propagation more generally occurs whenever a role with the ‘action‘ attribute is cast. [Note: It is tempting here to model cases where a relayed action recursively relays other actions. For instance, if someone gossips about someone gossiping, is the action that was gossiped about in the first place relayed to the recipient of the higher-order meta-gossip? I decided that in *Hennepin* it does not, since it seemed like a dangerous rabbit hole to climb into (though one I would have gladly plumbed in my work on *Talk of the Town*).] Additionally, characters may *recall* past events in the course of internal actions, in which case the memory becomes strengthened, since the recollection action will be added to the sources of the knol for the recalled action. Moreover, as I will explain further in Section 11.2.11, artifacts in *Hennepin* may encode knowledge about actions. For instance, if someone writes a note recounting a past action, examining that artifact will cause knowledge of the recounted action to be inferred by the examiner. As such, this is another way that knowledge may propagate. #### Character–Location Models I briefly mentioned earlier that characters build up simple Bayesian models instantiating theories about where other characters tend to spend their time. In such a *character–location model*, every other character in the storyworld is associated with the number of times that she has been located at the various storyworld locales (inasmuch the owner of the model knows that information). Whenever a action is learned about for the first time, the learning character will take every present participant in that action and increment by one the number of times that the character is known to have been at the location at which the action occurred. In this way, someone's model of another character's whereabouts may look something like this: ‘{Horswill Farm Park: 3, Lessard's Lounge: 8, Law Offices of Mateas and Wardrip-Fruin: 1, Talking Cure: 4}‘. As such a model evolves over time, in this computationally efficient manner, a character builds up an increasingly refined sense of where someone may be at any time. One action that I have authored, called ‘search-for-person‘, relies heavily on this knowledge. In executing this action, the actor heads to the three most likely locations, each in turn, in an attempt to track someone down (usually to impart something urgent, such as the person's house being on fire). Even though this method is very simple and does not account for a number of things—whether the place still exists, what time of day it is, the last time the person was known to be there—it actually tends to work pretty well. It is intriguing to watch a character successfully track down another by utilizing simple knowledge that was built up in the course of her experience in a storyworld. Knowledge is power. #### Memory Salience and Forgetting Finally, as I noted above, knols have associated *salience* values that capture the strength of a character's recollection of some action. As a new sources for a knol is processed, its salience rules are evaluated, which may trigger updates to the salience associated with a knol. Thus, the more often a character hears or thinks about an action, the more salient it becomes for her. Over time, salience decays as an operationalization of a character's memory of some event fading—if a low salience threshold is crossed, the character will *forget* about the action. The rate of decay depends on the character's ‘memory‘ attribute. However, if later on the character hears about it again, she recalls the action and her original sources for it are likewise retrieved. #### No Fallibility Unlike *Talk of the Town*, this system does not model memory fallibility. This design pivot is intended as a simplifying measure, since the fallibility phenomena of my earlier system incurred massive authorial burden (to specify all the different ways each kind of belief should mutate), as I explained in Chapter 9. If I encounter a strong use case for fallibility, I may implement a simpler, more generalized approach—for example, characters could conflate the entities that were cast in the roles of actions they know about, which would be akin the *transference* phenomenon in *Talk of the Town* (see Section 9.2.12). ### Character Internal Worlds I have already noted several times that I am interested in modeling the internal lives of characters. As I discussed in Section 7.3.15, in *World* this notion was briefly explored through the simulation of characters grieving, regretting, wondering, worrying, and reminiscing. [Note: While *Talk of the Town* essentially does not simulate character internal worlds, with Tyler Brothers I developed an extension to it by which characters would generate streams of consciousness in response to emotionally charged environmental signals. The farthest we got in this direction was an initial videogame prototype, called *Juke Joint* [ryan2016juke], about a haunted jukebox that changes people's lives (according to the particular lyrics that it emits).] In *Hennepin*, inner life transpires as characters take the various internal actions that I have authored—so far, these are: > ‘admire-the-sunrise‘ ‘admire-the-sunset‘ ‘agonize-over-hair‘ ‘agonize-over-outfit‘ ‘agonize-over-quality-of-work‘ ‘consider-a-new-perspective‘ ‘contemplate-prolonged-unemployment‘ ‘contemplate-serial-mistreatment‘ ‘crack-under-pressure-at-school‘ ‘crack-under-pressure-at-work‘ ‘cringe-over-past-action‘ ‘cry-over-past-action‘ ‘decide-to-confront-person-over-past-action‘ ‘envy-more-popular-kid‘ ‘envy-more-successful-sibling‘ ‘envy-spouse-of-love-interest‘ ‘fantasize-about-life-with-love-interest‘ ‘gaze-upon-the-stars‘ ‘obsess-over-love-interest‘ ‘stare-at-self-in-mirror‘ ‘vent-about-mistreatment‘ #### Related Work Briefly, I would like to outline some earlier work on this topic. At a high level, inner life pertains generally to the autonomous processing of ongoing subjective experience. A multitude of earlier projects have explored agent real-time perception (often visual processing) in real or simulated environments [horswill1993polly,scheier1996categorization,ferber1999multi,weyns2004towards], including perception systems for NPCs in combat and stealth games [leonard2003building,diller2004behavior,orkin2006three,isla2013third]. More relatedly, projects on autonomous characters—from *Tale-Spin* [meehan1977tale] to the Oz Project [bates1992architecture] to *Facade* [mateas2003faccade]—have modeled environmental perception for expressive purposes. While these projects aim to generate optimal or believable agent behavior in particular environmental contexts, in *Hennepin* I am more interested in how a character's subjective inner world may buzz as a largely involuntary dynamic of how the world is and who the character is (namely her personality profile). Given this difference, let us turn then to the expressive modeling of agent subjectivity. While in Section 9.2.12 I reviewed the literature on modeling subjective beliefs, here I would like to consider systems that have modeled memory, thought, and other internal phenomena. Interesting early systems in this vein include: the curiously forgotten *Aldous* [loehlin1962personality,loehlin1963computer,loehlin1965interpersonal,loehlin1969machines], an autonomous agent that processes its environment to generate emotionally charged responses; *Erma* [clippinger1975discourse,clippinger1975speaking], an obscure early chatbot that deeply models the subconscious layers of processing that mediate speech (to introduce disfluencies, for instance); *Parry* [colby2013artificial,kochen1981generality], Kenneth Colby's famous model of clinical paranoia; and *Cyrus*, which models agent reconstructive memory in a simulated politician [kolodner1983reconstructive]. *Daydreamer* is a later system that generates daydreams by reflecting on past experiences encoded in a knowledgebase [mueller1985daydreaming,mueller1990daydreaming]. More recently still, *Griot* uses conceptual blending to generate poetry that proceeds from evocative user input [harrell2005shades]. Follow-up work extended the system to produce daydream-like output that generates character thoughts, outlined in the third person, that are also guided by user input [zhu2008daydreaming]. *V-Daydreamer* has similar aims to these systems, but produces visual output [perezyperez2007computer]. Generally, *Hennepin* departs from these projects by more deeply *situating* its characters—internal phenomena is not the entire simulation, but rather one thing that can happen to characters as they go about their tiny little lives. ### Artifact Phenomena As I have already explained, certain actions cause new *artifacts* to be created in the storyworld. For example, ‘write-a-poem‘ produces a poem and ‘file-deed- on-parcel‘ yields a deed. An artifact has the following attributes: - **Description.** A human-readable *description* of an artifact, for example, ‘a child's drawing of [write-a-poem] by Amanda Muskopf‘. [Note: This was a drawing by a young girl that depicted her mother writing a poem, an action she had heard about from her brother.] - **Location.** Artifacts are always positioned at specific *locations* (either in a building or on a lot). An artifact may only be examined by characters who are at its same location. - **Durability.** An action may *destroy* an artifact. For instance, if a character performs ‘burn-artifact‘ with a poem cast in the ‘artifact‘ role, then that poem would likely be destroyed according to an executed action effect. Specifically, such an effect would specify the chance of an artifact being destroyed according to its *durability*, which is defined by an attribute that takes a numeric value. For example, a poem is less durable than a ring. If a calamity occurs at a location, *all* of its artifacts may be destroyed—if a house were to burn down, as in Figure 11.3, all the artifacts inside the house could potentially be destroyed. Finally, an artifact weathers over time, which is modeled by its ‘durability‘ numeric value gradually lowering. - **Detectability.** When a character is located near an artifact, she may take the action of examining it, but only if she detects it; the *detectability* of an artifact is another attribute that is represented by a numeric value. This is handled by a simple probabilistic precondition on a catch-all action ‘examine-artifact‘, which gates examination by using the detectability value to generate a detection chance. Action effects may also modulate the detectability an artifact—for instance, if a character buries an artifact on a lot, it becomes far less detectable. - **Intrigue.** Some artifacts are more interesting than others, and this notion is captured by an artifact's *intrigue*, which is also represented as a numeric value. For instance, a bloody knife is generally more intriguing than a paycheck. As with detectability, intrigue is referenced in a probabilistic precondition on the ‘examine-artifact‘ action. - **Origin.** The *origin* of an artifact is the action by which an artifact was created—for instance, ‘write-a-poem‘ in the case of a poem. - **Destruction.** The *destruction* of an artifact is the action by which an artifact was destroyed—for example, ‘burn-artifact‘ in the case of an incinerated poem. - **Moves.** Certain actions may cause an artifact to be *moved* to a new location. For example, ‘move-belongings‘ causes all of the artifacts located in one house to be moved to another house. Whenever an action moves an artifact, it is added to that artifact's ‘moves‘ list attribute. - **Examinations.** Whenever a character carries out an *examination* of an artifact, the corresponding ‘examine-artifact‘ action is added to the artifact's ‘examinations‘ list attribute. - **Inscriptions.** As I explained in Section 11.2.9, an artifact may encode knowledge about past events, which a character learns about upon examining the artifact. Typically, an artifact encodes knowledge about its origin—for example, information capturing a ‘file-deed‘ action will be encoded in the deed produced thereby. Additionally, certain actions may cause information about additional past actions to be *inscribed* into an artifact after its time of origination. For instance, the action ‘journal-about-event‘ causes information about a subject action to be inscribed into a journal artifact that already exists. Whenever an action inscribes new information into an artifact, it is added to the artifact's ‘inscriptions‘ list attribute. - **Transmissions.** An artifact's *transmissions* are all of the actions about which knowledge will be transmitted upon a character examining the artifact; these are stored in a ‘transmissions‘ list attribute. [Note: Note: transmissions are a superset of all inscribed actions and all the other actions that are recounted by an artifact.] Since there is currently no modeling of partial information, a character who learns about an action has full access to all of the pertinent information, including all of the entities bound to all the action's roles and its location and time of occurrence. If I encounter a use case for partial information, I will likely introduce a procedure for determining exactly what information about an inscribed action is encoded in an artifact (and thereby what information will be transmitted upon examination). In Section 9.3, I will outline some emergent phenomena that demonstrates the narrative potential of encoding information about the past in artifacts. - **Effects.** Finally, when an artifact is examined by a character, *effects* may be conditionally executed. Technically, these effects are attached to the ‘examine-artifact‘ action definition (with preconditions on each specifying an artifact type), but for clarity I describe it here. In this way, examining an artifact may cause an action to be added to a character's action queue. In the next section, I describe how examining a treasure map queues a follow-up action by which the map examiner may dig up the treasure at the location specified on the map. Of course, these conditional effects on artifact examination may specify other concerns such that not every character will react the same way to examining an artifact. For instance, if a character were to read her partner's diary and learn of an extramarital love interest, she might queue an action to question her spouse. However, the subject of that love interest, upon reading the diary, would react differently, perhaps by increasing her spark for the diarist. Such variation would be specified in the condition logic of the various alternative effects, following the same patterns that I illustrated in the various code listings included above. ## Emergent Phenomena Just as I did with *World* and *Talk of the Town*, I will now report some examples of interesting emergent phenomena that I have encountered in *Hennepin* storyworlds. Whereas *World* primarily generates emergent images, as discussed in Section 7.4, and *Talk of the Town* only produces *emergent scenarios*, as explained in Section 9.3, *Hennepin*'s storyworlds reliably yield *emergent storylines*. To be precise, what emerges are contingency structures, not fully formed storylines—as I have established repeatedly by evoking the ideas of Hayden White, Arthur Dantos, Epsen Aarseth, and others, actual storylines only obtain through an act of narrative construction. In the case of emergent narrative, such an act will more specifically be a procedure of curation. Thus, in this section I am presenting cases of emergent contingency structures that have enough causal coherence to greatly facilitate the work of a story sifter and narrativizer. For convenience, I will use terms like ‘emergent storyline' to refer to these structures, but really I mean ‘emergent contingency structure'. #### Human Dramatic Situations When I began authoring actions for *Hennepin*, I decided to target a particular pocket of narrative possibility space: *revenge stories*. More specifically, I authored toward the emergence of revenge by arson, which the excerpt sequence of Figure 11.3 exemplifies. At this time, I was rearing from the trial of attempting to do automatic curation in *Talk of the Town*, a problem of which is that the events that are modeled in that system are generally not inherently interesting. It is hard to tell a good story about a business's hiring process, for instance, and that is the kind of emergent material that the engine tends to produce. As such, I figured that I would start my work on *Hennepin* by targeting emergent material that is unequivocally dramatic, and revenge by arson is certainly that. [Note: In hindsight, I was intuitively veering toward Roger Schank's absolute interests, a notion that I have outlined several times now. In the case of revenge by arson, Robert Wilensky's variant phrase “human dramatic situation” [wilensky1982points,wilensky1983story] is a particularly apt descriptor.] Once I had authored all the component elements that would compose a storyline concerning revenge by arson, I booted up the simulation engine to test whether the scenario could actually emerge given what I had authored. Remarkably, even though I had authored only a few action definitions, a storyline emerged that surprised me. #### The Arsonists Among this particular county's settlers were a husband and wife named Julius and Marie Eckert, each of whom had high values for the ‘cruel‘ personality trait. Julius owned a farm and employed a farmhand named Roy Champ, who was a frequent target of Julius's ‘ridicule‘ actions during workdays in the field. At this time, there were only a few authored actions for characters to choose from, and so Julius spent each workday incessantly ridiculing the farmhand Roy Champ. Meanwhile, Julius's wife Marie spent most of her days calling on a neighbor named Catherine Lumpp, who was the wife of another local farmer. Like her husband, Marie had a predilection for bullying others, in her case the target being the unfortunate Catherine Lumpp. Eventually, both Champ and Lumpp would come to perform the ‘contemplate- serial-mistreatment‘ action. Remarkably, both characters had high enough ‘vengeful‘ trait values for such contemplation to cause a ‘hatch-revenge-scheme‘ action to be added to their respective queues. While the schemes were not hatched on the same timestep, improbably they would be *enacted* on the very same night. This caused both characters to arrive at the Eckert farmhouse, which was empty, as Julius and Marie had gone to a tavern in the county. Stunningly, neither Champ nor Lumpp noticed the other being there—this was modeled by each performing the action ‘fail-to-notice-witness‘. Next, each took the action ‘set-fire-to‘, which queues a series of actions in turn: ‘burn-to-the-ground‘ (with a null initiator) and ‘escape-burning-building‘ for each character that is in the building besides the arsonist. As such, the ‘escape-burning-building‘ action was queued for both Lumpp and Champ. Critically, ‘burn-to-the-ground‘ was queued twice, once for each ‘set-fire-to‘ action, and in each case the non-arsonist was pre-bound to a role called ‘potential- victim‘. When ‘burn-to-the-ground‘ occurs, its effects queue ‘die-in-a-fire‘ for all characters bound to ‘potential-victim‘, though this is conditional on those characters still being located inside the building. Additionally, using kill codes, ‘burn-to-the-ground‘ cancels any queued ‘escape-burning-building‘ actions. As such, with both ‘escape-burning-building‘ and ‘burn-to-the-ground‘ (and thereby the latent ‘die-in-a-fire‘) queued, survival becomes a simple matter of which outcome the action manager randomly selects for targeting first: if an ‘escape-burning-building‘ action is targeted, its initiator escapes the building; if ‘burn-to-the-ground‘ is randomly selected instead, then it is executed, which queues ‘die-in-a-fire‘, which kills the initiator. In this case, both of the ‘burn-to-the-ground‘ actions were targeted first, and thereby neither Champ nor Lumpp were able to escape, and so both died in the conflagration. While I authored to enable the emergence of storylines concerning revenge by arson, this I had not anticipated. The result was a simple reduplication of the same exact contingency structure—each example was composed of the same action types, though retargeted to different characters and storyworld contexts—but the improbable lockstep interaction produced something striking (and surprising). This tale of two arsonists was a story of karmic coincidence, with the culprits each receiving a taste of their own deadly medicine at they administered it. The takeaway for me was that the potential for interaction between emergent contingency structures produces a combinatorial explosion of the narrative possibility space, introducing fundamentally new kinds of emergent storylines that even I cannot anticipate. This is what emergent narrative is all about, and this initial test case was very exciting for me. #### Storyline Interlocking I now realize that this structural interaction works by the same principal as scenario stacking in *Talk of the Town*, which I described at length in Section 9.3 and in the opening of this chapter. An example of scenario stacking is a *family rivalry* stacking atop a *business rivalry*, and in turn this combination stacking onto a case of *love* between two characters in those families. The resulting composite scenario might be called *forbidden love*, but I had no intention of authoring toward the emergence of such a scenario—it was itself a dynamical emergent byproduct of the mechanical interaction of the specific kinds of scenarios that I *had* intentionally targeted (family rivalry, business rivalry, love). While *Talk of the Town* generates scenarios, *Hennepin* produces action sequences, and so this kind of combination in this engine concerns the interaction of concrete structures, not just scenarios. I am very excited about the potential for wild interlocked emergent action sequences that combine multiple discrete storylines—something like the procedurally generated equivalent of a Thomas Pynchon storyworld. Let us call the phenomenon *storyline interlocking*. #### The Picnic In another case of storyline interlocking, a character John Lenning's disparaging of ‘family‘ values at a park led two other men to independently (and ironically) pick a fight with him. As John performed ‘fight-back‘ in response to both instigations, two fights broke out simultaneously at Milot Park, each pitting Lenning against a family-oriented foe, with the blows being interleaved. A bystander, Susan Ask, watched both skirmishes, presumably in horror. [Note: Another humorous scene centered on value systems concerned one Daryle Guffey, who showed up at the Main Street Brewery in the town of Patience apparently with the sole purpose of denouncing the value ‘merriment‘. This was entirely coincidental, since the action manager had no means with which to associate merriment and breweries, but apophenia takes over.] #### The Treasure *Hennepin*'s rich modeling of artifact phenomena also generates some interesting narrative potentials. One evocative pattern concerns artifacts that encode information about past events that no living character knows about. As a simple proof-of-concept test of this idea, I defined a series of actions that led to the following emergent sequence. In the 1850s, at the beginning of a county's history, a character named William Weismantel performed an action ‘bury-treasure‘, whereby a treasure artifact was buried at a secluded lot in the county. [Note: In my hasty crafting of this proof of concept, this action actually causes the artifact to exist. Of course, it would make more sense for the treasure to originate in a natural way, in which case its acquisition would enable the burying action.] As an effect of this action, the treasure artifact's ‘detectability‘ attribute value was set to ‘0.0‘, making the artifact totally undetectable, even to characters positioned on that lot. As one of the ‘bury-treasure‘ action's effects, a prospective follow-up action was added to Weismantel's action queue: ‘draw-treasure-map‘. When Weismantel performed this action in turn, a map artifact was created as a result. Critically, this map artifact included the ‘bury-treasure‘ action in its transmissions, which meant that examining the map would transmit knowledge about where the treasure was buried. As an effect of ‘draw-treasure-map‘, a ‘hide-artifact‘ action was in turn queued for Weismantel, with the treasure map pre-bound to an ‘artifact‘ role and Wisemantel's house pre-bound to ‘hiding-place‘—for this proof of concept, I hardcoded that one always hides an artifact at one's home. As an effect of ‘hide-artifact‘, the treasure map's detectability was set to a very low value, but critically one that was nonzero; its intrigue value was set to be extremely high. From this point, the decades passed by and eventually Wisemantel died. Because he never told anybody about his treasure map, and because nobody ever detected it in his house, upon his death no living character in the county had knowledge of his past actions pertaining to the treasure, and thus nobody knew about the treasure. But while no character had knowledge of these events, information about them was still inscribed in the storyworld through the hidden treasure map, which encoded the ‘bury-treasure‘ action. A few years after Wisemantel's death, a character named James Bellard moved into his former home, and some time after that he happened to discover the treasure map, which was still hidden in the house. At a technical level, this occurred when the action manager randomly targeted ‘examine-artifact‘ with the treasure map randomly bound to its ‘artifact‘ role (because the candidate pool includes all artifacts at the prospective initiator's location). Critically, the preconditions held, which was remarkable because the map's ‘detectability‘ numeric value was very low, making detection unlikely. Though the system does not record this information, it is very likely that the action manager had unsuccessfully targeted this action and binding many times prior, only to have the preconditions fail as a modeling of the artifact not being detectable at that time. When Bellard examined the artifact, an effect caused a new action to be added into his queue and marked urgent: ‘dig-up-treasure‘. Later in the timestep, the action manager targeted this action, causing Bellard to move to the (still vacant and secluded) lot in the county where the treasure was buried. Upon performing ‘dig-up-treasure‘, an effect of the action modified the detectability of the treasure artifact to a very high numeric value representing maximum detectability—this models the unearthing of a buried artifact. Additionally, another effect of ‘dig-up-treasure‘ urgently queued ‘hide-artifact‘ for Bellard, with the treasure bound to the ‘artifact‘ role and Bellard's house bound to ‘hiding-place‘. Finally, by performing this action, Bellard hid the treasure in his home, where its detectability was set to a low level. #### Artifact-Driven Storylines This is where this story ends, since it was only a proof of concept. Nonetheless, it makes for an intriguing little emergent tale, and more importantly it suggests the feasibility of a larger narrative possibility space concerning sought-after artifacts that are hidden and hunted. My favorite aspect of this tale is that knowledge of the treasure did not exist in any living character's mind for a number of years (between Wisemantel's death and Bellard's discovery of the map). What if Bellard's house had burned down, destroying the map? In that case, the treasure would have lied buried, with no record of it existing, except for the undetectable treasure artifact itself. This gave me the idea of having routine actions potentially causing buried artifacts to be unearthed. To model this, I added an effect to ‘lay-foundation-for-building‘ that causes any artifacts located on the lot in which the foundation is being laid to have their ‘detectability‘ values raised, thereby ‘unearthing' them. Thus, *Hennepin*'s narrative possibility space now contains an emergent storyline in which a treasure map is destroyed, but years later the forgotten buried treasure is serendipitously unearthed as part of the routine work of building a house. I have tried a couple different seeds, but so far I have not encountered an emergent sequence of this sort. This could also be implemented as an effect of county work crews preparing lots to serve as road segments, which would cause the construction of roadways to potentially unearth buried artifacts. More broadly, the fact that examining an artifact may trigger arbitrary effects means that this kind of sequence has narrative potential far exceeding mere tales of treasure. For instance, I can imagine the secret artifacts anchoring stories of blackmail, or Cohen brothers-style escapades. To return to the notion of emergent interaction between emergent storylines, there could be a case of evidence of arson being kept somewhere hidden, and thereby a story about hunting down a secret artifact could interlock with an arson tale like the one recounted above. #### Feedback Mechanisms One of my major design goals for this engine is to implement feedback mechanisms that cause earlier emergent events to alter the course of a storyworld in potentially dramatic ways. This is in line with my ideas on simulation feedback that were presented in Section 4.1.6. Specifically, in *Hennepin*, this would mean that characters may take actions that drastically change how the county looks, or even works, thereby pushing a particular storyworld into its own sector of the simulation engine's possibility space. A concrete example of this pertains to characters starting new towns in a county. As I have explained in this chapter, characters form value systems about what they believe is important in life. If a group of characters discover that they each hold the same extreme beliefs about a particular set of values, they may decide to form what they view as a utopian town—one built on the ideals they hold in common. As an example, let us say that a group of characters all believe in ‘law‘ and despise ‘merriment‘, so they start a town rooted in these principles; let us call it Temperance. As I have mentioned above, *Hennepin* characters hold town hall meetings in which they may propose and vote on new legislation—if the legislation passes, it can actually affect how life in that town is simulated. For example, the residents of Temperance may decide to outlaw drinking in the town, which would be modeled as a new prohibition statute whereby character drinking actions are now illegal. Now, when a police officer learns about a drinking action in the town, through the standard mechanisms for knowledge propagation, an effect conditionalized on there being a prohibition statute causes the officer to queue an ‘arrest‘ action accordingly, which means the drinker will be arrested if she ends up at the same place as the officer (or alternatively the officer could work to track down the drinker). Thus, through a feedback mechanism whereby characters actually change how the simulation works, individual storyworlds may propel into novel (and potentially strange) pockets of the possibility space. To be clear, this particular example has not been implemented yet, but it would be possible to author given how the statutes system works. #### Emergent Images Lastly, I will conclude in this section with a few emergent images, in the style of the evocative situations that I recounted in Section 7.4 with regard to *World*. The first concerns one Edward Runyan, mayor of a town called Runyan that he founded early in a county's history. Runyan was a hard worker and a hard drinker who spent most of his days at the town hall performing ‘work-hard-at-work‘ and most of his nights at home performing ‘have-a-drink‘. Occasionally, he would get into arguments with Rose Vaillancourt, his secretery, on the merits of ‘stoicism‘, which Runyan valued highly. In one evocative nighttime visit to the Vaillancourt residence, the stoic Edward Runyan performed only these three actions: [Note: This is an excerpt from the console logging that is displayed in the terminal window during world generation.] ``` ID: 8529 Name: have-a-drink Date: Night of October 1, 1853 Location: Vaillancourt residence (158 Runyan Avenue) Drinker: Edward Runyan ID: 8532 Name: examine-artifact Date: Night of October 1, 1853 Location: Vaillancourt residence (158 Runyan Avenue) Examiner: Edward Runyan Artifact: a child's drawing of Rose Vaillancourt ID: 8533 Name: discern-knowledge-transmitted-by-artifact Date: Night of October 1, 1853 Location: Vaillancourt residence (158 Runyan Avenue) Artifact: a child's drawing of Rose Vaillancourt Learner: Edward Runyan Past Action: ID: 7734 Name: draw-a-picture-of Date: Day of February 27, 1853 Location: Vaillancourt residence (158 Runyan Avenue) Picture: a child's drawing of Rose Vaillancourt Drawer: Agnes Vaillancourt Subject: Rose Vaillancourt ``` Another character, the first to arrive in his county, happened to cap off the completion of a difficult project with a celebratory drink (a notion not modeled in the action precondition logic, though it works nicely by an apophenia hack): [Note: This was an earlier version of the worldgen printout.] ``` ** Day of May 22, 1839 ** 17: [lay-foundation-of-house] by John Lanclos at a spot on public land ** Day of May 23, 1839 ** 18: [build-frame-for-house] by John Lanclos about Unoccupied building at a spot on public land ** Day of May 24, 1839 ** 19: [raise-roof-on-house] by John Lanclos about Unoccupied building at a spot on public land 20: [have-a-drink-during-the-day] by John Lanclos at a spot on public land ``` Finally, the tragic case of one John Putterman. Putterman had high trait values for both ‘emotionally_obsessive‘ and ‘love_propensity‘, which unlocks the internal action ‘obsess-over-love-interest‘. In high school, John Putterman fell in love with a classmate named Sallie Koppinger, but nothing ever materialized between the two and Koppinger ended up leaving town when they were in their twenties. All throughout his life, Putterman constantly performed ‘obsess-over-love-interest‘ with Koppinger as its absent subject. Moreover, this recurring action was actually part of a tragic feedback loop: when a character obsesses over a love interest, the spark for that person increases, thereby reinforcing the obsession further. In this way, while his spark for her did decrease over time, the decay rate was no much for the rapid spark increases caused by his constant obsessing. Finally, on his death bed, Putterman, now almost fifty years removed from Koppinger's departure, performed one final action: ``` >>> print john John Putterman, 1840-1909 >>> print john.death Death of John Putterman in 1909 >>> print john.love_interest Sallie Koppinger, left town in 1865 >>> print john.actions.taken[-1].outline ID: 72735 Name: obsess-over-love-interest Date: Day of January 30, 1909 Location: Putterman residence (705 6th Street E) Thinker: John Putterman Love Interest: Sallie Koppinger ```