Procedural Map Generation

Abstract

This paper explores how map design effects gameplay in Age of Empires III through research and a series of playtests. We examined four different gameplay scenarios: one that encourages aggressive strategies the secone one supports defensive strategies, the third map all resources are evenly spread out, except gold and the last one players do not start with starter resources and resources are randomly spread over the map. The playtests provided data that supports the theory discussed in this paper, showing how these map elements influences players behavior. Also, this research provides a tutorial how to modify and create custom maps from scratch in Age of Empires III.

Content

• Introduction
• Existing Map Elements
• Optional Map Designs
• Testing Plan Overview
• Procedural Content Generation
• Conclusion
• Bibliography
• Appendices

Introduction

Age of Empire 3 (AoE) is a real-time strategy (RTS) game with single- and multiplayer. The game-genre, RTS, is a subgenre of strategy video games. RTS differentiates itself because it does not progress turn by turn, but instead allows players to play at the same time.

In AoE you play as a historical civilization and have to build and expand your civilization from the Exploration Era to the Industrial Age. To expand your civilization, you have to focus on collecting and managing resources, exploring the map, military conquest and economic growth. Players collect resources like food, wood and gold to construct buildings, train armies and advance through different ages to unlock new troops and technology. The ultimate goal is to eliminate your enemy(s) to win the game.

AoE contains at least 66 different maps to play on, with additional maps introduced through DLCs and updates. Each map varies in size, terrain and resources. All maps reflect a different geographical region, like Africa, Asia, Europe and America. The maps are categorized into the following categories:

• Standard Maps: These are symmetrical or asymmetrical maps that balance the gameplay by providing the players with the exact same access to resources.
• Special Maps: These maps contain special conditions that make them unique. Give examples
• Team Maps: These maps are designed for team-based gameplay, with the layout encouraging teamwork.
• Land Maps: These maps exist entirely out of land (walkable and buildable tiles), which leaves naval units and water-related strategies out of the game.
• Water Maps: These maps contain large amounts of water, making naval combat and water resources a more critical aspect of the game.
• Hybrid Maps: These maps combine the elements of water and land.

The variety of maps in AoE allows players to explore a wide range of strategies as each map presents unique challenges and opportunities, encouraging different styles of gameplay. Players can become more skilled by repeatedly playing specific maps, which can be beneficial as it allows players to tweak their strategies. However, this familiarity can create an imbalance, giving experienced players an edge over those less experienced with certain maps. This imbalance can be addressed by adding the feature of random maps, using Procedural Content Generation (PCG). This way, players would encounter new layouts every match. This could level the playing field, ensuring that no one has the advantage because they are more familiar with a specific map.

Existing Map Elements

In AoE maps are very critical to the gameplay. The maps serve as a strategic element that heavily influence how players play. The design of each map, its terrain, resources and unique features, forces players to adapt their strategies.

The placement of food, wood and gold impacts how players develop. If the resources are scarce, players are forced to take greater risk by sending their villagers farther away from the safety of their town center. On the other hand, in wood-heavy maps for example, players may adopt more defensive strategies, keeping their villagers closer to the town center, which makes it easier to protect them.

Chokepoints are geographical features such as narrow valleys and rivers. These locations are critical for defensive or offensive tactics. Controlling a chokepoint can allow a player to effectively defend against larger forces, as fewer units can pass through at once. These areas often become key strategic points in battle.

Maps without chokepoints forces players to have a completely different strategy than maps focused on chokepoints. Without natural barriers, players must focus on open field tactics.

Trade posts are map elements that provide resources. Controlling trade posts can give players a constant income. Players who control more trade posts, often have a stronger economy, which can lead to a stronger military or faster technological progress. The location of these trade posts are important to how players engage with them strategically. The farther away a trade post is from the player’s town hall, the greater the risk is in defending it.

Treasure sites are also map elements that by collecting them rewards players with free resources, or units. These treasure sites are mostly useful at an early stage.

Native American Settlement plays a strategic role. They are placed as neutral structures that can be allied with building a trade post. Once allied, players gain access to unique Native American units and technology.

Optional Map Designs

In an RTS game like AoE, the gameflow is very important. Players can start off playing very aggressively and try to win the game in a short amount of time or go for a more passive playing style and try to win with a more defensive style. The game flow is heavily influenced by the way the map is designed. In this chapter the topic is what map elements can effectively influence the players behavior in a way to create a curtain game flow is going to be discussed. (McCole, 2015)

