In this chapter, the results, considerations, and evaluations of the previous chapters get combined to create conclusions that allow answering the fundamental question of this work.
8.1. In-game economies
The economic systems of video games show many similarities with the economic systems utilized in the real world. The main difference between them is that in the real world every economic entity wants to grow, while in the economic systems of games, this is only true for player entities. The goals of all other economic entities of a game can be controlled to fit the goals of the design.
Because of this, it is assumable, that the or at least one of the better approaches to creating economic systems for games is, to create a system based on the rules and patterns that can be seen in real-world economic systems. This system should be tested for problems by utilizing tools like Machinations (Dormans, n.d.) and then be adjusted to fit the design goals utilizing the freedom given by the ability to control the economic goals of all non-player entities.
8.2. Controlling player possessions in video games
For this work, three different concepts were tested utilizing six different approaches. These concepts are: Adding more possibilities to spend earned currency, limiting the overall amount of currency a player can obtain and introducing negative feedback loops (Salen & Zimmerman, 2004, p. Chapter 18) that scale the number of possessions a player has.
The overall evaluation of those tests is, that:
Adding more possibilities to spend earned currency leads to an overall decrease in the amount of possessions players have, but has no real effect on extreme cases.
Limiting the overall amount of currency a player can obtain does not affect the amount of possessions players have at all but creates fail states in which nothing is left in the game.
Introducing negative feedback loops (Salen & Zimmerman, 2004, p. Chapter 18) that scale the number of possessions a player has actively reduced the amount of possessions players have while also controlling the strength and amount of extreme cases, but can be problematic to explain to the player within the logic of the game world.
A more detailed overview of all prototypes can be found at: https://philippstenger.com/wp-content/uploads/2019/02/EconomySystems_ExcelDocumentation.7z.
The Prototypes can be found at: https://philippstenger.com/wp-content/uploads/2019/02/EconomySystems_MachinationsPrototypes.7z.
8.3. Use cases of controlling player possessions in video games
The use cases of the results of this work will usually revolve around a specific problem discovered during the development of a project and are therefore very project dependent.
Common problems this work will try helping to solve are adjusting NPC-merchant prices in a way that allows for interesting choices for the player, handing currency to the player in a way that allows it to be meaningful until the end of a game and the creation of economic systems meant for long-term use while allowing a for the controlled level of inflation.
8.4. Application of the results of this work in financial in-game economic systems
It can be said, that based on the results of the evaluation of the created prototypes, it is possible to adjust the amount of currency a player is capable of obtaining and needs to spend within any duration of time. The problem is, that achieving this goal is often in opposition to the desired design goals of a project. Because of this, it becomes necessary to evaluate first if any given game has the need of controlling player income and spending. This can be decided based on the expectation, about how much the results of not controlling income and spending differ from the design goals of the game.
If it is deemed necessary that the financial economy of a game is placed in a controlled environment, it becomes important to decide what method is used to control it. The evaluation of the approaches created for this work can be used as a guideline for determining in which way one wants to restrict or react to the economic situation of the player.
For the creation of these approaches, it is important to understand, that a game has the possibility to restrict the economic system in any way imaginable and can adjust all NPCs to have the economic goals the design needs them to have. But it is not possible to adjust the economic goals of the player within one game system. In most cases, the economic goals of the player will align with personal economic growth, but it is possible that different games incentivize other economic goals.
Because of this, it can be said that the approach chosen to control income and spending in games must align with the set design purpose of the economic system and the economic goals players have within that system, while also achieving its original goal of controlling income and spending of the players.
8.5. Advantages the utilization of Machinations (Dormans, n.d.) offers to the game development process
The advantages this tool offers to the members of a development team are that it eases the communication between departments since it allows to showcase of the systematic structure of a game in a visually representative way. In addition to that, it allows for quick iterations by exchanging single structures in an already existing system. This tool also enables a team to work on the system simultaneously, since most changes to the system can quickly be explained to the rest of the team. Finally, it reduces the margin for human error, since the visual representation adds a layer of logic to the system in which problems can be spotted quickly.
The tool does also enable the developers to create tests of the base system of a game before the first gameplay prototypes are created and it is capable of running large playtesting sessions with simulated players. While there are already tools that allow for this Machinations72 does so in a way that allows the whole team to understand why different changes must be made.
8.6. Inclusion of Machinations (Dormans, n.d.) into established pipelines
The tool allows for easy inclusion of the created data into already established pipelines. It does so by enabling the user to select and track specific variables of a created system. And export the data collected as a .csv file. This can be utilized by most common spreadsheet programs, at which point it is in an established pipeline.
That being said the inclusion of the prototypes into version control could be improved to allow multiple people to work on the same system at the same time. This could be done by allowing different prototypes to derive from each other.
