# Pegasus: A Simulation Tool to Support Design of Progression Games

Authors: Marcelo Arêas R. da Silva; Geraldo Bonorino Xexéo
Journal: International Journal of Computer Games Technology
 (2018)

---

## Abstract

The process of designing a game involves many phases. We can summarize the work of the game designer as satisfactorily converting the idea in their mind to a digital game, which is not a simple task. Therefore, game designers should have a variety of tools to assist them. However, there are not that many specialized tools to support the game design process. Herein, we describe the experience of using Pegasus to design a part of a game. We propose an environment to simulate progression games based on game design patterns. Thus, we described the interaction of the game designer with Pegasus in such an environment, in order to support the process of creating, testing, and refining game elements before proceeding to the programming phase. Each configuration of the game elements corresponded to a simulation that could be performed multiple times, like in discrete event simulation. The results showed that Pegasus has the potential to support game design. Additionally, we presented some support components that were created to facilitate the use of the tool.


---

## Body

## 1. Introduction

The digital games industry is growing fast. A survey conducted annually in the United States indicated that consumer spending on digital games increased 42% from 2010 to 2016. The same research indicated that there is at least one person in every United States household who plays three or more hours of digital games a week [1]. There was a time when people thought that videogames were aimed only at children, but that is a fallacy; there are studies that characterize the profile of older players [2].Despite such growth, the process of creating a digital game can be as complex as creating an information system. There are many steps—from designing the initial idea to reaching the final product—involved in conceiving a digital game. Several authors have dealt with this subject [3–7]; some for specific types of games (e.g., serious games [8, 9]), but few have attempted to support the design process by using formal methods [10]. In fact, as stated by Neil [11] and Koster [12], there is a lack of tools to support game design.If the game designer could test scenarios and refine the game prior to the programming phase, it is reasonable to say that product quality would improve and time would be saved. Thus, this paper is part of a thesis [13] and we propose an environment to simulate games that have a progression-based structure.This paper is organized as follows: Section2 describes some related works in this research area; Section 3 presents our proposal of an environment to simulate progression games; Section 4 introduces the Pegasus simulation tool; Section 5 reports on the experience using the simulator to support the design of part of a game; and finally, Section 6 presents the conclusions and future work.


## 2. Literature Review

TheMachinations framework is a way to represent games by highlighting their internal economy, focusing on the relationships of the game mechanics and the dynamic gameplay that emerges from these relationships [14]. It works as a visual language, composed of diagrams and components, in which the game designer can create, simulate, and test the internal game economy.Machinations is satisfactory for simulating emergence in games, but is not suitable for progression games. Dormans [15] tried to shape emergent mechanics to produce progressive experiences; however, due to limitations ofMachinations, only an evolution of the same structure of the emergence pattern was achieved to represent the constant increase in difficulty.The simulation technique is often used in several areas, for example, analysing production processes, optimizing transport networks, evaluating user behaviour, and learning [16, 17]. In the study of Nummenmaa et al. [18], the authors proposed simulating gameplay as a design tool. They described a case study with implementation of a simulation model for a game using a simulation software package.Evaluating player enjoyment is also a common theme in this area of research; there are works presenting models for analysing game playability [19, 20]. Syriani and Vangheluwe [21] proposed an approach to improve game playability by simulating the movement of characters with simple mechanics as well as by evaluating player behaviour.Even if it was just a theoretical foundation, Grünvogel [10] introduced formalism for designing games from small submodels, due to complex games being difficult to simulate. Gradually, those models would be combined into more complex systems to represent the game as a whole.


### 2.1. Progression and Emergence in Games

