Settlement Generation Challenge 2022

This is the overview page for the fifth iteration of the GDMC AI Settlement Generation Challenge in Minecraft, running in 2022. This competition round is in the past, but this page still exits to document the rules for the past competition, and show the winners. Submission Deadline is the 31st of May, 2022. extended to the 14th of June, 2022 (submit via the submission interface here) The 1st place in the general GDMC Settlement Generation competition will recieve 500 US dollars. The Settlement Generation Challenge is about writing an algorithm that can create a settlement for a given, unknown Minecraft map. The challenge is to produce an algorithm that is adaptive towards the provided map, creates a settlement that satisfies a range of functional requirements - but also looks good and evokes an interesting narrative. The goal is to basically produce an algorithm that can rival the state of the art of what humans can produce. So far there have been 4 iterations of the challenge: once in 2018, and in 2019, in 2020, and in 2021. You can watch the presentation for last years winner's here on youtube. To participate, you have to write a program that can build a settlement for an unknown Minecraft map. After you submit your algorithm, we will run it on 2 to 3 previously unseen maps, and a panel of human judges will then evaluate the resulting settlement, based on a set of criteria focusses on Adaptation to the Environment and Terrain, Functionality from an Embodied Perspective, Narrative Integration, and Visual Aesthetics. Results Video

Previous Years 2018, 2019, 2020, 2021 Conferences CoG Submission Languages Python, Java, other Submission Types HTTP Interface via Forge Mod MCEdit Filter Participants Choice Deadlines: Submission: 14. of June, 2021 Results: August, 2021

