Social simulation has been a popular domain in computational creativity for decades. However, while it has been used in applications that are easily digestible by end users (e.g., stories, games, theatrical performances, audio plays), it has typically not been modifiable or authorable for people who are not the original developers. Towards addressing this, we present Kismet, a small social simulation language. While Kismet is not as powerful as other social simulation approaches, it leverages computational machinery (such as an inheritance system) and is authored using natural language inspired syntax that is designed to be end user facing. The ultimate goal of Kismet is to facilitate the authoring of scenario content modules, such as those used in table-top role-playing games.
Since Meehan [
The use of artificial techniques to enhance and improve table-top role playing games (TTRPGs)
is a recent development, with approaches ranging from using constraint satisfaction to perform
character and relationship construction [
Toward the goal of making an approachable social simulation system to support other creative
endeavors (TTRPGs, videogames, etc.) that are authorable and modifiable by people who do
not have (or are in the process of acquiring) Computer Science Ph.D.’s focused on artificial
intelligence we present Kismet – a small social simulation language. Kismet is developed with
an eye towards languages like Tracery [
© 2020 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
it is relatively simple. It does not require a specialized tool to author for [
In this way, Kismet serves as a step towards accessible—yet expressive—social simulation. Its natural language inspired syntax excels at allowing authors to define the types of actions that simulated characters can engage in, and the social, cultural, and personal influences (referred to in the system as proclivities) that might sway a character to select any given action over another. Running the simulation yields sequences of character actions that are locally believable (i.e., any given action makes sense), though might lack global coherence (i.e., the system has little machinery for maintaining direct cause-and-efect relations between actions). However, when used in conjunction with an automated story-sifter or a human storyteller as typically found in table-top role-playing games, Kismet’s action sequences become the atomic raw material that other systems—human or otherwise—can embellish upon. Though not discussed in this paper, exciting future work remains to explore Kismet’s afordances as a tool for co-creation and shared authorship.
In the rest of the paper, we first discuss Kismet in context with existing social simulation approaches. We next describe its approach to simulation at a high level. Finally we delve into the syntax and semantics of the language with some worked examples.
We motivate this work by providing an overview of inspirational previous work, and discuss how it helped inform the development of Kismet.
Kismet is meant to be a simple way to author and represent social simulations. By social simulations, we refer to representing agents (typically afectionately known as Non-Player Characters or NPCs) whose behavior is at least in part modeled by social considerations. There have been many previous explorations of social simulation research with a diverse range of application areas.
Social simulation techniques have been applied in many serious games projects, or other
applications with pedagogic or training goals. Stacey Marsela’s PsychSim [
Social relationships are at the heart of many narratives, and as such social simulation is
frequently a technique used to create or foster dynamic and compelling interactive emergent
narrative experiences [
These too have frequently been made with pedagogic aims; FearNot! [
Indeed, some interactive experiences revolve entirely around playable social interactions.
Some games, such as the wildly popular Sims [
In comparison to the information-dense simulation system of Prom Week, which made use of thousands of “social influence rules” to power its characters, or the powerful afordances of ABL to simultaneously enforce Façade’s strong narrative while adapting to player input, Kismet is very simplistic. However, we claim that this simplicity is one of Kismet’s greatest strengths, and certainly what makes it well suited for use in casual creator systems more so than powerful-butweighty systems as CiF and ABL. Although Kismet has no mechanisms for ensuring satisfying dramatic arcs, it allows for users to quickly and easily spin up and simulate virtual characters governed by simple social laws. “Good” story content can be divined either through the use of story sifters, or by embedding Kismet into a larger playable experience. And though tools like Ensemble permit a rich interplay of individual social forces, it typically demands a significant authoring efort before character’s dynamic behaviors begin taking shape. Though driven by less sophisticated motivations, characters in Kismet can begin acting believably with a fraction of the initial authoring efort, resulting in a much less daunting barrier to entry for the end user.
Though Kismet does not seek to aim to emulate the fine degree of expressivity of these other systems, other inspirations from these systems remains as future work. Namely, many of these existing systems have companion authoring tools that enable non-programmers to create content for them. Kismet has no such authoring tool, but developing one would eliminate the need to author syntax by hand, and would no doubt be a boon to its use as a casual creator for non-technical users.
Despite the popularity of the casual creator framework, there has been a relative dearth of
languages devoted to use by casual creators. Tracery [
Given the lack of casual creator languages, it is hard to draw many conclusions, but a common
thread is the use of natural language syntax – used in both Inform 7 [
Table-Top Role Playing Games (TTRPGs) have recently become a focus for artificial intelligence
techniques. Bardo [
We imagine one way that Kismet will be a valuable contribution to AI for TTRPGs is in its capacity to facilitate co-creation. TTRPG game masters can author Kismet content scenarios to generate small worlds with social dynamics, suitable for quickly creating environments replete with characters, relationships, and backstories that players can explore. Though not a traditional TTRPG, mediated exploration of generated worlds such as this is akin to the experience Bad News, which we describe below.
Perhaps Kismet’s greatest influence is Bad News [
This piece has been performed internationally, at game festivals, film festivals, computer science conferences, universities, and the San Francisco Museum of Modern Art. It has won awards at both the ACM SIGCHI conference and the IndieCade festival of independent games. It appears to be an experience that captures the imagination on both a technical and emotional level. However, one of it’s greatest strengths—the spectacle of a computer simulation and three humans in the roles of Actor, Wizard, and Guide creating and portraying a unique, ephemeral world for each player—is also one of its greatest limitations. The game is an installation piece, and as such requires a hefty amount of logistics to be performed, severely limiting the number of people who could ever experience it.
We hope that Kismet’s potential as a co-creative partner can serve as a first step towards a “Bad News: The Home Game.” There are many challenges to creating such a system. However, giving players the ability to quickly and easily develop their own social simulation modules is an important first step to achieving it. To do so will allow players to personalize their simulated worlds with virtual denizens that think about, care about, and behave in accordance to values aligned with the types of story-worlds any given end user hopes to capture.
The goal of Kismet is to be a small language that supports small social simulations. The core entities of the Kismet social simulation are Characters and Locations.
Unsurprisingly, characters are the most important entity found in Kismet. A Kismet character is a set of traits and statuses that influence their actions and the actions that others take towards them. Traits and statuses are efectively the same thing – a single predicate that is attached to a character that influences how likely they are to take certain actions – with the key diference being that traits are inherent to a character (i.e., they are attached to the character when the character is instantiated) while statuses are (and must) be applied to a character during the simulation.
Traits come in two varieties – default and random. Default traits are traits that are inherent to all characters in a simulation. These can be thought of as encoding societal norms – e.g., people are generally not rude to each other, or people avoid incestuous relationships. Random traits are the spice of the simulation – they provide diferent behavioral patterns that let characters have personality and diferentiation – and each character is assigned a random number of them. This random number is configurable by an end user / module author, but in practice we have found three to five to be an efective number that allows for enough personality, while still being understandable by an end user.
Some traits do not make sense in conjunction with each other – e.g., a character can not be both a drunkard and a teetotaler or a character can not be both serene and rage-filled simultaneously. To account for this, traits can be stated to be in opposition to each other, so that a character can have only one of those traits.
The other major class of entity are locations. Locations are where the simulation takes place. Each location has a number of roles that the location supports, each of which can support a diferent number of characters. E.g, a grocery store might have one manager, between three and five grocers, and up to 30 patrons. Some roles are cast upon instantiation of the location (which is the instantiation of the simulation) while others are cast and recast every tick of the simulation. Some actions are only available to certain roles, and only when the character enacting that role is at the location where they enact that role – e.g., a character might perform the action “tend bar” if they are enacting the role of bartender at the bar where they work.
To save on duplication of efort, roles have a form of inheritance. Roles can inherit all of the preconditions and tags of their ancestors, minimizing the burden of authoring many diferent roles. E.g., the role of b a r t e n d e r might inherit from s t a n d a r d - l a b o r which inherits from l a b o r . l a b o r might have the tag w o r k which s t a n d a r d - l a b o r and b a r t e n d e r both inherit. Consequently, perhaps s t a n d a r d - l a b o r might have the precondition that the character enacting the role must be older than 18 years old. This allows for a split in the inheritance of l a b o r where c h i l d - l a b o r inherits from l a b o r but requires the character be less than 18 years old.
These pieces come together in the simulation. At initialization, a number of characters are instantiated – and their personality traits are chosen. Then the locations are spawned – each of which cast their initial roles. During each tick of the simulation, the characters choose which location they should go to. Once there, they choose which action to take based on their traits, statuses, and the other characters (who may be colocated, located elsewhere, or unspecified).
The actions are the most important aspect of the simulation. They are how the characters and their relationships evolve during the course of the simulation. It is the history of these actions and the resultant relationships that form the material that end users mine from. Each action has a number of tags that describe how the action should be interpreted by the characters. E.g., the action g o s s i p might have the tags t a l k and r u d e . A character with the trait i n t r o v e r t might be less likely to take t a l k actions, so they would be less likely to take the g o s s i p action. Similarly, a p o l i t e person may be less likely to take r u d e actions. Thus, a p o l i t e i n t r o v e r t would be highly unlikely to g o s s i p , while an i m p o l i t e e x t r o v e r t would be more likely to take the action.
While the tags – in concert with the character traits – afect how likely a character will be to take a certain action, there are also binary conditions that afect whether a given action can even be attempted. Actions all have an enactor that needs to be cast, but they can have any number of targets – those who the actions are performed upon – and subjects – those who the actions are about. E.g., the g o s s i p action would have the enactor g o s s i p e r , target g o s s i p e e , and subject g o s s i p e d - a b o u t .
The action also has a set of preconditions that must be met for the action to be possible. These conditions can be of: • Unary Arity – is a fact true about a single character – e.g., A is d r u n k • Binary Arity – i.e., is there a relation between two characters – e.g., A l i k e s B • Arbitrary Arity – is there a relation that holds over multiple characters – e.g., l o v e t r i a n g l e (A,B,C) All of the preconditions must be true, i.e. they are all connected via logical and. To author an or, one would need to create two nearly identical actions that difer only in those preconditions. The results of the action are two-fold. First, the action occurs and is recorded in the history of the simulation – which can be used by end users as well as the simulation to check for certain relationships. The actions are also observed by bystanders, based on how noticeable they were. Two characters chit-chatting is not particularly engaging, so it might not be observed, while two characters getting in a fistfight is going to be observed by everyone at the same location. Second, the actions can add or delete statuses and relations. E.g., the action d r i n k might apply the status d r u n k which can have downstream impacts, while the action s o b e r - u p might remove the d r u n k status. Similarly, the action of A f l i r t ing with B might add the relation B l i k e s A, while the action b r e a k - u p might remove the relation d a t i n g .
The aim of these small simulations is to provide a scafolding for further downstream processes (e.g., Table-Top Role Players) to embellish upon. This leads to a design decision where the characters have somewhat caricaturish personality traits – e.g., a drunk is much more likely to go and drink at a bar – and the actions that the characters take are to be seen as simplified stand-ins – e.g., “drink at bar” should not be interpreted as a person getting a single drink, but rather could be interpreted as “wasted the afternoon getting drunk at the bar.” Furthermore, the goal is that the language allows for end users to modify scenario modules, and possibly create their own. To this end, the language has been designed to be approachable, using some standard programming syntax, but more heavily inspired by natural language approaches like Imaginarium and Inform 7.
In this section we will describe the language – first starting with some syntax. Some notes about Kismet syntax: (1) variables are upper cased, (2) definition names are lower cased, (3) lists are separated with commas (4) the components of a definition are separated with semi-colons , and (5) definitions are ended with periods. Argument lists of characters use special syntax to define who is the enactor ( > ), the target (< ), the subject (̂ ), or an action (* ). Also, anything in bold below is a keyword in Kismet.
Random selections are contained in square brackets:
or text strings separated by | ’s [ h e a d s | t a i l s ]
Text strings can reference Tracery grammars (in separate files) using the standard hashtag syntax: [ # c o i n t o s s # | # d i c e r o l l # ]
For ranges of numbers users can specify the shape of the probability distribution using
the symbols _ - ̂ . [
A location is specified with the l o c a t i o n keyword: l o c a t i o n LOCATION-TYPE: s u p p o r t s : LIST OF ROLES; n a m e : TEXT; i n i t i a l i z a t i o n : LIST OF CAST; e a c h _ t u r n : LIST OF CAST. [ N U M B E R ] N A M E
A role is defined as the number of that kind of role that the location supports as well as the name of the role:
The cast commands are the c a s t keyword, the role to cast, and the number of characters to
cast in that role. i n i t i a l i z a t i o n is for the roles that are cast when the location is created, and
e a c h _ t u r n is for the roles that are cast on each turn of the simulation. Putting this all together a
description of a bar that has an owner, a few bartenders, and a number of patrons might look
like:
l o c a t i o n bar:
s u p p o r t s : [
c a s t [
Roles are defined with an optional extension of another role, a set of tags that the role embodies, and the preconditions required for a character to be capable of taking on that role. r o l e ROLE-TYPE(CHARACTER)
[e x t e n d s ROLE-TYPE]: t a g s : LIST OF TAGS; i f : LIST OF PRECONDITIONS.
E.g., to represent the concept of having a job – and only being allowed to have a single job at a time – and that bartending is a kind of job one might use the following roles: r o l e j o b (> W o r k e r ): t a g s : l a b o r ; i f : Worker i s m i s s i n g j o b . r o l e b a r t e n d e r (> W o r k e r )
e x t e n d s j o b (> W o r k e r ): t a g s : d r i n k i n g ; i f : W o r k e r . a g e >= 18.
Traits have the name (or names) of the trait and the proclivities that the trait entails. Optionally, the trait can be flagged as being default and/or the trait that is opposition to the trait: [d e f a u l t ] t r a i t NAMES [o p p o s e s NAMES]:
LIST OF PROCLIVITIES.
A proclivity is represented as the impact to how much more or less likely a character is to take an action based on the tags associated with the action. These proclivities can also be conditioned on traits, statuses, and relations between characters:
VALENCE(LIST OF TAGS
[i f LIST OF CONDITIONS]) t r a i t e x t r o v e r t / e x t r o v e r t e d
o p p o s e s i n t r o v e r t / i n t r o v e r t e d : + + + ( t a l k ) . t r a i t i n t r o v e r t / i n t r o v e r t e d
o p p o s e s e x t r o v e r t / e x t r o v e r t e d : — ( t a l k ) .
E.g., to represent the fact that there are extroverts and introverts who are more or less likely to talk than others, respectively, one might write:
Opposition traits are defined as having the opposite valence, so an identical way to represent this would be:
The strength of the proclivity is represented by the number of pluses or minuses. All actions are assumed to default to a score of 0, but for all engaged proclivities the score is modified. Traits and statuses can work in concert, or – alternatively – can counteract each other. By default, an action with two pluses is twice as likely to be selected as one with no pluses, but the temperature of the selection (as in simulated annealing) can be set an end user or content module author to make their characters more or less predictable (lower or higher temperature, respectively). The multiple names delimited with slashes is a bit of syntactic sugar that allows an author to use multiple names to represent the same concept.
An example of a default trait that all characters would have might be that people are more likely to do nice things (and less likely to do mean things) to people that they like: d e f a u l t t r a i t k i n d - t o - p e o p l e - i - l i k e :
+ + + ( n i c e i f > S e l f l i k e s < O t h e r ) .
This uses a conditional proclivity, such that the odds of doing a nice action towards someone only increase if the enactor likes the target. The greater than and lesser than symbols tell the system how to bind to the characters in an action.
Next, we come to actions. Actions have a name, an argument list of involved characters (and possibly historical actions), text for how the action should be descibed, how (if at all) the action extends another, a list of tags, constraints on the location(s) of the characters, the visibility of the action, the preconditions for the action, and the results of the action.
a c t i o n NAME(LIST OF CHARS)
[e x t e n d s ACTION]: “TEXT” l o c a t i o n : LIST OF LOCATIONS; t a g s : LIST OF TAGS; i f : LIST OF PRECONDITIONS; r e s u l t : LIST OF RESULTS; VALENCEv i s i b i l i t y .
a c t i o n c h i t - c h a t ( > C h a t t e r , < L i s t e n e r ) : “ C h a t t e r c h a t s w i t h L i s t e n e r ” l o c a t i o n : ( C h a t t e r , L i s t e n e r ) ; t a g s : t a l k .
Which means that chit-chat is a t a l k action, and that the participants must be co-located (but that otherwise there are no constraints on their location).
An action can also be tied to specific roles, in which case the action must take place at the location where those people enact those roles. E.g., a bartender might “pour the troubles away” for a sad patron: a c t i o n p o u r - t h e i r - t r o u b l e s - a w a y
( > T e n d e r : b a r t e n d e r , < P a t r o n : p a t r o n ) : “T e n d e r l i s t e n s t o t h e t r o u b l e s
o f P a t r o n a n d p o u r s t h e m a d r i n k ” l o c a t i o n : ( T e n d e r , P a t r o n ) ; t a g s : w o r k , d r i n k i n g , t a l k , n i c e ; i f : P a t r o n i s s a d ; r e s u l t : P a t r o n l i k e s T e n d e r , a c t i o n f i g h t ( > F i g h t e r , < F i g h t e e ) : “F i g h t e r a n d F i g h t e e c o m e t o b l o w s ” l o c a t i o n : ( F i g h t e r , F i g h t e e ) ; t a g s : s c a n d a l o u s , v i o l e n t , a n g r y ) ; + + + + v i s i b i l i t y ; r e s u l t :
F i g h t e r a n d F i g h t e e
d i s l i k e e a c h o t h e r , F i g h t e r a n d F i g h t e e
d o n o t l i k e e a c h o t h e r .
Note, this action can only occur at a bar, since that is where the Tender is enacting the role of bartender.
Actions can also have diferent levels of visibility – e.g., everyone is aware that a fistfight occurred in the same location.
Two notes, (1) A and B C “each other” is syntactic sugar for A Cs B and B Cs A, (2) “do not” removes the relationship (or fact) if it exists. We can create a more specific version of the action if we want quite simply: a c t i o n b a r - r o o m - b r a w l ( > F i g h t e r , < F i g h t e e ) e x t e n d s a c t i o n f i g h t ( > F i g h t e r , < F i g h t e e ) : “A b a r r o o m b r a w l b r e a k s o u t
b e t w e e n F i g h t e r a n d F i g h t e e ” l o c a t i o n : b a r ( F i g h t e r , F i g h t e e ) ;
The primary diference between bar-room-brawl and fight is that bar-room-brawl specifies that the location that the fighters are in must be a bar. The two actions also have diferent descriptions.
Finally, since the fight is a very visible, scandalous action, it might be gossiped about by people who observed it:
Knowledge about actions can be seen (directly observed), heard (received second-hand), did (the enactor of the action), received (the target of the action), known (any of seen, heard, did, or received), and forgotten (the character no longer knows about the action). The gossiping makes sure that people don’t gossip about their own or their target’s scandalous exploits. Further, the tags of the action can be reasoned about as one would the status, traits, and relations of characters.
Finally, there are a syntactic sugaring shorthand patterns that can be used in actions, traits, and other patterns – easing the authoring burden.
For instance, a large portion of the above gossiping action’s preconditions could be summarized as “A and B weren’t involved in a scandalous event”. One might find themselves using that pattern in other actions, so they could specify: p a t t e r n n o t - i n v o l v e d - i n - s c a n d a l ( > A , < B , * E ) : i f :
A d i d n o t d o E , B d i d n o t d o E , B d i d n o t r e c e i v e E ,
E i s s c a n d a l o u s . p a t t e r n l o v e - t r i a n g l e ( A , B , C ) : i f :
A l o v e s C ,
B l o v e s C . or p a t t e r n u n r e q u i t e d - l o v e ( A , B ) : i f :
A l o v e s B ,
B d o e s n o t l o v e A .
Which could then be reference elsewhere. These can also be exposed to an end user, as a way to highlight potentially juicy tidbits:
Kismet is parsed using ANTLR4 [
Σ /
Where is the weight assigned to going to location . Once characters are at a location, Clingo is once again used to determine the proclivity weights, and an action is sampled for each character as with the locations. Once the actions are selected, their results are applied and the current social state is updated. This process proceeds until one of two things occurs – (1) most simply until a certain number of steps has occurred or (2) until a set of conditions is met – either of which can be set by a content module author or the end user.
Although a formal evaluation of Kismet has yet to take place, some preliminary testing has transpired with an undergraduate research assistant who used Kismet to create a world of responsible business employees and casino frequenting layabouts.
The “experimental set-up” of this preliminary work is simple to explain: this student is a sophomore in computer science, and had never been exposed to many of the underlying principles of Kismet—such as Clingo, answer set programming, or the very notion of a domain specific language—prior to working on this project. However, they did have a background in the Java programming language, and general approaches to procedural thinking. Kismet’s abstractions away from it’s underlying processes made it possible for the undergraduate to design and create a social world, which is heartening. At the same time, their attempts to use the system highlight some of its limitations, both in terms of expressively and accessibility. Although perhaps having some programming experience is a requirement for the “target user,” a mark of a successful casual creator is a tool which is easy to jump into. Thus, points of confusion this undergrad experienced highlight potential problem areas that future users might encounter as well, and warrant our attention moving forward.
Some of the issues the undergraduate encountered pertained to simple syntax misunderstandings, though some of these spoke to more fundamental conceptual issues. For example, the ifrst set of actions written had no post-conditions specified, indicating a disconnect between recognizing a character taking an action and the resulting underlying social state changes.
Other questions frequently revolved around the notion of “roles” in the system. For example, in example code included in the Kismet documentation, it introduces a location called a bar, and says that it has one owner, two to three bartenders, and one to ten patrons. The roles of “owner” and “bartender” speak to one’s profession, and have an air of permanence to them; e.g., even as the person cast as the owner lives their life and visits other locations, say, goes grocery shopping, they are still a bartender even as they are a patron of the market. However, the role of patron speaks to something much more ephemeral; even though one might always consider themselves a patron of a spot they frequent often, it is likely less a central part of one’s identity than the occupational roles such as bartender or owner would be. This distinction between roles referring to professions and roles referring to momentary qualifiers boils down to diferences between the “initialization” specification of a location, and a location’s “each_turn” specification, as described above, but this distinction was a challenge to understand.
Other limitations centered around the notion of tags. One such limitation is that there is currently no way to mark a duration of a tag. For example, the undergraduate wished to create a tag to mark a character as being “recently promoted.” This should heavily influence behavior in the short term (e.g., celebrating during the week of the promotion) but should not influence behavior in the long term (e.g., influencing the character’s desire to celebrate years after the promotion feels incorrect). At present, the way this is handled is to have certain actions remove tags. As previously mentioned, the “sober_up” action could remove the “drunk” tag; the tag will continue to influence the character’s behavior until they happen to take the aforementioned action to remove it.
Another limitation of tags is that they they help influence the behavior of those who wish to take actions, but they do not influence the selection of other non-initiating characters in the action. This can be circumvented, however, through clever use of traits. Though the “+” and “-” syntax is still applying from the enactor’s perspective (i.e., making them more or less inclined to take an action), it is possible to write traits such as: d e f a u l t t r a i t p r o m o t e _ h a r d w o r k e r s : + + + ( p r o m o t i o n
i f < O t h e r i s h a r d w o r k i n g ) . t i m e c y c l e [ a m , p m ] i f t i m e i s p m . . .
where hardworking is a tag here applying to a character. Still, the +++ is applying specifically to the enactor; they are more likely to engage in promote actions if someone around them is hardworking.
Shifting away from tags, the undergraduate was curious about capturing a sense of operating hours for certain locations. In Bad News, which ofered much inspiration for Kismet, each simulated day was split into two time blocks: day and night. Any given business operated either during the day, or the night, or both day and night. At present, the only sense of time in Kismet is the granularity with which an author specifies actions. However, there are currently plans to implement time cycles. A simple time cycle might look like:
Which would cycle between morning and night, and then could become conditions for certain behaviors, e.g.,
t i m e c y c l e [ m , t , w , t h , f , s a , s u ] [ a m , p m ]
Which would cycle through monday am, monday pm, tuesday am, tuesday pm, wednesday am, until eventually wrapping back around to monday am. These cycles could be extended indefinitely (e.g., capturing four weeks in a month, twelve months in a year, etc.).
Another desire the undergraduate had was to design situations in which characters could either choose to go to work or play hooky. Although this could be achieved through traits and actions (e.g., a trait “diligent” that increases the likelihood of taking “go_to_work” actions and an equivalent “lollygagger” trait which reduces the likelihood), this still demands that any given “work” action is then explicitly written and given the “go_to_work” tag. Another piece of future work is to implement prototypical actions (such as a generic “work”). Connected to the notion of inheritance described above, prototypical actions would not be directly selectable by characters to perform but could be extended to subactions which themselves are selectable. This ensures the tag only need to be specified once for ease of authoring and revising, such as: p r o t o t y p e a c t i o n w o r k :
t a g s : g o _ t o _ w o r k .
ensuring that every action which inherits from work will have the g o _ t o _ w o r k tag, without it needing to be specified for each individual action.
An exciting next step is to begin making sample modules and playable experiences using Kismet. This process will undoubtedly lead to accessibility improvements, which in turn will further enable Kismet to be adopted as a casual creator tool.
Additionally, formal user studies with additional participants with a variety of backgrounds would further substantiate the preliminary heartening observations that Kismet’s abstractions permit for non-technical authors to utilize Kismet to create meaningful or otherwise interesting stories. To this end, additional authoring support such as an authoring tool would provide valuable scafolding to introduce newcomers to the language. Lastly, a user study that compares Kismet to other social simulation systems, such as Ensemble, could be extremely valuable, and would validate (or invalidate) the author’s belief that Kismet permits users to generate small but dynamic social worlds at far quicker rate than its contemporaries. Such a study could begin to further explore the trade-ofs between accessibility and expressivity in social simulation systems, and in so doing not only inspire future directions for Kismet, but help establish goals and baselines for any future systems that may be developed.
Kismet is a small language for small social simulations, with an eye towards end user authorability. It is not as powerful or as in-depth as other expressive social simulation, but it is the first that has a focus on language design for novice use. It is still relatively early in development, with additional language constructs planned. Furthermore, our belief that Kismet is easier to use and author than other social simulations is mostly untested. In the future, we would like to get Kismet into the hands of more novices to be able to test this, to examine the range of social simulations they create.