Among the many genres and subgenres of digital games, a game is classified into these different genres depending on the observer [22]. However, according to Juul [23], we can say that there are two basic structures of games: emergence and progression.In a game structured by emergence, a small set of rules combine to produce large game variations, and players then create strategies to deal with the random world [23]. We found emergence in strategy, card, and sports games, as well as in chess and tournaments. On the other hand, progression deals with a controlled sequence of events and often tells a story. The game designer plans each level and its challenges. The player must overcome the events in a given sequence to advance in the game [23]. In general, adventure and actions games are based on progression structure.Most modern digital games fit the two definitions; that is, they contain elements of emergence and progression [14]. For example,Assassin’s Creed,Red Dead Redemption,GTA,The Division, andDestiny are open world games, in which a player controls a character with freedom to explore and perform various activities. However, there are optional and main missions; the latter usually unlock new places when completed. These games contain a progression structure and tell a story, but despite this, each mission has its own emergent elements.


## 2.1. Progression and Emergence in Games

Among the many genres and subgenres of digital games, a game is classified into these different genres depending on the observer [22]. However, according to Juul [23], we can say that there are two basic structures of games: emergence and progression.In a game structured by emergence, a small set of rules combine to produce large game variations, and players then create strategies to deal with the random world [23]. We found emergence in strategy, card, and sports games, as well as in chess and tournaments. On the other hand, progression deals with a controlled sequence of events and often tells a story. The game designer plans each level and its challenges. The player must overcome the events in a given sequence to advance in the game [23]. In general, adventure and actions games are based on progression structure.Most modern digital games fit the two definitions; that is, they contain elements of emergence and progression [14]. For example,Assassin’s Creed,Red Dead Redemption,GTA,The Division, andDestiny are open world games, in which a player controls a character with freedom to explore and perform various activities. However, there are optional and main missions; the latter usually unlock new places when completed. These games contain a progression structure and tell a story, but despite this, each mission has its own emergent elements.


## 3. Proposal of Environment to Simulate Progression Games

Björk and Holopainen [24] presented a large collection of patterns in game design. We studied patterns and their relationships in order to propose a favourable environment for simulating progression games. Table 1 shows the relationships among some patterns commonly found in games with a progression-based structure.Table 1
Patterns in game design and their relationships.
Pattern Instantiates Instantiated by Game world - Levels Levels Game world - Inaccessible areas Traversing - Enemies Combat Boss monsters, Avatars, Units, Elimination Boss monsters Enemies Elimination Obstacles Inaccessible areas - Avatars Enemies - Units Enemies, Resources - Tools Improved abilities, Rewards Pick-ups Pick-ups Tools Power-ups, Resources Power-ups Pick-ups, Improved abilities - Lives Resources - Resources Pick-ups, Rewards, Penalties Units, Lives Combat Randomness, Resources Elimination, Enemies Movement - Traversing Improved abilities Rewards Power-ups, Tools Rewards Balancing Improved abilities, Tools Penalties - Elimination, Resources Elimination Combat, Penalties, Enemies, Boss Monsters - Traversing Movement - Randomness Balancing Combat Balancing - Rewards, Randomness


### 3.1. Types of Progression Games Covered

The proposed environment supports games with elements that are typical of role-playing and adventure games and could involve single-player or multiplayer games. The player controls a character or a team, starts from point A, faces some challenges, and tries to reach point B alive. During the journey, the player visits several places, which may contain enemies, items, and/or obstacles. Places can be mandatory or optional, which results in many possible ways to reach the end. The degree of complexity depends on the player's creativity in combining elements to create the game world.Games of theDungeon Crawl genre—such asRogue,Gauntlet,Dungeonlike, andDiablo—fit the described characteristics very well. Furthermore, the proposed environment is also suitable for any game which involves entering a place, resolving conflicts, collecting items, and moving on.


### 3.2. Description of the Environment

