# Curating Simulated Storyworlds — Chapter 9: Talk of the Town

> 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 9 of 14 only: Talk of the Town (~25,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

At the beginning of 2015, during my second year at UC Santa Cruz, I took Noah Wardrip-Fruin's *Playable Media* class  [wardrip2015cmpm290j] for a second time. As I mentioned in Chapter 7, this course requires students to distribute a project to the rest of the class for critique; in the previous instance I had developed *Islanders*, the text adventure built atop the *World* simulation engine. This time around, Adam Summerville—a newly arrived PhD student in the Expressive Intelligence Studio who was also taking the class—asked if I would like to work together with him to distribute a collaborative project for critique. I agreed, and offered up some initial ideas that had been brewing in my mind.

My first idea was to build a rhetorically charged inversion of *Super Mario Bros.* [nintendo1985super], which I described in this way in an email to Adam:

> A networked multiplayer (sub)version of Super Mario Bros., where Mario is the AI and humans control various NPCs in a level (with their exact affordances intact) and collaborate to try to stop Mario. If I did this, I was planning to call it Super Bowser Corps and make a new manual for the game, where the subverted narrative is described: Bowser is this heroic revolutionary who's toppled the hegemonic Mushroom Kingdom in a liberation effort involving persons of all kinds (i.e., the Mushroom Kingdom supports only toadstools, but Bowser's minions come from several species, or whatever you'd call them), but now there's a pair of evil plumbers who are undermining the heroic effort for purely personal reasons. [Note: Personal communication, January 23, 2015.]

 As Adam pointed out, the idea was probably too ambitious for a class project, since it would require implementing multiplayer support for real-time gameplay. We decided not to go that route, though it is interesting to ponder about now, since it would have represented a major departure from the kind of work that I had done to that point and since. [Note: Adam, on the other hand, would go on to do a lot of work in the context of the *Super Mario* series [summerville2015mcmcts,summerville2016super,summerville2017does,summerville2017understanding,summerville2018learning], though in the area of procedural content generation. My idea was of course incidental to his interest in the series.] Another idea that I proposed was more directly in line with the simulation work I had been doing on *World*:

> A game where knowledge propagation is the core mechanic. I had two ideas for premises. The first is a multiplayer game where two players are both chasing each other, and their primary means for tracking is knowledge acquisition by dialogue interaction with NPCs [non-player characters]. The other premise is an asymmetric multiplayer game where one player is on the run and attempting to reach a certain location before another character, who's managing a network of NPCs over which knowledge is propagating, tracks them down. In both of these, the world would have a fairly rich simulation to allow for interesting knowledge prop patterns. [Note: Personal communication, January 23, 2015.]

At this point in my simulation practice, I had become particularly interested in two new directions: character knowledge propagation and the prospect of automatically recognizing interesting emergent stories. While the latter would gradually develop into an increasing emphasis on curation, itself the subject of this dissertation, I had already begun to explore the former notion in *World* and I was very excited about the possibilities. As I recounted in Chapter 7, knowledge phenomena in that system is extremely limited—characters exchange last known whereabouts for common acquaintances—but it had captured my imagination since an initial test in which an elderly man was reunited after sixty years with a childhood friend, who proceeded to tell him, one by one, when and where everyone he had known had died in the intervening years. This emergent phenomena was enabled by just a few days of work, and I wanted to explore the topic more deeply in a successor system. [Note: Apparently, I was initially interested in doing a project for the class that would also extend *World*'s language simulation, as I jotted in a short note at that time: “Knowledge propagation in a language-contact zone—speakers of different languages have a pidgin, but knowledge propagation is impoverished in this mode. Aesthetics: flat design; dull pink and lime green”.] In his response to my email, Adam expressed interest in the idea and proposed that we could even model interesting memory effects:

> This is the one that is the most intriguing. [...] I'm a huge fan of asymmetric multiplayer, and I feel like there's a lot that could be done here.  The obvious things are the player trying to disseminate false information about who they are and their intentions, and classic memory degradation for witnesses as well as priming (both of which I think would be very interesting effects to model). [Note: Personal communication, January 23, 2015.]

From here, we set out to design a game that would be *about* character knowledge phenomena—later on, in an email describing the project to our labmate Ben Samuel, I wrote: “The idea is to deal in character knowledge as richly as Prom Week deals in character social interactions, so ‘knowledge physics', if you will”. [Note: Personal communication, August 13, 2015.] We decided that adapting the *World* simulation technology would give us a head start on the project, but we felt that a contemporary urban setting, where knowledge propagates quickly, would work better than island archipelagoes. Eventually, we realized that it would not be feasible to model an entire city filled with *World* characters, so we converged on the American (very) small town as our domain—something on the order of a few hundred characters. In the end, I took this as an opportunity to abandon the *World* codebase—which was my first major programming project, and thus of dubious structural and aesthetic quality—and to do an intellectual reboot in terms of my approach to modeling.

As for the actual game, much of our early design work centered on the construction of a narrative premise that would foreground character knowledge and support our vision for asymmetric multiplayer. The obvious framing was gritty crime and detection, but we wanted to explore territory that would be thematically peculiar for a videogame—our primary influence was Wes Anderson's *The Grand Budapest Hotel* [anderson2014grand]. Here is our description of the narrative premise that we eventually invented, as published in a first paper on the project:

> The story that frames gameplay surrounds the death of a very important person who, seventy years prior, founded the town in which gameplay takes place. Since that time, the founder has accumulated considerable wealth and produced several descendants who now constitute an aristocracy in the town. Many of these family members had been anticipating the founder's death for the inevitably large inheritances that would thereby be disbursed, but in his or her last moments the founder apparently signed a document willing everything to a secret lover whose existence had not been known to the family. In one week, the town will gather at a theater to remember the deceased and to hear the will be read, but the family plans to ascertain the identity of the lover and apprehend this person before the document can ever be delivered to the presiding attorney. Meanwhile, the town is abuzz with rumors about the mysterious lover, whom a handful of witnesses briefly observed on the night of the founder's death. [ryan2015toward, p. 57]

 We felt that this framing would support our targeted pattern of asymmetric gameplay centered on character knowledge phenomena, which we described in this way:

> The game is multiplayer and asymmetric: one player controls the lover character and the other player controls a member of the founder's family. The lover's goal is to go undetected until the will ceremony, while the family member works to ascertain the lover's appearance before that time. [...] Because the family character is established in the town, the player controlling him or her will have the town's entire knowledge network at her disposal. As such, her job becomes *managing* this network so that information about the lover's appearance flows toward her; the lover player's task then is to *pollute* this knowledge network by, for instance, changing the character's appearance and spreading lies. Gameplay culminates in a scene showing the town's citizens filing into the theater for the will ceremony, during which time the family player must select the person who best matches her conception of the lover—if she selects correctly, she wins; otherwise, the lover player wins. [ryan2015toward, p. 57]

In line with my proclivity for world generation, already established in *World*, we had always planned for the town to be procedurally generated prior to gameplay. Critically, this procedure would entail the simulation of its entire history, during which time characters would form and propagate knowledge about one another. During gameplay, the town would be represented as a 3D space that players could navigate using the visual metaphor of a board game (from an aerial view, click to select destination). The core gameplay experience was to be conversational interaction with characters in town—this is the context in which players would be able to ask questions (inquire about knowledge) and also make statements and tell lies (pollute knowledge).

[Figure omitted]

Though we never completed the game, we did build a prototype that was distributed to the class; Figure 9.1 shows screenshots from this software. Due to a limited development period (six weeks), we could not produce a multiplayer experience, but instead a single-player configuration in which the player attempted to discover the name of the lover. As with my *Islanders* project, which was developed for the same class the previous year, the critique did not go particularly well. We faced a number of technical challenges in developing the game—it was a Unity project [goldstone2009unity] and integrating my Python simulation engine became a nightmare for Adam—and due to the amount of character knowledge that players could inquire about, conversational interaction required navigating an unwieldy series of nested menus. There was a lot intrigue emerging in the simulation, but significant design and technical challenges led to that intrigue being obscured at the surface—we were up against the *Tale-Spin effect* [wardrip2007three,wardrip2009expressive].

While eventually we abandoned development on the game, many of the concepts that originated in its design were ultimately realized in the completed project *Bad News*—I will tell that story in the next chapter. Through that work and other experiments, the simulation engine that drove the *Talk of the Town* prototype took on a life of its own. Confusingly, however, I also refer to this simulation engine as *Talk of the Town*. This is because the moniker had already become associated with the simulation through early papers on the project that were primarily about that component [ryan2015toward,ryan2016sbg,ryan2017simulating]. [Note: From this point forward, I will refer to the simulation engine as *Talk of the Town* and to the videogame prototype as *Talk of the Town* (2015).] As I mentioned in Chapter 7, a similar confusion had transpired with regard to the titles *World* and *Islanders*, and generally this was a manifestation of conceptual murkiness in my simulation practice. In wrangling the notion of what exactly ‘Talk of the Town' had come to denote, I began to realize what that practice is all about: building simulation *engines* that are themselves standalone media works, but ones that are ultimately meant to drive *second-order media experiences* like *Talk of the Town* (2015) or *Bad News* or the other examples that I will mention later in this thesis.

*Talk of the Town* is a simulation engine that models an American small town over the course of its history, with particular attention to the lives of its denizens. Its modeling of social phenomena is fairly abstract, though it supports some interesting emergent dynamics; its hallmark is a rich modeling of character knowledge phenomena, particularly memory fallibility. As I have noted above, *Talk of the Town* was initially created in the context of a collaboration with Adam Summerville, and much of the core details are the result of design brainstorming that we conducted at that time. I continued to develop the engine through the beginning of 2017, at which point I abandoned it to begin work on its successor, *Hennepin*, which is the subject of Chapter 11. While I have carried out a number of (collaborative) experiments with the engine that led to the introduction of experimental modules—notably ones pertaining to conversational interaction [ryan2016aiide,ryan2016lightweight,summerville2016cfgs,ryan2016translating,ryan2016generative] and character streams of consciousness [ryan2016juke]—I will describe it in this chapter in terms of the specific instantiation that is used to drive *Bad News*, since that is the case study of the next chapter.

Again, a note on evaluation: I believe that computational systems that are intended to support media experiences can only be appraised through actual implemented experiences that are built atop them, as others have articulated before me [mateas2001expressive,stern2008embracing,horswill2013science,koenitz2014five,wardrip2014envisioning]. Because the purpose of *Talk of the Town* is to drive second-order media experiences, I will hold off on appraising it in that regard until the following chapter, in which I will critique it through the lens of *Bad News* (an actual implemented media experience built atop it). In lieu of such appraisal, in this chapter I will instead situate *Talk of the Town* against related technical work, both in a broad sense of its approach to simulation and also in terms of some of its specific subsystems, particularly the one that models character knowledge phenomena. For clarity, I discuss this related work in a distributed manner, throughout the chapter, as the pertinent concepts arise in my discussion. While specific aspects of the system have been reported in earlier papers, this chapter will provide the first published explanation of its general machinery for building and simulating American small towns. [Note: In the case of subsystems that have been reported before, I will note the earlier publications as I describe those subsystems. Though it has not appeared in print, I have provided an explanation of how towns are generated and simulated in two invited presentations: “Generating American Small Towns for Narrative Applications”, delivered at the 1st Workshop on Tutorials in Intelligent Narrative Technologies, held in Los Angeles on November 15th, 2016; and “How to Make an American Small Town”, given at the University of Turin on October 9th, 2017.]

## Modeling

Each *Talk of the Town* storyworld is modeled as a small town that is populated by a few hundred characters, who construct houses and other buildings in the town, some of which headquarter business operations. In this section, I will give a basic overview of the modeling of characters and the various entities that are included in the simulation. As I explained in the opening of this chapter, this simulation engine was originally developed to drive a videogame with a particular design. This is the context in which the majority of design decisions were made, and so a few peculiar aspects—namely the overwrought modeling of character appearances—are artifacts that remain from this origin. Finally, unlike *World*'s hodgepodge domain, *Talk of the Town*'s is explicitly the American small town. This is as specific as it gets, however—it could be a small town in any area of the country (though certain business types, such as a coal mine, may suggest something about the region of a particular town instance). [Note: Some observers from coastal regions have assumed that the towns must be based in the Midwest. I am bothered by that assumption, since it evokes the problematic stereotype that the Midwest is a miscellanous area dotted with farming communities and small towns. Every region in this country has both urban and rural areas, and the threshold between those is the nation's most significant cultural divide—not coastal versus interior. The region called the ‘Midwest' is a meaningless conglomeration of distinct regions that have little in common, and its very reification reflects a troubling coastal bias. Minnesota has more in common with Massachusetts than it does with Missouri, for example. I refer to my hometown of Minneapolis as being in a region called the ‘North', following a movement that is afoot to recast it as such [binkley2015minnesota,rayno2017how,raice2018forget]. This rant is courtesy of a Minnesotan's five-year stint in California.]

### Time

*Talk of the Town* models time more finely than its predecessor *World*: whereas in the latter engine time passes one year at a time, in the former it proceeds by *day* and *night* timesteps. Thus, the simulation deals in roughly half-day chunks, marching from day to night to day to night and so forth.

For *Bad News*, however, I do not simulate every timestep in the history of a town at full granularity, but instead utilize *level-of-detail modulation*. [Note: Again, the purpose of this chapter is to describe *Talk of the Town* as it is utilized in *Bad News*, since that is the case study of the next chapter.] Level-of-detail modulation is a general technique whereby the granularity of simulation or representation is adjusted for some system according to various contexts, usually under the influence of computational constraints. While it originated in computer graphics [luebke2003level], the concept has also been applied to character simulations [doull2008death,mark2009aiide,ohalloran2016multi]. In the case of modeling a *Bad News* storyworld, *Talk of the Town* simulates approximately four days each story year, and then critically extrapolates the results of character social simulation on a given timestep according to the amount of time that has passed since the last simulated timestep. For instance, if 200 timesteps have passed since a timestep was last simulated, and two characters engage in a social interaction whereby one comes to like the other more by some unit of increase, her affinity for that character will be increased by a level corresponding to 200 of those units. This makes individual social interactions between characters stand for a period of game months characterized by extended interaction between the dyad. This saves on computation, and critically I have found that this measure does not compromise the richness and coherence of generated storyworld material. [Note: As I will explain in the next chapter, each *Bad News* storyworld is generated just as a player is arriving to our installation to experience the next performance. In the interest of scheduling as many performances as possible, we need to limit the amount of time it takes to produce a storyworld. This is the basic impetus for doing level-of-detail modulation in this way.] I will return to this consideration below, in Section 9.2.5.

### Characters

Characters have been the central concern in my simulation practice ever since I developed the name generator described in Chapter 6, and this project is no exclusion. In this section, I will describe what a *Talk of the Town* character is made of. In doing so, I will emphasize what this engine inherits from *World*, as well as how it departs from its predecessor. Again, a core aim of Part II of this thesis is to describe the evolution of my simulation practice over time.

#### Name

The procedure for giving characters *names* in *Talk of the Town* generally follows that of *World*, but with some revisions that reflect the former's specific domain of the American small town. When a new character is born, she may be named for a family member (at a set probability), but generally characters are named according to census data that captures the most common baby names throughout American history. If a character is to be named after a family member, a probabilistic procedure determines whom that will be with likelihoods depending on the relation of the infant to a set of potential namesakes. Otherwise, naming works like this: for the character's year of birth, look up the relative frequencies of the 200 most common baby names for that year, and name the child accordingly (by deriving a probability distribution from the relative frequencies). This leads to names like ‘Mary' and ‘Elmer' giving way to examples like ‘Deborah' and ‘Kevin' and eventually to ‘Ashley' and ‘Ryan' and so forth. [Note: ‘Ryan', which is my surname, was essentially unused as a forename (in the United States) prior to the 1940s, and even then it was obscure until the 1960s, when its popularity exploded [ryannamepopularity]. When I would introduce him to friends with that name, my late grandfather, Jack Ryan, reacted with incredulity: “Ryan!? That's a last name!”] Additionally, there is a small chance that a character will be named by randomly selecting from the forenames corpus that I have been using since my early name generator. Deciding a character's middle name works in this same way.

Character surnames come from the same surnames corpus that was utilized in *World*, and following American custom, a patronymic naming scheme is enacted. However, parents may also decide to give their children hyphenated surnames. This occurs at a set chance in the codebase that drives *Bad News*, but later I altered it to change over time according to attested data—this is the modeling used in *Hennepin*, as I will explain in Chapter 11. As in *World*, a character with the same full name of a parent is given the appropriate numeral suffix, and the system tracks the namesakes and ultimate originating character for each forename and surname. Finally, the system keeps track of the ethnicity of surnames, which is discernible due to the surnames being grouped in the ethnically delineated corpus. As I will explain in Section 9.2.12, characters may reason about this information and a surname's ethnicity affects how it may be misremembered.

#### Appearance

As I explained in this chapter's opening, the game design that Adam Summerville and I devised for *Talk of the Town* (2015) was in large part about character *appearances*: the family member attempts to ascertain the appearance of the secret lover so that she may pick her out of a lineup at the will ceremony in which gameplay culminates. [Note: The subsystem discussed in this section was designed in collaboration with Adam Summerville, in the context of development of *Talk of the Town* (2015). Throughout Part II of this thesis, in which I report both independent and collaborative work, I will attempt to clearly attribute my collaborators and their contributions.] Due to its importance in this design, *Talk of the Town* richly models character appearance, to a degree that may seem overwrought with regard to its more abstract modeling of other physical concerns. I should also note that the introduction of character appearance represents a fundamental addition relative to *World*, which did not model any physical characteristics of characters beyond what is implied by one's age.

What follows are the system's twenty-four appearance attributes (which pertain primarily to the face) and the values that characters may take for each:

>

-  Skin color: ‘black‘, ‘brown‘, ‘beige‘, ‘pink‘, ‘white‘
-  Head size: ‘small‘, ‘medium‘, ‘large‘
-  Head shape: ‘square‘, ‘circle‘, ‘heart‘, ‘oval‘
-  Hair length: ‘bald‘, ‘short‘, ‘medium‘, ‘long‘
-  Hair color: ‘black‘, ‘brown‘, ‘blond(e)‘, ‘red‘, ‘gray‘, ‘white‘, ‘green‘, ‘blue‘, ‘purple‘
-  Eyebrow size: ‘small‘, ‘medium‘, ‘large‘, ‘unibrow‘
-  Eyebrow color: ‘black‘, ‘brown‘, ‘blond(e)‘, ‘red‘, ‘gray‘, ‘white‘, ‘green‘, ‘blue‘, ‘purple‘
-  Eye size: ‘small‘, ‘medium‘, ‘large‘
-  Eye shape: ‘round‘, ‘almond‘, ‘thin‘
-  Eye color: ‘black‘, ‘brown‘, ‘blue‘, ‘green‘, ‘yellow‘
-  Eye horizontal settedness: ‘narrow‘, ‘middle‘, ‘wide‘
-  Eye vertical settedness: ‘high‘, ‘middle‘, ‘low‘
-  Ear size: ‘small‘, ‘medium‘, ‘large‘
-  Ear angle: ‘flat‘, ‘protruding‘
-  Nose size: ‘small‘, ‘medium‘, ‘large‘
-  Nose shape: ‘long‘, ‘broad‘, ‘upturned‘, ‘pointy‘
-  Mouth size: ‘small‘, ‘medium‘, ‘large‘
-  Facial-hair style: ‘none‘, ‘mustache‘, ‘full beard‘, ‘goatee‘, ‘sideburns‘, ‘soul patch‘
-  Freckles: ‘no‘, ‘yes‘
-  Birthmark: ‘no‘, ‘yes‘
-  Scar: ‘no‘, ‘yes‘
-  Tattoo: ‘no‘, ‘yes‘
-  Glasses: ‘no‘, ‘yes‘
-  Sunglasses: ‘no‘, ‘yes‘

Heritability with regard to character appearance is modeled using a similar procedure to the one that drives the inheritance of personality traits in *World*, which I described in Section 7.2.2. When a child is born, the system consults a set of heritability probabilities that I authored for each trait to determine whether a given trait will be inherited or not. If inheritance is triggered, one of the child's parents is randomly chosen and that character's trait value is inherited. If inheritance is not triggered, the system will generate a value for the character using a set of population distributions that I authored for each trait—this loosely models a kind of genetic mutation (or latent features recurring after skipping a generation). Some traits are not heritable (e.g., whether a character wears sunglasses), and a child's skin color is set at a midpoint between her parents' respective tones. Of course, characters without parents—*primordial* characters who already exist at the beginning of the simulation (about which more below)—cannot inherit trait values. Finally, a character's hair color changes over time (by probabilistic triggering), first to ‘gray‘ and eventually to ‘white‘.

#### Personality

Just as in *World*, character *personality* in *Talk of the Town* is driven by the famous *five-factor model of personality* [mccrae1992introduction,wiggins1996five], which is also referred to as the *Big Five* model. This subsystem works exactly as it does in my earlier engine, which means I have already described it at length in Section 7.2.2. To briefly recapitulate, the personality traits in this model are *openness to experience*, *conscientiousness*, *extroversion*, *agreeableness*, and *neuroticism*. Values for each trait are represented as floating-point numbers on a continuous scale from ‘–1.0‘ to ‘1.0‘. Children inherit these values from their parents, with a mutation factor that modulates the exact value instantiated in the child. Character personalities are static profiles that do not change over time. As I have alluded to above and will explain in Section 11.1.2, in *Hennepin* I am no longer using the five-factor model—this is because I have come to believe that the model is not dramatically potent and not particularly conducive to authoring character behaviors.

#### Knowledge

A character's accumulated *knowledge* of the storyworld is structured as a collection of mental models, each of which is comprises a variety of beliefs about an individual entity in that world. Section 9.2.12 is devoted to the subsystem that handles character knowledge phenomena in *Talk of the Town*, which is the system's core technical contribution.

#### Miscellaneous Attributes

*Talk of the Town* characters are also modeled according to several additional attributes beyond name, appearance, personality, and knowledge. These include *sex*, *sexuality*, *fertility*, and *memory*, the latter of which is modeled as a floating-point value that decreases over time to make the phenomena pertaining to memory fallibility more likely. As in *World*, a character's sexuality is composed according to whether she is probabilistically determined to be attracted to men and/or women. Additionally, the system tracks character-specific data pertaining to a number of concerns including social relationships, romantic history, work history, residential history, and more.

### Other Entities

[Figure omitted]

In addition to characters, *Talk of the Town* models the town, of course, including its streets, tracts, lots, businesses, homes, and a few artifacts. I will describe each of these in this section.

#### Towns

A town is represented as a rectangle that spans nine city blocks on each side. Before the town is created, a plat is generated for it using a *quadtree* [samet1984quadtree,shaker2016constructive]. This procedure was developed by Adam Summerville and works as follows: subdivide a rectangle (spanning nine by nine city blocks) into four squares, probabilistically subdivide those squares into four smaller squares, and repeat for a number of iterations. The result is a grid of variably sized rectangles, but the procedure is tuned so that nearly all the rectangles will be squares spanning one city block on each side. Unlike *World*'s settlements that grow over time and annex one another, described in Section 7.3.9, the layout of a *Talk of the Town* town does not change over time (except that roadways are constructed as needed). I view this as a limitation, since character decisions (and disagreements) about how to change the town would yield intrigue and narrative potential. As I explain in Chapter 11, *Hennepin*'s counties (and their component towns) are dynamically reconstructed over time by the characters who live in them. Figure 9.2 shows an example *Talk of the Town* town after several decades of existence.

#### Tracts, Lots, Streets, and Blocks

As I just noted, the procedure for plat generation produces a grid of variably sized rectangles, most of which are one-by-one squares—in *Talk of the Town*, these are called *lots* and the larger rectangles are *tracts*. Homes and businesses may be constructed on lots, while tracts can become the sites of specific kinds of businesses (cemeteries, parks, farms, quarries, and coal mines). As they become needed by new buildings, *streets* are constructed to follow the town's plat grid; they do not cut through tracts, as Figure 9.2 illustrates. Streets are additionally broken into *blocks*, which are short segments with two lots on either side. When a street is constructed, it is named by a probabilistic procedure by which there is a chance of giving it a numbered name (e.g., ‘2nd Street‘) or a name randomly selected from either the surnames corpus or the corpus of American place names that was also used in *World*. [Note: I am now realizing that I did not boost the probability of selecting ‘Minneapolis' from the corpus of place names, as I did in *World*—a missed opportunity.] Lots and tracts are attributed *house numbers* according to their position on the town plat, and the concatenation of a house number and a street name produces an *address* (such as ‘255 2nd Street‘) that may be attributed to a building or other business site constructed on that land.

#### Homes

A character may build a *house* on a lot, as I will discuss below. In *Talk of the Town*, a house is abstractly a building, and all houses are modeled the same. The system keeps track of data surrounding the construction of a house (architect, builders, construction firm) and its former and current residents.

#### Businesses and Vocations

As I will explain shortly, characters may start businesses in a town. The modeling of a business integrates both the abstract idea of a company and the concrete notion of the building or site where that company is headquartered. In *Talk of the Town*, a *business type* is defined compositionally according to author-defined values for each of the following set of features:

-  **Advent.** A year in which a business of this type becomes era-appropriate. For instance, a tattoo parlor would be anachronistic prior to 1970 or so, and so I set the advent value for that business type to ‘1970‘. Other business types may already exist at the beginning of the simulation, such as a farm.
-  **Demise.** A year in which a business of this type stops being era-appropriate. For example, blacksmith shops should disappear shortly after 1945, so I set the demise for that type at ‘1945‘. As I explain below, businesses do not automatically shut down when a demise year is reached, but rather the probability of that happening increases dramatically.
-  **Minimum population.** The minimum population that is necessary for a business of that type to operate in a town. For example, it does not make sense to open a department store in a town with few residents, so I set the value for this feature to ‘200‘ in defining that type.
-  **Maximum number.** The maximum number of businesses of this type that may simultaneously operate in a given town. This value captures that a small town could potentially have several taverns or restaurants, but not two hospitals, for example.
-  **Land requirements.** Whether a business of this type operates on a tract or a lot. For instance, farms requires tracts, while taverns operate on lots.
-  **Services.** The services that are provided to town denizens by a business of this type, e.g., ‘furniture‘ or ‘dairy‘. These are used to guide the simulation of character routines.
-  **Owner.** The vocation of an owner (and thus founder) of a business of this type. For instance, a blacksmith shop should be owned by a blacksmith, and so I defined this value as ‘blacksmith‘ in defining that business type.
-  **Day shift.** Vocations for a minimal set of employee positions that are needed for a business of this type to operate during a day timestep. In the case of a bank, I defined this as ‘(bank teller)‘.
-  **Night shift.** Vocations for a minimal set of employee positions that are needed for a business of this type to operate during a night timestep. Banks are not open at night, but they may have a janitor there to clean up; as such, for that business type I defined this feature as ‘(janitor)‘.
-  **Supplemental day shift.** The vocations of additional daytime employee positions that may be hired for in the case that an owner of a business of this type seeks to expand it. Here is how I set this feature in the definition of a bank business type: ‘(bank teller, bank teller, manager)‘.
-  **Supplemental night shift.** The vocations of additional nighttime employee positions that may be hired for in the case that an owner of a business of this type seeks to expand it. In the case of a bank in a small town, one janitor is probably enough, so I defined this feature value as an empty list.
-  **Public.** Whether a business of this type is a public utility, such as a cemetery, park, or city hall (as opposed to a bar, bank, or restaurant, for instance). Public companies have no owners.

In the codebase that was used in *Bad News*, I authored the following fifty-two business types: ‘apartment complex‘, ‘bakery‘, ‘bank‘, ‘bar‘, ‘barbershop‘, ‘blacksmith shop‘, ‘brewery‘, ‘butcher shop‘, ‘candy store‘, ‘carpentry company‘, ‘cemetery‘, ‘city hall‘, ‘clothing store‘, ‘coal mine‘, ‘construction firm‘, ‘dairy‘, ‘day care‘, ‘deli‘, ‘dentist office‘, ‘department store‘, ‘diner‘, ‘distillery‘, ‘drug store‘, ‘farm‘, ‘fire station‘, ‘foundry‘, ‘furniture store‘, ‘general store‘, ‘grocery store‘, ‘hardware store‘, ‘hospital‘, ‘hotel‘, ‘inn‘, ‘insurance company‘, ‘jewelry shop‘, ‘law firm‘, ‘optometry clinic‘, ‘painting company‘, ‘park‘, ‘pharmacy‘, ‘plumbing company‘, ‘police station‘, ‘quarry‘, ‘realty firm‘, ‘restaurant‘, ‘school‘, ‘shoemaker shop‘, ‘supermarket‘, ‘tailor shop‘, ‘tattoo parlor‘, ‘tavern‘, and ‘university‘.

Beyond the above features, the system tracks data about businesses pertaining to its founder, current owner, former owners, current employees, former employees, founding, building construction, closure, and building demolition. Of course, businesses also have names, and these are attributed by probabilistic procedures that I defined for each business type. A generated name may include the name of the town (‘Duluth Dairy‘), a street (‘5th Street Diner‘), or the business owner or employees (‘Law Offices of Mateas and Wardrip-Fruin‘), or it may reference an emergent town element that is associated with that land. For example, a new park that is established an the site of a former farm may be named for the farmer who had tended to the land, e.g., ‘Horswill Farm Park‘ or simply ‘Lessard Park‘. [Note: This is probably my favorite system detail. As I have expressed at various times in this document, I am interested in feedback loops between emergent phenomena, and one interesting kind of feedback loop connects units of emergent content whose procedural generation is decoupled in the simulation procedure. In the case of farm naming, a little piece of procedurally generated content—a string constituting the name of a storyworld landmark—captures what has come before in the storyworld, and more specifically, it explicitly references an earlier unit of procedurally generated content (a character name). Now, in *Hennepin*, I am exploring the generation of artifacts that capture past events so that characters who encounter those artifacts come to learn about the captured events. This is the way toward *generative environmental storytelling*, as I have noted multiple times above.] In the case of a bar or restaurant, a name is determined by selecting from a corpus of evocative bar and restaurant names that I found online. The *Bad News* aesthetic, familiar to anyone who has experienced the piece, is derived in part from the peculiar monikers that adorn its generated bars and restaurants—one performance, for example, centered on a rivalry between two restaurants called ‘Prawn Logic‘ and ‘Fish Matrix‘.

Vocations themselves follow a simple representation scheme that entails the definition of values for the following features:

-  **occupational status.** An integer between $1$ and $5$ that captures the prestige of a particular vocation. For example, ‘apprentice‘ is attributed a level of ‘1‘, ‘quarryman‘ a ‘2‘, ‘jeweler‘ a ‘3‘, ‘doctor‘ a ‘4‘, and ‘owner‘ (e.g., of a bank) a ‘5‘. As I will explain below, other characters recognize the social status of high-prestige occupations, and occupational status also figures heavily in character decision making surrounding the hiring process. Moreover, when a character is generated outside the town to move there for occupational reasons, the character's age will be sampled from a normal distribution associated with the occupational status (this captures a general positive correlation there).
-  **Employability conditions.** This is a simple function that takes a character as an argument and returns whether that character would be employable in this vocation given the current era of the storyworld. This is meant to prevent anachronisms such as a female police chief in the 1860s, for instance. I could have authored the simulation to instead be utopian, but my approach was to target a general verisimilitude so that players could bring their intuitions about rural American life (and its history) to bear in playing *Talk of the Town* (2015), and ultimately *Bad News*. As such, I was aiming for a particular kind of *SimCity effect*—Noah Wardrip-Fruin's term for cases in which “a system [...] brings the player to an accurate understanding of the system's internal operations” [wardrip2007three, p. 2]—by which humans may more easily understand systems whose operations match their *preexisting* mental models about a subject phenomenon. Some have taken exception to this design decision, but I think I stand by it. [Note: Of course, subverting preexisting mental models can be a powerful design move, especially when such mental models are rooted in prejudice or misunderstanding. To name just two examples, Mary Flanagan's book *Critical Play* articulates a poetics of what she calls ‘radical game design' [flanagan2009critical], and Vi Hart and Nick Case's ‘playable' *Parable of the Polygons* [hart2014parable] operationalizes game theorist Thomas Schelling's model of segregation [schelling1971dynamic] to upturn interactor misconceptions pertaining to the phenomenon. While *Bad News* is subversive in other ways—in an early paper on the project, we wrote about how it subverts the treatment of death in videogames [ryan2016bad]—it does not aim to critically interrogate American society, culture, or history, and this design (dis)inclination has worked to structure *Talk of the Town*.]
-  **Degree requirement.** Whether a vocation requires a college degree in order for a character to be hired—e.g., one does not become a doctor or a lawyer right out of high school. As I explain below, there is a very rudimentary modeling of characters attending college by which a probabilistic trigger may cause characters who are unemployed (and more than four years out of high school) to be awarded a degree.

In the codebase that was used for *Bad News*, I authored the following seventy-nine vocations: ‘apprentice‘, ‘architect‘, ‘baker‘, ‘bank teller‘, ‘barber‘, ‘barkeeper‘, ‘bartender‘, ‘blacksmith‘, ‘bottler‘, ‘brewer‘, ‘bricklayer‘, ‘builder‘, ‘bus driver‘, ‘busser‘, ‘butcher‘, ‘carpenter‘, ‘cashier‘, ‘clothier‘, ‘concierge‘, ‘cook‘, ‘cooper‘, ‘daycare provider‘, ‘dentist‘, ‘dishwasher‘, ‘distiller‘, ‘doctor‘, ‘dressmaker‘, ‘druggist‘, ‘engineer‘, ‘farmer‘, ‘farmhand‘, ‘fire chief‘, ‘firefighter‘, ‘grocer‘, ‘groundskeeper‘, ‘hotel maid‘, ‘innkeeper‘, ‘insurance agent‘, ‘janitor‘, ‘jeweler‘, ‘joiner‘, ‘laborer‘, ‘landlord‘, ‘lawyer‘, ‘manager‘, ‘mayor‘, ‘milkman‘, ‘miner‘, ‘molder‘, ‘mortician‘, ‘nurse‘, ‘optometrist‘, ‘owner‘, ‘painter‘, ‘pharmacist‘, ‘plasterer‘, ‘plastic surgeon‘, ‘plumber‘, ‘police chief‘, ‘police officer‘, ‘principal‘, ‘professor‘, ‘proprietor‘, ‘puddler‘, ‘quarryman‘, ‘realtor‘, ‘seamstress‘, ‘secretary‘, ‘shoemaker‘, ‘stocker‘, ‘stonecutter‘, ‘tailor‘, ‘tattoo artist‘, ‘taxi driver‘, ‘teacher‘, ‘turner‘, ‘waiter‘, ‘whitewasher‘, and ‘woodworker‘.

#### Events

As I will explain shortly, the *Talk of the Town* simulation is primarily concerned with the generation of *events*, generally in the sense of character life events. In the simulation code, event definitions bundle all of the functionality that is needed in order to model the transpiring of an event and its effects on the storyworld. Critically, the system also tracks metadata for past events, including the date and location of occurrence, as well as any other event-specific information that may be useful to reason about later—in the case of *Bad News*, this is information that I may query in my capacity as ‘wizard' (see next chapter).

Because it stores representations of past events so that they may be reasoned about later, *Talk of the Town*'s chronicling far exceeds that of *World*, which makes the task of story sifting—one of my jobs as *Bad News* wizard—more feasible. Indeed, it would be very hard to be a human story sifter for a *World*-driven experience. Still, *Talk of the Town* fails to do causal bookkeeping. This makes automatic story sifting a difficult prospect, since a computer program lacks my common sense about what kinds of events tend to cause others, let alone my expert design knowledge as the person who crafted the simulation. I will return to this deficiency in the course of my *Bad News* case study in the next chapter.

#### Artifacts

Like its predecessor *World*, *Talk of the Town* also features character gravestones, though with an added flourish: inscriptions. Specifically, a gravestone inscription is a string that is generated by the following template:

> ‘[header]‘

‘[name]‘

‘[birth year – death year]‘

‘[optional occupation inscription]‘

‘[optional family inscription]‘

‘[optional epitaph]‘

 An example header is the canonical ‘Rest in Peace', while an epitaph is something like ‘Peace is thine and sweet remembrance is ours'; in each case, an instance is selected from corpora that I found online. In a bygone era, American gravestones often featured the vocation of a deceased male in the case that the occupation was central to that person's identity [hijiya1983american]—this practice of including *occupational inscriptions* is operationalized in this system. Likewise, the optional family inscription may capture the relation of the character to any family members that survive in the town (a practice that is extant in the real world). Here are example gravestone inscriptions for actual *Talk of the Town* characters who were buried in a mining town called Kessenich:

> ‘Loving memories last forever

Mable Lena Topham

1816-1904

Loving Wife and Mother

Beautiful memories left behind
‘

>  ‘Here lies buried‘

 ‘Charlie Joseph Gradert‘

 ‘1830-1900‘

> ‘In remembrance of

Herbert Jessie Leuthold

1901-1973

Miner

Loving Husband, Father, Grandfather

Memory is a golden chain that binds us till we meet again‘

Additionally, there is one other kind of artifact in *Talk of the Town*: wedding rings, which are of course worn by characters who are married. In each case, the artifacts encode an emergent simulated event—either a death or a marriage—and in the case of a gravestone, the content instantiated in the artifact captures more emergent information (such as a character's occupation or family relations). Again, in designing a simulation I seek to target such emergent feedback loops.

Artifacts hook into the system's modeling of character knowledge phenomena, as I will explain in more detail below. When a character examines an artifact, knowledge about its subject is transmitted and the examiner's beliefs are updated accordingly. In this way, each of the components of a gravestone inscription are data-rich, in that they encode information about the storyworld that a non-player character can actually glean. [Note: For last year's Procedural Generation Jam (better known as PROCJAM), I gave an invited remote presentation titled “Beyond Vending Machines: Character–Content Feedback Loops” (November 8, 2017). In the talk, I identified a design pattern whereby procedurally generated content actually changes the constitution of simulated characters in meaningful ways. By targeting such *character–content feedback loops*, a system may model the internal lives of characters who have meaningful ongoing experiences in their simulated storyworlds; moreover, such feedback loops between generated content and future generated content can propel storyworld instances into novel pockets of a simulation engine's possibility space. While I am now more deeply exploring this notion in *Hennepin*, the implementation here of procedurally generated data-rich gravestone inscriptions—ones that actually *change* characters who examine them—represents an initial attempt at following this design pattern.]

Another impetus for modeling artifacts was to provide critical information and intrigue to *Bad News* players, who are tasked with learning about a character's family history. To my continuing astonishment, however, no player has ever taken the liberty of visiting a town's cemetery. As for wedding rings, these likewise provide valuable information, since knowing a character's marital status is critical to ascertaining the identify of her next of kin. However, my collaborators and I discovered through playtesting that the expression of whether characters wear wedding rings actually disrupted the balance of the experience (players learned too much too early) and so I removed that component of character descriptions. As such, characters do wear wedding rings in the simulation, but this is never expressed at the surface of *Bad News* gameplay. Now you know.

I also planned to implement other artifacts such as maps, documents, photographs, and paintings, all of which would encode knowledge about the world that characters could glean by examining the artifacts. As I will explain in Section 11.2.11, such extensive artifact modeling is now implemented in my new system *Hennepin*, where artifacts may encode information about past events.

## Simulation

Now that I have explained the basics of *Talk of the Town*'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 predecessor *World* and its successor *Hennepin*: 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. As I have noted above, 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—together, these constitute the simulation engine's procedure for *world generation* [martin2012landscape]. I will describe both of these simulation modes in turn.

### Setting Up a Town

Each *Talk of the Town* storyworld begins with the same essential scenario: it is the summer of 1839 and a few families move into an empty American townscape to establish a farming community; just prior to its establishment, a plat is generated for the town following the procedure explained in Section 9.1.3.

#### Retconning

As with *World*, modeling this initial scenario requires some retroactive simulation, in this case pertaining to the lives of the initial town denizens prior to their moving into the storyworld. Essentially, this entails determining birthdates for these *primordial* characters and simulating a history of childbirth in the case of a married couple, which produces children who will also be among the town's founding citizens. The number of families that move into the town will depend on the number of tracts there—one tract will be reserved for a town cemetery, and the remainder will become family farms. [Note: If a generated plat contains less than two tracts, a new one is created to replace it.] Additionally, there is a small chance of one of the tracts being used for a coal mine or a quarry instead of a farm, in which case the place will take a form more akin to a company town than a farming community. Beyond the characters who will own the farms or companies (and their family members), other characters will also move to the town to work there as farmhands or cemetery workers, or in other capacities in the case of a coal mine or quarry being founded at the outset of the town's history.

#### A Simple Block of Code

As I will explain more thoroughly in Section 9.2.7, the entire procedure of creating an initial set of characters to live in the town is driven in a elegant way by the simple instantiation of a new business. For example, consider the following block of Python code:

```
Create character
farmer = PersonExNihilo(
    sim=self, job_opportunity=‘farmer'
)
```
 When this code is executed, a new character is created outside the town—the class ‘PersonExNihilo‘ (lit. ‘person out of nothing') represents characters who are not born from parents in the simulation—to become a farmer there. That is, they will be created according to a recipe for what makes an American farmer of 1839; this recipe is composed modularly according to the definition of the ‘farmer‘ vocation, which specifies a typical age, sex, and family status for various eras. By executing this code, the execution of other code will be triggered, which may cause additional family members to be created in turn. Once all of the characters' backstories have been simulated, they will seek residence in the town—because no homes will exist yet, they will have to select an empty lot and construct a house (according to the procedure that I will outline in Section 9.2.8). Having constructed a house, they will move into it, and thereby the first characters will come to live in the town.

Here is the next line of code that will be executed in the procedure that is enacted to set up the town:

```
Have that character start a farm in town
Farm(owner=farmer)
```
 When this line is executed, other code will be triggered to handle the character selecting an empty tract on which the farm will operate (likely the one closest to the character's new home), and critically the hiring of an initial farmhand. By the latter procedure, the character will attempt to first hire someone in the town, but no one in the town will be qualified, so the simulation will generate a new character from outside the town to serve as a farmhand. This will trigger an enactment of the same process whereby the farmer came to exist and eventually live in the town. This process is repeated for all of the initial farms and businesses that will exist in the town, and once everyone has moved in accordingly, the town's history is set in motion.

#### Town Seeds

Eventually, I set up a mechanism for *seeding* towns—i.e., initializing the simulation's random number generator by using a numerical *seed* [marsaglia2003random]—which allows for the same town to be generated again by using the same storyworld seed. This was, however, not implemented in the version of the simulation codebase that is used for *Bad News* (which means that *Bad News* storyworlds are irretrievable).

### Simulation Loop

[Figure omitted]

Once a town has been established, its history is simulated until a specified *termination date*; in the case of *Bad News*, this is August 19, 1979. [Note: I was keen on setting *Talk of the Town* (2015) specifically in the summer of 1979, due to it being an aesthetically pleasing number, and moreover because it solved a design issue that Adam Summerville and I identified: gameplay could break down were it set in the current day, because cell phones and the internet would yield hyperactive knowledge propagation. Since this was still a concern in the context of the *Bad News* design, the summer of 1979 stuck.] As with *World*, time progresses in *Talk of the Town* according to the execution of simulation loop that recurs each timestep.

#### Level-of-Detail Modulation

As I noted above, not every timestep is actually simulated—more precisely, not every timestep is simulated *at full granularity*. For one, character knowledge phenomena is not simulated until after world generation ends—i.e., after the termination date has been reached—because it is too computationally expensive (both in terms of memory usage and speed). What may or may not be enacted on a given timestep is the procedure that drives social simulation; the probability of carrying out social simulation on a timestep is parameterizable, and in the case of *Bad News* it is set such that approximately four days will be simulated a year. Regardless of whether social simulation will be enacted on a timestep, various other high-level phenomena may be triggered. Figure 9.3 shows the raw console output that is displayed on screen as this procedure is underway. In the following sections, I will explain all the various phenomena that are simulated over the course of a *Talk of the Town* simulation loop. While these phenomena are grouped into more specific subroutines in the actual code for the simulation loop, for clarity I will describe them in terms of larger conceptual groupings.

### Birth and Death

Just as in *World*, a character's time in the simulated storyworld is bookended by *birth* and *death* events, whose modeling I will explain in this subsection.

#### Birth

When a character becomes pregnant, the date that she will give birth is established at that time. This is kind of like a ‘due date', except that it represents the actual date of birth (using the simulation cheat of *foreordaining*). Once that date arrives, there is a 50% chance that the birth will occur during the day timestep, otherwise it will happen at night. The birth event itself is abstractly simulated by the parents soliciting a doctor to delivery the baby (if there are any in town) and then giving birth at the hospital (if there is one in town), where any nurses who are on duty will also become associated with the event. Once the baby is born, the parents name her by the procedure outlined in Section 9.1.2, which includes decision-making about whether to give the infant a hyphenated surname. Next, the characters take the baby home, which triggers updates to that character's home attributes (including those that track residential history). Finally, depending on the era and whether there is a daycare center in town, the mother may decide to quit her job to become a stay-at-home parent. [Note: Of course, in the real world, fathers can also be stay-at-home parents. This was probably not typical in American small-town life prior to 1979, however, so this phenomenon is not modeled in the simulation.]

#### Death

Death strikes according to a probabilistic trigger, just as in *World*. Whereas a number of causes of death were defined for the latter, in the version of *Talk of the Town* that is used in *Bad News*, there is only ‘natural causes'. Once a character reaches the age of 68, there is a set chance on each simulated timestep that she will die of natural causes at that time. [Note: The oldest character that I have encountered was 111 years old, and this character emerged in a fitting context: Tarn Adams was playing *Bad News* at the San Francisco Museum of Modern Art, and the next of kin to whom he was tasked with delivering a death notification was an 111-year-old woman. This is fitting because Tarn Adams, as cocreator of *Dwarf Fortress*, is likely the person on this planet who is most associated with emergent intrigue and bizarre procedural outliers. I will mention more about this story in the next chapter.] When it has been determined that a character will pass away on a timestep, an abstract simulation of the event transpires in the same style as the birth event that I have just described. If there is a mortician in the town, the next of kin contracts that character to handle the interment. This involves the selection of a cemetery plot and the placement of the deceased in that place (abstractly modeled as updating her home attributes).

If the character is married, her widow(er)'s marriage attributes will be updated and that character will begin to grieve (which alters decision making) and she will take her wedding ring off her finger. [Note: I understand that a grieving widow(er) is probably not likely to do this. One of many ‘todo‘ items in the code concerns the development of a more nuanced modeling of this process, but I never got to it. As I have noted above, this chapter is about describing the system (with full disclosure) with regard to how it is actually implemented in driving *Bad News*.] If the deceased was a single parent, her adolescent children will depart the town (and thus the simulation) as an abstract modeling of the notion of being taken in by family in another place. If the deceased owned a home and a grown child lived with them at the time of death, ownership of her home will be transferred to the child. Finally, if the deceased character was still working at the time of death, her company will hire someone to fill her vacated position; this may trigger the generation of a new character to move into the town, per the procedure outlined in Section 9.2.1.

### Character Routines

The primary driver of character simulation in *Talk of the Town* is a procedure that handles *character routines*. On each timestep that will be simulated at high-granularity, every character in the town decides where to go; characters do not change locations within a timestep, so this decision determines where they will spend the entire day (as in daytime period) or night.

#### Mechanic: Deciding Where to Go

To decide where to go, a character carries out a probabilistic procedure that works as follows. If the character is a child and it is daytime, she will attempt to go to either school or daycare, depending on her age; if she is too young for school and there is no daycare in town, she will stay home, and likewise if there is no school in town (because it is very early in the town's history). During nighttime, children stay at home. If the character is an adult and the time of day corresponds to her work shift, she will go into work (unless she will call in sick, which happens at a low probability). [Note: Weekends are not modeled in the simulation, which means that every day works according to the same simulation procedures.]

If an adult character does not have to go to work, then she may decide to stay home, the chance of which depends on her personality (extroversion and openness) and whether there are kids at home to look after. If a character decides to leave home, she then probabilistically determines whether she will visit another character or visit a business. In the former case, another procedure determines whom she will visit, based on concerns such as whether the candidate is a neighbor, a family member (and if so, what relation), a friend, or a coworker, but namely her affinity for the character.

To decide which business to visit, the character considers all the services that are provided by each (see Section 9.1.3) and selects the one she desires probabilistically, depending on the time of day—that is, for both daytime and nighttime I authored a set of relative utilities for each type of service, to which a probability distribution can then be fit in order to select one probabilistically. These relative utilities capture that, for example, during daytime one is more likely to seek baked goods than a bar, but at nighttime that relation is inverted. Once a service has been selected, the character compiles all the businesses in town that provide that service and then selects which one to visit probabilistically according to the distance from her home. In a sense, town locales in this procedure are like the *smart objects* [forbus2001some] of *The Sims* [maxis2000sims], which are storyworld objects (including characters) that *advertise* affordances for character interactions—for instance, a refrigerator advertises eating (more precisely, lowering hunger) while a nearby character advertises social interaction (which satisfies a social need).

#### Dynamic: Emergence of Neighborhoods

From this procedure, distinct neighborhoods emerge in a way that is centered on public establishments (what sociologist Ray Oldenburg calls *third places* [oldenburg1982third, oldenburg2001celebrating]): characters tend to visit the establishments in their proximity, and so the characters in a given neighborhood will tend to congregate at the hot spots that are located there; in turn, according to the system's social simulation (discussed in the next section), characters will build relationships with the people that they encounter at those hot spots. This feedback loop is also driven by the social mechanic of characters being more likely to visit neighbors and friends. Generally, *Talk of the Town* is about utilizing simple social mechanics to yield rich social dynamics, as the rest of this chapter will emphasize.

### Social Simulation

Social simulation in *Talk of the Town* works according to a basic principle: characters' (nonreciprocal) *affinities* for one another evolve as a function of the compatibility of their personalities and the amount of time that they spend together. [Note: The subsystem reported in this section was first reported in an earlier workshop paper [ryan2016sbg], though the prose here is significantly revised.] In this way, friendships emerge as compatible characters interact more extensively and enmities emerge as incompatible characters do so. This aspect of the subsystem extends *World*'s approach to social simulation, which I described in Section 7.3.4. Beyond platonic affinity, character romantic feelings evolve by the same principle (applied to romantic considerations).

#### Evolving Social Networks

Over time, this abstract social simulation evolves a *social network* in the town that interconnects its denizens according to their social and romantic feelings for one another, as well as the distinct relationship types of ‘aquaintance‘, ‘friend‘, and ‘enmity‘. This network, along with the intermeshed family and work networks of a town, form the social substrate that character knowledge networks ride atop, as Section 9.2.12 illustrates.

#### Character Affinities

Social simulation in *Talk of the Town* is driven by several concerns (about which more soon), but the two core notions are called *charge* and *spark*:

	-  **Charge.** A nonreciprocal *platonic affinity* held by one character toward another, represented by a continuous numerical value. This value may be positive, signaling feelings of friendliness, or negative, indicating feelings of enmity. Broadly, charge increases as a character spends more time around someone who is compatible with her and decreases as she spends more time around a character who is incompatible with her. When little or no time is spent with someone, charge remains neutral.
	-  **Spark.** A nonreciprocal *romantic affinity* held by one character toward another, represented by a continuous numerical value. This value may be positive, signaling romantic attraction, or negative, indicating romantic aversion; additionally, a default value (‘n/a‘) represents the absence of such feelings, in cases where romantic attraction is not applicable. As I will explain shortly, spark evolves similarly to charge.

 Additionally, it is critical to note an additional notion, *salience*:

	-  **Salience.** For each character in the town, the system tracks the salience of all other characters to that person. Salience values are on a continuous scale, and the procedure for calculating them captures that for example, one's best friend is more salient than an acquaintance, a neighbor who is also a coworker is more salient than another neighbor, and so forth. Additionally, characters with higher occupational statuses are more salient to others, and salience increases slightly for each social interaction one has with another character.

When two characters interact on a given timestep, their respective affinities for one another will evolve according to how *compatible* each is with the other:

	-  **Charge increment.** As characters spend more time together, their respective charge values for one another will increase or decrease according to a notion of *friendship compatibility*, which is nonreciprocal. Specifically, this notion is used to determine a *charge increment*, which specifies how much a character's charge for another will increase (or decrease) in the case of a social interaction. In *Talk of the Town*, charge increments are modeled by operationalizing the following relationships between the five-factor personality model and friendship formation that have been identified by Maarten Selfhout and collaborators [selfhout2010emerging] and Lois Verbrugge [verbrugge1977structure]:


		-  People with similar openness, extroversion, and agreeableness personality components are more likely to befriend one another [selfhout2010emerging].
		-  People with higher extroversion select friends more frequently [selfhout2010emerging].
		-  People with higher agreeableness are selected as friends more frequently [selfhout2010emerging].
		-  People of the same sex are more likely to become friends [verbrugge1977structure].
		-  People closer in age are more likely to become friends [verbrugge1977structure].
		-  People of the same occupational status are more likely to become friends [verbrugge1977structure].

To calculate the two respective charge increments for a pair of characters, the system carries out the following procedure (numbers here indicate which finding from above each step operationalizes):

		-  Calculate a base charge increment (for both characters) as the average difference between the characters' openness, extroversion, and agreeableness personality components, and then normalize this average to a scale between ‘–1.0‘ (maximum disagreement) and ‘1.0‘ (maximum agreement).
		-  Modulate the charge increment held by each character according to the character's own extroversion personality component: if she is extroverted, boost the charge increment; if she is introverted, reduce the increment.
		-  Modulate the charge increment held by each character according to the *other* character's agreeableness personality component: if the other character is agreeable, boost the charge increment; if she is disagreeable, reduce the increment.
		-  Reduce both charge increments if there is a sex difference between the characters.
		-  Reduce both charge increments commensurately to the difference in age between the characters.
		-  Reduce both charge increments commensurately to the difference in occupational status between the characters.



	-  **Spark increment.** Like with charge, as characters spend more time together, their respective spark values for one another will increase or decrease according to a nonreciprocal notion of *romantic attraction*. Specifically, this notion is used to determine a *spark increment*, which specifies how much a character's spark for another will increase or decrease in the case of a social interaction. Again, the system operationalizes findings from the social sciences. In this case, these are the following relationships between the five-factor personality model and romantic attraction that have been identified by Shanhong Luo  and Guangjian Zhang [luo2009leads], Andrew Hayes [hayes1995age], and John Marshall Townsend and Gary D. Levy [townsend1990effects]:


		-  People with higher openness, extroversion, agreeableness, and neuroticism are more likely to form romantic attractions [luo2009leads].
		-  People with higher conscientiousness are less likely to form romantic attractions [luo2009leads].
		-  People with higher conscientiousness, extroversion, and agreeableness are more attractive to others [luo2009leads].
		-  Romantic attraction decreases with age difference [hayes1995age].
		-  People with higher occupation status are more attractive to others [townsend1990effects].

	Interestingly, Luo and Zhang found no significant correlation between attraction and personality similarity [luo2009leads], and so such correlation is not operational in *Talk of the Town*. To calculate a spark increment for one character relative to another, the system carries out the following procedure (numbers again indicate which finding from above each step operationalizes):

		-  If romantic attraction does not apply—because the character is not attracted to that sex, or they are family members, or attraction is inappropriate given the age of one or both—then set the spark increment to ‘n/a‘; more precisely, in the Python code, this is ‘None‘. As I will note below, this step introduced unintended behavior that would produce a hallmark of the *Bad News* aesthetic.
		-  Calculate a base spark increment according to the character's own openness, extroversion, agreeableness, and neuroticism personality components. Here, the system follows the sex differences of Luo and Zhang, and in fact uses the very numbers that they report in their paper [luo2009leads, p. 948]. This is a good example of the appeal of using the five-factor model: sometimes a paper will essentially include pseudocode for modeling a human phenomenon that is driven by personality factors.
		-  Modulate the spark increment according to the character's own conscientiousness personality component: if she is conscientious, decrease the charge increment; if she is not, boost the increment.
		-  Modulate the spark increment according to the *other* character's conscientiousness, extroversion, and agreeableness personality components: for each, higher values yield commensurate boosts and lower values produce corresponding decreases.
		-  Reduce the spark increment commensurately to the difference in age between the characters. While Hayes reports sex differences, this nuance is not operationalized in the system.
		-  Boost the spark increment commensurately to the other character's occupational status. While Townsend and Levy report sex differences, this nuance is not operationalized in the system.

#### Intergenerational Romance

The first time a pair of characters meet, the system will calculate the respective charge and spark increments by following the procedures that I have just outlined. One unintended (and intriguing) system behavior arises from the procedure for determining a spark increment, as I have alluded to above. When two characters meet prior to reaching the age in which romantic attraction begins, the system will attribute a spark increment of ‘n/a‘ in each direction. This makes sense and produces the intended behavior initially, but a problem arises in that these increments do not change over time, a ramification of which is that characters who meet early in life (e.g., in school) will *never* be able to develop romantic feelings for one another (even in adulthood).

The perhaps unintuitive upshot of this bug is romantic relationships with massive age differences, which obtain because characters can only become romantically attracted to others whom they meet *once they have reached the age of romantic life*. Usually a first meeting like this only occurs in the case of a generational gap—since otherwise the characters will have grown up together and congregated in the same social circles (at school and in other public places)—and so age differences dominate the romantic world of *Talk of the Town*.

When my collaborators and I began performing *Bad News*, we encountered this phenomenon as a curious recurring motif: characters were constantly falling in love with their parents' friends. Initially I assumed that age difference was positively contributing in the determination of spark increments, rather than negatively contributing, but as I have just explained the strange behavior was in fact dynamical rather than mechanical. In any event, we found that the emergent quirk actually contributed dramatic intrigue to the world—players found the age gaps to be curious and worth inquiring about—and so I elected not to fix the bug in the version of the code that is used in that project. [Note: Later, in another version of the simulation code, I fixed the romance bug by simply altering the procedure to recalculate spark increments once each story year.] These are the *aesthetics of the uncanny* at work, and this is an example of the broader phenomenon of a bug producing surface-level aesthetic quirks that become adopted as canonical.

In a similar case—though one without an intriguing byproduct—a bug was yielding strange population dynamics in the generated storyworlds: each town would gradually dwindle in its population, but never all the way to zero. After hours of fruitless investigation as to the cause of this behavior, I returned to working on the subsystem that handles character routines, where I noticed a typo in the code that made characters unable to go out for errands or for leisure. When I fixed this, I was shocked to discover that the population dynamics had reverted back to normal. At first, I could not comprehend how the two concerns were connected, but eventually it dawned on me: if characters only left their homes to go to work, their only potential romantic partners would be coworkers—but most people worked at family businesses, and so this bug had essentially disabled the system's romance simulation. As a result, few characters had romantic lives, which ultimately meant few children were ever born, and the towns' dwindling populations could not be replenished.

#### Simulation Bugs Are Narratable

One enjoyable aspect of crafting character simulations is that otherwise benign bugs in the code generate *narratable* surface expressions, since the bugs alter the behavior of anthropomorphized code objects (characters). Indeed, to use Michael Mateas's phrasing, the actual simulation execution concerns “a purely relational (and thus literally meaningless) technical manipulation of computational material” [mateas2003expressive, p. 61]. Here, Mateas is writing about how AI approaches, all of which are instantiated in the otherwise meaningless manipulation of computational material, are actually distinguished by the coupled interpretative strategies employed by their human practitioners:

> The rhetorical strategies used to narrate the operation of an AI system varies depending on the technical approach, precisely because these interpretative strategies are inextricably part of the approach. Every system is doubled, consisting of both a computational and rhetorical machine [mateas2003expressive, p. 61]

 In the case of character simulation, the rhetorical machine drives the narration of code objects as anthropomorphic beings whose behaviors we charge with all the meaning that structures human life. Really, though, there is nothing there—the town is just an electric wind. But now I have digressed back onto my tangent on representation, rhetoric, and symbol grounding that appeared in Section 4.2.1. [Note: For more on representation and expressive simulation, see an underappreciated paper by Mike Treanor and Michael Mateas titled “Understanding Representation in Playable Simulations” [treanor2014understanding].]

#### Procedure

The actual procedure that evolves character affinities over time works by carrying out the following steps:

-  **Decay charge and spark.** First, at the start of a simulated timestep, the system *decays* all the charge values held by the characters who currently live in the town; this is done by regressing the values (whether positive or negative) toward ‘0‘. This makes strong feelings of friendship or enmity weaken as time passes without the character interacting with the subject of such feelings. Without this step, childhood friendships would never fade, even if one of the pair were to leave the town, for example. In the case of spark, decay works differently: instead of reducing spark itself, the spark *increment* is decreased as two characters spend more time together. This supports romantic attraction that evolves quickly but eventually plateaus, as well as romantic obsessions that persist even without extended interaction with the target of such affection (“distance makes the heart grow fonder”). Both of these are are media tropes that I wanted the system to operationalize.

-  **Trigger social interactions.** Once character routines have been enacted on a timestep, each character in the town will have navigated to the location where she will spend that day or night. In this place, she may engage in *social interactions* with nearby characters. In *Talk of the Town*, a social interaction is instigated by a probabilistic trigger that considers: a character's extroversion (extroverts instigate more social interactions), the salience of other nearby characters, and one's respective charge and spark values for those individuals (characters interact more with people they like). By considering charge and spark, the procedure yields feedback loops that may reinforce emerging friendships (or romantic crushes): characters are more likely to interact with better friends, and interactions between friends will cause friendships to be strengthened; in turn, such strengthening will increase the likelihood of future interactions between the friends, which will work to further strengthen the friendships, and so forth. This is how *best friend* relationships emerge in *Talk of the Town*.

-  **Update charge and spark.** Once a social interaction has been instigated by a character, the charge and spark values that each holds for the other are updated. As I explained above, each character holds a charge and spark increment for every other character she has ever met—updating means incrementing the corresponding charge or spark by that amount, but in a way that *extrapolates* according to the amount of time that has passed since the last simulated timestep. As I noted earlier, *Talk of the Town* does not simulate every timestep in the history of a town, but rather four or so a year. By extrapolating individual social interactions, they may come to stand for extended periods of social interaction that would have transpired over the course of the interim period. To extrapolate a social interaction, the charge and spark increments are multiplied by the number of timesteps that have transpired since the last simulated one.

-  **Reconstruct discrete relationships.** After the charge and spark values that one character holds for another have been updated, the system checks for whether any *affinity thresholds* have been eclipsed. For example, when a character's charge for another exceeds a certain number, the character will come to view that person as a friend, and thereby a *friendship* relationship is instantiated by the system. Because charge is nonreciprocal, this works unidirectionally, and indeed the other character may not feel the same way. In *Talk of the Town*, there are three platonic relationship types: ‘acquaintance‘ (default type, associated with neutral charge), ‘friend‘ (associated with significant positive charge), and ‘enmity‘ (associated with significant negative charge). Additionally, three superlative relationship types are tracked by the system: ‘best friend‘ (character for whom one holds the highest charge; must be above a positive threshold), ‘worst enemy‘ (character for whom one holds the lowest charge; must be below a negative threshold), and ‘love interest‘ (character for whom one holds the highest spark). Because of decay, it is also possible for relationships to be demoted over time—for example, a childhood enemy who leaves the town may be considered a mere (former) aquaintance after the passing of decades.

By this procedure, character feelings for others evolve over time, enabling the emergence of social networks that capture platonic affinities, romantic attractions, and discrete social relationships. At any point in the history of a generated town, each character will harbor a specific degree of both platonic affinity and romantic attraction for every other character in the town (though both values will be neutral in the case that the characters have not met). Below, in Section 9.3, I will discuss some interesting emergent phenomena that are produced by *Talk of the Town*'s mechanics for social simulation.

#### Related Work

A particularly related approach to social simulation has been reported by Gonzalo Méndez, and Pablo Gervás and Carlos León [mendez2014model,mendez2016use]. This project also targets a lightweight design and features a low-fidelity simulation procedure that evolves mutual character affinities over the course of many social interactions.

In their system, character affinities evolve according to abstract social exchanges in which one character proposes an interaction to another character, who then chooses whether to accept or reject the proposal. The potential interactions that characters may engage in depend on their mutual affinities (for instance, only dating characters may have a romantic dinner together) and the various interactions affect affinities differently (a romantic dinner boosts affinities more than watching TV together does, for example). If the recipient accepts an interaction, both of the characters' mutual affinities increase; upon rejection, the proffering character will lower her affinity toward the recipient. As such, it works like a lower-fidelity version of *Comme il Faut* (*CiF*) [mccoy2014social], the engine underpinning *Prom Week* [mccoy2011prom,mccoy2013prom], which I discussed at several points in Part I of this thesis. While social exchanges in *CiF* have a rich array of preconditions and postconditions and are rendered in natural language, exchanges in the system under discussion have simple conditions and are only represented symbolically. In sacrificing fidelity, their system gains in computational efficiency, which affords the generation of large social networks, a task for which *CiF* could prove too heavyweight.

*Talk of the Town*'s social simulation takes this lightweight approach further, with exchanges that are even more abstract: interactions in the system are represented merely as functions that evolve affinities. While Méndez, Gervás, and León's system has been applied to social networks comprising fifteen characters [mendez2016use], storyworlds in *Talk of the Town* generally contain on the order of several hundred characters. Another distinction is that their system models a single notion of affinity, subsuming both platonic and romantic feelings, while these are decoupled in my project. While *Talk of the Town*'s lightweight social simulation proved to be a good fit for *Bad News*, which requires storyworlds to be generated quickly as players arrive for their scheduled performances, I am now jumping across the continuum to model fine-grained character actions in *Hennepin*. As I explain in Chapter 11, I still produce storyworlds with hundreds of characters, which means this increase in granularity comes at steep computational costs. Accordingly, *Hennepin* can probably only drive second-order media experiences for which it is alright to take a day or so to generate a storyworld. *Sheldon County*, the subject of Chapter 12, has been designed to work under this constraint.

### Marriage and Divorce

Unfortunately, *Talk of the Town* does not model the romantic lives of characters beyond the triggering of marriage and divorce events. Partly this is due to the abstract modeling of social interaction in the system, but it still would have been possible to introduce a discrete dating relationship into the simulation—this was high on my ‘todo‘ list, but I never got to it. As I explain in Chapter 11, *Hennepin*'s major departure from *Talk of the Town* is its modeling of fine-grained social interactions. One outcome of this increase in detail is the actual simulation of romantic life, which has been long overdue in my simulation practice—in this case of this simulation engine, I consider it a modeling gap (see Section 4.1.5).

In *Talk of the Town*, a social interaction between two characters may trigger either a marriage event or a divorce event. The mechanism that handles this is embarrassingly simple given the importance of such life events, especially in the domain of an American small town. To that point, a comment above the code block that handles this behavior states:

```
# TODO fix currently dumb way of ‘proposing'
and divorcing
```
#### Marriage

Here is how marriage triggering works: if both of the respective spark values among two characters exceed an authored threshold after a social interaction, then a marriage event is triggered. [Note: I had assumed this at least worked by a probabilistic trigger, but I see now that it does not. This appears to be a case of placeholder code becoming calcified in a framework.] Same-sex marriage is not possible, since it was not legal in the United States in the simulated period (i.e., 1839–1979). As such, and due also to the lack of simulation of romantic life aside from marriage, in *Bad News* the scenario of a queer character who remains in the town is tragical (as Section 9.3 will show). When a marriage event is triggered, a probabilistic procedure determines whether a newlywed or stepchildren may take a new surname, including a hyphenated construction. Additionally, the newlyweds determine new living arrangements: if either owns a home, they move there, otherwise they obtain a home in the town according to the procedure outlined in Section 9.2.8.

#### Divorce

If a married character falls deeply in love with someone else, a divorce will be triggered. Specifically, if a married character's spark for another character exceeds twice that of her spark for her spouse, then divorce occurs. This does not mean that the character will automatically marry her love interest—that character may not even feel the same way—but it of course opens up the possibility. Again, I view this modeling as embarrassingly abstract, and an intellectual (and technical) thrust of my development of *Hennepin* has been to actually do romance simulation.

### Business Operations

Business operations constitute the primary structural scaffold for simulated life in a *Talk of the Town* town. With each new timestep, there is a chance that a new business may open in the town or that an existing business may shut down; here, the respective probabilities are authored simulation parameters.

#### Business Establishment

If the opening of a new business is triggered, the system randomly selects a business type and then checks whether it could successfully operate given the current state of the town. Here, success is contingent on: the ‘advent‘ year having been reached, the ‘demise‘ year having not been reached, the town exceeding the business type's specified ‘minimum population‘, and there not already being enough businesses of this type in the town (as specified by the type's ‘maximum number‘ attribute). [Note: These attributes were defined above in Section 9.1.3.] Additionally, if the business will require a tract to operate, there must be an open tract in the town. If the randomly selected type is not applicable in the town, another type is selected and evaluated in the same way; this process terminates after a set number of failures.

If the system does successfully select a type of business to open in the town, the next matter is deciding who will own the business. In the case of a public business type, this is not necessary, but for all other business types the system will reason over the characters in the town to determine if anyone is a good fit for the vocation of the owner position. Here, the system operates over concerns such as the presence of a college degree (if the owner vocation requires a degree), occupational status, and whether a character is employable in that vocation given the current historical era. If no one in the town is qualified, then an adult character is generated to move into the town to start the business.

Once a character has been selected to run the new business, she must name the company, obtain a lot or tract, contract the construction of a building there, and hire an initial set of employees. Naming follows the procedure that I outlined in Section 9.1.3. To decide where to locate the business, the owner carries out a procedure of *utility-based action selection* [maes1989right,mark2009behavioral] whereby every lot (or tract) is scored according to a single concern: how near the location is to every other business in town. This simple mechanic causes downtown areas to emerge over time, and also secondary neighborhoods, since new businesses may be forced to locate outside a downtown area if its perimeter is taken up by residential areas (i.e., if characters build homes on lots that surround the downtown area, as in Figure 9.2). Rather than selecting the top-scoring lot, the owner probabilistically selects from the top three candidates.

To actually obtain the lot, the owner *contracts* a realtor in the town by another utility-based procedure: she scores all the realtors in town according to concerns such as familial relation, affinity, and whether she has contracted that person before. (As I will note below, this procedure is used whenever a character needs to contract someone of a certain vocation.) If there are no realtors in the town, no character is contracted, but the job is still carried out. [Note: This could be taken as implying that the character purchases the lot without the help of a realtor, but really the realtor does not actually do anything anyway. There is no concrete economical simulation carried out by the system, and the modeling of contracts is meant as a cheap source of social intrigue.] Once a lot or tract has been obtained, the new business owner carries out the same procedure to contract an architect (who works at a construction firm) to construct a building on the lot. This will trigger a construction event whereby a new building is constructed; the system tracks data about this event such as its date of completion, the character who contracted the work, the architect, and the builders who carried out the work.

Now that the character has constructed a building on her acquired lot, she must hire an initial set of employees to work at the business. To do this, she considers each of the vocations that are listed in the business type's ‘day shift‘ and ‘night shift‘ attribute definitions. For each of these vocations, the owner assembles a list of candidates given all the other characters in the town. These are characters that meet the criteria for taking on that vocation—which I listed above in explaining how the system selects a new business owner—but overqualified candidates (with occupational statuses equal or greater to the one at hand) are not considered.

Once the job candidates have been assembled, the owner scores each according to whether: she already works at the company, she is in the owner's immediate family, she is in the owner's extended family, she is a friend of the owner, she is an enemy of the owner, she is an acquaintance of the owner, and her current occupational status. This simple scoring procedure yields the emergent phenomena of in-house promotion (due to preference to hire from within the company), family businesses (due to preference to hire family), nepotism (due to preference to hire friends and family), and leaving a company for a better position elsewhere (since all qualified candidates in the town are considered). Finally, the owner probabilistically selects one of her top three candidates, and that character is thereby hired for the position. Because overqualified candidates are excluded and having the same occupational status as the position is treated as an overqualification, the opening represents a promotion in status for every character in the candidate pool. As such, though the procedure only explicitly models the decision making of the business owner, it may be viewed as abstractly modeling the entire hiring process whereby job candidates apply for a position, the owner interviews them to evaluate them, one is selected, and the person accepts the position. [Note: In *Hennepin*, which features fine-grained character actions, each of these steps are concretely realized, as I explain in Section 11.2.1.]

If a hired character is currently working in a different position, that position is vacated and the same hiring process is then carried out by the owner of that business (to hire a replacement); in this way, the process of hiring for one position may trigger a chain reaction in the town. Additionally, if there are no qualified candidates in the town for a given position, an adult character will be generated to move into the town. As such, even if a character in the town is hired for a position, the hiring may trigger a chain reaction that ultimately brings new people into the storyworld. In this way, the opening of a new business works as the primary driver of town evolution in terms of the actual composition of residents who live there. As such, the specification of the probability of a new business opening on some timestep is a powerful authorial lever for controlling the general population dynamics of the engine's generated worlds.

#### Business Operation

Once all of the initial employees have been hired for a new business, it commences operation. This means that all of the employees will start going to work there on their specified shifts, following the simulation of character routines that I discussed in Section 9.2.4. Additionally, the business will now provide the services associated with its type, which means characters may start visiting it as their routines bring them out into public.

There are two attributes in the definition of a business type that I have not yet discussed: ‘supplemental day shift‘ and ‘supplemental night shift‘. As I explained in Section 9.1.3, these are lists of additional employee positions that are not necessary for the business to operate. These are filled over time as the owner of a business does favors for friends and family members who are out of work. Specifically, when a character who is old enough to work (and not retired) is unemployed for an extended period, a procedure determines whether any business owner in town would be willing to hire them as a favor. In this way, for example, the children of a business owner may be given low-level positions at the parent's company once they reach a working age. Over time, however, due to how owner hiring preferences favor family members and internal promotion, the children may rise the ranks in the company and eventually take it over when the owner retires or passes away. This is the mechanism by which family businesses may be sustained over generations, which is a distinctive feature of American small towns and, in turn, the *Bad News* aesthetic.

Finally, characters may not be fired and only quit their jobs as part of the process of being hired for a better one; however, characters may retire according to a probabilistic trigger, which kicks in once the character reaches the age of 65. If the owner of a business decides to retire, she first hires her replacement.

#### Business Closure

As I noted above, with each passing timestep there is a chance that a business will shut down. Specifically, there are two authored probabilities at play here: a general chance for any business, and a high chance for businesses for which the ‘demise‘ year has been reached or eclipsed. Thus, while a shoemaker shop has a ‘demise‘ year of 1900, it will not immediately go out of business at that time, but rather the chance of that happening is greatly increased (making it a matter of time before the closure is probabilistically triggered). Likewise, as I explained above, a business will not come to exist right at the time of its specified ‘advent‘, but instead it becomes possible then. In this way, the modeling of the shifting of historical eras with regard to business operations is smooth in its expression across generated towns. When a business closes down, its employees are all laid off (and thus become unemployed) and its building is demolished (by contracting a construction firm in town).

### Real Estate

In *Talk of the Town*, characters live in houses or apartment units. The decision making that drives the simulation of real estate works according to the kinds of utility-based procedures that I have outlined in the previous section. Specifically, a character who seeks housing will contract a realtor and then score every vacant home and lot in the town according to a number of concerns. This scoring procedure considers the distance of that home or lot to every other character in the town, with the score increasing when friends are close and either increasing or decreasing when family is close, depending on the character's personality (conscientiousness boosts the score, openness lowers it). In the latter case, the specific familial relation with a relative in town also modulates the score, making conscientious characters more likely to live by a mother than an aunt, for example. Additionally, this scoring procedure models characters preferring homes and lots that are near their workplaces and preferring vacant homes over vacant lots (since the latter require an additional construction step). If a character is married, her spouse will also contribute to the score of a given home or lot.

Once the scoring has been carried out, one of the top three candidates is selected probabilistically. If a vacant lot is selected, then an architect will be solicited and a construction event will be triggered, just like with business construction. Finally, the character—along with her immediate family, if applicable—moves into her new home.

### Education

As I noted in Section 9.2.4, children in *Talk of the Town* go to school during the day, assuming there is one in town. Specifically, this will be a K–12 school, which means every student attends the same school. [Note: In the United States, a ‘K–12' school is one that is attended by children of all ages, from kindergartners to high-school seniors. For obvious reasons, they are typically encountered in very small towns.] Additionally, there is a chance of a character dropping out of high school to begin work—this depends on the character being offered a job at that time (and also on a set probability, so that not all characters drop out when offered a job). In some humorous cases encountered during *Bad News* performances, students have dropped out to become teachers at the same schools they stopped attending. Earlier, I alluded to the modeling of higher education in *Talk of the Town*, which I mentioned as being very abstract. If an adult character is unemployed in the town for at least four consecutive years, a probabilistic rule may trigger to cause her to instantaneously receive a college degree. This may be viewed as an abstract modeling of the character taking classes at a nearby university outside the town (or by correspondence, even).

### Departing the Town

A character may leave her town, and thereby the simulation. Such a departure is permanent, and may be probabilistically triggered for a number of reasons: a child becomes an orphan (this is an absolute trigger); a character is unemployed for a prolonged period; a new adult has a high openness-to-experience personality component, and decides to leave for greener pastures; there are no vacant homes or lots in town;  a character simply elects to depart for unspecified reasons (i.e., a general probabilistic rule triggers). When a working character leaves the town, her position is vacated and then filled according to the procedure outlined above. If a married character departs, her family will join her in leaving.

### Artifacts

As I explained in Section 9.1.3, there are two kinds of artifacts that are modeled in *Talk of the Town*: *gravestones* and *wedding rings*. When a character dies, a gravestone is generated following the procedure outlined above. As part of the abstract modeling of a marriage event, both spouses begin wearing wedding rings; upon divorce or widowing, a character stops wearing a wedding ring. Unlike in *World*, artifacts do not weather over time.

#### Artifacts and Knowledge Transmission

As I have noted already, artifacts hook into the system's rich modeling of character knowledge phenomena. Specifically, when an artifact is examined by a character, it transmits information about the subject of the artifact according to a procedure that I will explain in the next section. By examining a gravestone, a character learns the following about the deceased: first name, middle name, last name, suffix, surname ethnicity, surname composition (hyphenated or not), birth year, death year, approximate age (assumes birthday already occurred in death year), condition (that the deceased is dead), and vocation (in the case that an occupational inscription is on the stone). In noticing a wedding ring on a character's finger, an observer will learn that that character is married.

### Character Knowledge

Characters in *Talk of the Town* construct (and mutate) subjective knowledge about the storyworld as they go about their daily lives; this rich modeling of knowledge phenomena is probably the hallmark of the system. [Note: The subsystem described in this section was designed in collaboration with Adam Summerville and has also been presented in a workshop paper [ryan2015toward] and a book chapter [ryan2017simulating]. The prose here is a revision of that of the latter document, though it does include some additional information pertaining to updates to the subsystem that were made after the composition of those earlier publications. As such, this section provides the most authoritative reporting on this aspect of the project.] In this section, I will describe *Talk of the Town*'s modeling and simulation of character knowledge phenomena, including the mechanisms by which knowledge may originate, propagate, deteriorate, and terminate according to the procedures of the architecture.

#### Overview

People and places in a simulated town have perceptible attributes that characters may observe to form corresponding beliefs about those subjects. Such knowledge may then propagate across characters during social interactions. Critically, character knowledge can also be misremembered (in multiple interesting ways), or it may be altogether forgotten. All throughout its modeling of such phenomena, this module keeps track of belief histories and knowledge trajectories, which allows for the tracing of any piece of modeled information.

#### Perceptible Attributes

*Talk of the Town* characters have *perceptible attributes*, meaning attributes that are directly observable by other characters. These are mainly physical features, like hair or eye color, but the system also models conditionally perceptible attributes—for instance, a character's workplace is observable while she is in the act of working. A *radius of perceptibility*, in which character attributes may be observed directly, is defined simply as a location in the town (either a dwelling place or a business); thus, characters whose routines have brought them to the same place on a timestep may observe one another at that time.

While a variety of modeled attributes may be perceived—I will list these shortly—perception (along with other knowledge phenomena) is triggered probabilistically according to how *salient* the subject and the attribute are to a given character. As I explained in Section 9.2.5, the system tracks how salient each character is to every character, according to a number of social concerns. Similarly, this subsystem utilizes specified *attribute saliences*, which prescribe how likely given character features are to be observed and to be talked about among characters. In the procedural content that I have authored, this captures, for instance, the real-world phenomenon of features of a person's hair and eyes being more salient than those of her nose and chin, as J. Kirkland Reynolds and Kathy Pezdek [reynolds1992] and Marcos Ruiz-Soler and Francesc S. Beltran [ruiz2012] have reported.

Character saliences work together with attribute saliences to determine the probability of knowledge phenomena occurring for a given character and attribute—that is, the probability of a perceptible attribute being observed, as well as the probability of a belief about any attribute being propagated, misremembered, or forgotten. Below, I will explain this extended salience computation in more depth.

#### Network Structure

[Figure omitted]

A character's composite knowledge of the world is structured as a *network* of interlinked mental models that each pertain to a single person or location. As Figure 9.4 illustrates, the interlinking occurs when a character's knowledge as to some attribute of a character or place resolves to some other character or place for whom or which they have another mental model. For instance, a character may believe that some person works at some business in town, and so her belief about that person's workplace would itself link to her mental model of that business (as I explain below). This network structure provides both elegance and convenience, since it allows characters to reason about entities in terms of knowledge they may already have about related entities (rather than by instantiating redundant or potentially inconsistent knowledge). For example, if a character knows where another character works, she may reason about the latter's work address in terms of existing knowledge about the workplace that can be stored and accessed independently of knowledge about the character who works there.

#### Mental Models

As I have already noted, characters form *mental models* about town residents and landmarks. Following *PsychSim* [marsella2004psychsim, p. 243] and *Thespian* [si2005thespian, p. 23], two earlier systems in which characters also richly perceive one another, I selected this term specifically to indicate that the structure of a character's knowledge of some entity closely matches the structure of how that entity is represented in the simulation itself. That is, the components of a mental model generally correspond to the components by which the simulation actual models a character, the set of which I outlined in Section 9.1.2. Each of a character's mental models pertains to a specific individual entity (either a character or a home or a business) and is composed by *belief facets* that each pertain to an individual attribute of that entity. In total, there are forty facet types that are modeled in the version of *Talk of the Town* that is used to drive *Bad News* (these are grouped conceptually for presentation clarity):

-  For mental models of characters:


-  **Status.** Condition (‘alive‘ or ‘dead‘), year of departure from the town (if any; e.g., ‘1972‘), and marital status (‘single‘, ‘married‘, ‘divorced‘, or ‘widowed‘).
-  **Age.** Birth year (e.g., ‘1941‘), death year (if any), and approximate age (e.g., ‘30s‘).
-  **Name.** First name, middle name, last name, surname ethnicity (e.g., ‘German‘), surname construction (whether it is hyphenated), and suffix (e.g., ‘III‘).
-  **Appearance.** Each of the twenty-four facial attributes that were listed in Section 9.1.2.
-  **Occupation.** Workplace (links to mental model of that place), vocation (e.g., ‘tailor‘), shift (‘day‘ or ‘night‘), and status (‘employed‘, ‘unemployed‘, or ‘retired‘).
-  **Home.** Home (either an apartment unit or a house; links to mental model of that place).
-  **Whereabouts.** Where a person was on a given timestep (links to mental model of that place). For example, a character could believe that someone was at ‘Horswill Farm Park‘ or the ‘Law Offices of Mateas and Wardrip-Fruin‘ on the night of August 12th, 1979. Such whereabouts knowledge was critical in the design of *Talk of the Town* (2015), since these beliefs would pertain to where characters were on the night that the lover was witnessed visiting the late town founder.


-  For mental models of businesses:


-  **Employees/Residents.** A list of its employees (each links to mental model of a character).
-  **Block.** Business block, for example, ‘800 block of Lessard Avenue‘.
-  **Address.** Business address, for instance, ‘222 Elson Street‘.


-  For mental models of homes:


-  **Residents.** A list of its residents (each links to mental model of a character).
-  **Apartment.** Whether it is an apartment unit (‘yes‘ or ‘no‘).
-  **Block.** Home block, for example, ‘300 block of Lyndale Avenue‘.
-  **Address.** Home address, for instance, ‘613 Fillmore Street‘.

Each facet is structured as a collection of data about the belief. In addition to its *owner* (who has constructed the mental model), *subject* (the character to whom it pertains), and *facet type* (e.g., ‘first name‘), this data includes:

- {**Value.** A representation of the belief itself, for example, the string ‘brown‘ for a belief facet pertaining to hair color.}
- {**Mental model.** If the value of this facet resolves to an entity for whom the owner of this facet has formed a mental model, this component will point to that mental model.}
- {**Predecessor.** The belief facet that the owner previously held, if any. This allows the system to track supplanted or forgotten character knowledge (about which more soon).}
- {**Evidence.** A list of the pieces of evidence by which the owner of this facet formed and continues to substantiate it. As I explain in the next section, all character knowledge is undergirded by evidence that a character accumulates as the simulation proceeds.}
- {**Parents.** If this knowledge originated in information from other characters, this will point to the belief facets, owned by those characters, that spawned this current facet. Specifically, if a piece of evidence represents that a character learned information from someone else, this component will point to that character's corresponding belief facet. This allows the module to trace the history and trajectory of any piece of information.}
- {**Strength.** The strength of this particular belief. This is the sum of the strength of all pieces of evidence supporting this belief, whose determination I will explain in the next section.}
- {**Accuracy.** Whether or not the belief is accurate (with regard to the *current* true state of the world). Thus, the accuracy of a belief can change over time as the storyworld changes. For example, if someone observes another character at work, a corresponding work-status belief facet (set to ‘employed‘) will be accurate; but if later on the working character retires without the observer finding out, the belief facet will have become inaccurate due to the storyworld changing in the interim.}

#### Evidence

All character knowledge is formed in response to evidence, and knowledge may also propagate, deteriorate, or terminate in a way that can be described using pieces of evidence. I will illustrate these details by way of an *evidence typology*, which comprises twelve *types* across five conceptual categories. [Note: This typology has evolved since the earlier publications that reported on this subsystem [ryan2015toward,ryan2017simulating], and as such, this section provides the only explanation of the final state of the system with regard to these concerns. Most pertinently, the simulation of artifacts transmitting knowledge is presented here for the first time.]

- {How knowledge *originates*:}


-  **Reflection.** A *reflection* occurs when a character perceives something about herself, which happens at every timestep.
-  **Observation.** When a character directly *observes* a person or place, she may form knowledge about attributes of that entity. Whether she forms knowledge about a particular attribute depends on the salience of the entity and the attribute type, as I will explain shortly.
-  **Examination.** When a character *examines* an artifact (either a gravestone or wedding ring), she forms knowledge about its subject entity (either the deceased of the ring wearer). As I explained in Section 9.2.11, a wedding ring imparts that a character is married and gravestones express the following information about the deceased subject: first name, middle name, last name, suffix, surname ethnicity, surname composition (hyphenated or not), birth year, death year, approximate age (assumes birthday already occurred in death year), condition (that deceased is dead), and vocation (in the case that an occupational inscription is on the stone).
-  **Transference.** If one entity reminds a character of another entity (determined by feature overlap between her respective mental models of them), she may unconsciously *transfer* a belief she holds about one so that its corresponding facet value is also attributed to a facet in her mental model of the other entity.
-  **Confabulation.** By *confabulation*, a character *unintentionally* concocts new knowledge about some entity. The particular facet value that gets confabulated is determined probabilistically according to the distribution of that feature type in the confabulator's town. Thus, in a town with a predominance of brown hair, a character would be most likely to confabulate someone as having that feature value.
-  **Lie.** A *lie* occurs when a character *intentionally* conveys information to another character that she herself does not believe. This is deemed a type of origination (and not propagation) because the knowledge in question is *invented* by virtue of the lie—that is, it does not propagate any existing knowledge.
-  **Implant.** As I mentioned in Section 9.2.2, for reasons pertaining to computational efficiency, the system does not simulate character knowledge phenomena until the end of world generation. At the beginning of this transition into a higher granularity of simulation, essential character knowledge is directly *implanted* into character minds, and thus will have no explicit point of origination. I will discuss this notion of knowledge implantation in depth below.


- {How knowledge *propagates*:}


-  **Statement.** A *statement* occurs when a character conveys information to another character that she herself believes. Whether characters will exchange a particular piece of information depends on the salience of its subject and type, as I will discuss shortly.
-  **Eavesdropping.** Characters may *eavesdrop* on nearby social interactions to overhear statements and lies; this happens at a set probability.


- {How knowledge *reinforces itself*:}


-  **Declaration.** Whenever a character delivers a statement, the strength of her own belief (being *declared* by her statement) will slightly increase. That is, the more a person retells some belief, the stronger that belief becomes, which is realistic [wilson1985effects]. By this mechanic, a character who frequently tells the same lie might come to actually believe it.

[Figure omitted]

- {How knowledge *deteriorates*:}


-  **Mutation.** As an operationalization of memory fallibility, knowledge may *mutate* over time. This is modulated by a character's memory attribute (see Section 9.1.2) and the facet type (e.g., a whereabouts belief will be more likely to mutate than a belief about someone's first name). The particular mutation that occurs is determined by the *belief-mutation graph*: an authored schema that specifies state-change probabilities given a facet value. For instance, given the value ‘brown‘ for a facet about someone's hair color, the module will consult this graph to decide how to probabilistically mutate ‘brown‘—here, the graph captures that, for example, ‘black‘ and ‘red‘ are more probable mutations than ‘white‘ or ‘purple‘. Figure 9.5 illustrates an excerpt from the graph that I authored for *Talk of the Town*.


- {How knowledge *terminates*:}


-  **Forgetting.** To further incorporate memory fallibility, knowledge may be *forgotten* due to the passing of time. This is affected by a character's memory attribute and the salience of the facet subject and type.

Characters are not consciously aware of transferences, confabulations, or mutations, and recipients (as well as eavesdroppers) of lies treat them as statements. That is, the recipient will reason about a lie as if it were a statement (and so the strength of a lie, as a piece of evidence, is equal to that of a statement), but the system nonetheless tracks that it was in fact a lie (to allow for reasoning about true knowledge trajectories). Additionally, each piece of evidence has metadata of the following types:

-  **Source.** In the case of a statement, lie, or eavesdropping, a piece of evidence's *source* is the character who delivered the information. This metadata allows the system to trace the history and trajectory of any piece of information, which was a major design goal in developing this project. With regard to *Talk of the Town* (2015), my collaborator Adam Summerville and I envisioned the trajectories of important pieces of knowledge (ones that affected the outcome of the game) being presented to the players at the end of the gameplay session. For example, if a non-player character told a player that the lover has a mustache and the player then identified a mustached character as being the lover, the system could visualize how that information originated in a critical lie constructed by the lover character.
-  **Location.** Where the piece of evidence originated (e.g., the specific location where an observation or statement took place).
-  **Timestep.** The timestep on which a piece of evidence originated.
-  **Strength.** The *strength* of a piece of evidence is a floating-point value that is determined by its type—for example, a mutation is weaker than an observation—and decays as time passes. In the case of statements, lies, and eavesdroppings, the strength of a piece of evidence is also affected by the affinity its owner has for its source and the strength of that source's own belief at the time of propagation.

#### Salience Computation

When a character observes some entity in the simulation, a procedure is enacted that determines, for each perceptible attribute of the observed entity, the probability that the character will remember what she saw; this procedure crucially depends on the salience of the entity and attribute being observed. Salience computation considers the relationship of an observed character (subject) to the observer (e.g., a co-worker is more salient than a stranger), the extent of the observer's friendship with the subject, the strength of the observer's romantic feelings toward the subject, and finally the subject's occupational status (characters with more prestigious job positions are treated as more salient).

For locations, salience computation currently only considers whether the observing character lives or works at the observed place. Additionally, this salience-computation procedures consult an authored schema specifying the salience of each attribute type. My authored knowledgebase captures, for instance, that features of a person's hair and eyes are more salient than those of her nose and chin [reynolds1992,ruiz2012]. Salience computation is also used to determine the probability that a character will misremember or altogether forget (on some later timestep) knowledge pertaining to some subject and attribute.

#### Knowledge Implantation

The simulation of character knowledge phenomena is computationally expensive. If all of these phenomena were to be simulated during the entire period of world generation—the town's total history—it could take several hours to produce a town. Moreover, a lot of computation would be devoted to modeling the knowledge of hundreds of characters who would have died long before the period of *Bad News* gameplay. In the case of that experience, a town must be generated in a few minutes or less, because we schedule performances one after the other to afford maximum player throughput. [Note: Additionally, it would not be feasible to generate a number of towns at the beginning of a day of performances, because *Talk of the Town* towns take up a considerable memory (on the other of several gigabytes each).]

Thus, in *Bad News*, this simulation detail is not worth the time and computation, and so the system approximates the history of character knowledge phenomena using a procedure of *knowledge implantation*. By this pattern, world generation employs all aspects of the simulation besides ones related to character knowledge—characters still form relationships, start businesses, and so forth—and then terminates one week prior to the specified end date in the summer of 1979. At this point, however, living characters have no knowledge at all. To resolve this, the module employs a procedure that *implants* into each character's mind the knowledge that would believably be ingrained in them. The following pseudocode illustrates this procedure:

```
for resident in town
    implants = []
    for immediate family member of resident
        add immediate family member to implants
    for friend of resident
        add friend to implants
    for neighbor of resident
        add neighbor to implants
    for coworker of resident
        add coworker to implants
    for every other character who has ever lived
        chance = 1.0 - (1.0/salience of that character)
        if random number < chance
            add other character to implants
    for character in implants
        for attribute of character
            chance = attribute salience
            chance += -1.0/salience of that character
            if random number < chance
                have resident adopt accurate belief
```
#### Knowledge Propagation

When two characters engage in a social interaction (see Section 9.2.5), they may exchange knowledge about other characters and locations in the town—these entities about which knowledge is exchanged are called the *subjects of conversation*. Currently, the subjects of conversation that come up in an interaction between two characters is determined by computing the total salience of all the entities that either of the characters know about. The $n$ highest-scoring entities are then brought up in conversation, with $n$ being determined by the strength of the interactors' relationship and also their respective *extroversion* personality components (each of these work to increase $n$).

For each subject of conversation, the characters exchange information about individual attributes of that subject (corresponding to the individual belief facets of the characters' mental models of that subject) according to the salience of each attribute type. Because a character may bring up subjects that her interlocutor does not (yet) know about, this propagation mechanism allows characters to learn about other people and landmarks that they have never themselves encountered. It is even possible for a character to learn about another character who died before she was born; this often occurs when parents tell their children about deceased relatives (who score highly in salience computation due to being related to both conversational partners).

#### Lies

During a social interaction, a character may convey false information about the subject of conversation—more precisely, information that she herself does not believe—to her interlocutor. Currently, this is triggered probabilistically according to a character's affinity toward the interlocutor, and the misinformation is randomly chosen. While I had a number of plans for extending this aspect of the system [ryan2015toward, p. 60], I never got to them.

#### Fallibility Modeling

As an operationalization of *memory fallibility*, characters may adopt false beliefs for reasons other than lies. On each timestep after world generation, the four phenomena associated with memory fallibility—transference, confabulation, mutation, and forgetting—are probabilistically triggered for character mental models. When this happens, the facets of that mental model are targeted for deterioration at probabilities determined by the character's memory attribute (again, modeled as a floating-point value), the facet type (e.g., a whereabouts belief will be more likely to mutate than a belief about a first name), and the strength of the existing belief (weaker beliefs are more likely to deteriorate).

As I explained already, mutation works according to the belief-mutation graph and a series of handcrafted procedures for certain other types. As another example of the latter, if a character will misremember another person's surname, the procedure retrieves a surname of the same ethnicity (from the surnames corpus) that is similar to the source name (modeled using edit distance between the strings representing each).

#### Belief Revision

Over time, as the storyworld changes and information travels and beliefs warp and mutate, characters carry out procedures of *belief revision*. A character always forms a belief upon encountering a first piece of evidence supporting it, assuming she has no current belief that it would replace. As a character accumulates further evidence supporting her belief, its strength will increase commensurately to the strength of the new evidence. Additionally, whenever a character delivers a statement, the strength of her own belief (that she is imparting with the statement) will slightly increase. That is, the more a person retells some belief, the stronger that belief becomes for her, which is realistic [wilson1985effects]. If that character, however, encounters new evidence that contradicts her currently held view, she will consider the strength of the new evidence relative to the strength of her current belief. If the new evidence is stronger, she will adopt the new belief that it supports; if it is weaker, she will *not* adopt a new belief, but will still keep track of the other *candidate belief* and the evidence for it that she had encountered. If she continues to encounter evidence supporting the alternative candidate belief, she will update its strength accordingly and, if at any time that strength exceeds the strength of her current belief, she will adopt the candidate belief and relegate the previously held belief to candidate status.

As an example, let us consider a hypothetical scenario involving two characters named Michael and Noah. Michael has just gotten a haircut, but Noah still believes that Michael has long hair because he had seen this for himself on multiple occasions and heard the same from a good friend, Jim, just yesterday. During a conversation, another character that Noah does not know very well mentions to him that Michael has short hair. Noah does not immediately change his belief about Michael's hair, because the strength of this new evidence does not outweigh the strength of his current belief (since he had heard only yesterday that Michael has long hair and moreover saw this himself on multiple occasions). Later, Noah's wife tells him that Michael's hair is in fact short. Noah now adopts the new belief, because the strength of the evidence constituted by both of these statements now outweighs the strength of the evidence supporting his prior belief. The prior belief was supported by more pieces of evidence, but this evidence was so outdated relative to the new information that its strength had decayed to the point where the new evidence was now stronger. Critically, this process of belief revision depended on Noah keeping track of the candidate belief—that Michael has long hair—even during the period prior to him adopting that belief.

#### Related Work

While story generators and expressive multiagent systems have typically featured characters who operate over perfect knowledge of the world—for example, see [aylett2006affectively,fendt2011case]—a fair amount of systems have incorporated models of character belief. As I noted above, characters in Sheldon Klein's murder-mystery generator can recursively simulate the storyworld in accordance with their subjective beliefs [klein1973automatic, pp. 29–30]. In *Tale-Spin* [meehan1976metanovel], discussed at length in Chapter 4, characters may be initialized to have some knowledge about the storyworld and may perceive which characters and objects are nearby. Agents in applications of the Oz Project similarly perceive their surroundings, but at a higher fidelity [bates1992architecture]. This is likewise seen in Hans ten Brinke, Jeroen Linssen, and  Mariet Theune's (2014) extension [tenbrinke2014hide] to the *Virtual Storyteller* system [swartjes2010whose], in which updates to character beliefs are fed to a reactive narrative-planning system.

Jonathan Teutenberg and Julie Porteous have also explored narrative planning with perceptive characters [teutenberg2015incorporating]. Stories generated by *Minstrel* [turner1993minstrel] may rely on false character beliefs, but such circumstances must be artfully crafted beforehand [perez2004three]. Chris Crawford has written extensively on an approach for modeling character gossip [crawford2012chris, pp. 235–244], including lies [crawford1999assumptions]. In a project that I mentioned earlier, Pablo Gervás has used chess gameplay data to generate stories focalized to individual pieces with limited *fields of perception* [gervas2013stories]. In the emergent-narrative system of David Carvalho and collaborators [carvalho2012perception], characters may operate over false beliefs. Recent work by Alireza Shirvani, Rachelyn Farrell, and Stephen G. Ware represents character beliefs in terms of possible worlds [shirvani2017possible,shirvani2018combining]. In *Tale-Spin*, *PsychSim* [marsella2004psychsim], *Thespian* [si2005thespian], *Othello* [chang2009planning], and Henrique Reis's extension [reis2012lie] to the *FAtiMA* agent architecture [aylett2006affectively], characters not only perceive the world, but form mental models of other characters and *their* beliefs—as such, these systems operationalize *theory of mind* [frith2005theory].

A handful of multiagent systems have specifically explored *deception in agents* [ward2003towards], a notion that naturally relies on the modeling of knowledge. *Tale-Spin* characters may lie to one another in pursuit of their goals [meehan1976metanovel, pp. 183–184]. *Golem* implements a *blocks world* [bailey1996generating] variant in which agents deceive others to achieve goals [falcone2001deceiving], while *Mouth of Truth* [de2003can] uses a probabilistic representation of character belief to fuel agent deception in a variant of Turing's *imitation game* [turing2009computing]. In David Christian's excellent masters thesis [christian2004strategic], he reports on a *deception planner* that injects inaccurate world state into the beliefs of a target agent so that she may unwittingly carry out actions that fulfill ulterior goals of a deceiving agent. Agents in Reis's aforementioned extension to *FAtiMA* [reis2012lie] employ multiple levels of theory of mind to deceive one another in the party game *Werewolf* [girlea2014tracking]. Matthias Rehm and Elisabeth André describe a system in which an embodied agent lies during a game of dice, but exhibits realistic facial cues while doing so [rehm2005catch]. Henry Mohr, Markus Eger, and Chris Martens recently developed a system that generates murder mysteries surrounding characters who form knowledge and may hide the truth [mohr2018eliminating]. Eger's *Impulse* language [eger2015impulse] for modeling stories explicitly represents character mental models, and his recent dissertation dives deep into the modeling of agent beliefs (and theory of mind) in games that center on player knowledge [eger2018intentional]. While all of the above systems showcase characters who perceive—and, in the latter cases, deceive—other characters, all of them appear to place less emphasis, relative to *Talk of the Town*, on knowledge propagation and memory fallibility.

Outside of *Dwarf Fortress* [dwarf], which I discuss next, commercial and even research videogames have been surprisingly spare in their modeling of character knowledge. There are many examples of stealth and action games that use complicated knowledge, perception, and alertness models to produce short-term non-player character (NPC) beliefs that are a core part of gameplay [diller2004behavior,welsh2013crytek,walsh2015modeling]—here, notable examples include *Thief: The Dark Project* [leonard2003building] and *Third Eye Crime* [isla2013third]. Few projects, however, have supported characters whose perceptual systems instantiate memories or lasting beliefs—though this has certainly been proposed [isla2002new]—and there are even fewer examples of the modeling of fallible character memory. This is curious, since issues of belief, especially false belief, are often central in other fictional media [palmer2004fictional]. Some games *are* about character beliefs, to be fair, but in these cases beliefs are typically handcrafted, as in the AAA game *LA Noire* [bondi2011noire].

In games that do model character knowledge procedurally, the AI architecture that handles such concerns is sometimes called a *gossip system*. A classic example of this type of module is the reputation system in *Neverwinter Nights* [brokington2003building]. More generally, *reputation systems* [gruenwoldt2005creating] (or *faction systems* [jannidis2007event]), which alter NPC behavior toward the player character according to actions she has taken, are a form of character knowledge modeling, but a rudimentary one in which NPCs seem to globally inherit perfect knowledge of player behavior. This can play out quite awkwardly, as in the familiar case in which NPCs in one area of the gameworld appear cognizant of a player's crime in another area before word of it could have ever spread to them [rappner2015dynamisk].

Phil Goetz's forgotten application of *SNePS* [shapiro1979sneps] to the domain of interactive fiction explored the development of NPCs who harbor subjective models of the simulated world [goetz1993notes]. *Black and White*'s “creatures” were special NPCs that could acquire knowledge (by *reinforcement learning* [sutton2018reinforcement]) about how to do certain tasks [evans2001future]. Interestingly for a mainstream title, the recent *Middle-earth: Shadow of Mordor* [monolith2014middle] features NPC enemies who may reference earlier combat [kroon2016nemesis, plater2015postmortem]. More commonly, games utilize simple *flags* that mark what plot knowledge the player currently has, so that only valid dialogue (sub)trees are deployed [wardrip2009expressive]. By extending *Comme il Faut* [mccoy2014social]—the AI system underpinning *Prom Week*, which features omniscient characters [mccoy2013prom]—*Mismanor* [sullivan2012design,sullivan2012grail] likewise incorporates a flag-like representation of player plot knowledge, but also a more general notion of character world knowledge (which specifies things like characters' knowledge of other characters' traits, something that *The Sims 3* also tracks [evans2010modeling]). Most interestingly, the player may manipulate NPC knowledge by asserting facts about the world, but this information does not propagate because the NPCs do not interact with one another in this same way. Jonathan Rappner has prototyped a system that does model knowledge propagation, at the level of discrete agent interactions [rappner2015dynamisk]. In *Versu*, characters cultivate beliefs that pertain to specific story concerns and, through dialogue interaction, can even persuade other characters to adopt such beliefs [evans2014versu]. Because *Versu*'s AI framework has only been applied to storyworlds with a small number of characters, it is probably not accurate to say that it features knowledge propagation; moreover, it does not appear to operationalize memory fallibility or character lies. Recently, Sasha Azad and Chris Martens reported on a system in which characters form opinions and exchange viewpoints [azad2018addressing]. Lastly, the *LabLabLab* title *Hammurabi* features characters who may lie to the player in a procedural manner [lessard2017striving].

It seems that *Dwarf Fortress* [dwarf] best represents the state of the art (certainly in the domain of computational media) in modeling character knowledge and its attendant phenomena. In the earlier paper on *Talk of the Town*'s simulation of character knowledge phenomena, I reported a series of insights that were gleaned from personal communication with Tarn Adams (May 28, 2015):

> The primary character-knowledge machinery in *Dwarf Fortress* is its *rumors system*. Rumors typically originate when a character witnesses an important event, such as a crime, and are instantiated at certain local and regional levels. Interestingly, characters in the purview of a rumor might then propagate it to new areas they visit. Examples of this include diplomats informing their home civilizations about traps they have encountered, caravans (who visit player fortresses) bringing rumors from their parent civilizations, and artistic and scientific knowledge moving across civilizations. Like a few other systems noted above, *Dwarf Fortress* also features characters who autonomously lie. When a character commits a crime, she may falsely implicate someone else in a witness report to a sheriff, to protect herself or even to frame an enemy. These witness reports, however, are only seen by the player; characters don't give false witness reports to each other. They may, however, lie about their opinions, for instance, out of fear of repercussions from criticizing a leader. Finally, *Dwarf Fortress* does not currently model issues of memory fallibility—Adams is wary that such phenomena would appear to arise from bugs if not artfully expressed to the player. [ryan2015toward, p. 61].

 Since that reporting, *Dwarf Fortress* has undergone a number of updates, notably one that is centered on storyworld *artifacts* and what characters know about them. As part of this update, characters may now adopt secret identities, as Tarn Adams explains in a recent invited paper on the topic [adams2017secret].

The approach taken in *Talk of the Town* exhibits several features that are found independently across the various systems that we have outlined. As in systems like *PsychSim* and *Thespian*, characters form mental models of one another. Following *Golem*, *Mouth of Truth*, *Dwarf Fortress*, and other projects, characters may lie to one another, though my system does not model this aspect nearly as richly. Along with *Dwarf Fortress*, *Talk of the Town* appears to be among the few systems to support detailed character knowledge propagation. [Note: This phenomenon could likely be supported by more of these systems if they were to include more characters in their simulations.] Lastly, to my knowledge, this system features the richest modeling of memory fallibility to yet appear.

## Emergent Phenomena

As I did with *World* in Section 7.4, I will now discuss examples of intriguing emergent phenomena in *Talk of the Town*. In my view, this engine cannot produce full-fledged narrative sequences because it does not model concrete events beyond abstract social interactions and nondescript life events (such as a house construction), but its modeling is rich enough to produce scenarios that have more to them than *World*'s poetic images. As such, while *World* produces emergent stories and images, as I explained above, *Talk of the Town* generates what may more aptly be described as *emergent scenarios*.

#### Bar-Crossed Lovers

I recently reached out to my *Bad News* collaborators, Adam Summerville and Ben Samuel, to ask them about their favorite *Talk of the Town* scenarios that emerged in the context of our many performances of the former. Before providing these examples, I should note a few things about *Bad News*, the subject of the next chapter. In this project, a player explores a generated *Talk of the Town* town by interacting with a wizard-of-Oz configuration mounted as an installation-based experience. Each performance begins with the death of a resident of the town, and the player's job is to find and notify the next of kin, which she does by speaking with residents in the town who are all played live by a human actor (Ben).

Here is what Adam had to say about his favorite *Talk of the Town* emergent scenario (citations inserted for clarity):

> 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” [morrissette2001scotland]—a retelling of Macbeth [shakespeare1901macbeth] 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.]

 While the tragical component of this scenario originates at the layer of the *Bad News* experience (since the scion of the first family died in that context), the rest of it emerged out of the various interworkings of *Talk of the Town*'s simulation.

For instance, the *business rivalry* is an emergent of the engine's business simulation, and the *family rivalry* is actually an example of a common system dynamic, which works as follows. Since characters inherit personality traits, over time a given family in a town will come to be associated with a personality archetype. In turn, due to the social simulation's modeling of personality compatibility, it is possible for one family's archetype to be incompatible with that of another—when this happens, enmities will tend to form between the members of each family. Coupled with the business rivalry (which in this example only required the presence of two bars in the town), this family incompatibility yields the emergent case of a family rivalry. Finally, the romantic attraction between the two characters is a basic phenomenon that is modeled by the system's social simulation, as I explained in Section 9.2.5. When all of these emergent phenomena stack up at a higher order, the result is what I am calling an *emergent scenario*—in this case one with a distinctly Shakespearian quality. [Note: Intriguingly, a quite similar emergent scenario underpinned a *Talk of the Town*-driven project that was carried out by researchers and students at the University of Turin in Italy [damiano2017thinning]. After collaboratively exploring the generated material of a particular *Talk of the Town* storyworld, students in a seminar run by Rossana Damiano, Vincenzo Lombardo, and Antonio Pizzo homed in on a romance between two characters who worked at rival bakeries. The result of this endeavor, *Hot Bread*, is a work of curationist emergent narrative that hooks into the researchers' *DoPPioGioco* framework for computationally assisted live performance [damiano2017doppiogioco]. The following year, I visited Italy to collaborate with this group on what became *Cattive Notizie*, a variant of *Bad News* that I describe in Section 10.2.5.]

#### Narrative Cornucopias

The beauty of *Talk of the Town* is that every one of its generated towns overflows with emergent scenarios like the one Adam recalls so fondly. This is because it follows *Dwarf Fortress*'s lead in modeling a storyworld with an abundance of simulated material, resulting in what I have termed (in Section 5.2) a ‘cornucopia' of narrative potential—this is the ‘overgenerate' component of my curationist tagline *overgenerate and curate*.

#### Deli Drama

Adam's example calls to mind a related scenario that concerned a character who dropped out of high school to start a delicatessen that would rival one that already existed in the town. This alone is mildly interesting, but in this particular case the rival deli was owned by the character's own mother. Due to having incompatible personalities, the mother and son did not like each other, and so they did not speak during the five years following the son's opening of the rival establishment. Eventually, this situation would also turn tragic, because the son was in fact the deceased character in the *Bad News* performance for which the town was generated—as such, the mother was the next of kin, and so this performance culminated in an emotional scene in which she (played by Ben Samuel) realized that she would never have a chance to rectify the unfortunate family situation. Many towns feature a more common type of family drama in the form of a *sibling rivalry*: two siblings with a mutual enmity.

#### The Recluse with Green Hair

While the richest scenarios combine material generated by various subsystems, just as Adam's example does, I have encountered instances pertaining to only one subsystem that are still narratively potent. One notable example pertains to a dynamic of the knowledge subsystem, whereby schools become the hot spots for gossip and popular kids in turn operate as the primary manipulators of knowledge in the towns. This may be unintuitive, so let me explain. While adults generally go off to various workplaces during the day, every child between five and eighteen years old spends such timesteps at a single K–12 school. As such, children have more opportunities for social interaction and knowledge propagation—since there are more nearby characters—and so a town's K–12 school tends to become a nexus for character knowledge. This pattern is further driven by children eavesdropping on their parents' social interactions at night and then going into school during the day to spread the information obtained thereby. Moreover, because the children with the most friends will engage in the most social interactions, popular kids become the primary drivers of (mis)information.

In one hilarious scenario, an introverted hermit who few had ever met became the subject of a widespread misbelief that his hair was green—upon investigation, I discovered that this false gossip had originated with a confabulation by the town's most popular kid. As such, the basic dynamics of character routines and character knowledge phenomena had produced a humorous variation on the literary trope of the *misunderstood recluse* (e.g., as exemplified by Harper Lee's Boo Radley [lee1960kill]).

#### The Night Beat

Another favorite scenario of mine emerged out of the basic dynamics of *Talk of the Town*'s affinity modeling. This situation concerned two police officers who worked the night shift in a town. One of these officers was a man who was among the town's most beloved individuals—he was maximally extroverted and maximally agreeable, which means he selected friends often and was selected as a friend frequently. The other officer was essentially his opposite: she was maximally introverted and maximally disagreeable, which led to her disliking nearly everyone she met and being considered a friend by few—she was a *misanthrope*.

However, due to the male officer's extreme agreeableness and especially to the amount of time the two spent together, he came to consider her his best friend; in turn, due to the amount of time spent together, she considered him her worst enemy. This kind of asymmetry is fairly common in the system, but in this case it was also stacked atop a case of emergent romantic intrigue: even though she disliked him as a friend, the woman was madly in love with the male officer; in turn, the man was extremely romantically averse to the female officer. As such, in total this scenario featured three kinds of interesting asymmetry: platonic asymmetry, romantic asymmetry (i.e., *unrequited love*), and internal asymmetry (each character simultaneously harbored asymmetrically extreme feelings for the other). The result, framed in the peculiar context of a small town's night beat, felt like a set-up for a *buddy cop* [buddycop] romantic comedy.

#### Yvette and the Love Polygon

When it comes to romantic affinity, a classic kind of emergent intrigue is the *love triangle* dynamic [lovetriangle]. In popular media, this trope can take a number of forms, but generally it involves three characters who are each in love with one of the others, who in turn does not reciprocate. At its most complex, a love triangle involves a character $A$ who only loves a character $B$, who in turn only loves a character $C$, who in turn only loves $A$.

[Figure omitted]

At the Workshop on Tutorials in Intelligent Narrative Technologies, held in Los Angeles in 2016, I led an interactive exploration of a *Talk of the Town* town that centered on a randomly selected character named Yvette. Even though the character was chosen at random, her life situation had no scarcity of social intrigue: Yvette was a teenage girl in 1979 who was in love with her stepsister Lori, who was married to David but was in love with David's brother Brian, who loved Lori back, while in turn David was himself in love with Yvette (who was thus his wife's stepsister). During the interactive session, Kate Compton took to a whiteboard to map out the welter for the benefit of all our understanding—Figure 9.6 shows an excerpt from this diagram. [Note: In the session, we followed Yvette over the course of her life, from her teenage years in the 1970s to the early 2000s, by simulating five years at a time. Eventually, she fell for other women who were not Lori, but tragically there was no one else in town with whom there was a mutual attraction. The workshop attendees collectively wished for her departure from the town with each passing half decade, but sadly she stuck around her entire life, with all her various infatuations going unrequited.]

In *Talk of the Town*, such dramatically potent structures appear in every town, which again I attribute to the utilization of an ‘overgeneration' approach to simulation that produces narrative cornucopias. More often than love triangles, towns feature *love polygons*, like the one that Yvette anchored. Sometimes these chains of unreciprocated love may span upward of dozens of characters—this may seem unrealistic, but it is hard to say for sure, since we do not have access to every human's true feelings in the real world. As such, this phenomenon may be like the unintuitive but realistic genealogical structures that emerge in *World*. In that case, and potentially here as well, such complex structures are only discernible from the omniscient perspective afforded by computer simulation.

#### The Interpersonal Circumplex

Another basic emergent social dynamic concerns the juxtaposition of character affinities and character *status* relations [hollingshead1975four,johnstone2012impro], which produces the *interpersonal circumplex* [wiggins1996informal], a model of interpersonal relations that maps affinity against patterns of dominance and submission. In *Talk of the Town*, there are a number of reified status relations: boss–employee, senior employee–junior employee, elder family member–younger family member, and so forth. While the interpersonal circumplex is not explicitly modeled in the social simulation, its various expressions could be recognized by a second-order system that processes its emergent material. Indeed, we do this in *Bad News*, where affinity and status—the latter of which is a central concern in improv [johnstone2012impro]—are primary concerns for Ben as he brings *Talk of the Town* characters to life. Some researchers have argued that the circumplex's affinity and status axes are actually equivalent to the agreeableness and extroversion components of the five-factor model of personality [mccrae1989structure]—of course, the various dynamics yielded by this notion could also be easily recognized in *Talk of the Town*'s emergent material.

#### The Restaurateur

I should also note that much of *Talk of the Town*'s emergent intrigue is the byproduct of a mere *improbability*—that is, situations or occurrences that are interesting simply because they are improbable. Such intrigue characterizes, for instance, the otherwise benign matter of a character surviving an extensive number of potentially lethal dice throws (by receiving unlikely outputs from the random number generator). I have already mentioned the 111-year-old woman who was the next of kin in the remarkable *Bad News* performance for which Tarn Adams was fittingly the player.

Another example proved central to one of Ben Samuel's favorite emergent scenarios (the larger context of which I will introduce in the next chapter):

> This [character] came from a long line of restaurateurs himself—his great-great-uncle (for some number of greats) established a restaurant over a hundred years prior. This restaurant had been a staple of the town, and was passed down from father to son for many generations, until finally it was bequeathed to an owner who would never have any children of his own. When this owner chose to retire, he passed the restaurant on to his nephew, who had been a successful server at this restaurant all his life. However, less than a year later, the nephew managed to drive the restaurant into the ground; a century's worth of family history and town pride forever lost. After this, the nephew became a laughing stock of the town, ridiculed and reviled in equal measure. He became a recluse, hesitant to leave his apartment and face the vitriol of his community. [Note: Personal communication, June 14, 2018.]

In this case, the family restaurant was remarkable for a few reasons: it was in operation for over a century, and it was passed down from father to son several times in a row. [Note: As I will explain in Section 10.6, in which I revisit this example at length, the restaurant in fact operated for 131 years.] In each case, this is the result of the simple mechanics that I have outlined above. As I explained in Section 9.2.7, a business will shut down on a given timestep if a probabilistic rule triggers. This means that a business that operates for a remarkably long time has simply been fortunate in terms of the random numbers that have been generated on its behalf. As for the notable succession of fathers and sons at the helm of the business, this is more dynamical, but still it emerges from simple mechanics: in this case, the structuring of the hiring process such that family members are preferred, which would have led each father, upon retiring, to score his son more highly than other prospective candidates. Finally, once the nephew took over, the business shut down after it had operated successfully for well over a century.

Our human minds leap to a causal explanation of this: the nephew was not cut out for the job, and the restaurant sunk like a ship; it was not his true inheritance, after all. But this is *apophenia*—the phenomenon whereby patterns of order are discerned when randomness is in fact at work [steyerl2016sea]—and so an overactive narrativization is at work. Really, the closure occurred because that probabilistic rule finally triggered. While most of the story was contingent on improbable series, the succumbing to probability in the long run is what proved poetic here. But, again, the real charge of this scenario is almost entirely due to a human proclivity to see narrative even where it is not.

#### The March of Progress

Another potent scenario produced by simple probabilistic mechanics concerned a character who owned a general store in a town for over fifty years, but was forced to close it after a new supermarket opened there. Ironically, and tragically, he spent his remaining days as a nighttime stocker at that very supermarket. Likewise, in one of our papers on *Bad News*, we recounted another scenario that also ended in tragical grocery stocking:

> [the player] explained [to the aunt of the next of kin] he was a historian chronicling the history of the town [...], hoping she would tell him more about her family, and ultimately the next of kin. The aunt obliged, telling familial history that reinforced the game's theme of loss: her father had been a town blacksmith for forty years of life, but as the march of progress advanced and demand for blacksmiths all but disappeared, her father lost his smithy and—after decades of being a skilled artisan—had to find work as a stocker at a grocery store, until he passed away [samuel2016bad, pp. 117–118]

 Both of these scenarios are essentially human narrativizations of the ‘demise‘ attribute of business definitions (see Section 9.1.3), which is what causes general stores and blacksmith shops to shut down around the same time that supermarkets begin to appear.

#### Design Pattern: Apophenia Hacking

In crafting a character simulation, it is helpful to anticipate that humans will unconsciously narrativize event patterns to identify emergent intrigue beyond what is actually generated by the system. In this way, apophenia may be targeted by a design pattern that I call *apophenia hacking*. In a keynote speech titled “The Power of Projection and Mass Hallucination: Practical AI in The Sims 2 and Beyond” [brown2006power], developer Matt Brown spoke about this phenomenon in the context of *The Sims 2* [maxis2004sims]. [Note: Though the talk was not recorded, a summary by Mark Nelson is available online: http://www.kmjn.org/notes/sims2_ai.html.] When it comes to *Bad News*, apophenia hacking undergirds a procedure of curation whereby Ben and I, as actor and wizard in the installation, process the raw emergent material of *Talk of the Town* towns to tell stories that are driven by an overactive narrativization. This is easy for us to do because we are humans, which means we cannot help but identify narrative patterns in the towns beyond what is modeled; I designed this simulation and still I cannot stop myself from noticing these patterns.

However, in letting our apophenia run rampant, we constrain ourselves according to a narrativization motto: *augment but do not contradict*. That is, while our curation procedure is partly about *augmenting* the material of a town to tell stories that deal in richer phenomena than what is actually modeled in the underlying system, in doing so we do not contradict any of the explicitly modeled concerns. For example, romantic infatuation is modeled by the system, so we can know for sure whether a character is in love with someone else—a fact like that should never be contradicted by our overactive narrativization. In the next chapter, I will return to this kind of discussion, but the takeaway is that *Talk of the Town* appears to succeed at suggesting narrative patterns beyond those that can actually be produced by the system's explicit modeling.

#### Emergent Scenarios

To summarize, while it does not generate stories, *Talk of the Town* tends to produce an overabundance of narratively potent situations in the form of what I call *emergent scenarios*. These scenarios pertain to various simulation mechanics and social dynamics, several which I have outlined in this section: misanthropes, recluses, social status, the interpersonal circumplex, unrequited love, asymmetric friendship, internal conflict, love triangles (polygons), extramarital obsessions, business rivalries, town institutions, family feuds, family drama, and forbidden love. More powerfully, an emergent scenario may concern higher-order dynamics that richly recombine the concerns of multiple of these lower-order dynamics.

Unfortunately, the simulation of character knowledge phenomena provides little in the way of narrative intrigue, and this is due to its particular emphasis on character appearance. Again, this curious predilection results from the importance of character appearance in *Talk of the Town* (2015). While appearance is also important in *Bad News*, as I will explain in the next chapter, it is not important enough to vindicate the misappropriation of computation and authoring effort that could have been spent instead on having characters form knowledge about more interesting social concerns. Now, in *Hennepin*, I am exploring a more narratively potent subject of character knowledge: past events.

Nevertheless, in *Talk of the Town* the simple modeling of abstract social mechanics is rich enough to produce an array of intriguing dynamical phenomena, as I have shown in this section. In the following chapter, I will discuss how such narratively potent material is excavated for purposes of curation in the course of a *Bad News* performance. Thus, while this chapter has concerned the ‘overgenerate' component of my tagline *overgenerate and curate*, the following chapter will make good on the second part.