Camelot is a modular customizable virtual environment that is inspired by the needs of current and previous narrative generation research. Camelot is meant to facilitate interactive narrative prototyping, controlled comparisons of different systems, and reproducing and building on the works of others. It provides a 3D presentation layer that is fully separable from the narrative generation system that controls it. This allows any application, AI algorithm, or technology, written in any programming language, to connect and use Camelot to visualize their interactive narratives. In this paper, we introduce Camelot and its capabilities, and provide some details on how and to what extent it can be used to benefit the interactive narrative community.
Camelot is a modular and customizable interactive narrative environment that provides a sandbox to act as a presentation layer for any narrative generation system. Camelot is a real-time 3D third-person virtual environment that takes place in a Medieval fantasy setting and includes customizable characters, places, and items. By using this environment, researchers can build and test prototypes faster and easier.
By providing a fully separate presentation layer, Camelot is independent of the programming language or technology used by the narrative generation system. This separation of concerns lets Camelot provide a standard of presentation that can be shared among the interactive narrative community. Through this standard, highly different AI approaches can be meaningfully compared to one another and evaluated in the same context and with the same subjects. Moreover, this standard can facilitate researchers to reproduce and build upon the works of others.
In this paper, we provide some details about the accessibility and capabilities of Camelot. We hope that it may reach and assist many researchers in their efforts to contribute to the interactive narrative and AI community. In section 2, we will discuss the design of Camelot to support research and simplify its application. Section 3 presents the potential applications of Camelot and several proof of concept games that are free to access and play. Section 4 discusses our previous attempts and future plans for community outreach, and finally, section 5 presents the conclusions.
2
2.1
To generate an interactive narrative, Camelot communicates
with an experience manager (EM)
A Camelot EM can be written in any programming language that has standard input and output capabilities. In fact, all communications between Camelot and the EM are transmitted via the standard I/O, e.g. System.out.Println in Java, print in Python, or Console.WriteLine in C#. Camelot has a large list of available commands that can be used to control its UI, characters, environments, etc. These commands are referred to as actions and have the following format1:
To execute an action, an EM can append start to a command and sends it to Camelot. Camelot then attempts to execute that command and responds with the same command with a 1For a complete list of actions, the description of their function, and the details of their arguments, please refer to the actions page of the documentation website (link provided at the end of the paper). succeeded prefix, when the execution is successful, or otherwise with an error or failed prefix. The response message starts with error if the action could not be started, due to, for instance, insufficient or incorrect arguments, or targeting characters, items, or places that were not instantiated beforehand. The response message starts with failed if the action execution fails after it was started, e.g. characters trying to walk out of a locked prison cell, player character walking interrupted by user input. Whether an action fails with an error or failed message, a short message is also appended that describes the reason for the failure. The EM can use these responses to properly sequence the commands its wants to visualize.
An EM can also append stop to a previously started command to stop its execution. In that case, Camelot responds with a failed message and does it best to revert back any changes made by the execution of that command. For instance, if a character is in the process of exiting a door after opening it, the door is closed as a consequence of stopping the Exit command.
Many Camelot actions are comprised of smaller units that are managed by Camelot without concerning the EM. For instance, when the EM calls the Exit command, Camelot makes the specified character walk to the specified door, open the door, and go through the door. Camelot then closes the door and makes the screen fade out. In doing so, Camelot does not burden the EM with small units of work that can be combined into a single action. In this case, walking to, opening, and closing a door, as well as having the screen fade out are all also available to the EM to execute individually.
Furthermore, the EM is free to define any level of action abstraction by managing the execution of a sequence of Camelot commands. For instance, in an EM, we can define a Shop function that when called, runs a sequence of Camelot commands that make a character walk to a merchant and take an item from them.
Camelot manages simultaneous actions that use the same assets. Camelot locks characters, furniture, and items when an action starts using them. All other starting actions that target those objects need to wait for the release of that lock. For instance, assume that an EM simultaneously asks both Tom and Jane to go to a merchant to take an item by calling Take(Tom, Item, Merchant) and Take(Jane, Item, Merchant). If Tom reaches the merchant first, they start taking the item, while Jane walks to the merchant and waits. At this point, the EM could, for instance, decide to stop the command Take(Jane, Item, Merchant) upon receiving started
sumes and since items cannot be in two places at once, the item disappears from Tom’s hand and is placed in Jane’s.
When the player interacts with the environment, Camelot sends messages with an input prefix to notify the EM. These commands include any interactions with the objects or nonplayer characters in the environment, dialog choices, keyboard inputs, or specific changes in the position of the player character.
e.g. input arrived Hero position Castle.Door input Draw Hero Sword
input Key Inventory
Since the EM is fully separate from Camelot, it is not dependent on any specific algorithms or technologies, and it does not even have to be deployed on the same physical machine (following the architecture used by Young’s Mimesis (2001), and many other similar systems). The only connection between Camelot and an EM are the simple strings of texts that are human readable and easy to understand. 2.2
While a user is playing an interactive narrative, Camelot generates a list of all its communication messages with the EM, as well as their time stamps. Camelot gameplay logs capture all the events that occur during a playthrough via the user input or the EM, including when actions start, succeed, or fail. These files can then be used to almost accurately reproduce and analyze a user’s playthrough and the story that unfolds based on their choices. A log file’s information and file size make it very efficient to transfer and collect a data set of user gameplay, which can benefit data-driven storytelling systems. We also provide an application that can be downloaded from Camelot’s website and used as an EM to almost accurately recreate a playthrough from a log file. 2.3
Camelot comes with a set of characters and places that can be customized as intended. To create various characters, the EM can choose from different body-types, hair styles, hair colors, eye colors, skin tones, and outfits. Figure 2 presents some examples of these characters. Camelot also provides many small, contained, pre-built environments, named places, that can be instantiated to create the story world. Figure 3 presents some examples of these places. Each place comes with a set of interactive furniture, such as shelves, chairs, tables, or cauldrons, that can be hidden or shown depending on the context of the story.
Camelot does not impose any restrictions on where the doors of each place lead to. This enables Camelot’s world creation to be modular and allows any configuration of the space. More specifically, every door leads to an area outside the place obstructed by white clouds. When a character exits through a door, they stay behind that door and wait for the EM to change their position. The EM creates the illusion that doors are connected by having a character enter through one door immediately after leaving through another. 2.4
Camelot only acts as a presentation layer to an EM. Since different AI technologies, e.g. planning and machine learning, have very different representations of state, Camelot does not require the EM to use any particular state representation. In fact, to a large extent, Camelot does not keep track of the state of the world.
For example, Camelot has a UI element named the List that can be used to represent character inventory (Figure 4). It is in fact the List and not a list, as in there are not different instances of it for different characters. Again, it is the EM that decides what to put in the list when to display the list (e.g. to show the inventory of a specific character).
Furthermore, Camelot also has no notion of the player. More specifically, any of the instantiated characters can be controlled by mouse and keyboard as long as they are the camera focus. We will discuss the camera focus later in the Camera Control subsection. Any references to the player character in this paper refer to the one currently being controlled by the user.
There are some exceptions to the stateless nature of Camelot, specifically the physical position of characters. For instance, if a character is sitting on a chair, an action that attempts to make another character sit on that chair will fail with a message stating that the chair is already occupied by another character.
Moreover, many character actions require the character to first walk to the target. Since places are independent contained environments, the corresponding actions will fail if a targeted character moves to a different place.
However, this is not true about items. All actions that
target items will teleport the specified item to the position
required by the action. For instance, if an item is on a shelf
and the EM asks a character to take the item out of their
pocket, the item will instantaneously disappear from the
shelf and appear in their hand. In addition, the SetPosition
command can be used to instantaneously teleport a
character or item to any other position within any place. Therefore,
Camelot can also be adopted in interactive storytelling
systems with a weak or non-existent sense of permanent state,
such as purely language-based interactive narratives (e.g.,
neural language model based storytelling systems such as
Affordances are the actions a player can choose from in an interactive narrative (not to be confused with Camelot commands also called actions). In Camelot, affordances can be simply described by the EnableIcon command. EnableIcon can be used to describe an affordance that can be performed to a character, furniture, or item. For instance, it can be used to allow the player to click on a chair to sit on it.
There are several important things to note about
EnableIcon. When EnableIcon is used for a character, furniture, or
item,
• The object will be highlighted when the user hovers the
mouse over it.
• If the user right-clicks on the object, a radial menu is
shown that presents all available interactions that can be
performed on that object. Each option can be presented
with a title and an icon. Camelot provides a large variety
of icons that can used for this purpose. Figure 1 presents
an example of a radial menu.
• When the user chooses to interact with an object, Camelot
only responds by sending an input message to the EM.
Camelot does not start any action unless directly
instructed by the EM. This grants the EM full control
over what to do next in response to user interactions and
whether to accommodate or intervene (see
As an example if Camelot receives EnableIcon(SitDown,
• When the user right-clicks on the chair, they see an option with title “Sit on the chair” and icon Chair. • If the user clicks on the chair, Camelot sends the following message to the EM: input SitDown Player Room.Chair.
This notifies the EM that the Player has chosen SitDown. • The EM can then choose to make the player character sit on the chair by sending start Sit(Player, Room.Chair) to Camelot, or it can choose to show a message to the user like “I am not tired right now!” 2.6
A large set of available Camelot commands can be used to animate characters. For instance, characters can open doors or chests, sit on chairs, or sleep on beds. These animations can be used as a visual response to user interactions in form of player character actions, as well as non-player reactions to those actions, e.g. clapping, laughing, waving, etc.
In addition to these animations, there are several
expressions that can be used to express character emotions, which
are happy, sad, angry, scared, surprised, and disgusted. The
SetExpression command changes a character’s facial
expression as well as their idle animation to reflect that emotion.
Character expressions can also change during dialog to
display their reactions to dialog choices. These expressions can
be used by believable agent research that model affect
Camelot does not support graphic depictions of strong
violence2 or inappropriate nudity in order to make
interactive narratives designed with it easier to approve by groups
like university Institutional Review Boards (IRBs). Several
Camelot games have been used in IRB-approved studies
Camelot provides several general UI elements to use in a narrative. In addition to the radial menu, the list window can be used to present a list of items to interact with, e.g. displaying the inventory of a character or container, RPG character statistics, a set of skills to purchase, etc., and the narration window can be used to present simple text.
The dialog window provides interactive dialog that can be
configured with character portraits and links embedded in
the text that the user can click
Camelot provides different options for controlling the camera, which can be used via SetCameraFocus, SetCameraMode, and SetCameraBlend commands. At each moment, 2Characters can attack using the Attack command presented by swinging their arm while holding an item such as a sword or hammer. the camera can be focused on a character, furniture, or item using SetCameraFocus. If the focus of the camera is a character and the input is enabled (via the EnableInput command), the camera follows that character’s movements, and that character can be controlled by mouse and keyboard. We must note that the input can also be disable at times, for instance, during cutscenes.
SetCameraMode can be used to switch between three camera modes in real-time. The follow camera mode displays a third-person over-the-shoulder view of the character that is the focus of the camera, e.g. as in action RPG games. This mode can only be enabled if the camera focus is a character.
In track mode, a top-down view of the place is displayed, e.g. as in point-and-click adventures. As the character moves, the camera changes rotation to keep the character at the center, and if the character moves too far, the active camera switches to a different camera of that place that has a better view of the character.
Finally, the focus camera mode, presents a front close-up of the camera focus. This mode can be used to display character expressions or temporarily shift the focus of the user to a specific item or furniture that can be interacted with.
When the EM changes the camera focus or mode, the view transitions from the active camera to the new focus or mode. The duration of this transition can be controlled via the SetCameraBlend command. This command gives the EM more freedom to control the camera and create dramatic shifts or cuts during cut-scenes. 2.9
Camelot is published under the Non-Profit Open Source License 3.0. This license allows Camelot to be used for personal, professional, and academic projects at no cost. It is only necessary to acknowledge the original project and creators in any derivative works3. Currently, the executable can be downloaded and used on Windows and Mac operating systems. The source code is also available to download. However, the copyrighted assets are not distributed with the source, and can be purchased from the Unity Asset Store at additional cost. The link to Camelot’s documentation and download are presented at the end of this paper.
3
Camelot can benefit a wide range of AI research including but not limited to:
3We ask users to cite this paper in any published works that use
Camelot.
• Automatic story generation and agent simulations
using neural networks, reinforcement learning, and other
machine learning algorithms
4
Our hope is to encourage researcher to adopt Camelot in
their relevant research. In previous years, Camelot was
introduced in the Playable Experiences track of AIIDE
Our focus for the future of Camelot is to organize the Interactive Narrative Challenge (INCH). The purpose of INCH is to solicit AI EMs from many interactive narrative researchers and present their interactive narratives to human judges for qualitative and quantitative evaluation. INCH provides a practical context for controlled comparisons of interactive narratives across different systems. INCH will feature awards for many contributions in various aspects of a narrative, including use of narrative devices, e.g. flashbacks, foreshadowing, suspense, etc., story coherence, player freedom, replayablility, character richness, and so on. As a result of INCH, researchers will have access to free evaluation of their work by human players, as well as the dataset of the logs of all playthroughs. These logs can be further used to analyze user experience or to train a data-driven AI narrative system.
5
Translating AI algorithms and technologies into a userfriendly, visual interface is almost always a step in evaluating narrative generation systems via a human audience. The purpose of Camelot is to provide a modular, customizable, and easy-to-use virtual environment for researchers to visualize their stories. Camelot is fully independent of the experience manager that controls it, which allows any programming language or algorithm to easy connect and take advantage of Camelot. In addition, it enables the controlled comparison of drastically different narrative generation systems and allows researchers to reproduce and build on the work of others.
We plan to take advantage of Camelot in the Interactive Narrative Challenge to encourage researchers to submit their interactive narratives and to provide them with access to qualitative and quantitative evaluation of their work by human judges.
Camelot is an ongoing project and we plan to improve and expand it to support future interactive narrative authoring techniques.
You can view a comprehensive interactive documentation website for Camelot at:
www.cs.uky.edu/ sgware/projects/camelot
The documentation provides details on how to use Camelot and its commands, as well as showcasing its characters, places, items, affordances icons, visual effects, and sound effects. You can also download Camelot for Windows or MacOs from the documentation website.
The website provides several applications that can be used as example EMs for Camelot. First, CamelotReplay is an application that reproduces a playthrough from a log file. Next, there are simple EMs that give beginners a place to start working with Camelot. They showcase a character moving from one place to another, trying out different outfits, and buying an item from a merchant. Finally, there are also two full interactive narratives, Murder in Felguard and The Three Kings, that showcase the wide range of things you can do in Camelot.
The development of Camelot was supported by the University of New Orleans and the University of Kentucky. We thank Edward T. Garcia, Rachelyn Farrell, and Porscha Banker for their insights and assistance with the project. Harrison, B.; Purdy, C.; and Riedl, M. O. 2017. Toward automated story generation with markov chain monte carlo methods and deep neural networks. In Thirteenth Artificial