The environment is composed of aSimulation Engine,Input Artifacts, andOutput Artifacts; see Figure 1. TheInput Artifacts areTeam,World, andSimulation Settings.Team is made up ofCharacters, which can beHeroes orFoes.Places are arranged inside theWorld and may containTeams ofFoes and collectibleItems.Figure 1
The simulation environment.TheSimulation Settings should allow the game designer to adjust and test distinct scenarios to obtain different results.Output Artifacts are data collected—in an easy-to-read format—from all of the simulation events performed. Thus, data could be processed to generate valuable information, reports, statistics, summarization, and graphs.The diagram in Figure2 illustrates how the game designer should act in the environment. The inspiration of a game designer remains fundamental. The process starts after the game designer constructs theInput Artifacts to feed the simulator; we call thisInitial Design. The designer then starts a test cycle, performing simulations (Simulations), analysing the results (Analysis), and, if applicable, adjusting some elements and settings to start new simulations (Refinement). Once the game designer approves the results, the participation of the simulator is concluded (End), and everything is set to move forward to the programming phase of the creation process.Figure 2
Actions of game designer.


### 3.3. Simulation Engine Requirements

The operations of theSimulation Engine must fulfill certain requirements to ensure the proper functioning of the proposed environment (Figure 3). The first step is to receive theInput Artifacts, then to restore all of them to their initial conditions. Thereafter, with theHero orTeamofHeroes at the first place, the conflict should be solved in the following order:(i)
Preconflict: preparation for the conflict;Heroes can useItems to improve or restore attributes.(ii)
Conflict: resolve the threats—such as battles—at the particular place.(iii)
Postconflict:Heroes collect pick-upItems as rewards, if they exist.Figure 3
Simulation Engine requirements.Heroes then move to the next place, and the aforementioned process starts again until one of the following happens:(a)
Heroes are in the final place or(b)
allHeroes are dead.In both cases the simulation ends.During a simulation, theSimulation Engine must record all data from each event as it happens. Such events can be battle logs; how the values of each attribute of the characters are modified, items collected, items used, keys found, etc. At the end of a simulation, all the collected data should be summarized.The described process comprises a single simulation. At this point, the next simulation can be performed or, if it was the last one, theSimulation Engine consolidates the results from all previous simulations and provides the data. In the subsequent sections we show some examples of processed data.


## 3.1. Types of Progression Games Covered

The proposed environment supports games with elements that are typical of role-playing and adventure games and could involve single-player or multiplayer games. The player controls a character or a team, starts from point A, faces some challenges, and tries to reach point B alive. During the journey, the player visits several places, which may contain enemies, items, and/or obstacles. Places can be mandatory or optional, which results in many possible ways to reach the end. The degree of complexity depends on the player's creativity in combining elements to create the game world.Games of theDungeon Crawl genre—such asRogue,Gauntlet,Dungeonlike, andDiablo—fit the described characteristics very well. Furthermore, the proposed environment is also suitable for any game which involves entering a place, resolving conflicts, collecting items, and moving on.


## 3.2. Description of the Environment

The environment is composed of aSimulation Engine,Input Artifacts, andOutput Artifacts; see Figure 1. TheInput Artifacts areTeam,World, andSimulation Settings.Team is made up ofCharacters, which can beHeroes orFoes.Places are arranged inside theWorld and may containTeams ofFoes and collectibleItems.Figure 1
The simulation environment.TheSimulation Settings should allow the game designer to adjust and test distinct scenarios to obtain different results.Output Artifacts are data collected—in an easy-to-read format—from all of the simulation events performed. Thus, data could be processed to generate valuable information, reports, statistics, summarization, and graphs.The diagram in Figure2 illustrates how the game designer should act in the environment. The inspiration of a game designer remains fundamental. The process starts after the game designer constructs theInput Artifacts to feed the simulator; we call thisInitial Design. The designer then starts a test cycle, performing simulations (Simulations), analysing the results (Analysis), and, if applicable, adjusting some elements and settings to start new simulations (Refinement). Once the game designer approves the results, the participation of the simulator is concluded (End), and everything is set to move forward to the programming phase of the creation process.Figure 2
Actions of game designer.


## 3.3. Simulation Engine Requirements

