Social simulations often need many of the same things - characters, locations, interactions, and relationships to name a few. These regular components of simulators are present in games ranging from major titles like The Sims [1]-[3], indie classics like Dwarf Fortress [4], and experimental interactive experiences such as Bad News (or at least in the simulator Bad News is build off - Talk of the Town) [5], [6]. Not only do these components need reimplementation in each sim, but they are also often difficult for anyone but original developers to modify [7]. In this paper we discuss how social simulators can be declaratively authored from an ontologybased representation while still maintaining playable framerates. We argue that an ontology for these entities allows for the expressive and flexible creation of social simulations. We present a language and ontology, Socialog, which enables one to declaratively author a simulation with these ontological statements while maintaining very good performance.
The use of declarative programming in game
development can provide several benefits such as
least-commitment design (leaving decisions about
implementation as open as possible), abstraction, and
modularity (by way of abstraction).
Leastcommitment design is a principle that is helpful when
handling major design changes that inevitably occur
during development. Abstraction and modularity are
commonly lauded principles in software development
and academia and industry more generally [
Unfortunately, the major hurdle for declarative
programming is often performance - an extra sticky
point in game development where milliseconds
matter. We believe there is a "sweet spot" when
developing social simulations where declarative
programming can still be performant. Using a
bottomup logic programming language [
While predicates allow for the description of
logical relations and properties, ideally one would be
able to make ontological statements about the social
simulation where the descriptions are of what stuff
exists, how things relate, and when events can happen.
Socialog is a language that allows one to build a
Many AI-based games have used symbolic rules for
character control. MKULTRA [
Several game development frameworks and social simulation middleware have used symbolic rules, particular for interactive narrative. One of the earliest and most influential such systems is Nelson’s Inform 7 language [21], [22], which allows designers to build interact narrative systems, particularly simulationist systems, using declarative statements. The Versu simulationist narrative system [23] used a custom logic programming language, Praxis, which was based on an exotic modal logic called eremic logic (aka exclusion logic) [24]. More recently, the Lume system [25] made extensive use of Prolog’s definite clause grammars [26], [27] for text generation. Lapeyrade has also used Prolog for better character decision making [28].
To our knowledge, bottom-up logic programming has not previously been used to implement social simulations. However, Datalog has been used for storysifting [29], the process of searching the output of a social simulator for interesting narrative content. Bottom-up logic programming, and Datalog in particular, has received the most attention in the database community [30]–[33] where its appeal came partly from the ability to compile it into relational algebra operators for efficient execution on classical database architectures, and because it can be extended to recursive rules using a fixed-point evaluation algorithm. This allows it to compute transitive closure (e.g., reachability in a graph), which standard relational algebra cannot. This is where most of the original research on the language and its implementation was done. More recently, it has seen extensive use for the semantic web [34].
Games involving large-scale social simulation are
relatively rare. The best known is Dwarf Fortress [35],
which supports real-time simulator of small hundreds
of characters. Achieving this level of performance
requires implementation in C++ and significant
programmer effort to optimize cache locality and
minimize the number of pointer indirections.
RimWorld is a very similar game that also involves
social simulation for the purpose of storytelling [36].
In the research literature, the best-known system is
Ryan’s Talk of the Town [37], which was used in the
award-winning game Bad News [
Kismet [
In the process of deciding on an ontological hierarchy we followed the guidelines of the Common Core Ontology (CCO) for creating ontologies [40], [41]. We also used the popular ontologies DOLCE [42], the Basic Formal Ontology (BFO) [43], and Cyc [44], [45] as comparison points for the creation of our ontology. For certain concepts like events and time there were additional ontological considerations.
Time is an inherent component of any simulation,
governing the level of detail (LOD) for events and
actions [46]. Kismet allows for the temporal “cycle” to
be authored [
There are a number of best practices in the construction of ontologies, such as adopting a “realism-based” approach or having at a multi-tiered architecture, that helped to guide our construction of this executable ontology [40], [41]. A realism-based approach means we are modeling the entities in the world that our data refers to rather than directly modeling the data elements and their respective relationships like in traditional database design [52], [53]. This technique helps to shift concerns away from implementation and toward declarability. A tiered architecture supports modularity with a common breakdown of levels including an upper ontology that defines generic types of entities, a mid-level that uses the upper ontology concepts to define structures that are common to many domains, and lastly a domainlevel that defines domain specific concepts [40], [41]. We have defined a simple upper ontology to guide our designs, built a mid-level ontology as a declarative programming language, and we have an example domain-level system in the research game Voix de la Ville.
General AI ontologies include very abstract high-level concepts, including some kind of top-level concept of which all other concepts are instances, For example, in DOLCE everything maps to a Particular [42], in Cyc everything maps to a Thing [44], [45], and in BFO everything maps to a continuant [43]. The ontology in Figure 2 is still far more detailed than is needed for the creation of a simulation but reflects the type of taxonomy one would find in a high-level ontology as it pertains to the concept of existence (here called existent, also known as a continuant or endurant).
Since most of the distinctions in Figure 2 are irrelevant to our needs, we do not have an explicit ontology at this level. Socialog is a mid-level ontology. However, it does assume a top-level ontology something like Figure 3.
The mid-level ontology for our system represents a majority of Socialog’s capabilities, though some functionality in Socialog isn’t included in this ontology section (such as table operators). Additionally, Effects – used in Events – are used to describe state evolution in the system and are not directly related to the highlevel ontology. 3.2.1. Event Events occur and can cause Effects. Events are parameterized by participants, the Things involved in the event. Events are represented by an occurrence predicate, parameterized by the participants, which is true when that event with those participants is occurring in the current simulation step. A chronicle also stores a record of the occurrence of every event.
Relationships are pairings that have a value (e.g., strength) attributed to them. The flavor of relationships that uses a numeric strength value we call Affinities and the flavor using a Boolean state value are called Relationships. Not included in Figure 6 is the ability of Relationships (the bool variety) to be chronicled much like an Existent. Relationships, naturally, have a start and an end but unlike regular existents these relationship states can come into and out of being repeatedly, meaning (potentially) multiple start and end times for a single relationship.
We are using this ontology to build a simulator called
Voix de la Ville (shown in Figure 7). The simulation is
a proof-of-concept partial reimplementation of Talk of
the Town [
Simulation proceeds, as all simulations do, by ticks.
Following TotT we have two ticks per day, but like
Kismet [
Occasionally, individuals who are romantically interested in each other will go out on a date. While at a location, everyone can choose someone else at the same location to interact with – preferring individuals most similar to themselves in addition to friends and romantic partners. These interactions can range from neutral chatting to positive empathizing to negative dueling, and each of the interactions affects the relationship between its participants.
An individual can have both a platonic and a romantic affinity to another individual, with various associated relationships like friendship, enemy, or romantic partners. Additionally, romantic partners that are also good friends can get married which is an exclusive relationship (although there is still a chance for cheating). The cycle of moving about the town and interacting is how socialization happens and drives the formation of our social networks.
There are 44 location types across 10 categories, each with a schedule of days and times of day they are open. There are 62 vocations that apply to the business locations and each business has an ideal number of positions for each vocation. Every person has an aptitude score for each vocation that is used to assign the best person for an open shift of some job. Some locations are not businesses like houses and as such do not employ anyone. Houses are an extra special case as they also are a type of accommodation – people live in houses (in addition to apartments and inns). Each house has an occupancy and as they fill up members of the household can leave – prioritizing keeping nuclear family units intact – for newly constructed homes. Also, when people die, they are buried in the town cemetery.
New people can be created when a couple goes on a very successful date. After conception approximately nine months pass and the mother gives birth to the baby. This is the major way in which a town progresses. However, drifters can also come settle in town (more come to town when there are ample jobs to fill with a new business). This cycle of birth and death is also applicable to location; new locations are created as the population grows due to population thresholds, density, or various specific cases (Doctors office only opens when you have a really good Doctor in town). Locations can also go out of business, and this forces people to either move to a new home or to find a new job.
The core simulation code – written in Socialog – is under 500 lines with comments. This does not include the Unity/GUI specific code, the TED and Simulog libraries, and ignores some custom value types and utils (mainly declaring enumeration types with some time structs/classes).
Simulog is implemented as a layer on top of TED [
Much of the ontology surrounds the concepts of events and existents. An event is a kind of thing that can happen at a point in time, such as birth or death. An existent is a kind of thing that exists during some interval of time, such as a person. The start and end of an existent are events. For example, the start of a person is their birth. 5.1. Event Events are both a standalone predicate that allows one to say what should be occurring on a given tick as well as the underlying mechanism that all other Socialog predicates use to express when something should happen. Events can declare Effects, which are additions or modifications to other predicates.
Figure 8 shows foreclosure and can be translated to say “There is an event called foreclosed upon that an occupant (person) participates in when the home they live at is ending (will no longer exist). When foreclosed upon, move the occupant of that place to another home that isn’t currently overcrowded.” “Place.End” inside Figure 8 is referring to the End event for the Place Existent, while “Home” is a standard Predicate that simply tracks who lives where.
Figure 9 outlines the Event architecture in Socialog, where each event that is defined has an internally maintained table with columns for each participant. A Chronicled Event is derived from its respective event, storing every occurrence of the event ever instead of just the occurrences in the current tick. The chronicle is created automatically when the simulation includes rules that refer to the history of the event (by saying, e.g., “ForeclosedUpon(who).At(time)”). Existents are things that exist with some temporal extent, not instantaneous events but also not universals with no durative quality. Characters and Places are good examples of existents (Figure 1 shows the Place existent), things with a clear start and end.
Existents are made up of several tables with three different events, the table of existents (with a Boolean exists column for quick access of those that do exist as well as those that did), and an optional table of attributes for the existent. Figure 10 outlines this architecture – the ellipses under the attributes table indicate that there can be a variable number of features and, like the limitation described in Figure 9, there can be up to 7 features in the attributes table.
Figure 11 shows the event for procreation, the embryo existent, and the connection between the embryo and character existents. This can be translated to say “Embryos are a thing that exist (with some temporal extent), and they have the features of a mother, father, sex, and date of conception. Embryos start when Procreation happens – Procreation happens when a woman and man successfully procreate, and this assigns a sex and name to the child.
An embryo ends after 9 months have passed with an 80% probability per tick to simulate labor. When an embryo ends, the child is added to the Parent table as a child of each parent and the embryo becomes a person in the Character existent.”
Of note here is the ability to rewrite the “Character.StartWhen(Embryo.End[person]);” line as “Embryo.EndCauses(Character.Start[person]);”. Separating out these effects into relevant groupings is yet another example of the modularity found in making these sorts of ontological statements. Effects are critical to Socialog’s expressive ability, allowing predicates to be modified by code omnidirectionally – instead of setting a column or adding a row in the code for a given predicate, we can do the same thing from any of the predicates that are referencing it.
Affinity is a type of relation between two things where the relationship has an associated score, or affinity. The Affinity architecture is rather simple, as shown in Figure 12, with a base table storing all affinities and a change event that indicates when an affinity needs to be updated and by what amount.
Figure 13 shows the Spark and Charge affinities which translate to platonic and romantic affinity and are lifted from TotT. While this code could be made even shorter by storing the interaction types and associated deltas in a dictionary or table, the readability of the update when functions would be compromised.
Although this example implies a use case of person-to-person affinity, this architecture is flexible enough to let one establish an affinity between any two classes of things. For example, spiritual or institutional affinity as is found in Dwarf Fortresses Deity, Object of Worship, or Force relationships. Another example would be the needs system found in The Sims where each need could be an affinity that scores action urgency.
Relationships come in several varieties, but the most basic is depicted in Figure 15. A relationship can come into and out of being, and the way in which a relationship starts or ends is decided by a start and end event. While this information is not stored in the Relationship table, a Relationship Chronicle can be made in much the same way as an Event Chronicle and this Chronicle tracks relationship starts and ends (even if they start and end multiple times).
In addition to this basic relationship type, there is a symmetric variant – e.g., where A relating to B is the same relationship as B relating to A – that uses the same structure as a relationship but internally maintains pair symmetry. One variant on the symmetric relationship is the exclusive relationship that, in addition to using the same basic structure and maintaining symmetry, also maintains exclusivity (a given individual can maintain the relationship with at most one other individual). By using the same structure for all relationship types, switching the logic of a relationship from the normal asymmetric type to a symmetric type is as easy as changing the constructor function name and/or pairing variable.
Another special case relationship is the affinity relationship. Affinity is already tracking some value for a pairing and a common way that we would create relationships was by using thresholds for the start and end values in some affinity table. To both simplify this process and ensure a performant implementation we added affinity relationships. While structured much the same as other relationship variants, there is no start/end when function as this is handled by the affinity start and end.
Figure 14 shows three affinity relationships and an exclusive relationship that is derived from the other relations. The affinity relationship lines translate to “there is a relationship named Name that starts at the affinity score value 1 and ends at the affinity score value 2.” In other words, this relationship starts when you cross one threshold and ends when you cross another. The lines for the Lover relation say, “there is an exclusive relationship called lover that starts when two people consider each other to be both friends and romantic partners and ends when one of the two dies.” It would be easy enough to make Lover non-exclusive (use Relationship not ExclusiveRelationship), but Lover acts as our analog for marriage currently.
While there is not any user intervention in the simulation yet, the visualization tools we have built are not only helpful in debugging but also entertaining to watch. There are currently two major visualizers in Voix de la Ville – Table viewers and Graph viewers. Predicates’ underlying implementation is as tabular data so a basic table viewer running during the simulation allows for inspection of the contents of the entire sim in neat tabular forms. While table viewers are a critical component of our debug/visualization capabilities, the point of Socialog is to build social sims and thus we naturally form social networks. A graph visualizer can be used for anything from family trees and friend networks to the dataflow diagram of how predicates connect to one another. Both display techniques are shown in Figure 7.
Tilemaps from Unity are also used to display locations. Although this isn’t as useful for debugging – only really showing how the town is physically laid out – you can hover over each tile and see some basic information including who is currently at the location.
In addition to the expressivity and modularity demonstrated by Socialog, the performance is acceptable, if not competitive with hand crafted code. The data shown in figures 16 through 18 were collected in one 15-minute run of the simulation. The simulation was running on a desktop PC with an i77700k CPU clocked at 4.6GHz (4.8 boost) and 32GB of 1,500 MHz RAM. While running inside of Unity, the data collected only measured the execution time of the Socialog code not any graphical computations (this is why the GPU information is not relevant).
Figure 16 shows the overall performance of Socialog in Voix de la Ville as a function of population. On the low end of the population spectrum – 50 characters – we have 15-25ms execution times per tick while the high end – 450 characters – takes roughly 600ms per tick. This reflects a sum of the per-entity updates, which grows linearly with the population, and the per-character-pair updates, such as affinities, which necessarily grow quadratically with the population. The per capita performance data is shown in Figure 17. On the low end of the population spectrum, we have 0.4ms execution per character and by the time we are at the high end that has only increased to 1.4ms.
Figure 18 shows the total run that collected this data. Over a period of 37 in-simulation years the population grew (shown by the green points) and with it the execution time (shown by the purple points). Clearly visible are some plateaus in population followed by sharp growth (this is caused by new locations attracting “drifters” to fill the jobs). Regardless of this inconsistent growth, the performance data heavily correlates with population. Additionally of note, the population can be capped to help maintain a higher performance – a technique present in Dwarf Fortress with a common high end of roughly 200 dwarves [54].
While the performance of Socialog is already acceptable for numerous use cases, there are two major bits of apologia that can address potential improvements. One is that the technique that drives Socialog, bottom-up logic programming, is amenable to parallelization and that is not something we have implemented yet. Second is that we have not done an optimization pass over TED, Socialog, and Voix de la Ville to ensure that we are eking as much performance out of these systems as possible.
Although we handle the quadratic nature of interaction reasonably well in terms of performance, there are doubtless better abstractions for addressing this problem. Similarly, there are modules that have yet to be built out for concepts such as ownership and part/whole relations. More patterns are likely to emerge in the development of Voix de la Ville, and these will inform future ontological categories and components.
While a full-fledged STRIPs planner is likely out of the picture for character control (for performance reasons), some form of action planning that goes beyond single-tick action section is also worth investigating. Level of Detail (LOD) support, such as in Talk of the Town, would also be useful. This would allow the system to simulate some parts or eras of the world more coarsely than others.
Social simulation is an important emerging area of gameplay, but building these simulators is difficult. Socialog shows that it is possible to author these sims at a remarkably high level while still maintaining acceptable performance. [20] [21] [22] [23] [24]
Jun. 2010, pp. 1–8. doi: 10.1145/1822309.1822319.
J. McCoy, M. Treanor, B. Samuel, A. A. Reed, N. Wardrip-Fruin, and M. Mateas, “Prom week,” in Proceedings of the International Conference on the Foundations of Digital Games, in FDG ’12. New York, NY, USA: Association for Computing Machinery, May 2012, pp. 235–237. doi: 10.1145/2282338.2282384.
B. Samuel, A. A. Reed, P. Maddaloni, M. Mateas, and N. Wardrip-Fruin, “The Ensemble Engine: Next-Generation Social Physics”.
G. Nelson, “Inform 7.” 2006.
G. Nelson, “NATURAL LANGUAGE, SEMANTIC ANALYSIS AND INTERACTIVE FICTION.”
R. Evans and E. Short, “Versu—A Simulationist Storytelling System,” IEEE Trans. Comput. Intell. AI Games, vol. 6, no. 2, pp. 113–130, Jun. 2014, doi: 10.1109/TCIAIG.2013.2287297.
R. Evans, “Introducing Exclusion Logic as a Deontic Logic,” in Deontic Logic in Computer Science, G. Governatori and G. Sartor, Eds., in Lecture Notes in Computer Science, vol. 6181. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010, pp. 179–195. doi: 10.1007/978-3-642-14183-6_14.
S. Mason, C. Stagg, and N. Wardrip-Fruin, “Lume: a system for procedural story generation,” in Proceedings of the 14th International Conference on the Foundations of Digital Games, San Luis Obispo California USA: ACM, Aug. 2019, pp. 1–9. doi: 10.1145/3337722.3337759.
F. C. N. Pereira and D. H. D. Warren, “Definite clause grammars for language analysis—A survey of the formalism and a comparison with augmented transition networks,” Artif. Intell., vol. 13, no. 3, pp. 231–278, May 1980, doi: 10.1016/00043702(80)90003-X. [42] [36] [37] [40] [41]
J. N. Otte, J. Beverley, and A. Ruttenberg, “Basic Formal Ontology: Case Studies”.
D. Lenat, M. Prakash, and M. Shepherd, “CYC: Using Common Sense Knowledge to Overcome Brittleness and Knowledge Acquisition Bottlenecks”.
D. Ramachandran, P. Reagan, and K. Goolsbey, “First-orderized ResearchCyc: Expressivity and efficiency in a common-sense ontology,” Jan. 2005.
J. F. Allen, “Towards a general theory of action and time,” Artif. Intell., vol. 23, no. 2, pp. 123–154, Jul. 1984, doi: 10.1016/0004-3702(84)90008-0.
“Time Ontology in OWL.” Nov. 15, 2022. [Online]. Available: https://www.w3.org/TR/owl-time/
S. J. D. Cox, “Time ontology extended for non-Gregorian calendar applications,” Semantic Web, vol. 7, no. 2, pp. 201–209, Feb. 2016, doi: 10.3233/SW-150187.
R. Casati and A. Varzi, “Events,” The Stanford Encyclopedia of Philosophy. Metaphysics Research Lab, Stanford University, 2023. Accessed: Jul. 15, 2023. [Online]. Available: https://plato.stanford.edu/archives/fall 2023/entries/events/
D. Davidson, “The Logical Form of Action Sentences,” in Essays on Actions and Events, 1st ed.Oxford University PressOxford, 2001, pp. 105–148. doi: 10.1093/0199246270.003.0006.
D. Davidson, “Causal Relations,” J. Philos., vol. 64, no. 21, pp. 691–703, 1967, doi: 10.2307/2023853.
B. Smith, “New Desiderata for Biomedical Terminologies,” J. Biomed. Inform. - JBI, Jan. 2008.
B. Smith and W. Ceusters, “Ontological realism: A methodology for coordinated evolution of scientific ontologies,” Appl. Ontol., vol. 5, no. 3–