Dynamic Resource Distribution

In AoE base building is a crucial part and can be done in a variety of ways. Resources play an important role on how players are building their base. Players must think on how to place their building to have quick access to resources while also keeping their villagers safe from enemy harassment. (McCole, 2020)

Dense vs Sparse Resources

Dense resources allow players to quickly gather a larger amount of resources. If there are many ways of gathering resources, it also provides more opportunities for enemy disruption and harassment. Players will try to secure valuable areas to boost their economy and military. The constant battles for resource control create a fast-paced gameplay with early confrontations. Sparse resource distribution often results in slower game pace. Players may have to expand their territories and use riskier strategies to secure resources. Players are more likely to go for a more defensive playstyle, as players focus on building up their economies and fortifying their positions. (Casteel, 2022)

Central Resources

When all or many resources are placed in one central point this will become an important strategic location. Players will try to block off enemy players from these locations by constant battle, building their bases around it and creating artificial chokepoints. (McCole, 2020b)

Choke Point Design

Natural Choke Points

Natural choke points are strategic areas on a map that restrict movement and provide tactical advantages. Typically, these chokepoints have single or double narrow pathways. The goal of these chokepoints is to create contested areas where players fight for control. Holding a chokepoint can significantly impact the flow of the game. The player who has control over a chokepoint gains a strong position from which to start attacking the opponent’s base. This makes controlling chokepoints a key aspect of strategic planning and highly influences the gameflow. Predictable gameplay can lead up to a stealth mate. (World of Level Design, z.d.)

Open Field Maps

In contrast open field maps lack natural choke points and allow for more varied strategies. Instead of battling over one strategic area, players can flank their opponents from different directions, destroying their villagers and slowly winning the game. Open field maps encourage dynamic gameplay as players can spread out their armies and maneuver freely across the map. This leads to less predictable and more diverse gameplay. (RTS With A Frontline Or Chokepoints Based Combat, 2024)

Risk-Reward Elements

Adding risk-reward elements to maps can further shape game flow, giving players the choice to take risks for potential rewards. Elements like treasure sites tempt players to venture outside their fortified bases, offering rewards but at the risk of leaving their defenses exposed. Similarly, trade routes or strategic control points can become high-stakes objectives that force players into conflicts over valuable resources​.

Balancing Maps

When designing maps with a specific gameplay goal in mind, the knowledge of what map elements affect player behavior is important. Based on the the principles that have been researched, four map designs have been created.

Map 1: Open field

• Map Layout: A flat, open map with no natural chokepoints, allowing for free movement.
• Resource Distribution: Dense clusters of resources are placed, enabling players to gather quickly.
• Gameplay Impact: With easy access to resources and no natural berries, players are encouraged to adopt aggressive tactics and rapid expansions.

Map 2: Dual Chokepoints

• Map Layout: This map features two chokepoints in the middle of the map between the player bases.
• Resource Distribution: Resources are sparsely spread across the map, requiring players to expand beyond their base to secure them.
• Gameplay Impact: Players are incentivized to secure the choke points for control of the map, as these areas serve as critical paths for launching attacks or defending expansions. Sparse resources mean that holding these chokepoints can provide easier access to resource patches, making them crucial for economic growth.

Map 3 Field of Fortune:

• Map Layout & Resource Distribution: All resources, except gold, are evenly spread outside the centre of the map. The centre is surrounded by natural berries with some chokepoints that function as entrances. Inside the centre are gold mines located.
• Gameplay Impact: The central gold mines become a crucial strategic objective, encouraging players to contest the area. Natural chokepoints around the centre foster intense battles, while the even distribution of other resources supports alternative strategies.

Map 4 Explorer’s Gambit:

• Map Layout & Resource Distribution: The map features a low number of resource locations. These locations contain larger-than-average quantities of resources. Unlike the other maps, players do not begin with starter resources. The map does not contain any natural barriers/chokepoints.
• Gameplay Impact: The primary goal of this map is to encourage unpredictability. Players must actively use their explores, and maybe even their villagers to scout the map and locate vital resource spots. This design encourages adaptive strategies and explorations.

Testing Plan Overview