The operations of theSimulation Engine must fulfill certain requirements to ensure the proper functioning of the proposed environment (Figure 3). The first step is to receive theInput Artifacts, then to restore all of them to their initial conditions. Thereafter, with theHero orTeamofHeroes at the first place, the conflict should be solved in the following order:(i)
Preconflict: preparation for the conflict;Heroes can useItems to improve or restore attributes.(ii)
Conflict: resolve the threats—such as battles—at the particular place.(iii)
Postconflict:Heroes collect pick-upItems as rewards, if they exist.Figure 3
Simulation Engine requirements.Heroes then move to the next place, and the aforementioned process starts again until one of the following happens:(a)
Heroes are in the final place or(b)
allHeroes are dead.In both cases the simulation ends.During a simulation, theSimulation Engine must record all data from each event as it happens. Such events can be battle logs; how the values of each attribute of the characters are modified, items collected, items used, keys found, etc. At the end of a simulation, all the collected data should be summarized.The described process comprises a single simulation. At this point, the next simulation can be performed or, if it was the last one, theSimulation Engine consolidates the results from all previous simulations and provides the data. In the subsequent sections we show some examples of processed data.


## 4. Pegasus: Progression Game Simulator

We built Pegasus to implement our proposal. It was constructed in the Python programming language [25] to comply with best practices for software design patterns [26]. In this section, we present the architecture, related artifacts, and support components.


### 4.1. Architecture and Input Artifacts

Pegasus architecture is divided into layers (see Figure4), as follows:(a)
Interface: where all the processes are initiated. TheInput Artifacts are forwarded to the subsequent corresponding layers.(b)
Component: collection of essential and nonessential modules that facilitate usage and give new configuration options to the game designer. It is referred to as theComponentlayer because new modules can be built and incorporated into it.(c)
Simulation: the simulation process core was developed respecting the guidelines of our proposal.(d)
Result Storage: it stores all simulation results; it works concurrently with theSimulationlayer.(e)
Result Processing: it generates reports and graphs from the collected data.Figure 4
Pegasus architecture.Grey arrows represent the sequence of events, whereas white arrows indicate that a layer acts upon another.TheInput Artifacts are class objects representing the game elements and simulation settings. Figure 5 shows a class diagram with the relationships.Figure 5
Class diagram for Input Artifacts.ACharacter, which can be either aHero orFoe, is part of aTeam and has a set ofAttributes andItems. TheAttributes define the kind of action aCharacter is capable of. There are four distinct types ofAttributes, all of which affect and are affected by battles:life,attack,defense, andagility. Thelifeattribute defines if aCharacter is still alive; thus, the absence of this attribute means that aCharacter does not participate in battles. Theattack attribute is essential to aCharacter inflicting damage on others. Thedefense attribute is the capacity to reduce damage suffered. Finally, theagility attribute influences how fast aCharacter can perform actions when in battle.ThePlaces can haveTeams,Items, or nothing. ThePlaces connect to each other; aTeam ofHeroes tries to find a way from the first to the finalPlace. TheItems may be weapons or potions for temporarily or permanently improving some of theAttributes; for example, a key to aPlace that would otherwise be inaccessible. This key/lock system is frequently found in a large range of games.Once these elements are prepared, they are all encompassed by the World.TheSimulation Settings comprise a set of options to guide the behaviour of some components. More details are introduced in the subsequent subsections.


### 4.2. Output Artifacts

