We discuss the ongoing development of MicroTales, a collection of elements that can be combined to generate interactive narrative environments of varying size and complexity. MicroTales aims to fill a gap among existing AI benchmarks by featuring active non-player characters, a wide variety of actions, and the possibility to soft-lock the problem. Its purpose is to provide a clearly defined environment to compare diferent experience management algorithms without enforcing any one definition of what makes a good story. We present design goals and a sketch of an initial design, and invite community feedback to help make our benchmark reusable by other narrative intelligence researchers.
community feedback. The remainder of this paper discusses our objectives and presents a tentative design along with some working examples.
This section describes the desiderata that MicroTales is meant to fulfill. As we discuss in Section 3, there are existing AI benchmarks that share some of these traits, but none that reflect all of them. Game-Like Storytelling Environment: MicroTales is designed to imitate a simple game environment where a player controls one character, and a human game master or an automated experience manager controls the other characters and the environment. Our intention for MicroTales is to reflect the kinds of problems that an experience manager would need to solve interactively, meaning that new solutions are generated during play to adapt to unexpected player actions. At the same time, the problems will be versatile enough to benchmark ofline planning approaches.
Action-Level Storytelling: Stories can be generated at many levels of granularity. The basic unit
of story content in MicroTales is an action, which would typically correspond to a sentence of a
written story with a subject, verb, and possibly one or two objects. Early intelligent narrative systems
like Universe [
Scalable Along Several Dimensions: It should be possible to generate a wide variety of problems of varying size and dificulty, from trivially easy to nearly impossible. MicroTales can vary in the size of the map, the number of characters, the number of items, the types of actions that are available, and the number and complexity of goals that need to be achieved. The ability to generate a wide variety of problems has several advantages. By generating problems of diferent sizes and with diferent features turned on or of, we can make a controlled study of what makes experience management problems easy or hard to solve. Having many problems to train on also encourages learning-based approaches to generalize rather than overfitting to a few specific problems.
Active NPCs: One purpose of MicroTales is to fill a gap we perceive in the kinds of games available
to test computational storytelling approaches, namely story games with active non-player characters
(NPCs). Many story games, like the interactive fiction Zork [
Following Genre Tropes: While MicroTales is meant to allow a wide variety of problems, it is also attempting to follow the genre tropes of simple medieval computer role-playing games. This serves two purposes. First, it allows players of an interactive MicroTales game to leverage existing genre knowledge and minimize the amount of onboarding required to understand the game’s rules. Second, MicroTales is intentionally attempting to mimic a spread of “naturally occurring” problems from human-designed interactive narratives, complete with their irregularities. MicroTales is not meant to represent every conceivable situation or action. It is not meant to be the only type of benchmark problem that experience managers should be tested on. We are attempting to add to, not restrict, the variety of storytelling problems available for testing.
Wide Variety of Actions: Many planning and reinforcement learning benchmark problems have a
limited variety of action types available. For example, the classic Blocks World planning problem [
Soft Locks are Possible: A soft lock means that a solvable problem has been put into a state from which no solutions are possible. The possibility to soft-lock a game or puzzle makes it challenging because solvers must plan ahead. Solvers that rely on performing random actions—like Monte Carlo random rollouts or random exploration in MDP solvers—will need to account for soft locks. Many of the benchmark problems used to test classical planning algorithms do not create the possibility for soft locks. Stories often feature irreversible actions that require careful planning, which is why the possibility of soft locks is allowed, and even preferable, in MicroTales.
Deterministic Actions: Actions in MicroTales are deterministic, i.e., the exact resulting state is known before the action is executed. Determinism allows a wide variety of search and planning techniques to be applied. Real-world problems are not deterministic, but MicroTales is not designed to simulate a real-world problem; it is designed to simulate a game in a virtual environment where the experience manager has full control over the virtual world. While a MicroTales problem in isolation is defined deterministically, the larger problem of experience management in an interactive game may be viewed as nondeterministic since the player may take unexpected actions.
Complex Multi-Agent Interactions: Most problems will feature more than one character. Many existing AI benchmarks feature only a single agent or assume agents are strictly cooperative or competitive. In MicroTales, each character has their own goals, and they should aid or thwart one another to the extent that their goals align or diverge. One of the central challenges of storytelling is ensuring that each character behaves realistically while maintaining a story’s central structure. MicroTales provides an environment to compare emergent storytelling via multi-agent systems to centralized storytelling via planning.
No Model of Storytelling Enforced: MicroTales enables the study of what makes an interactive narrative believable, interesting, and fun. It tries to avoid enforcing any particular model of storytelling in its rules. Action preconditions are meant to be minimal requirements on when an action would be “physically possible” in the virtual world. For example, one character can only give an item to another if they are in the same location and if the giver has the item. The preconditions do not require that the receiver wants the item; it is up to a model of storytelling to determine whether this action makes sense. To study a model of good storytelling, it must be possible to generate bad stories. Many AI benchmark problems define success as reaching a clear goal via a shortest or lowest cost path, but many MicroTales problems will have “solutions” that are bad stories—that is, sequences of actions that achieve the story goals but are made of actions that are not believable, interesting, or fun. The quality of a MicroTales solution should not be judged solely on whether it achieves goals or on the number of actions it contains. A solution must be evaluated as a story, but MicroTales does not define what makes a good story. In other words, MicroTales defines a set of objects, actions, and goals so that two researchers can be said to be working in the same domain, but it does not define success in that domain.
Riedl and Bulitko [
Another challenge is the fact that the choices most convenient for an experience manager’s goals do
not always align with the choices that make sense for the NPCs involved [
Ramirez et al. [
One of our inspirations is the International Planning Competition [
TextWorld [
This section describes the design of MicroTales, centered around an example. A fuller set of definitions is in Appendix A. As we discuss in Section 5, the framework is a work-in-progress and we are interested in incorporating community feedback from the workshop.
At a low level, a running MicroTales environment is a deterministic state transition system. At any given time, the story world is in a state, which is defined by a complete assignment of values to a set of variables. There is a set of actions that, when taken, determine the world’s next state. An action has preconditions that limit when it can occur, defined by a proposition over the variables. An action also has efects that take place when it occurs, defined in terms of new value assignments to variables.
This generic framework does not assume any particular implementation. We want it to be possible
to implement MicroTales in everything from the Planning Domain Definition Language (PDDL) [
Our running example, illustrated visually in Figure 1, is based on the tale of Robin Hood. Figure 2 shows a problem definition in YAML, the primary input format we are considering; we will explain its components throughout this section. The sets of variables and actions are not specified directly in a problem file, but rather implied by higher-level elements. Among other components, a problem includes a map of locations, their types, and the paths between them, as well as a set of characters and their types. For example, in Figure 2, Sherwood is a location of type forest with paths to all other locations, and Robin is a character of type bandit.
Most variables are associated with a character, such as the character’s current location and held items. Most actions are also associated with a character; the basic actions available in every MicroTales problem are to walk between locations that have a path, give an item to or trade items with another character, and drop or pickup an item at the current location. For example, the Figure 2 problem implies a variable () an action (, ) with precondition () = ℎ and efect () = . The problem specification does not include an explicit notion of player character—this is specific to the use case—but typically, an interactive narrative will assign a player to choose actions for one character while an experience manager will control the other characters as NPCs.
A core feature of MicroTales is the ability to specify any number of extensions in a problem. An extension is a group of related problem elements that become available when an extension is included in a problem. Extensions are designed to allow additional types of actions in a problem, but doing so means enabling the location and character types that would make those actions possible and relevant.
For example, in the Figure 2 problem definition, the inclusion of the Theft extension implicitly adds the action take to the list of available actions, allowing characters with a Sword item to take an item from another character. Characters of the bandit type have the special ability to bypass the Sword requirement and take at any time. The bandit character type and Sword item are illegal in a default MicroTales problem and specifically made legal by the Theft extension, as their relationship to the take action is what gives them their unique functionality. Similarly, the problem can include chapel locations where the marry action can occur because the Marriage extension is enabled, and so on.
The initial state of the world is another largely implicit element except where overridden in the problem definition. In Figure 2, Robin’s starting location is set to Sherwood explicitly, but John’s, Marian’s, and the Sherif’s do not need to be specified because the noble and knight types default to the ifrst castle in the locations list, in this case Nottingham, when one is available.
Items in this case are also created from defaults; in this case, as a knight the Sherif starts with a Sword and as nobles John and Marian start with Coins. Items are not first-class elements in the way that characters and locations are; instead, they exist as variable values such as ( ℎ) = denoting a Coin existing in John’s left hand. If Robin takes the Coin from John, the efect is ( ℎ) = and () = , or ℎ() = if Robin’s left hand is full. The advantage of this scheme is compatibility with an implementation that must declare a finite set of objects at the beginning, such as a PDDL planning domain; the items do not need to have their own individual identities and can be “created” or “destroyed” at will, such as by crafting actions.
A component of the problem definition we have not yet discussed is goals. Unlike the other components, goals do not modify states, variables, or actions. Instead, they suggest objectives the individual characters should try to achieve, in the case of character goals, or that the story overall should try to achieve, in the case of story goals. A goal is declared with these components: the character who has the goal (omitted for story goals); a goal type; and a list of arguments.
For example, in Figure 2, the first line of the goals list declares that Robin has the goal ℎ(). The rich goal type takes a character as a parameter—in this case, Robin himself—and states that the goal-possessing character wants the parameter character to have Coins. Meanwhile, the last line of the goals list declares a story goal of (, ) giving the experience manager itself an objective—namely, a wed goal is fulfilled by having the parameter characters be each other’s spouse. Like character and location types, most goal types are enabled by extensions, such as wed having the Marriage extension as a prerequisite as it could not be achieved without Marriage-specific actions.
MicroTales does not define the relative importance of one goal to another, and when a goal can be achieved in multiple ways, it only defines ordinal preferences. For example, if a character has both rich and wed goals, MicroTales does not specify whether it is more important to that character to have Coins or marriage; this is up to the experience manager. Similarly, for rich, a character would prefer to have two Coins over one Coin, but it is not necessarily twice as good to have two Coins than it is to have one. Again, this is left up to the experience manager.
MicroTales tries to avoid imposing any particular model of what makes a good story. Some good stories may not achieve story goals, and stories that achieve story goals are not necessarily good stories. If goals can be ignored, why define them at all? First, MicroTales is meant to study the challenges of storytelling. Goals provide constraints that make planning a story challenging because the storyteller needs to look ahead to reason about what is and is not possible when deciding what actions to take. Second, in an interactive setting, goals are what will be communicated to players about what the characters want. Stories are meant to involve multiple active characters, so anticipating how non-player characters will act requires information about what they want.
Here are some example stories that could result from the Figure 2 problem. Recall that the story goal is for Robin Hood and Maid Marian to get married. We assume this problem is presented as an experience-managed interactive game where the player controls Robin Hood. walk(Robin, Nottingham) # Robin goes to Nottingham Castle. take(Robin, Coin, John) # Robin is rich, so he wants coins. attack(Sheriff, Robin) # The Sheriff drops Robin’s health to "hurt". attack(Sheriff, Robin) # The Sheriff drops Robin’s health to "dead".
This is a simple but unsuccessful story. Robin robs Prince John, but the Sherif of Nottingham executes Robin for his crimes. This example does not achieve the story goal and in fact soft-locks the problem, but if the problem is presented as an interactive puzzle it might be the outcome of a reasonable attempt by the player to achieve Robin’s goals. Suppose the player tries a diferent approach. walk(Robin, Nottingham) # Robin goes to Nottingham Castle. take(Robin, Crown, John) # Robins steals John’s crown. enthrone(Robin) # Robin is crowned king. arrest(Sheriff, Robin, Jail) # Lawful Sheriff throws Robin in jail. walk(Marian, Sherwood) # Marian on her way to release Robin. release(Marian, Jail) # Marian unlocks the jail. walk(Robin, Jail, Sherwood) # Robin on his way to marry Marian. walk(Robin, Abbey) # Robin goes to the chapel. walk(Marian, Abbey) # Marian goes to the chapel. marry(Robin, Marian) # Marian becomes queen by marriage.
This story is more interesting. Robin steals the crown and becomes king. The experience manager is faced with two possible responses from the Sherif: attack like in the previous story, or arrest Robin and move him to the jail. Killing Robin would end the story before the goal is achieved, but arresting him leaves it open for a happy ending later. Robin can’t do anything from the jail, but Marian comes to free him. From here, Marian can marry Robin to satisfy her ruling goal, which also satisfies the story goal. We consider this story more interesting because non-player characters take an active role.
While this makes a plausible story, it may not work when presented as a puzzle, since the player might wonder why Robin was allowed to take several actions in a row without any response from the Sherif. Next, we will consider a story that enforces strict turn-taking, always allowing one player action after one NPC action. enthrone(John, Nottingham) # John is crowned king. # The player chooses to wait, passing their turn. walk(John, Sherwood) # John on his way to marry Marian. take(Robin, Coin, John) # Robin steals John’s money. walk(Marian, Sherwood) # Marian on her way to marry John. take(Robin, Crown, John) # Robin steals John’s crown. walk(John, Abbey) # John on his way to marry Marian. walk(Robin, Nottingham) # Robin on his way to be crowned. walk(Marian, Abbey) # Marian on her way to marry John. enthrone(Robin) # Robin is crowned king. take(Sheriff, Crown, Robin) # Sheriff steals Robin’s crown. walk(Robin, Sherwood) # Robin on his way to marry Marian. walk(Sheriff, Sherwood) # Sheriff on his way to John. walk(Robin, Abbey) # Robin on his way to marry Marian. walk(John, Sherwood) # John on his way to the Sheriff. marry(Robin, Marian) # Marian becomes queen by marriage.
John starts by achieving his ambition to become king. He and Marian then set of in the direction of Fountains Abbey for their wedding. On the way, John gets robbed by Robin Hood. The player waiting for John to pass by is a prime example of a player anticipating active NPCs. Robin then goes to Nottingham Castle and crowns himself king before the wedding can take place. The Sherif takes the crown from Robin and goes to Sherwood Forest hoping to give the crown to John. Robin makes his way to Fountains Abbey and marries Marian, achieving the story goal.
In this example, we assume characters only witness actions that occur in their location (except enthrone, which gets announced to everyone throughout the kingdom). The Sherif is not aware of Robin’s crimes, since he was not in Sherwood Forest during the robbery. This model of limited observability is not required. MicroTales does not model character beliefs; that is left to the experience manager, which is free to use this or any other model. For this problem, we think it makes the characters seem more realistic, and it adds a new dimension to the puzzle by encouraging Robin to avoid witnesses.
Given the Sherif does not know about Robin’s crimes, it may seem odd that he would take the crown. The Sherif thinks he is stealing, which makes him a criminal and goes against his lawful goal which calls for minimizing criminals who walk free. The Sherif takes the crown because he hopes to return it to John so that John can again take the throne. After returning the crown, the Sherif plans to arrest himself, satisfying all his goals, though the story ends before he can complete his plan. Does it make sense for the Sherif to arrest himself? This is up to the experience manager.
Notice also how the Sherif and John meet in Sherwood Forest. According to our earlier assumptions about belief, the Sherif saw John leave for the forest, but did not see John continue to the Abbey, so the Sherif wrongly believes John is in the forest. John did not see the Sherif go to Sherwood, so John wrongly believes the Sherif is at Nottingham. Luckily, these two meet by chance in the forest despite their wrong beliefs thanks to some coordination by the experience manager.
Our intention in presenting this early-stage work to the Intelligent Narrative Technologies community is to elicit discussion on how we can make the final benchmark relevant to a suficient breadth of experience management approaches and reusable for other narrative AI researchers. The following are some topics that we are especially interested in presenting for feedback.
One point of discussion is the appropriateness to the target audience. The design commitments of
MicroTales preclude its relevance to certain types of narrative generation and experience management:
Some experience management approaches focus on tailoring a more reactive game environment to
player preferences [
A design challenge we have faced is the tension between the objective to avoid enforcing a model
of storytelling, and the need to articulate character goals. Although they do not appear in action
preconditions and in theory can be ignored at an experience manager’s convenience, there are some
variables in our state models that represent social rather than physical properties. For problem, in
order to define the avenged character goal, which says that a character wishes death upon someone’s
enemies, we needed to introduce a relationship variable that tracks friendship and enmity and an
explicit definition of what causes those relationships to change. We are looking to find the right balance
between defining benchmarks that can clearly express social goals, and ensuring that diferent narrative
approaches can override these definitions with their own models of phenomena like interpersonal
relationships [
A notable exclusion from our design so far is actions that exist solely for the purpose of communication
between characters. Fully open-ended dialog is out of our scope; it would make the action space vast
or infinite and sometimes trivialize the situations we want to study where players and experience
managers must infer each other’s intentions from their decisions [
Our next step after this workshop will be to leverage community discussions to reach a stable version of MicroTales. We will then create tools implementing the framework. One tool will be a procedural generator that can create MicroTales problems scaled to a desired number of locations, characters, and extensions. Others will include an API for running a generated problem with arbitrary player and experience manager agents; sample implementations of random and human-controllable agents as a template for implementing new agents; and a graphical interface to facilitate experiments with human participants, similar to Figure 1. Our latest work will be available on the project webpage at http://cs.uky.edu/~sgware/projects/microtales/.
In the longer term, we will use our benchmark to study story generation and experience management approaches from a variety of angles. In ofline benchmarking, we can compare the scalability of narrative planning algorithms and heuristics by varying the size and complexity of problems. In interactive experiments with human participants, we can change the game over multiple within-subjects trials so a player reasons about new situations instead of memorized ones. We will use these experiments to investigate what makes an experience manager efective at balancing properties like cohesive story structure, achievement of story goals, player agency, and character believability.
This material is based upon work supported by the U.S. National Science Foundation under Grant No. 2145153 and the U.S. Army Research Ofice under Grant No. W911NF-24-1-0195. Any opinions, ifndings, conclusions, or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation or the Army Research Ofice.
The author(s) have not employed any Generative AI tools.
This appendix is a tentative listing of the full collection of MicroTales elements; refer back to Section 4 for how they appear in a problem file and how they are used to define gameplay. This version of the definitions is informal and compact to fit the page limits. A more detailed version can be found at https://github.com/sgware/microtales-doc, which will be updated as the project is developed. As shorthand, in definitions of parameterized elements—actions, goals, and variables—assume parameters starting with are characters, are item constants, and are locations.
sorcerer characters; ℎℎ variables; CursePotion items; ℎ and ℎ goals; , , , and actions camp locations; bandit and sorcerer characters; variables; HidePotion items; ℎ actions sorcerer characters; TeleportPotion items; actions bandit characters; Coin and Sword items; ℎ goals; actions graveyard locations; cleric and sorcerer characters; BanishPotion and RaisePotion items; ℎ and , , and actions knight characters; ℎℎ variables; Sword items; ℎ and ℎ goals; , , , and actions
MicroTales elements cannot be created or destroyed, but items are not first-class elements. Rather, they are a group of constants, special values that can be assigned to some variables. Each character has left and right hand variables, and the values that can be assigned are the item constants or Null to represent holding nothing. This means each character can hold zero to two items.
Table 2 lists the item constants along with a summary of associated uses. Items listed as “potion” in the table can be created by , and “metal” by . See Section A.7 for full details about how actions interact with items. All items have extensions as prerequisites; refer back to Section A.1.
MicroTales problems take place on a map made of one or more locations. A location has a unique name and a type. A problem must define at least one location, and how locations are connected via paths. Paths are symmetric and are used to determine where characters can .
Table 3 describes each location type. The cave, crossroads, forest, and village types can be used in any problem; the rest are enabled by extensions as listed in Section A.1. Locations typically have actions associated with them; these are elaborated in the Section A.7 action definitions. location type camp castle cave
Used to and . 1–3 paths.
Used to and . 2–4 paths.
Used to , , and . 0–4 paths.
Used to and . 0–2 paths.
Used to , , and . Has variable. Exactly 1 path.
Used to . 1–2 paths.
Used to . 1–4 paths.
Used to and . 0–4 paths.
Used to . 1–2 paths.
A character has a unique name and a type. Table 4 defines the character types. Default locations initialize () to the first defined location of that type. Default items initialize () to that item constant. Some character types have special abilities that override the action preconditions in Section A.7. The is available in all problems; the rest come from extensions in Section A.1.
Starts at camp or crossroads by default. Can without Sword and ℎ without HidePotion. cleric Starts at chapel by default. Can ℎ or ℎ without potions. Can .
goal forbidden. knight Starts at camp or crossroads with Sword by default. Can without Sword. merchant Starts at market or crossroads with Coin by default. Can’t . goal forbidden. noble Starts at castle or chapel with Coin by default. Can ℎ without
CharmPotion. peasant Starts at village or workshop by default.
sorcerer Starts at laboratory or graveyard by default. Can without laboratory.
A variable is identified by a name followed by an ordered list of arguments. Table 5 lists these variables. It describes the parameter types, the values that can be assigned to the variable, and default initial value. If the default value is an item constant that requires an extension and the problem does not enable that extension, the default value is Null instead. Some character definitions also override default values. Variables are used to define the preconditions and efects of actions, as well as goal fulfillment. More details are in the definitions for those elements. The , , , ℎ, and ℎ variables exist in all problems; see Section A.1 for the extensions that enable the others. variable () ℎℎ() () () () maps a jail to Boolean, default False single character, default Null maps two characters (asymmetric) to Friend, Null (default), or Enemy maps character to item, default Null maps character to another character (symmetric) maps character to Boolean, default True
Table 6 defines the possible goals. The first column is the goal with name and arguments. The second column describes the goal’s objective. The , , , , and goals may be added to any problem; the others come from extensions.
There are additional goals that always apply implicitly. First, if Sickness or Violence is enabled, characters prefer ℎℎ() = Healthy over Hurt, Hurt over Dead, and Ghost over Dead. Second, if Undead is enabled, each has a goal that behaves as () when ℎℎ() = Ghost. goal (, ) () () ℎ() () () () () ℎ() () ℎ() (1, 2)
Actions have a name and arguments. Table 7 lists the actions and their preconditions and efects. We use shorthands as follows.
“Must” implies a precondition; other statements imply efects unless otherwise noted. For a character to have an item means () = ∨ ℎ() = . To lose means there is an efect of or ℎ no longer being . To expend must have and loses it. Available space means () = Null ∨ right(c) = Null. To gain means the value becomes if it was Null, otherwise the ℎ value becomes . Given a location rather than a character, these terms apply similarly to ().
We say a character or location “is” (for preconditions) or “becomes” (for efects) a constant, e.g., Healthy, when the relevant variable, e.g., ℎℎ(), takes that value. We say is “at” (precondition) or “moved to” (efect) when () = . To raise or lower ’s health is to change ℎℎ() by one stage along the ascending ranking Dead, Hurt, Healthy if possible, no change otherwise. Likewise, the “relationship of to ′” raises or lowers ℎ(, ′) along Enemy, Null, Friend.
If a variable would be checked or modified by an action while not enabled by an extension, that part of the action description is ignored. Some character abilities override preconditions; see Section A.4. Unless otherwise specified, assume actions require characters to be alive; actions with two characters require their to be the same, and the second character to be .