Overview To participate, you, or a team, have to write some code that can generate a Minecraft Settlement for an unseen Minecraft map. We accept submission in several frameworks, see below. You submit the code, together with some additional information to us before the deadline. We then apply this code to usually 2 to 3 competition maps selected by the organizers, which are not known before the deadline. The resulting settlements will then be sent to a range of expert and volunteer judges, who use Minecraft to look at and interact with the settlements, and then assign scores to each generator. We then announce the results - including who got the highest score and relating the settlements, code, and feedback publicly, both online and at a suitable scientific conference. Rules To participate you need to submit your code to our website before the deadline. Team submissions are allowed. Anyone is able to participate. One submission per person / team only (We have considered exceptions for academic supervisors who led several teams - please contact us to discuss) Unless you object specifically, we will publish the code and attached documentation after the evaluation period. You keep ownership and rights to your own code and work - but unless you object we assume we can share it and use it in our material. If you have any further questions about the rules, please aks them on our discord, so we can clarify: Join Discord Winners will be announced during the 2022 Conference on Games in August 2022. At the same time we will also publish the detailed evaluation results online for each algorithm. Once the results have been announced we will also publish the competition maps, the settlements generated by the algorithms, and the participants description of their algorithm. We also encourage participants to publish their code, but this will not be mandatory. Unless participants object to sharing their code, we will make it available on our website with an appropriate open source license. If they decline, we will not publish the code. In either case, the organizers will not take exclusive ownership of the code. You can find previous years maps, code, resulting settlement, evaluation scores and other things on our website. Due to some generous funding from the IEEE CIS Competition Subcommittee we have an actual prize this year: The 1st place in the general GDMC Settlement Generation competition will recieve 500 US dollars. The prize will be claimable via the submission email, and teams will have to figure out how to split the prize themselves. Evaluation The submitted algorithms will be judged based on a set of 2 to 3, different, unknown maps. Example training maps will be provided. The competition maps will not be publicly available until after the competition. Every submitted algorithm will be run on the same 2 or 3 unknown maps, and the resulting maps with settlements will be anonymized and given to the judges. The judges will also be able to see the 2 or 3 maps in their natural state, before the algorithm was applied. The exact number of maps will depend on the number of submissions. The algorithms are given (dependent on the framework) a map and a 3d bounding box they should generate a settlement in. The algorithm should be able to run on maps of varying sizes - and should not run substantially longer than 10 minutes on a regular PC, and not exceed 2 Gbit of RAM for a single map. In the past we have usually used maps of around 256 by 256 blocks, as well as larger maps of around 1000 x 1000 blocks that were generated by the standard Minecraft terrain generator. But the algorithm will be given the exact dimensions of the map when it is run and should be able to adapt to slightly bigger or smaller maps. For example, a competition map might be 200 by 300 in size. The competition is judged by a set of human judges who are either members of the advisory board or delegates selected by the organization team. If a member of the advisory board or the organization team ends up submitting an algorithm themselves, they will be excluded from the evaluation process for that year, i.e. they will not be allowed to nominate judges or judge themselves. The plan is to have all judges evaluate all algorithms and average their scores. If this is not possible, due to high number of submissions, there might be several evaluation rounds, where earlier rounds are used to reduce the number of submissions by evaluating a lower number of maps with only a subsection of the judges. The judges will then evaluate all 2 or 3 maps for a given algorithm by spawning at the central point (for the x and z coordinate) of the map. While the judges are in creative mode, they are encouraged to walk through the settlement from a survival perspective. They are given a set of evaluation criteria (see Evaluation Criteria) and are asked to assign points based on the performance of the algorithm across all maps. The sum of the points is the score of the algorithm. The algorithm with the highest score wins. Evaluation Methods in 2022 For 2022 we plan to have a similar evaluation process as in 2021 First, we will include one larger map, possibly around 1000 by 1000 blocks. Here the challenge is to a.) make sure the algorithm still finished in the allotted 10 min. time window and b.) to figure out where to built on the map. Judges will spawn in the middle point of the map, and the generators should ensure in some form (sign, road, etc.) that judges are able to find the generated settlement on the map. Secondly, since we want to move more towards co-creativity we will have one map that has already some structures build on them, similar to a player starting a settlement. These pre-existing structures may be a combination of settlements generated by the standard Minecraft generator as well as previous entries of the competition. We acknowledge that this is challenging, and are interested in how this can be dealt with. Participants are allowed to ignore, destroy, modify, or built over the existing structure, but we assume that judges will reward adaptivity to existing structures in their scoring. Evaluation Criteria We defined a set of evaluation criteria based on what we believe the challenges in moving towards more human-like settlement generation are. So, when evaluation the generated settlements judges are asked to score each generator in four categories: Adaptability, Functionality, Narrative and Aesthetics. For further details, read on at 'Challenges' below. Chronicle Challenge We are also still running the optional bonus challenge: Chronicle Generation. This is an optional challenge, that is evaluated separately from the regular competition. Contestants will have to indicate that their entry is competing in this challenge during submission. For the chronicle challenge, the generator needs to produce a written book in Minecraft and places it inside the generated settlement – ideally in a place where it is easily found. The book should contain a text that is in some form about the settlement (in English) and contain some form of narrative related to the settlement or how it came about. The entries are evaluated based on how well the given chronicle fits the generated settlement and on overall quality. For further details, read on at 'Challenges' below. Submission See valid submission methods page to see all current methods. Challenges This section is about the specific challenges in generating a Minecraft settlement on a given map. We believe that these are some of the core obstacles that need to be overcome to move closer to human-level design. We should point out, though, that this list is not exhaustive. It is likely that there are other challenges and obstacles to get to human-like settlement generation. Furthermore, we consider the challenges outlined here ambitious goals to move towards, and do not expect them to be fully solved right away. The evaluation criteria that will be given to the judges are based on these challenges, because we want participants to address these problems. Adaptation to Environment and Terrain Real-life human settlements are adapted towards their surrounding environment and terrain in multiple ways. On a per-building basis, houses and structures reflect the climate conditions they are built in. Furthermore, the environment of a settlement might also dictate the available resources for construction, and certain conditions might require specific types of buildings, such as irrigation, shelter, etc. A house in the cold climate of Edinburgh, for example, might be built sturdy, to protect against wind and cold and keep the warmth in. Likewise, the easy availability of stone might influence the choice of building material. Real-life settlements are also adapted to the immediate terrain they are in. Natural features, such as mountains or lakes, play a role in the selection of where to settle. Some terrain features can be both positive and negative for a specific settlement, and settlements are often built to take advantage of the benefits and to compensate for the problems. A river, for example, might provide more food and added mobility via ship travel, but might also limit mobility by foot, and be a potential flooding hazard. A settlement might subsequently be built close to the river (or even more likely, at a good location to cross the river), to take advantage of the benefits. The same settlement might also build a dam to protect against flooding, and houses close to the water might sit on stilts. If the settlement dumps waste into the river there might also be a development of different districts, where better, more desirable houses are further up on the river. On the other hand, humans change the terrain and environment in a limited fashion to better suit their needs. While it might be impossible to remove a mountain or an ocean, it might be possible to build a canal or tunnel. In summary, human settlements are shaped by and in turn shape the terrain and environment around them. If we study human-built settlements in Minecraft, we can see that these principles are realized in some existing builds. AI settlement generators, on the other hand, struggle to adapt to environment and terrain. They often rely on flattening large areas and then building settlements that do not reflect the surrounding map at all. Similarly, the houses and structures built by them are often templates that get placed as a whole unit, and are in no way reflective of the environment they are in. As part of this challenge, we encourage participants to develop generators that produce different settlements for different kinds of maps, reflecting the available materials, surrounding terrain and environmental conditions. In particular, successful entries should generate settlement that fit into the topography of the map without changing it too much, and build structures that fit into the topography. We also encourage participants of the challenge to think of other ways in which the given maps influences the generated settlement, ideally in such a fashion that it is evident to a human observer what kind of adaptation happened. Ideally, different maps should lead to different settlements, and it should be clear in which way the settlements where shaped by the map. Also note, that there is some overlap with the other three criteria, as their particular solutions are also often ideally adapted to the underlying map. Functionality from an Embodied Perspective Minecraft is not just a creativity tool, but also a game. Subsequently, a Minecraft settlement is not just an aesthetic artifact; it also needs to fulfill certain functional roles. One big aspect of this is accessibility and mobility. Is it actually possible to walk through the settlement and reach its different parts? Are there doors into the buildings, are the bridges over the river? How easy is it to navigate the settlement? A second big function a settlement provides is protection from various dangers. Is the settlement well lit, or does it otherwise prohibit mobs from spawning? Does the settlement manage to keep dangerous mobs outside? Are there other forms of defenses and traps to protect the player? Finally, there is also a need to obtain food and process it - so is there an accessible way to produce food and not starve? This list of functional requirements is not exhaustive - it is just meant to give some examples. This criterion does have a certain overlap with the challenge of adaptivity. Certain functionality only needs to be provided in some cases. For example, bridges compensate for reduced mobility introduced by obstacles. They are an adaptation to reduce the negative effects of the terrain. Other functionality takes advantage of given terrain features, such as river lock further enhancing the mobility of an existing waterway. This should also be considered, not just from a player perspective, but also under the assumption that the NPC villagers living in the settlement have similar needs. There is crossover here with the next section, because some functionality displayed in typical human-build settlement is not functional in the strict sense. For example, in reality a lot of houses have pitched roof to ensure better rain water runoff. In Minecraft, this is not necessary (as rain does not pool on the ground), but players still build houses with pitched roofs. This narrative functionality alludes to a functionality we understand, yet is not strictly functional in Minecraft. We still encourage the inclusion of such functional elements. Ideally, these narrative functionalities should also be adaptive to the environment. So, pitched roofs should be more popular in a rainy swamp than in a dry dessert, etc. In summary, the fact that there is an actual player in the world gives us an embodied perspective. The avatar can interact with the world in a variety of different ways, and a settlement can provide different affordances to the player. The challenge in this competition is to produce a generator that can ensure that the settlement provides a maximum of functionality and affordances for the player, while also satisfying the other criteria. Believable and Evocative Narrative Human settlements are not just collections of functional buildings, but they also tell a story about how they came about, who are the people living there, and how they see the world. When we look at human-created Minecraft settlements, we can often see how certain human or imagined cultures are reflected in the created buildings. There are cities that resemble ancient Rome, mythical Elven forest outposts, and modern US cities. Often, the buildings also reflect very clear narrative ideas, such as “this is a defensive mining outpost built in a harsh environment”, or “this is a capital city, built to impress foreign and domestic visitors alike”. These settlements are evocative, i.e. they manage to transport this story by looks alone. Relating to the earlier challenge of adaptivity, the better settlements also evoke narratives that work well with the terrain and biome they are in. The narrative they evoke should fit the terrain and environment of the given map, and ideally arise from it. Different maps should result in different narratives. Human settlements also reflect how they came about. Medieval cores of modern cities, for example, tell a part of a settlement's origin story. This is something rarely seen, even in human-made Minecraft builds, as settlements here are created with the final state in mind. But procedural content generation does have a tradition of simulationist approaches, which would be a possibility for this challenge. An AI could simulate people living and building a settlement over several stages, rebuilding or replacing structures, or slowly modernizing them. This could solve several of the previous problems, as buildings and the overall settlement would be the actual result of an adaptive process, and the produce of an actual sequence of events forming the basis for a possible narrative. There is also a certain overlap between narrative and functional requirements. How easy the player can obtain wood for building and further process it is a functional requirement. To satisfy this a settlement could have a nearby forest and a workbench nearby. But to make this work with a narrative of a settlement that relies on wood production it might also be good to build a structure that looks like a sawmill, and a street to transport the goods to town. This would not produce any additional functionality to the player (or the digital villagers), but it would tell a narrative that aligns with the functionality provided to the player. Similarly, there could also be elements that have purely narrative functionality, i.e. structures that have a believable fictional use that is not immediately reflected in the game mechanics. For example, a settlement could have an aqueduct to provide water, even though Minecraft characters do not need to drink. To summarize, the particular challenge here is not just about narrative generation, but also about generating a narrative that fits with the generated settlement, and ensuring that this narrative is communicated to the player with the generated structures. Inspiration by existing, historical or imagined cultures can help to transport this narrative. The aim is to produce something that is both believable and evocative, while still being aligned with the previous criteria. Visual Aesthetics Aesthetics are arguably subjective, yet architects and city planners usually follow a range of principles when it comes to designing a settlement or a house. While untrained humans manage to intuitively realize these principles with some success, it is difficult to design an algorithm with automated aesthetic judgment. Existing Minecraft mods that add structures to the world circumvent this problem by hand-designing appropriate templates, and then building a settlement out of those templates. This solution has several problems: it allows for little variation between the buildings, as they all need to be pre-designed, and it also allows for little adaptation of the buildings to the surrounding buildings, the underlying terrain, etc. Buildings are sometimes parameterized, and hence reflect some specific environmental settings, such as available materials or the climate they are in. This makes them more adaptive, but there seems to be trade-off between controlling the exact look of a structure, and making it adaptable towards uncontrolled environmental factors. The challenge in our case is to ensure that buildings still follow basic design principles while being adaptive, functional and evocative. There is also the further problem that the overall settlement itself should follow certain aesthetic rules. How buildings are aligned and what sight lines exist can play an important role for the overall feel of the settlement. Finally, there is also the question of how well the particular aesthetic expression chosen aligns with the other challenges. For example, a settlement which has a narrative of being a foreboding fortress, and is designed with that functionality, should also have an aesthetic that reflects this. Bonus Challenge: Chronicle While cities implicitly tell a story about their inhabitants, cities also often have explicit stories about their history. These chronicles contain notable events that affected and shaped the settlement, such as fires, wars of periods of vibrant trade. The can also provide a lot of additional context, such as what was the function or reason for the settlement during different time periods, or what ideas and philosophies have shaped the settlements development. They also often contain stories about important people that shaped the city. Basically, anything that could be written about a city and would be achieved in the city is appropriate. For this challenge, your task is to create a chronicle that is currently stored in the city. It should be written as a Minecraft book, and should contain text relating to the generated city. This challenge relates back to several of our earlier criteria, such as adaptivity and narrative. The chronicle should be adapted to the actual generated city, and should the story of that specific city. The less generic this story is, the better. The chronicle challenge is optional, and entries will be evaluated based on the overall quality of the chronicle, and how well it fits with the different cities generated. Examples Here is a link of videos of good, human-created settlements that showcase some of the things we are looking for in a generator. FAQ Here is a short FAQ. Results The 2022 competition is finished, and below you can find links and direct information about the results: Maps You can download the maps with the settlement generated by all the generators here. Warning, this is a rather large .zip file with 2 GB, as it contains about 30 Minecraft maps, 3 for each generator. Results You can see the scores here and also download the code by the individual entries. Individual Descriptions Below is the info provided by the participants, and potentially a link to a page about the entry itself. PCGNN_Wits_GDMC We use the procedural content generation approach titled PCGNN (Procedural Content Generation using NEAT and Novelty Search) in this submission.\r\nThis method leverages NEAT and Novelty search to evolve \"level\" generators — each network can generate multiple levels. This further uses novelty search to incentivise generators to be diverse. Finally, this uses intra-generator novelty, which incentivises the same generator to generate multiple diverse levels.\r\n\r\nIn this competition, we leverage composition.\r\nEffectively, we have different concepts of a \"level\":\r\n- House: a 3D tilemap representing empty space and \"wall\"\r\n- Decorations: Filling up a 3D space using decorations\r\n- Roof: A 3D tilemap that covers the area beneath it\r\n- Garden: A 2D tilemap placing elements such as flowers, grass, etc.\r\n\r\nThen, a town is then just a 2D tilemap with objects such as houses, gardens, roads, etc.\r\n\r\nWe evolve generators for each of the above (using novelty search & some type-specific feasibility fitness functions).\r\nThe final town is generated by first obtaining a 2D level from the town network; and then filling in each type using the corresponding network. For example, if the town network outputs \"house\" at tile (0, 0), we replace that with the 3D output of the house network.\r\nDifferent networks can arbitrarily be composed, e.g. using different house networks for different houses, generating different gardens, etc.\r\n\r\nWe can extend the compositionality to e.g. create cities, which are conglomerations of towns, etc. Each artifact itself can also be extended, and generated at arbitrary size.\r\nFinally, we can recursively apply this compositionality, by creating cities using the same network that generates towns. Now, however, when this network indicates a house tile, we simply build a new town there. This can further be extended to e.g. create mega-cities.\r\n\r\nWe further adapt to the current biome by choosing our tile palette accordingly. Each tile is placed at an appropriate height\r\n\r\n\r\nThis was slightly adapted from our submission to the Evocraft 2022 Competition (evocraft.life/): https://github.com/Michael-Beukman/Evocraft22_PCGNN La team baguette This Minecraft Settlement Generator creates a coherent minecraft village. \r\nThe main purpose is to create a better version of existing village, so the generator will not use or place\r\ngame breaking blocks or items.\r\n\r\nThe village you will encounter after the generation can be a basic, a medium or an advanced one. \r\nIt will have relations with surround settlements, the relation will be from very close relation to war.\r\nThe war relation is very important because if your village has only one war relation, it will enter\r\nthe war status.\r\nYour village can be destroyed too. By many cause such as war or pillager raid.\r\n\r\nIn that village, there are unique interactions between villagers using diaries on their house.\r\nThere is a system of death, with a death book in the village and one the graveyard. \r\n\r\nOne murderer/Spy often takes place in the village with war status, so be sure to look around for any clue.\r\nThe murderer will be happy on a destroyed village by the war. Its hiding place will get bigger. \r\n\r\nEach village has its own currency system, which villagers use to sell items to the player. \r\nIn addition, villages can be linked by trade pacts.\r\nThe material system is not fully used but is represents the power of the village for commercial purposes.\r\n\r\nA chest will be placed 20 blocks above the ground containing information about generated settlement(s)\r\nThe position of all village will be indicated on the terminal too.\r\n\r\nIf you want to test more easily different village, you could use the config file. It is explained on the read.me of my repository.\r\nSet of values to check most of the cases of the generations:\r\nTest 1 : tier 0, destroyed : true, status: war, age : 0\r\nTest 2: tier 1, destroyed : false, status peaceful, age : 0\r\nTest 3: tier 2, destroyed: false, status war, age : 1\r\n\r\nGithub link: https://github.com/MightyCode/GDMC2022\r\n CharlieMDRz Third iteration on my 2020 team \"LesCharretiers\"' submission and my 2021 solo submission.\r\nDescriptions for these two submissions still stand ! My main additions this year are:\r\n- railway tracks joining the several towns of my settlements, with a template train station that rings a jingle upon departure and arrival :D\r\n- Handmade \"palette generators\" unique to each town, such that houses should be similar within a town but vary a lot from town to town.\r\n- Simple furnishing algorithm that seeds furniture along the walls, includes chests filled with MC loot tables + a few custom loot tables. Most houses should have a jukebox, take a pick from the vynils on the walls !\r\n- Animal farms should only have animal species found in the build area PolyRifts Submitting with the normal \"Zip File Submission\" was unsuccessful (probably due to a large file size), so here is the GitHub link: https://github.com/akwong189/gdmc\r\nPaper about the generator: https://drive.google.com/file/d/1oOYzoMvevR8jvwdD2TrR3YaNX8D81oGa/view?usp=sharing\r\n*Disclaimer: Vanilla Minecraft NBT files are used, but cannot be included in the GitHub due to copyright issues. Mike's Angels Our aim was to create a realistic medieval city. We use an agent-based approach: our cities are created by various agents, such as road agents and plot agents.\r\n\r\nWhen generating a city, before placing any block, we first plan it out in detail. We start by generating some basic properties of the city: its name, when it was founded, what types of wood are available in its area and where exactly it will be placed. We then use an iterative agent simulation to slowly build up the city from the center outwards. In each step, the various agents make gradual changes to the city plan. For example, the road connector agent may connect two road nodes, and the standard plot agent may reserve some plots near the current roads for buildings. Some agents are only active at specific steps: the wall agent, which plans out a protective wall around all current plots, only becomes active once. Some agents, such as the decorative plot agents and the farm agents, only become active later in the simulation, to ensure ensure that a solid city core is built up first. All plot-placing agents try to find optimal placements for their own purposes. This can be flat land for farms, high ground for watchtowers, next to roads for residential buildings, or in the water for boats.\r\n\r\nFor larger build areas, where filling them with a single city would become unnatural, we generate multiple smaller cities. To keep the generation cohesive, we connect these smaller cities with inter-city roads.\r\n\r\nAfter planning a city out in the manner described above, we build all its structures at once. There is already a lot of variation in the city layouts generated by the agent simulation, but many of the structures that we place in this phase have a lot of variation as well. We build various types of procedural houses: some houses are basic rectangles that only adapt to their plot size, while others use generated heightmaps that can yield many different shapes. Some of our structures even use Markov rules, and the wall and the farms use even more specialized construction algorithms. Even the large church that is generated in every city has randomized elements in its heightmap. PandaVision Welcome to the world of PandaVision. Until last year, we were concentrating on Japanese-style architecture. However, this year we changed from Japanese to Chinese. The new team name will be PandaVision. The name was inspired by two films, Planet of the Apes and WandaVision. Like the monkeys in Planet of the Apes, it's not humans who live in the world of PandaVison, it's somehow pandas. GW The town we created was designed so that every building always has one or more gimmicks. All gimmicks have a Redstone circuit and are designed to hide the circuit.\r\nEach building has a clean design based on the rules based on white. In addition, we made it mysterious by reducing the use of wood as much as possible.\r\nFor this code, I heard that there was no team that participated in c ++ in the past, so I am building the system from scratch. When this code is executed, all the blocks in the target area will be replaced. This time, the theme is the city in the sky, but it is also possible to create a city underground. Niels-NTG Field Lab Beta is a mysterious scientific research station that suddenly just appeared into the world. Where did it come from? Who were the staff? What were they looking for and where have they gone to?\r\n\r\nSETUP\r\nThis script works combined with the Minecraft HTTP Interface for Minecraft 1.16.5 with the Forge mod installed. The generator itself is written for Python 3.9 and requires the packages listed in requirements.txt. Start the generator by running main.py, no arguments required. By default the structures will be placed somewhere within default build area sized 128x128 at the world's zero x-z coordinates. This can be changed by setting the buidarea by running `/setbuiltarea fromX fromY fromZ toX toY toZ` in Minecraft itself before running the generator.\r\n\r\nMETHODS\r\nThe generator is built around the generator of nodes, which are not unlike the Jigsaw technique Minecraft itself uses to generate settlements such as villages. Each node contains a prefab structure contained in a NBT file + JSON file with additional information, such as what the connection points to attach other nodes, applying post-processing steps, amongst other things. Before doing any placement, the generator evaluates if the placement is possible (no terrain in the way, not exceeding built area) and also calculates a building cost for each possibility to act as an inverse probability for picking the next node. Team Sebastian Chr. This project applies the CycleGAN (Cycle-consistent generative adversarial network) model to generate Minecraft settlements.\r\nGANs are relatively new in machine learning, thus this project was the perfect subject for my masters thesis, I've trained a CycleGAN model on images of a handmade (not by me) Minecraft map replica of the city of Chicago (https://www.minecraftmaps.com/city-maps/chicago) and images akin to satellite imagery of the Minecraft overworld.\r\nThe model was trained for days, and is capable of translating a satellite-like image of the Minecraft overworld into the \"city\" domain, this means that all the features of the terrain are retained while altering content of the image. \r\nAs a result an overworld satellite image is translated into its corresponding look as a city.\r\nThe output of the CycleGAN is then mapped back into the game space (from an image) to produce cohesive roads, parks, and highrises.\r\n\r\nWhile a city is generated not much is achieved in the way of aesthetics, as roads consist only of white wool, while highrises consist only of gray wool blocks.\r\nThis project mainly explored the possibilities of applying GANs to the domain of Minecraft settlement generation, and is successful (for the most part).\r\n\r\nBecause of the overworld satellite imagery, the CycleGAN model has no sense of depth, thus can struggle to produce realistic cities when terrain heights change radically within the buildArea.\r\n\r\nThe extreme zip size is due to the inclusion of the trained models of CycleGAN along with the code. Terje Schjelderup This is a continuation of my Leifsbu generator from last year. The name of the generator translates to \"Leif's settlement\" or \"Leif's place\", and is named after Leif Erikson who built a settlement on Newfoundland a thousand years ago.\r\n\r\nThe general approach is to survey the land for suitable settlement locations, wall in a suitable perimeter for the settlement, divide the space inside the wall with roads (some roads leading to the outside world and some roads internal to the settlement), divide each area into plots, build houses on selected plots, and finally furnish the interior of the houses.\r\n\r\nThe main improvements since last year are:\r\n* Works with Minecraft 1.16 (a massive undertaking to bring it up from the old save format of Minecraft 1.12)\r\n* Houses now have interior (last year they were empty shells)\r\n* Improved shapes of buildings\r\n* Stability improvements (last year the generator failed miserably on one of the input worlds. JHU CLSP # GDMC 2022 Submission - Henry Li\r\n\r\nWelcome to Henry Li's GDMC 2022 submission!\r\n\r\n## Overview\r\n\r\nOur settlement generation procedure simulates the process in which a group of human players would settle a new area in Minecraft. We aim to capture the early settlement process, where players build rudimentary shelters with the appropriate amount of stylistic decorations (specifically, in the style of village houses) while more importantly satisfying the utility requirements of early shelters (equipped with bed(s), chests, crafting tables and furnaces). As the settlement progresses, more ambitious buildings may be added to the settlement, including enchantment tables and simple iron farms. Most of our settlement buildings are constructed out of simple building materials which would be available in the inventory of any player who's been spending enough time in their Minecraft world.\r\n\r\n## Reading the map\r\n\r\nThe build area is a 256 $\\times$ 256 $\\times$ 256 array that is very inefficient to read. This issue is amplified by the long response time of the HTTP interface mod which this submission depends on. As such, we have to rely on Minecraft's in-house chunk information in order to get a decent representation of the map.\r\n\r\nWe use the in-house \"motion blocking no leaves\" height map as the basis for our height map. As buildings and roads are added, the height map is adjusted accordingly. We also make use of a sea map which affects our building and road location choices. The sea map is calculated by comparing the \"motion blocking no leaves\" height map with the height map with the \"ocean floor\" height map.\r\n\r\nWe attempted to produce a corrected version of the height map which would account for non-geographic features such as logs, generated structures, among other things. Unfortunately, the overhead of such a procedure would be prohibitive.\r\n\r\n## Choice of starting location\r\n\r\nThe first player to jump into the map constructs a \"starter house\", a simple hut from simple materials that provides shelter for the first player. In our imaginary scenario, the first player in the group teleports to a new location. They subsequently seek to build the starter house at the most common altitude level in the area, in order to facilitate further construction. The process of choosing the starting location is very haphazard, as any Minecraft player would attest to.\r\n\r\n## Choice of subsequent building locations\r\n\r\nSubsequent buildings are constructed on plots of land that are in relative proximity to existing buildings while also being at similar altitudes. We achieve this by performing a breadth (distance)-first search, starting from existing buildings. The distance is a combination of horizontal distance and height gradient. We thus locate points on the map that are close to existing buildings (while not being too close as to induce claustrophobia), while also not being too much of a hike to reach.\r\n\r\nBased on the chosen point, we look at all the possible plots which would contain said point. The plots are chosen to minimise terraforming - excessive modifications to the landscape. This process is performed efficiently using convolution.\r\n\r\nPerforming a breadth-first search on the entire map is computationally expensive. As such, we perform early stopping in order to save time. This occasionally results in the failure to find a point that satisfy the requirements, resulting in the early stopping threshold increasing. We selected threshold values which are a reasonable trade-off between success rate and performance, while also increasing our threshold slowly during settlement generation to account for the increasing difficulty in location appropriate plots of land as the number of buildings increase.\r\n\r\n## Choice of subsequent buildings\r\n\r\nBeyond the starter house/hut, the vast majority of the subsequent buildings are small, 1-story houses that have just enough space to satisfy the utility requirements. Occasionally larger buildings would be generated, with more living quarters and space for communal activity (larger chests as well as villager job tables). On most occasions a grand diorite iron farm would be generated, the culmination of the group's activity in the area. The iron farm can only be generated once. On rare occasions an additional starter hut might be generated.\r\n\r\n## Construction of buildings\r\n\r\nWe observe that in GDPC the efficiency of geometric or list-based construction functions are the same as that of placing blocks individually. As such, we save our building blueprints in dictionary format (as block_key, point_list pairs) and read them during run time.\r\n\r\n## Road network\r\n\r\nWe aim to simulate the spontaneous nature of road building which typical player-built road systems exhibit. Each time a building is added to a settlement, a new road is constructed to connect it with either anther building or the existing road network. The road follows the shortest path that our breadth-first search produced during selection of building location. We use linear programming to ensure that roads doesn't have a height gradient more than 1 at any adjacent blocks under most circumstances (a problematic scenario which would prevent roads from being walkable) while also minimising the amount of terraforming needed.\r\n\r\nRoads are kept one block above any body of water whenever possible, so that the waterway would still be navigable. We place a small penalty on roads that cross over water.\r\n\r\n## Run instructions\r\n\r\nRun main.py to generate a settlement. main.py does not take any command line parameters; instead, important parameters can be found at the top of main.py and the user is invited to tune those parameters to their liking.\r\n\r\n### Dependencies\r\n\r\nmain.py requires a running instance of JAVA-edition Minecraft with the target Minecraft open in-game. The Minecraft client should be of version 1.16.5 and should have the [Minecraft HTTP Interface mod](https://github.com/nilsgawlik/gdmc_http_interface) version 0.4.2 installed. main.py is dependent on the [Generative Design Python Client](https://github.com/nilsgawlik/gdmc_http_client_python), version 5.0. Notable 3rd party dependencies are Numpy and Scipy (for convolution operations and linear optimisation).\r\n" Alexis and Youri - Tsukuba team The Cozy City Gen uses a simulation to generates building. The building are from templates made with structure blocks but we modify them to create diversity and adaptation to the terrain. (For example, quarry depth is dynamic) We start with a Town Hall then we add building generating food or production and houses to have beds for our settlers. The buildings are choose depending on the city needs. Each year, we place one building, then an event can happen. It can be a bad event, like an attack or a fire, this will kill settlers, add graves to the graveyard, modify a building or even make settlers build something in response. The history of the city will be printed in a book located in the Town Hall. Also, villager will displays quests in the Town Hall. There is a hidden treasure that can be found with piece of paper spread in the city's chests indicating one coordinate.