TheResult Storagelayer records all events that have occurred in the simulations, thus satisfying what was described in our proposal. Subsequently, theResult Processinglayer generates summary and detailed reports. Figure 6 contains snippets of some reports as examples.Figure 6
Simulation reports: (a) summary report, (b) consolidated results, and (c) detailed report.
(a) (b) (c)Both theSummary Report (a) and theDetailed Report (c) contain data from each simulation, composed of the places entered, number of turns in each battle, and items found. At the end of each simulation there is a summary with the following: total number of places visited, names of all items found, number of the place where the simulation ended, total number of turns, average number of turns, and the order of the places visited. TheDetailed Report (c) also contains logs of each battle; the values of the attributes vary according to each battle.In each report, the consolidated results (b) contain information on all simulations and are shown after all simulations, at the end of the report. They state the number of times theHeroes concluded a simulation, average number of places visited, average number of items found, average number of turns per simulation, average number of turns per place, and the most common order of the places visited.One of the modules developed in theComponentlayer acts on theResult Storage layer to generate graphs from the collected data. Currently, the following graphs can be generated:(a)
Bar chart and pie chart for the number of times a simulation ends in a place.(b)
Scatter plot and Box plot for the variation in aHero attribute at each place, for all simulations.(c)
Line chart for the average value of the attributes of everyHero at each place.(d)
Scatter plot for the variation in number of turns at each place, for all simulations.(e)
Line chart for the most common order of places visited.(f)
Bar chart for the order in which the different places were visited.(g)
Pie chart with the percentage of successes and failures of theTeam ofHeroes.


### 4.3. Support Components

We created an XML format in order to create the elementsWorld,Place,Character andItem, as well as an XML reader to read files with this format and to create the corresponding objects. As this reader was not a part of the simulator, we preferred to put it here. The next components are part of theComponentlayer. One of them is the module to support graph generation, which was introduced in the previous subsection. The other modules operate according to the options set inSimulation Settings.Here we show a list with the names and options available for each component developed so far:(a)
Movement strategy: next place, random place, farthest place, prioritized unvisited places.(b)
Strategy for choosing character to attack in battle: pick randomly, pick character with highest value for a particular attribute, and pick character with lowest value for a particular attribute.(c)
Strategy for choosing character to benefit from item: same as previous.(d)
Battle mechanics: alternating turn system; active time battle system.(e)
Randomness generator: choose minimum and maximum bonus value for attacking and defending.(f)
Output settings: set the path on the computer to save theOutput Artifacts.(g)
Graph generator: inform the relationship of the graphs to be generated.Pegasus’s architecture was designed to permit the addition of new options. These options are relatively simple and only the first ones created. There are other studies in research areas related to the topics covered in these options that could be adapted and incorporated into our simulation system.


## 4.1. Architecture and Input Artifacts

Pegasus architecture is divided into layers (see Figure4), as follows:(a)
Interface: where all the processes are initiated. TheInput Artifacts are forwarded to the subsequent corresponding layers.(b)
Component: collection of essential and nonessential modules that facilitate usage and give new configuration options to the game designer. It is referred to as theComponentlayer because new modules can be built and incorporated into it.(c)
Simulation: the simulation process core was developed respecting the guidelines of our proposal.(d)
Result Storage: it stores all simulation results; it works concurrently with theSimulationlayer.(e)
Result Processing: it generates reports and graphs from the collected data.Figure 4
Pegasus architecture.Grey arrows represent the sequence of events, whereas white arrows indicate that a layer acts upon another.TheInput Artifacts are class objects representing the game elements and simulation settings. Figure 5 shows a class diagram with the relationships.Figure 5
Class diagram for Input Artifacts.ACharacter, which can be either aHero orFoe, is part of aTeam and has a set ofAttributes andItems. TheAttributes define the kind of action aCharacter is capable of. There are four distinct types ofAttributes, all of which affect and are affected by battles:life,attack,defense, andagility. Thelifeattribute defines if aCharacter is still alive; thus, the absence of this attribute means that aCharacter does not participate in battles. Theattack attribute is essential to aCharacter inflicting damage on others. Thedefense attribute is the capacity to reduce damage suffered. Finally, theagility attribute influences how fast aCharacter can perform actions when in battle.ThePlaces can haveTeams,Items, or nothing. ThePlaces connect to each other; aTeam ofHeroes tries to find a way from the first to the finalPlace. TheItems may be weapons or potions for temporarily or permanently improving some of theAttributes; for example, a key to aPlace that would otherwise be inaccessible. This key/lock system is frequently found in a large range of games.Once these elements are prepared, they are all encompassed by the World.TheSimulation Settings comprise a set of options to guide the behaviour of some components. More details are introduced in the subsequent subsections.


