AgentCraft: An Agent-Based Minecraft Settlement Generator Ari Iramanesh, Max Kreminski University of California, Santa Cruz {airanman, mkremins}@ucsc.edu Abstract AgentCraft is an entry for the Generative Design in Minecraft (GDMC) AI Settlement Generation Competition, including the optional Chronicle Generation challenge. It makes use of an agent-based simulation to organically produce a plausible settlement and a written history of the settlement’s develop- ment. Uniquely, AgentCraft utilizes the HTTP Server version of the competition framework to show the agents constructing the settlement in real time—a visual technique that can’t be achieved with the earlier MCEdit framework. In this paper, we aim to provide a point of reference for future agent-based settlement generators by describing how our competition en- try works and discussing the benefits and downsides of the agent-based approach. Additionally, we propose a new op- tional challenge for the GDMC competition, centering on the development of settlement simulations whose inhabitants can be directly observed or interacted with by the player. Figure 1: An example settlement generated by AgentCraft, showcasing a variety of buildings connected by roads and Introduction built from appropriate materials for the local environment. This paper presents AgentCraft, a Minecraft settlement gen- erator that uses agent-based simulation to create a plausi- ble settlement with adaptations for local terrain in a bottom- Our goals in this writeup are twofold. First, we aim to up way. It was created as an entry to the Generative De- provide a reference description of an agent-based Minecraft sign in Minecraft (GDMC) AI Settlement Generation Chal- settlement generator that can serve as an inspiration and lenge (Salge et al. 2020), which scores entries based on jumping-off point for future agent-based competition en- four high-level criteria: Adaptability, Functionality, Narra- tries. To this end, we attempt to document our approach tive, and Aesthetics. In the 2021 iteration of the competi- more thoroughly than other competition entries have done tion, AgentCraft took second place out of 20 total entries and to date and provide a brief accounting of significant difficul- earned the second-highest Narrative score of any GDMC en- ties we encountered in the process of developing our gener- try to date (just behind the overall winner in 2021.) ator. Additionally, we provide links to a GitHub repository Though not the only competition entry to use an agent- containing the complete AgentCraft source code1 and video based approach, AgentCraft is (to the best of our knowledge) documentation of the generator in action.2,3 unique in its incorporation of lightweight social simulation Second, beyond the current explicit goals of the GDMC elements, loosely inspired by the social simulation frame- competition, we believe that a compelling new challenge work Talk of the Town (Ryan and Mateas 2019). Further- might be found in the live simulation of settlement inhab- more, AgentCraft goes beyond the scope of GDMC by ren- itants that players can observe or even interact with in real dering the settlement’s development (including the move- time. To that end, we suggest that the GDMC competition ment and interaction of the agents that created the settle- could adopt a new optional “Liveness Challenge” (in the ment) in real time, allowing the player to watch the settle- same vein as their current Chronicle Generation challenge) ment develop before their eyes. oriented around this goal. 1 Copyright © 2021for this paper by its authors. Use permitted under https://github.com/aith/agentcraft 2 Creative Commons License Attribution 4.0 International (CC BY https://www.youtube.com/watch?v=Gc5h54Bus k 3 4.0). https://www.youtube.com/watch?v=DGLiWOxWLig tion. To accomplish this, each node stores a prosperity value that measures how busy that node is. A node’s prosperity in- creases by a task-specific amount when an agent performs an action within that node, and decays over time. After a node reaches a certain prosperity threshold, the generator will de- cide whether to generate a road from that node. Agents will also favor roads when pathfinding to a destination, so that the agents and their roads work cohesively. This synergism of behavior fulfills the positional realism of roads. Our prosperity-based approach to road generation is based on the one used in TownSim (Song and Whitehead 2019), which in turn was inspired by a survey of road network patterns present in complex real-world cities (Batty 2007) and earlier work on the generation of naturalistic terrain- adaptive road networks (Emilien et al. 2012). Additional re- lated work on road network generation is surveyed by Sme- lik et al. (2014) and Kelly and McCabe (2006), as well as in Figure 2: An aerial view of the road network in a generated the TownSim paper. settlement, showing how roads conform to the terrain and connect buildings in an organic-looking way. Traversability and Efficacy-Based Placement Real-world road design aims to satisfy several requirements. Generally, roads are expected to: Starting the Generator 1. Minimize the user’s travel time to a destination The AgentCraft generator runs as a CLI, with a few optional flags. Upon starting, the generator searches for a suitable set- 2. Be connected to pre-existing roads tlement location within the user-specified boundaries, or the 3. Be traversable build area. This location must: 4. Avoid redundancy with other roads • Be on land For the purposes of realism, AgentCraft aims to fulfill • Have water nearby (otherwise a well will be placed) each of these requirements. Requirements (1) and (2) tend • Be traversable, i.e., flat and unobstructed enough to be to conflict in practice, since the fastest path to a destina- walked across tion is simply a straight line to the destination, or the path that minimizes the Euclidean distance from the start to the • Have suitable locations for a building, a road, and the ini- destination. To fulfill both (1) and (2) in a reasonable and tial agents realistic-looking manner, when the generator decides to link • Be at minimum 32x32 blocks in size a particular node to the road network, it first attempts to do If a valid build location was found, the generator will cre- so by generating a straight-line path from the target node ate a small cast of agents, an initial building, and the first to the nearest road-type node. However, this often doesn’t node of a road network. It will then launch an iterative set- lead to paths that satisfy Requirement (3): buildings, trees, tlement construction process that repeatedly steps through or steep slopes can intercept these paths. each agent and performs appropriate actions based on the If the desired straight-line path is not traversable, the gen- current state of the settlement. erator will first attempt to split this straight line into two con- Information about the build area is stored as a grid of nected linear paths to get around an obstacle. If one or both nodes overlaid on the surface of the world. Each node is of the resulting split paths are themselves not traversable, composed of nine surface blocks, arranged in a 3x3 man- the generator will then perform a series of raycasts outward ner. When the generator requires information about a node, from the target node in a circle to identify a “good enough” it inspects those nine tiles to classify the node as belonging plausible path that still connects the target node to the road to one of several high-level categories. This information is network. If no traversable path can be found in this manner, used in many ways, including for agent-based pathfinding the generator gives up on connecting this particular node to and road network placement. the road network for now, though it may try again later once the road network has expanded further. Roads Traversability checks involve two key components. First, to be traversable, a path must never require an agent to Traffic-Based Placement move from one block to another when the change in height Real-world settlement traversal and design revolves around between the two blocks is greater than the designated roads. Real-world buildings are built along roads, and foot- agent jump height (by default, one block.) Second, to be path-based roads are typically built for the purpose of facil- traversable, a path must not move through any nodes that itating traversal through a popular route. AgentCraft repli- have been classified as non-traversable due to the types of cates these features in order to achieve realism of simula- blocks they contain (for instance, water or lava blocks.) Figure 4: Several screenshots of agents as they appear in the world, carrying out their business. During the settlement generation process, agents visibly walk from place to place, Figure 3: The initial road network can’t be extended in a collect resources, and interact with other agents. straight line to reach the nearest tree, so we first find a route around the building, extend the road network slightly, and construct a straight-line road to the tree from the new exten- 4. Propagate to produce a new “child” agent, if lover-lover sion. interaction threshold met with another colocated agent 5. Build using shared resources, if enough resources exist The combination of these checks and algorithms is com- 6. Log OR grow a tree, picking stochastically putationally more expensive than some simpler road net- 7. Grow a tree if no trees exist within a fixed radius work generation algorithms, but results in an iterative and Notably, all actions except socializing require movement organic road system that builds on top of itself, effectively to a destination. This works synergistically with the prosper- replicating real-life road systems—particularly those found ity system, which results in roads being generated often and in older cities with less-than-modern city-planning origins. in the places where agents go most (hearkening back to road efficacy.) Agent pathfinding is accomplished via A* search Agents on the two-dimensional grid of nodes that AgentCraft over- Agent behavior in AgentCraft is context-free and local to lays on the surface of the world. each agent: when deciding what to do next, agents do not The socialize action occurs when two otherwise unoccu- consider past experiences or (except in the case of specif- pied agents are positioned in the same node. There are three ically social actions) the state of other agents. The agents possible relationship types for the agents: lovers, friends, have seven different actions, or motives, that they choose and enemies. All of these are mutual relationships, with the from based on a set of rules, similar to cellular automata. The relationship between each pair of agents being chosen at behaviors that are necessary to retain agent “health”, such as random. If an agent has performed enough socialize inter- gathering water or getting rest, are decided by non-stochastic actions with their lover and neither has any higher-priority rules. The decision to grow or log a tree is stochastic, unless actions to perform, they will both pathfind to a building and there are no trees nearby. propagate to produce a new “child” agent. Socialize inter- Here are all of their possible actions, in order of priority: actions between friends and enemies affect the interacting agents’ happiness, but in the current version of AgentCraft, 1. Socialize, if another willing agent is in the same node happiness has no visible effect on the agents. Agents are rendered as Minecraft armor stand entities, 2. Rest in a building, if tired which offer expressive options that allow them to visually 3. Drink from a water source, if thirsty represent Minecraft player models. Each agent carries a motive-specific item in one hand (indicating to the player Optimization 3 ensures that node data structures (which what action this agent is currently performing) and a ran- cache information about specific parts of the build area’s domly chosen agent-specific “favorite item” in the other. surface) are only created when needed for decision-making. An agent’s clothing is colored based on a randomly-chosen Each node stores a fairly large amount of information, so color representing the settlement as a whole, while their this helps to reduce memory usage during simulation. shoes represent the overall prosperity of the settlement (with Optimization 4 separates the generator’s model of the agents from richer settlements having higher-quality shoes.) Minecraft world from the live, player-facing version of the Minecraft world after the generator starts up. Unfortunately, Optimizations this means that a modification to the Minecraft world during Because the GDMC competition imposes a 10-minute cap the simulation may lead to incoherent results. Because this on the time that a generator may take to produce a settle- could potentially compromise the illusion of the settlement ment, and because we perform fairly in-depth simulation of as a real, living and responsive place, we would like to find agent activity, the implementation of AgentCraft required a way for the generator to receive local updates to the ac- many unexpected optimizations to be performed. Optimiza- tual Minecraft world during simulation; for the time being, tions were especially needed for large build areas, such however, we leave this to future work. as the 1000x1000 build area used as the upper bound for Optimization 5 is available as a CLI option for build area size in the 2021 iteration of the GDMC competi- AgentCraft users. It simply holds off all simulation-to-world tion. On a 4-Core Thinkpad T480, given a 1000x1000 block rendering until the generator completes. Live rendering of build area, the retrieval of world data from the HTTP Server agent behavior and block updates during simulation is one competition framework alone took 5 minutes—leaving only of AgentCraft’s key features, so disabling it runs counter 5 minutes for the generator to produce a plausible settle- to our intended player experience—but for the time-limited ment. This was not an easy target for us to hit, given that GDMC competition, which does not take live rendering AgentCraft constructs settlements iteratively through the ac- into account during judging, this optimization is essentially tions of agents over time. mandatory. The following optimizations were necessary to make the generator produce a complete and plausible settlement in un- Chronicle Generation der 10 minutes: GDMC currently offers one optional bonus challenge for 1. Pre-compute legal A* paths for agents on startup settlement generators: the Chronicle Challenge, which in- 2. Recompute legal A* paths when a change in a block leads volves generating a written history, or chronicle, of the gen- to a change in reachability from surrounding blocks, in a erated settlement. To date, most competition entries have not depth-limited fashion attempted to address this optional challenge: of the 20 en- 3. Lazy-load block and type information from the HTTP tries to the 2021 iteration of the competition, only three (in- server on a per-node basis cluding AgentCraft) attempted to participate in the Chroni- cle Challenge. 4. Store block data in an internal buffer in the generator, rather than repeatedly requesting it from the Minecraft Since AgentCraft creates a settlement incrementally world through agent behavior, producing a chronicle was an easy fit for our approach. In the current version of AgentCraft, 5. Disable mid-simulation rendering of all changed blocks whenever an agent performs an action, there is a chance that and agents, if desired the action will be described in the chronicle. To add some Optimization 1 entails calculating inter-traversability be- light variation to the generated text, we choose randomly be- tween blocks and their neighbors. This guarantees that tween two potential sentence templates for each high-level pathfinding to an unreachable location fails immediately. action type; swap agent names into these templates where Without this, A* would iterate through every block to see appropriate; and add random adjectives (drawn from a list) if a path is attainable; in a 1000x1000 build area, around to specific fixed points in most of these sentences. These ac- 1,000,000 surface blocks would have to be searched every tion descriptions are then written to a Minecraft book in the time an agent attempted to go to an unreachable location. order that the actions were performed (Fig. 5). In the future, Trickily, the reachability of specific blocks has to be re- a lightweight text generation tool such as Tracery (Compton, calculated whenever a block’s traversability is changed in Kybartas, and Mateas 2015) could be used to add procedural the world—for instance, when an agent places a building variation to these descriptions. Future attempts at extending or chops down a tree. Recalculating traversability for ev- the chronicle generation components of AgentCraft could ery block would be enormously expensive, given how many also borrow methods from NaNoGenMo, as surveyed by van times each block might be changed during the simulation. Stegeren and Theune (2019). For this reason, we implemented Optimization 2, which In our original plan for AgentCraft, we intended to gen- limits recalculation of block traversability to only those erate per-agent diaries that gave separate and sometimes- blocks whose reachability is known to have changed. Fur- conflicting accounts of the same events in the settlement’s thermore, we made this computation depth-limited, account- history, inspired loosely by the biased per-character percep- ing for the furthest distance that an agent could actually tions of narrative in Why Are We Like This? (Kreminski et al. reach from their current location. 2020a,b). In practice, this proved to be out of scope for our Liveness: A New Challenge In the process of developing AgentCraft, we rapidly realized that it was fun to watch the agents go about their business in the world and construct a settlement in real time—maybe even more fun than to walk around the resulting settlement once the agents had completed their task. Others who have seen the agents in action (including the GDMC organizers) seem to agree: people consistently find the liveness of agent behavior compelling. In light of this reaction, it stands out to us as unusual that, even in building-focused games like Minecraft, non-player characters that attempt to systematically change their envi- ronment over time are almost unheard of. In AgentCraft, our simulated agents are not fully realized NPCs, because the player cannot meaningfully interact with them—but in prin- ciple, nothing seems to preclude the possibility of further developing AgentCraft-like agents into NPCs that can inter- act with the player through (at least) trade and combat, much like the villagers of vanilla Minecraft. With this goal in mind, we propose a new optional chal- Figure 5: A page in a generated Chronicle describing three lenge for the GDMC competition, centered on liveness: the various events in time. creation of live settlement simulations whose inhabitants can be observed or even interacted with by the player. Like the current Chronicle Generation bonus challenge, a prospec- tive Liveness Challenge might serve as an optional objective that favors generators with a deeper understanding of the ar- tifacts they create—and thereby steers the community as a whole toward better orchestration (Liapis et al. 2018) across multiple distinct facets of generative design and game AI. Conclusion Figure 6: A group of generated Chronicles for a settlement procedurally named Verdictland. AgentCraft’s success (taking second place overall in the 2021 GDMC competition) indicates that the use of social agents to create a settlement can result in organic design, if done with care. By integrating the simulation of agent entry this year; consequently, we leave per-agent diary gen- needs with a prosperity-based approach to road network eration to future work. generation, AgentCraft generates realistic-seeming road net- works that adapt to local terrain and resource availability. Additionally, an agent-based approach to settlement gener- Building Placement ation makes first-pass chronicle generation relatively easy and provides lots of hooks for deeper chronicle generation In some ways, using agents to create settlements signifi- going forward, especially if integrated with a slight deepen- cantly increases the complexity of settlement generation— ing of social simulation. However, agent-based approaches which is already a difficult task on its own. For this reason, to settlement generation come at a performance and devel- we chose to strategically limit complexity in other areas, opment cost that grows with simulation scale—necessitating especially in the potentially thorny area of building gener- more optimization effort than might otherwise be required ation. Rather than procedurally generate new building ge- and limiting the amount of time and energy that can be spent ometry from scratch, our agents construct buildings based on other aspects of settlement generation, such as procedural on human-authored schematics. Nonetheless, we do lightly building design. process these schematics to allow some flexibility and varia- Nonetheless, we find that generated settlements are made tion in which blocks are used to construct them. This entails more interesting when you can directly witness the pro- allowing “air” blocks in schematics to be replaced by blocks cess by which they were constructed—especially when this already in the world; wood blocks to change based on the process involves the live simulation of believable charac- type of logs that agents have gathered; and directional blocks ters. For this reason, we suggest that future iterations of (such as staircases) to adjust their directionality based on the the GDMC competition might want to adopt a new optional rotation of the building. In addition, to make these buildings bonus challenge centered on the development of live settle- sit correctly on uneven terrain, we generate a flat scaffolding ment simulations—in which plausible settlements go hand foundation underneath them. in hand with the plausible NPCs that live inside them. References Batty, M. 2007. Cities and Complexity: Understanding Cities with Cellular Automata, Agent-Based Models, and Fractals. MIT Press. Compton, K.; Kybartas, Q.; and Mateas, M. 2015. Trac- ery: an author-focused generative text tool. In Interna- tional Conference on Interactive Digital Storytelling, 154– 161. Springer. Emilien, A.; Bernhardt, A.; Peytavie, A.; Cani, M.-P.; and Galin, E. 2012. Procedural generation of villages on arbi- trary terrains. The Visual Computer 28(6): 809–818. Kelly, G.; and McCabe, H. 2006. A survey of procedural techniques for city generation. ITB Journal 14(3): 342–351. Kreminski, M.; Dickinson, M.; Mateas, M.; and Wardrip- Fruin, N. 2020a. Why Are We Like This?: Exploring writ- ing mechanics for an AI-augmented storytelling game. In Proceedings of the Electronic Literature Organization Con- ference. Kreminski, M.; Dickinson, M.; Mateas, M.; and Wardrip- Fruin, N. 2020b. Why Are We Like This?: The AI archi- tecture of a co-creative storytelling game. In Proceedings of the Fifteenth International Conference on the Foundations of Digital Games. Liapis, A.; Yannakakis, G. N.; Nelson, M. J.; Preuss, M.; and Bidarra, R. 2018. Orchestrating game generation. IEEE Transactions on Games 11(1): 48–68. Ryan, J.; and Mateas, M. 2019. Simulating character knowl- edge phenomena in Talk of the Town. In Game AI Pro 360, 135–150. CRC Press. Salge, C.; Green, M. C.; Canaan, R.; Skwarski, F.; Fritsch, R.; Brightmoore, A.; Ye, S.; Cao, C.; and Togelius, J. 2020. The AI Settlement Generation Challenge in Minecraft. KI- Künstliche Intelligenz 34(1): 19–31. Smelik, R. M.; Tutenel, T.; Bidarra, R.; and Benes, B. 2014. A survey on procedural modelling for virtual worlds. Com- puter Graphics Forum 33(6): 31–50. Song, A.; and Whitehead, J. 2019. TownSim: Agent-based city evolution for naturalistic road network generation. In Proceedings of the 14th International Conference on the Foundations of Digital Games. van Stegeren, J.; and Theune, M. 2019. Narrative generation in the wild: Methods from NaNoGenMo. In Proceedings of the Second Workshop on Storytelling, 65–74. Association for Computational Linguistics.