After researching multiple gameplay elements and designing map layouts on these findings, the aim now is to find out if these map functions are effective and support the desired gameplay goal. To achieve this, playtests will be conducted.

Define Testing Goals

When conducting playtests, it is important to have clear objectives. These objectives help to ensure that the changes implemented in the map design support the intended gameplay. We are going to conduct playtests for all four scenarios. The first scenario will have the following goals:

• Resources Accessibility: Verify that resource clusters enable fast gathering, encouraging players to expand their base quickly.
• Aggressive Play Style: Check if the absence of natural choke points allows for easy troop movement and frequent skirmishes/battles.

For the second scenario the goals are as follows:

• Resources Accessibility: Verify that sparsely spread resources supports players to use riskier strategies to secure resources and go for a more defensive playstyle.
• Choke Point Control: Check if presence of chokepoints encourage players to have a more defensive playstyle.

Third scenario goals are as follows:

• Strategy: Check if players adapt to the scarcity of gold by prioritizing military units that rely on wood and food and adjusting their resource-gathering strategies.
• Central Control: Verify if players contest the central gold mines as a critical objective while utilizing natural chokepoints to fortify positions near the entrances to the gold zones.

Fourth scenario goals are as follows:

• Exploration Behavior: Check if the players actively use scouts and villagers to explore the map and locate resources areas. Also see if players take higher risk and putting their villager farther away from their town centre.
• Adaptive Strategies: Determine if players develop flexible and creative strategies in response to the unpredictable resource locations.

Set Up Test Scenarios

Random map creation is not provided within the AoE. Instead, it can be done by creating a custom script. The code language used for scripting in AoE is called eXtensible Scripting (xs). This is a custom scripting language designed for the AoE.

For the first scenario the map Central Plains has been modified to meet the requirements of the first test scenario and for the second scenario Northwest Territory has been modified. Four people are going to play a game for each scenario. The two chosen maps for the test scenario were selected because their layouts matches the requirements of the scenarios. The resources have been modified by adjusting some variables in the xs scripts. Each game will have the same circumstances so it will be easy to compare results to create a conclusion.

For the third and fourth scenario’s I have designed complete custom maps from scratch, using xs. In the chapter Age of Empires III modding Guide, the code will be explained in further debt.

Scenario 1 & 2:

In this scenario, each playtest consists of one human player and three AI-controlled opponents. The game is structured as a 2v2 match, where the human player will play as the Netherlands, their AI teammate will play as France, and the opposing AI teams will play as the UK and Spain. The AI difficulty is set to “Hard” to ensure a challenging environment.

The purpose of this scenario is to evaluate whether the gameplay aligns with the defined testing goals. To achieve this, specific criteria have been outlined in the metrics measurements to track key aspects of player and AI behavior.

At the conclusion of the playtests, the collected data will be analyzed to draw meaningful insights and conclusions. While no specific success conditions are defined beforehand, observations from the playtests will help identify patterns and areas for improvement.

Original Map (Scenario 1):

Modified Map (Scenario 1):

Original Map (Scenario 2):

Modified Map (Scenario 2):

Scenario 3:

In this scenario, each playtest consists of a one-versus-one match between a human player and a single AI-controlled opponent. The human player will play as the UK, while the AI opponent will play as the France. The AI difficulty is set to “Hard” to maintain a challenging and competitive environment.

The testing pattern and data collection remain consistent with those used in Scenarios 1 and 2 to ensure comparability, except other criteria will be observed.

Custom Map:

Scenario 4:

In this scenario, each playtest consists of a one-versus-one match between a human player and a single AI-controlled opponent. The human player will play as the UK, while the AI opponent will play as the France. The AI difficulty is set to “Hard” to maintain a challenging and competitive environment.

The testing pattern and data collection remain consistent with those used in Scenarios 1 and 2 to ensure comparability, except other criteria will be observed.

Custom Map:

Here are examples of the playtests:

Metrics Meassurements

During the playtest data was tracked and at the end of each game, AoE shows the game statistics. Relevant information have been added to an Excel sheet, wich can be used to draw conclusions. Postgame statistics can be found in the last chapter, named appendices.

Scenario 1 & 2:

Scenario 3:

Scenario 4:

Findings

The playtests for both scenarios provided valuable insights about the players behavior. Now with the data that has been collected we can see if the theory that was brought up before is correct.