## 4.2. Output Artifacts

TheResult Storagelayer records all events that have occurred in the simulations, thus satisfying what was described in our proposal. Subsequently, theResult Processinglayer generates summary and detailed reports. Figure 6 contains snippets of some reports as examples.Figure 6
Simulation reports: (a) summary report, (b) consolidated results, and (c) detailed report.
(a) (b) (c)Both theSummary Report (a) and theDetailed Report (c) contain data from each simulation, composed of the places entered, number of turns in each battle, and items found. At the end of each simulation there is a summary with the following: total number of places visited, names of all items found, number of the place where the simulation ended, total number of turns, average number of turns, and the order of the places visited. TheDetailed Report (c) also contains logs of each battle; the values of the attributes vary according to each battle.In each report, the consolidated results (b) contain information on all simulations and are shown after all simulations, at the end of the report. They state the number of times theHeroes concluded a simulation, average number of places visited, average number of items found, average number of turns per simulation, average number of turns per place, and the most common order of the places visited.One of the modules developed in theComponentlayer acts on theResult Storage layer to generate graphs from the collected data. Currently, the following graphs can be generated:(a)
Bar chart and pie chart for the number of times a simulation ends in a place.(b)
Scatter plot and Box plot for the variation in aHero attribute at each place, for all simulations.(c)
Line chart for the average value of the attributes of everyHero at each place.(d)
Scatter plot for the variation in number of turns at each place, for all simulations.(e)
Line chart for the most common order of places visited.(f)
Bar chart for the order in which the different places were visited.(g)
Pie chart with the percentage of successes and failures of theTeam ofHeroes.


## 4.3. Support Components

We created an XML format in order to create the elementsWorld,Place,Character andItem, as well as an XML reader to read files with this format and to create the corresponding objects. As this reader was not a part of the simulator, we preferred to put it here. The next components are part of theComponentlayer. One of them is the module to support graph generation, which was introduced in the previous subsection. The other modules operate according to the options set inSimulation Settings.Here we show a list with the names and options available for each component developed so far:(a)
Movement strategy: next place, random place, farthest place, prioritized unvisited places.(b)
Strategy for choosing character to attack in battle: pick randomly, pick character with highest value for a particular attribute, and pick character with lowest value for a particular attribute.(c)
Strategy for choosing character to benefit from item: same as previous.(d)
Battle mechanics: alternating turn system; active time battle system.(e)
Randomness generator: choose minimum and maximum bonus value for attacking and defending.(f)
Output settings: set the path on the computer to save theOutput Artifacts.(g)
Graph generator: inform the relationship of the graphs to be generated.Pegasus’s architecture was designed to permit the addition of new options. These options are relatively simple and only the first ones created. There are other studies in research areas related to the topics covered in these options that could be adapted and incorporated into our simulation system.


## 5. Results

