Tile-based maps are used in a wide variety of games, including Zelda: Link's Awakening, Super Mario Bros, and many tabletop role-playing games. They represent a relatively simple method for designing game worlds, which makes them a great medium for casual users. However, creating tile maps entirely by hand can be tedious, especially for large maps or across several map generation tasks. There is potential for generative systems to support users in more efficiently and enjoyably creating tile maps, but a more streamlined content generation experience often comes at the cost of reduced control over the generated content. In this paper, we present a mixed-initiative map generation tool that supports users in creating customized tile maps by providing complete control over both the map being generated and the rules governing an underlying Answer Set Programming-based generator. Using a small palette of rules designed for tile map generation, users define constraints on the types of maps the system will generate, view and edit generated maps, and selectively re-generate sections of the map until they are satisfied. We discuss our current progress on this tool and present several opportunities for future work, with a particular focus on expanding the capabilities for authoring rule-based tile map generators.
Tile-based maps are used in many video games, including
Zelda: Link’s Awakening and Super Mario Bros, and
tabletop role-playing games like Dungeons and Dragons and
Pathfinder. There is extensive support for the creation of tile
maps and the use of tile maps for creating video games. For
example, the Tiled map editor (Thorbjørn Lindeijer 2008)
has been used in the creation of hundreds of indie games,
and the popular Unity game engine (Unity Technologies
2005) features native support for tile maps. For tabletop
role-playing games, map editors like Tiamat Tile Mapper
(RPGObjects.com 2010) and map generators like DunGen
Mixed Initiative Co-Creation (MI-CC) systems aim to foster this type of productive human-computer collaboration during creative tasks (Yannakakis, Liapis, and Alexopoulos 2014). By supporting interaction between a human initiative and a computer initiative, with both the human and computer proactively contributing to a creative task, MI-CC systems can lead to truly co-creative experiences. In an MI-CC relationship, the human and computer are able to work in harmony to complement each other’s weaknesses. For example, the computer can act as an expert guide for a particular content creation task by providing suggestions based on an existing body of work, thereby scaffolding a user’s initial exploration of a new domain. The computer can also take on the role of an additional worker providing suggestions for parts of the generated content that the user is less interested in focusing their time on.
MI-CC tools can be designed to embody the principles of
casual creators
In this paper, we present a mixed-initiative tile map
creation tool that implements several casual creator patterns
We discuss our progress on the tool’s design and development, describing our initial goal of supporting the creation of individual tile maps and our recent focus on supporting the creation of rule-based tile map generators. We also present promising directions for future work, especially opportunities for expanding the tool’s rule authoring capabilities.
Mixed-initiative and casual creator tools have been
developed to support a wide range of content generation tasks,
including the creation of game maps and levels with Tanagra
(Smith, Whitehead, and Mateas 2011), Evolutionary
Dungeon Designer
Germinate and Imaginarium differ from Tanagra, Evolutionary Dungeon Designer, and Sentient Sketchbook because they support users not only in generating artifacts, but more broadly in the creation of the PCG systems that generate those artifacts. These casual creators present novicefriendly interfaces for declaring constraints on generated artifacts, thereby allowing users to create their own procedural content generators.
Germinate, which is built on top of the Gemini game generator (Summerville et al. 2018), presents a domain-specific visual programming language that allows users to declare constraints on the types of games that the system will generate. These constraints include types of entities (i.e., graphical objects, such as characters), resources (i.e., quantitative values that define the goals of the game, such as happiness or confidence), relationships between entities and resources, and triggered gameplay events. Constraints in the visual programming language are translated by Germinate into Gemini intents, which are ASP programs. When users are done declaring constraints, they ask Germinate to produce a batch of games that attempt to satisfy the constraints specified by the user while also introducing additional entities, resources, relationships, or triggers. The generated games are presented in a playable form, so users can immediately playtest what was created based on their core design intent. Additionally, the games are displayed in the same visual programming language that is used to create the design intent for generating games. This allows users to clearly see where their constraints were implemented or modified and to take inspiration from generated games by pulling new constraints into their core design intent.
Imaginarium supports users in the development of procedural content generators for tabletop role-playing characters and items. Users provide structured natural language descriptions of some rules that they want a set of entities (e.g., characters and items) to follow and the system generates entities meeting these requirements. For example, by enumerating sets of possible characteristics that cats could have (e.g., “Cats are white, gray, black, or ginger”), followed by asking Imaginarium to “Imagine 3 cats”, the system will generate three cats that embody some combination of the possible characteristics. This is done by translating the structured natural language the user provides into an ASP program, running the program, and translating the output back into natural language. By doing so, users are able to leverage some of the power of ASP without needing to be proficient in logic programming. This allows the generative tool to be approachable for users with many different backgrounds, since the technical barrier to entry has been significantly reduced.
Beyond the work presented in Germinate and
Imaginarium, several other domain-specific languages have been
developed to support the creation of generative systems, such
as the Grammatical Item Generation Language
The tool that we present in this paper was originally inspired most heavily by the MI-CC systems that are concerned with generating individual game artifacts (i.e., Tanagra, Evolutionary Dungeon Designer, and Sentient Sketchbook). These systems inspired the high level of interactivity that our tool provides to users when they are generating a tile map. However, we have recently identified the use of ASP-based rules to design tile map generators as a particularly interesting application of our tool. Thus, our focus has begun to shift toward developing a system that has more in common with Germinate, where the central interaction being supported is the use of a domain-specific programming language to define procedural content generators.
We have made significant progress toward developing a mixed-initiative casual creator tool that helps users make tile maps. The tool, developed with the Unity game engine, features a map generator based on Answer Set Programming that can be configured by a set of natural language constraints. There is also an interactive representation of the map that the user can edit at any time. By combining an interactive map with a configurable constraint-based generator, users are able to manually add whatever they want to the map and ask the generator to fill in all of the parts that they are less concerned about. Once they see what the generator creates, the user can pick and choose any parts that they like and ask the generator to once again fill in the gaps. Through this iterative process of co-creation between the user and the generator, users have the benefits of complete control over the generated map while also having a reduced workload and the opportunity to be inspired by the generator.
The tool’s interface is broken up into five different areas, which are shown in Figure 1. Area 1 displays the map that is being collaboratively generated by the user and the ASPbased map generator. The map is interactive, allowing users to manually add tiles in specific locations and to lock certain areas of the map to let the generator know what it is allowed to overwrite. Area 2 allows users to start creating a new map and to assign a name to the map. Clicking the button to create a new map also brings up a window where users specify the desired height and width of the map. Area 3 shows all of the tiles that are available to the user and the generator. Currently, users only have access to a small set of tiles, but a future version of this tool will allow users to import their own images as tiles. Users can click to select tiles in this area and manually place them on the map. They can also rightclick tiles in this area to assign tags, which allow users to provide metadata about tiles to group them together. For example, house, palace, and temple tiles might all be grouped together under a “building” tag. Area 4 is the rule creation interface, which provides six rules (explained in detail in the next section) that can be used to create tile map generators. These rules can operate on both tile types and tags. Finally, Area 5 has a “Generate new map” button that users can click to ask the generator to create a new map or re-generate the unlocked portions of the map that they are currently working on.
The tool relies on Answer Set Programming (ASP),
specifically using the Clingo language
Rules were created in two directions. First, we formulated the kinds of constraints we would expect from a generator, which included things like specifying the types and how many of each building should exist, the proximity of buildings to other buildings, and the connections between buildings. From those formulations, we implemented an example of each in Clingo, our chosen ASP language, in order to establish that it was possible to create the rule in a generalizable way. From there, the only remaining step was to create an internal C# script that queries Clingo with a file (or, as we came to call it, a rule set) and awaits the response in the form of logic atoms which indicate the layout of the map.
We chose to formulate rules as natural language sentences where the user is able to adjust numbers and select operative words to form legal rules (see Figure 2 for some example rules in the tool). Each rule has an associated C# function which accepts the numbers and operative words as parameters and returns all necessary Clingo code for that specific rule as a string. When the user indicates they are ready to generate a new map with their existing rules, the proper function calls are made and all the Clingo code is added to a base Clingo file which contains definitions about the domain space. The result of solving the Clingo file produces the logic atoms which are parsed and displayed on the screen.
Users construct rules by typing strings or numbers into input fields or by selecting values using dropdown menus. Rules are validated before being compiled into ASP code, so individual rules that get passed to the generator are always error-free. In fact, the only way for the user to produce invalid rules is to leave some input fields blank, but this does not affect the generator because incomplete rules are ignored. However, it is not always true that the rules are valid when taken together, since there could be contradictory constraints. The tool notifies users when a map cannot be generated given the rules and locked tiles on the map, but it does not currently do anything to highlight the potential problems.
Base Rules A base rule set contains all information that Clingo needs to know about two-dimensional tile maps, such that it is able to generate valid maps. The first element of the base rule set is the set of dimension atoms. These define that there are two dimensions, X and Y, which each take a numeric input. The dimensions define the size of the map. The second element is a choice rule which indicates to Clingo that there should be exactly one tile on each dimension pair. Finally, the concept of adjacency is established by creating atoms that define vectors of movement. These step rules are expanded to arbitrarily large X and Y coordinates based on the rules used during generation. The base rule set is never exposed to the user, so they do not need to worry about creating valid maps and can focus on defining rules that generate interesting maps.
Rules Presented to the User There are five main rules available to the user for crafting a tile map generator: Adjacency, Proximity, Connection, Count, and On. The natural language and Clingo representations for these rules are laid out below. A sixth rule (Tile Inclusion) allows users to specify which tiles the generator can use when creating a map, thus providing a way to prevent irrelevant tiles from appearing in certain maps (e.g., ocean tiles in a landlocked city).
The Count rule is the simplest of all the rules. It states “There are ( ; ; =) Count TileA”. The rule translates to the following ASP code: :- #count{X, Y : at(X, Y, house)} (<, >, !=) Count.
A Count rule is satisfied if there exists a number of the specified building or tag to satisfy the rule. The count rule can be used to indicate a specific number of buildings that should exist, or to create a range for a certain type of building.
The Adjacency rule specifies that a certain tag or tile must have a certain number of another tag or tile adjacent to it. It states “There are ( ; ; =) Count TileA adjacent to each TileB.” The rule translates to the following ASP code: :- at(X, Y, TileA), #count{Z, N : at(Z, N, TileB), steplong(DX, DY, 1),
Z = X + DX, N = Y + DY} (<, >, !=) Count.
For example, the rule “There are at least four parks adjacent to each palace,” indicates that wherever a palace is placed, there should be four parks in the surrounding eight squares.
The Proximity rule is an extrapolation of the Adjacency rule for a specified radius around the specific tile. It states “There are ( ; ; =) Count TileA within Dist spaces of each TileB”. The rule translates to the following ASP code: :- at(X, Y, TileA), #count{Z, N : at(Z, N, TileB), steplong(DX, DY, Dist),
Z = X + DX, N = Y + DY} (<, >, !=) Count.
Using the Proximity rule instead of the Adjacency rule, our previous example could be accomplished like this: “There are at least four parks within one space of each palace.”
The On rule directly uses the dimensions in the base rule set to specify whether a tile should or should not be on a specific coordinate. It states “All tiles in Row/Column Num are TileA”. For specifying tiles in a certain row, the rule translates to the following ASP code: :- not at(X, Num, TileA).
As an example, the maps shown in Figure 3 use an On rule to ensure that only tiles with a Wall tag appear on the outer edges of the map, thus creating a walled city.
The last rule, and the most complicated, is the Connection rule, which states “All TileA are connected to all TileB by TileC”. The rule translates to the following ASP code: has_TileC. 1 {TileC_start(X,Y) : dimX(X), dimY(Y), at(X, Y, TileC)} 1 :- has_TileC.
TileC_conn(X, Y) :- TileC_start(X, Y). TileC_conn(NX, NY) :- TileC_conn(X, Y), step(DX, DY), NX = X + DX, NY = Y + DY, at(NX, NY, TileC). :- at(X, Y, TileC), not TileC_conn(X, Y). :- at(X, Y, TileA), #count{Z, N : at(Z, N, TileC), step(DX, DY),
Z = X + DX, N = Y + DY} < 1. :- at(X, Y, TileB), #count{Z, N : at(Z, N, TileC), step(DX, DY),
Z = X + DX, N = Y + DY} < 1.
The Connection rule takes three tiles or tile tags as parameters and specifies that every instance of the first tile is connected to every instance of the second tile by the third tile. Take, for example, the road Connection rule which states that “All Buildings are connected to all Buildings by Roads.” This guarantees that there is a connected chain of roads that links buildings to one another. It implies, as well, that, “All roads are connected to all roads by roads.” The third tile in the rule will always be connected to itself in order to achieve the rule.
The workflow we intend to support with this tool consists of two tasks: using rules to define a tile map generator, then iteratively collaborating with the generator to create specific map instances.
The creation of a tile map generator would proceed as follows: 1. Define constraints on the map generator by adding new rules or by loading an existing rule set. 2. Ask the generator to create one or more new maps. 3. Inspect the generated maps and refine the set of rules that make up the map generator to better reflect your design goals. 4. Repeat from Step 2 until the generator consistently creates maps that you are satisfied with.
Once the generator is more or less finalized, the user would take the following steps to create a specific tile map instance: 1. Specify the dimensions of a new map. 2. Ask the generator to create new maps until you find one that interests you. 3. Manually edit the map by adding tiles or locking sections of the generated map that you want to keep. 4. Ask the generator to re-generate the unlocked parts of the map (see Figure 3 for an example). 5. Repeat from Step 3 until you have a map that you like.
Since the primary purpose of this tool is to support a wide
range of users in the creation of tile maps and tile map
generators, it is important to evaluate it in relation to
maps generated by the tool are not designed for any specific use case, such as a particular game, it is difficult to determine what metrics might be generally useful to include. Therefore, this design pattern is not addressed.
Entertaining evaluations. This is not applicable to the current version of the tool because the tile maps being generated do not undergo any sort of evaluation.
No blank canvas. As a starting point for users, we designed three base rule sets that create a city, a walled city, and a port city. These rule sets can be used to generate reasonably interesting city maps with the click of a button, and both the map and the rule sets can be modified by the user to start creating something new. Moreover, with the ability to save and share rule sets, there is potential for users to have community-sourced resources that prevent them from having to deal with a blank canvas.
Limiting actions to encourage exploration. When modifying an individual map, users have access to just two core actions - they can place tiles on the map and lock or unlock tiles to tell the generator which parts of the map it is allowed to overwrite. To define rules for a tile map generator, users only have access to five different rules, which represents a significant simplification compared to creating a generator directly using ASP.
Mutant shopping. By allowing users to directly interact with the tile map that is being generated and to lock or unlock parts of the map to tell the generator what it is allowed to overwrite, users are able to iteratively keep newly generated sections of the map that they find interesting. There is currently no equivalent feature for designing tile map generators, but in the future it may be possible to suggest new rules, either randomly or in a data-driven manner. Modifying the meaningful. The base rules that are used to define a generic tile map generator, such as a rule for populating each grid on the map with exactly one tile, are entirely hidden from the user. The user only needs to worry about high-level rules for generating different types of tile maps.
Saving and sharing. All constraints for a map generator can be saved to a JSON file, which can be loaded back into the tool at a later time or shared with other creators. These constraints include all rules as well as the types of tiles allowed in the map and tags used to group tiles. In the future, we also plan to allow users to export individual maps that they have created as JSON files and images.
Hosted communities. We do not currently have hosted communities, but the ability to export map generator rule sets as JSON files would support this. There is a lot of potential for users to share generators that reflect different map archetypes, such as the walled city that we provide as a base rule set, that users can download and immediately use or modify to fit their needs.
vide support for modding or hacking the tool, but it may be interesting to provide advanced users with an interface for defining their own rules templates that compile into ASP.
Moving forward with this tool, we are most interested in
expanding the rule creation interface to provide users with
greater capabilities for creating tile map generators.
However, as this is meant to be a casual creator tool, it will be
important for the tool to remain novice-friendly while also
allowing advanced users to create more complex and
expressive generators. To this end, we are interested in
reimplementing the rule creation interface using Blockly, which
has been used extensively in introductory programming
environments
It will also be helpful to introduce debugging support in
the form of static program analysis. For example, if a user
adds two rules that contradict each other, the system could
flag these rules and notify the user that they are not
compatible. A meta analysis of the ASP program constructed
by the user, such as by using Gebser et al.’s spock
system
Another interesting direction for future work is to
investigate methods for inferring constraints from hand-authored
maps
There are also several potential opportunities for expanding the tool’s generative capabilities. First, we could allow local rules that only apply to certain parts of the map, thus allowing for finer control over the maps being generated. We could achieve this by supporting the composition of maps from multiple smaller maps, each with their own generators. Using a similar approach, it would be interesting to allow users to create rulesets for different layers of a map (similar to layers in a program like Photoshop or Tiled). For example, users could generate entire game levels by first creating a map layer and then adding an entity layer on top of it that generates gameplay elements like characters or items. Finally, we could add the ability to generate hex tile maps or even abstract graph visualizations, not just square tile maps. As a result, the tool could potentially be adapted for an entirely different domain like narrative generation by introducing rules about temporal sequencing (e.g., X happens before/after Y), types of actions and states (e.g., Actors can do Action, Actors can be State), and action preconditions and effects (e.g., Doing Action makes an actor State). Providing support for other domains would likely require substantial work, but the potential to expand beyond tile maps is certainly interesting.
Regardless of which directions we choose to pursue, it will be essential to conduct user studies with an updated version of the tool. We will want to evaluate how easy it is for novices to use the tool, the types of generators and artifacts that users are able to make with the tool, and the extent to which users find the tool engaging and rewarding.
We describe preliminary progress on a mixed-initiative tool
for the casual creation of tile maps. The tool features a small
palette of natural language rules specifically designed for tile
map generation tasks, thereby allowing users to design their
own tile map generators without requiring knowledge of the
underlying ASP code that the rules are compiled into. Users
are able to offload as much of the map generation task to the
system as they desire, presenting opportunities for increased
efficiency and inspiration, while support for direct editing of
the map provides users with the ability to override the
generator at any time. We evaluate the tool in relation to
Karth, I.; and Smith, A. M. 2021. WaveFunctionCollapse: Content Generation via Constraint Solving and Machine Learning. IEEE Transactions on Games . Neufeld, X.; Mostaghim, S.; and Perez-Liebana, D. 2015. Procedural level generation with answer set programming for general video game playing. In 2015 7th Computer Science and Electronic Engineering Conference (CEEC), 207– 212. IEEE.
Smith, A. M.; Andersen, E.; Mateas, M.; and Popovic´, Z. 2012. A case study of expressively constrainable level design automation tools for a puzzle game. In Proceedings of the International Conference on the Foundations of Digital Games, 156–163.
Smith, A. M.; and Mateas, M. 2011. Answer set programming for procedural content generation: A design space approach. IEEE Transactions on Computational Intelligence and AI in Games 3(3): 187–200.
Smith, G.; Whitehead, J.; and Mateas, M. 2011. Tanagra: Reactive planning and constraint solving for mixed-initiative level design. IEEE Transactions on Computational Intelligence and AI in Games 3(3): 201–215.
Summerville, A.; Martens, C.; Samuel, B.; Osborn, J.; Wardrip-Fruin, N.; and Mateas, M. 2018. Gemini: Bidirectional generation and analysis of games via asp. In Fourteenth Artificial Intelligence and Interactive Digital Entertainment Conference, volume 14.
Taylor, S.; Min, W.; Mott, B.; Emerson, A.; Smith, A.; Wiebe, E.; and Lester, J. 2019. Position: IntelliBlox: A toolkit for integrating block-based programming into gamebased learning environments. In 2019 IEEE Blocks and Beyond Workshop (Blocks and Beyond), 55–58. IEEE. Thorbjørn Lindeijer. 2008. Tiled Map Editor. URL https: //www.mapeditor.org/.
Unity Technologies. 2005. Unity Game Engine. URL https: //www.unity.com.
Yannakakis, G. N.; Liapis, A.; and Alexopoulos, C. 2014. Mixed-initiative co-creativity .