Scenario 1: Aggresive Play Style

In scenario 1, the objectives was to verify if resource clusters helps players gather faster and more resources and encourage an aggressive play style also due to the absence of choke points. The data indicates that players were able to gather resources effeciently, with an average of 164890 total resource collected.

The efficient resource gatehering helped players to advance to the colonial age quickly, what gained players access to train armies which prepared the environment for skirmishes and battles. The first battles appeared early in the game and continued frequently throughout the rest of the match. The data confirms that this scenario encourages players to adopt a more aggressive play style, as evidenced by the high number of skirmishes, with an average of 15 battles per player.

The total units lost and killed shows the aggressive nature of this scenario. For example, player 2 has the highest number of units killed (286) but also lost a big number of units (156). This sort of gameplay happened to all players in scenario one, showing the high risk that comes with maps that are similar to this scenario.

Scenario 2: Defensive Play Style

In scenario 2, the aim is to see if having resources spread out and chokepoints on the map would lead players to play more defensively and take more risks to secure resources. It was noticeable that players had to send their villagers farther away from the safety of their town hall to gather resources, this a good example of players using a more risky strategy.

Players in scenario 2 played more cautiously. For example, player 3 lost 73 units but killed 319, showing a more defensive approach for battle. The lower number of battles (around 5-10 per player) suggests that players were more careful with their attacks. The cautious approach led to fewer battles and more strategic battles. Players were focused on gathering resources to reinforce their economy to build an army that was capable of eliminating the opponent in one battle.

Chokepoint played an important role by helping the players to predict from were the opponent was going to attack. Players managed to secure these chokepoints early in the game by building walls around them. Unfortunately the computer did not compete for control over the chokepoints, by building walls around it. The chokepoints became less important as expected, but still remained a key map element.

Scenario 3 Field of Fortune:

In scenario 3, the focus was on giving the players an important strategic objective, with limited gold resources and see how players adapt their strategies on it. The data shows interesting insights.

The players adapted their strategies due to the limited availability of gold by prioritizing military units (pikeman and crossbows) that required wood and food. This can be supported by the high total of recourses collected, mostly food and wood, rather than gold.

Also, there was more variety in the units used compared to scenarios 1 and 2. In scenario 3, no single military unit dominated the army, with the most frequently used unit often making up only around half of the total military forces. This variety shows that players tried out different combinations of units to deal with the limited gold and the challenges of the map, rather than relying on a single strong unit.

The findings confirm that the central gold mines became an important strategic point. Most battles happened near the choke points around the gold zone. Walls were being built around the chokepoint, to block the other players from reaching the goldmines. Notably, once a player gained control of the center, the game tended to end quickly. Blocking access to the gold made it difficult for opponents to continue fighting effectively, as they were cut off from this important resource.

Map 4 Explorer’s Gambit:

For Scenario 4, the objective was to observe how players adapt to the random placement of resources and how flexible their strategies are.

An interesting finding from the data is the significant variation in the outcomes of the games. Each match had a different duration, and in one of the three games, the player was defeated by the computer.

Additionally, players built more outposts in this scenario compared to the other scenarios. This suggests that players were prioritizing the protection of their villagers, who had to travel farther from the safety of the town center to gather resources.

Overall Conclusion

This playtest was successful, with most of the data supporting the initial theories. Scenario 1 confirmed that clustered resources and open terrain encouraged a more aggressive playstyle. In Scenario 2, sparse resources and strategic chokepoints led players to adopt a more defensive approach, delaying attacks while building stronger armies. In Scenario 3, both players and computers developed different strategies based on the circumstances they encountered. However, I struggled to determine if the test goals of Scenario 4 were met because I wasn’t sure which elements to focus on when measuring the adaptability of players to the random placement of resources. Despite this, the insights gained from all scenarios provide a strong foundation for developing procedural content generation systems for RTS games like Age of Empires.

Conclusion

The original goal of this project was to develop a Procedural Content Generation system capable of creating random maps for AoE. The aim was to reintroduce the elements of suprise for players and ensure the fairer playing field by preventing experienced layers from gaining an advantage through familiarity with specifc maps.

During the research, I explored several map elements to determine how they could enhance the gameplay experience. The findings provided valuable insights into resource distribution, choke points and risk-reward elements, all of which contribute to creating engaging and strategic maps.