In this section we report on the experience using Pegasus to support the design of a level of an adventure type of game. In this game, a group of three heroes with different abilities need to reach the end of the map and defeat the boss who is there. On the way they may encounter some foes and collectible items.The imagined level has seven different places, and all of them have some enemies to confront. Place 2 has a key. If the heroes do not possess this key it is not possible to enter place 6. Place 4 has a shield to improve defense. Places 5 and 6 have potions to restore life, and place 6 has a sword to improve attack. These places are part of the world, as Figure7 shows. Table 2 shows the enemies and items at each place, and Table 3 contains the chosen settings for the simulations. The attributes of the characters were not included in order to keep the tables brief.Table 2
Foes and items at each place.
Place Foes Items 1 4 goblins - 2 5 goblins, 1 orc Silver key 3 3 goblins, 1 troll - 4 6 goblins Defense shield 5 2 goblins, 1 orc, 1 troll Life potion 6 2 orcs Silver lock, life potion, and sword 7 Warlock (Boss) -Table 3
Simulation settings.
Setting Option chosen Movement strategy Random place Character to attack in battle Randomly picked Character to benefit from item Randomly picked Battle mechanics Active time battle system Randomness generator for attack Min 0% and max 60% Randomness generator for defense Min 0% and max 30%Figure 7
World map for the adventure game.We performed 10,000 simulations in a computer with an Intel Core i5 processor (5th generation, 8 GB RAM), which took 9 min 48 s. The following are the consolidated results of the Summary Report: heroes’ successes: 985 (9.85%); heroes’ failures: 9015 (90.15%); average number of places visited: 6.31; average number of items found: 3.37; average number of turns per simulation: 205.09; average number of turns per place: 35.47; and most common order of places visited: 1, 3, 4, 5, 7–1292 times (12.92%). We assembled some interesting graphs in Figure 8.Figure 8
Simulation results from the first iteration: (a) average life at each place, (b) number of turns at each place, (c) life of the AmazonHero at each place, and (d) place where simulation ended.
(a) (b) (c) (d)Upon analysing (d), we could see that the heroes arrived at the final place 70.5% of the time, which seems to be a good number. However (a) and (c) indicate that they arrived with a low life value.There are several ways to change the balance of the game. Due to the heroes being successful only 9.85% of the time, we wanted to increase the success rate, but without changing the attributes of the final boss. In order to do this, we thought of some options like adding new power items to the map or decreasing some attribute of the enemies. In the end, we chose to decrease the number of enemies at Place 5, due to it being the place where the battles lasted the longest—see (b)—and where a big drop in life value occurred; see (a) and (c).Thus, in the new configuration, we removed one goblin and one troll from Place 5. After another 10,000 simulations (in 10 min 4s), the new results were as follows: heroes’ successes: 4469 (44.69%); heroes’ failures: 5531 (55.31%); average number of places visited: 6.65; average number of items found: 4.11; average number of turns per simulation: 199.65; average number of turns per place: 32.56; and most common order of the places visited: 1, 3, 4, 5, 7–1280 times (12.8%). The new graphs are shown in Figure9.Figure 9
Simulation results from the second iteration: (a) average life at each place, (b) number of turns at each place, (c) life of the AmazonHero at each place, and (d) place where simulation ended.
(a) (b) (c) (d)Now the heroes reached the final place almost every time (97.4%); see (d). We can see in (a) and (c) that the curve from place 4 to place 5 became smoother. Also, the number of turns at each place decreased, as we had planned.We considered the results of this iteration to be satisfactory; therefore, we finished the refinement phase. However, a new cycle could be started in order to test other configurations. This process can be repeated extensively until an ideal configuration producing the expected results is achieved.


## 6. Conclusions and Future Work

In this paper, we proposed an environment to support the design of games with a progression-based structure. We studied the well-known patterns in game design, and highlighted the ones typically found in the kind of games in which we were interested. We introduced Pegasus—a simulation tool created according to our proposal—and described its architecture and how it operates. We also developed some support components that can be improved and expanded.Pegasus showed potential to be a valuable tool in assisting game designers with their tasks. The ability to test the variation of scenarios—even during the design phase of a game’s production—is a great benefit.In our tests, we noticed that varying the strategy for choosing the character to attack in battle can produce different results to those using characters picked randomly. We believe that therandom strategy is the most appropriate for evaluating what the behaviour of an ordinary player would be. Moreover, adjusting the strategy gives an idea of how players with more skill could behave. Similarly, it is possible to test different strategies for the behaviour of enemies. Thus, this is a useful feature to discover the best configurations for multiple difficulty levels of the same game.For future work, we intend to create new modules as well as new options for the existing modules of theComponentlayer, starting with a new battle system. We also intend to make some improvements so that the designer could prepare more than one scenario, which would lead to the simulations producing collections of results.



---

*Source: 9341032-2018-12-02.xml*