However, through the process of working on this project, I discovered that modding in AoE is very limited. The limitation restricts the implementation of a fully functional PCG system. For readers intrestested in understanding these constraints, I have included a tutorial in this research that explains how to make a custom map from scratch.

Despite these obstacles, this project has laid a strong foundation for future exploration of map design in real-time strategy games. It also demonstrates how thoughtful research into map elements can lead to a deeper understanding of game balance and player engagement.

Bibliography

Bridson, R. (n.d.). Fast Poisson disk sampling in arbitrary dimensions. University of British Columbia.

Casteel, B. (2022, August 25). Food, gold, and beyond: Exploring multiple means of generating resources in RTS games. Wayward Strategy. https://waywardstrategy.com/2022/01/23/food-gold-and-beyond/

Deep Dive Dev. (2024, March 21). Poisson disk sampling: Unshrouding the secrets of uniformly distributed points [Video]. YouTube. https://www.youtube.com/watch?v=jofUe3Kjag4

McCole, C. (2015, August 25). What makes RTS games fun: Flow. GameCloud. https://gamecloud.net.au/features/opinion/what-makes-rts-games-fun-flow

McCole, C. (2020, November 24). What makes RTS games fun: Meaningful base building. Wayward Strategy. https://waywardstrategy.com/2019/03/14/what-makes-rts-games-fun-meaningful-base-building/

McCole, C. (2020b, November 24). What makes RTS games fun: Meaningful base building. Wayward Strategy. https://waywardstrategy.com/2019/03/14/what-makes-rts-games-fun-meaningful-base-building/

RTS with a frontline or chokepoints based combat. (2024, July). Reddit. https://www.reddit.com/r/RealTimeStrategy/comments/1e6g7wn/rts_with_a_frontline_or_chokepoints_based_combat/

The Coding Train. (2016, August 22). Coding challenge #33: Poisson-disc sampling [Video]. YouTube. https://www.youtube.com/watch?v=flQgnCUxHlw

World of Level Design. (n.d.). 6 principles of choke point level design for multiplayer maps as seen in CS . https://www.worldofleveldesign.com/categories/csgo-tutorials/csgo-principles-choke-point-level-design.php

Age of Empire III modding Guide

This chapter is going to be a guide how to create custom maps from scratch in AoE.

Step 1: Locate the Map Files

The first step is to navigate to the AoE installation directory on your pc and open the RandMaps folder in which the AoE maps are stored. In case you downloaded AoE from Steam, you will be most likely to find the directory here: C:\Program Files (x86)\Steam\steamapps\common\AoE3DE\Game\RandMaps.

When you have opened the RandMaps folder, you notice there are two types of files stored: .xs and .xml files. The .xs file is the script file for the map. It contains the logic and instructions for generating a map. The .xml file is the metadata file for the map. This provides the information about the map that the game displays in the loading stage.

Step 2: Create .xs and .xml Files

Create a .xs and .xml file with the same name as your desired map name and save both files in the RandMaps folder. Make sure to set the Save as Type field to All Files. Example: CustomMap.xs and CustomMap.xml.

Step 3: Edit the Map Logic

Open the .xs file in a text editor, like Notepad or Visual Studio Code. In this script create a main method, this is going to be the main entry point for your custom map.

void main(void) {
    
}

The first step in any .xs file is to define the size of the map. It is important to scale the map size based on the number of players and whether the map size is set to normal or large. Below is an example of how this can be done.

void main(void) {
    int myTiles = 8000; /* This is a typical variable for the map size */

    if (cMapSize == 1) { /* This if function checks if map was selected normal or large. cMapSize (1=large, 0=normal) */
        myTiles = 12000; /* This is a typical variable for the map size, when map chosen large! */
        rmEchoInfo("Large map"); /* Output information for the RMS debugger! */
    }

    int mySize = 2.0 * sqrt(cNumberNonGaiaPlayers * myTiles);
    /* Since the map size is proportional to the square root of the player number, */
    /* the map area will be proportional to the player number! */
    rmEchoInfo("Map size=" + mySize + "m x " + mySize + "m"); /* RMS debugger output */
    rmSetMapSize(mySize, mySize); /* Build the map size */
}

After setting the map size, the next step is to define constraints. Constraints are like rules or boundaries that manage how objects are placed on the map. They make sure objects, such as resources and terrain features do not overlap each other. Constrains function as classes in which we are going to define the rules and store the objects.

Define classes:

    int treeConstraint = rmCreateClass("TreeClass");         
    int startingAreaConstraint = rmCreateClass("startingArea");

Add objects to the classes:

    rmAddObjectDefToClass(treeID, treeConstraint);
    rmAddAreaToClass(cliffs, startingAreaConstraint);

Define constaint rules:

The syntax of a distance constraint typically includes:

• descriptive string: Explains the purpose of the constraint to other developers.
• variable (class): Specifies the class of objects this constraint applies to.
• float: Sets the minimum required distance between objects.

    int forestConstraint = rmCreateClassDistanceConstraint("forest vs forest", treeConstraint, 40.0);
    int avoidStartinArea = rmCreateClassDistanceConstraint("stuff vs starting area", startingAreaConstraint, 12.0);

Now that we have defined the constraints, the next step is to create the actual objects that will appear on the map.

• rmCreateObjectDef defines a new object definition. You have to define the object first because you need to assign it properties before placing it on the map.
• rmAddObjectDefItem this function adds specific objects to the object definition. treeID associates the item with the object definition. “treeNewEngland” specifies a particular type of tree. rmRandInt(6, 9), this random integer determines how many of this type of tree wil be placed in the group. 10, is the radius in which the trees will be placed around a central point.

    int treeID = rmCreateObjectDef("trees");
    rmAddObjectDefItem(treeID, "treeNewEngland", rmRandInt(6, 9), 10);

After defining the objects and specifying their properties (like type, quantity, and radius), the next step is to actually place the objects on the map. This is done using the rmPlaceObjectDefAtLoc function. This function takes the object definition (which is a collection of objects that share properties) and places it at a specific location on the map.

• treeID: object definition.
• i: this mean to which player the object belongs. To make an object neutral, give the object the value zero. This way the object does not belong to any player (usefull for objects like resources that everyone should have access to).
• x: position on the x-axis.
• y: position on the y-axis.

    rmPlaceObjectDefAtLoc(treeID, i, x, y);

Step 4: Edit .xml file

This XML file defines a custom map’s metadata for the game. Thetag includes details such as the map’s description (“This is a custom map”), the display name (“CustomMap”), the image path for its background, and the screenshot images to show in the map selection screen. Thetags specify the paths to the screenshot images that represent the map visually in the game’s interface.

<?xml version = "1.0" encoding = "UTF-8"?>
<mapinfo detailsText = "This is a custom map" imagepath = "ui\random_map\all_maps" displayName = "CustomMap" cannotReplace = ""
loadDetails="" loadBackground="ui\random_map\all_maps">
    <loadss>ui\random_map\new_england\new_england_ss_01</loadss>
    <loadss>ui\random_map\new_england\new_england_ss_02</loadss>
    <loadss>ui\random_map\new_england\new_england_ss_03</loadss>
</mapinfo>

Step 5: Testing

Start AoE and open the tool editor. Click on files and select your own custom map.

Appendices

Figure A1: Shows postgame statistics about resources about scenario 1 and player 1. Figure A2: Shows postgame statistics about military about scenario 1 and player 1. Figure A3: Shows postgame statistics about resources about scenario 1 and player 2. Figure A4: Shows postgame statistics about military about scenario 1 and player 2. Figure A5: Shows postgame statistics about resources about scenario 1 and player 3. Figure A6: Shows postgame statistics about military about scenario 1 and player 3. Figure A7 Shows postgame statistics about resources about scenario 1 and player 4. Figure A8: Shows postgame statistics about military about scenario 1 and player 4. Figure B1: Shows postgame statistics about resources about scenario 2 and player 1. Figure B2: Shows postgame statistics about military about scenario 2 and player 1. Figure B3: Shows postgame statistics about resources about scenario 2 and player 2. Figure B4: Shows postgame statistics about military about scenario 2 and player 2. Figure B5: Shows postgame statistics about resources about scenario 2 and player 3. Figure B6: Shows postgame statistics about military about scenario 2 and player 3. Figure B7: Shows postgame statistics about resources about scenario 2 and player 4. Figure B8: Shows postgame statistics about military about scenario 2 and player 4.