Dynamic Economy
(Go back to the main GSoC 2015 page)
Disclaimer
This idea is going to be pretty popular, and most likely selected by many people. You are welcome to pick it up anyway, but in this case we suggest you to also submit another proposal for a second PlaneShift idea. You can submit as many proposals as you want for one organization.
Skills needed
Our server and client are all coded in C++ and the database is MySql. For this project C++ knowledge is needed with some knowledge of mysql.
How does the economy work in PS today
Today every item in game has a fixed price, stored in the database. The price never changes and it's identical between all cities and all merchants.
The merchants are NPCs (controlled by the server) and they have a fixed list of categories they sell and buy, for example: swords, helms, plants. This means you can sell them anything which is in their category, no matter of quantity. They will buy any quantity today, even millions of pieces. For selling they are restricted to those categories defined on them, but in addition they also have a list of items to sell within those categories. The items they sell are defined in the db and those rarely change, so we can consider those basically static today. They supply is infinite, so they can sell any quantity of the same item, and the price stays the same.
There are no players owned shops. Players can still sell items to other players just by trading an item for money.
Players can mine and can craft items, in that case the final price of the item is determined by the "quality" of the item. So for example a 1 kg of iron can be more or less pure, and that determines its quality. The quality is determined when the ore is extracted and depends on the mine itself plus the skill of the miner. The same happens with crafting a sword, the quality of the components are summed up and the skill of the crafter as well, to result in a final quality of the sword. The final quality determines also the price of that item. So a merchant will pay more for a quality 300 sword compared to a quality 50 sword.
All items sold by NPCs have a quality of 50, while player crafted items go from 0-300, but usually if you get a quality 30 means you made something wrong. So a player made item is generally better than an NPC one. This is made to avoid having NPCs competing with the player crafted items.
Where is the data stored today
item_stats.base_price is the cost of each item
merchant_item_categories lists the categories each merchant is selling
item_instances contains the inventory of the merchants, from which they determine what to sell. all they have in their inventory they sell it, excluding worn equipment.
Item Types
We have to consider there are at least two major categories of items: - the items produced by the players (like mining ore, crafting swords, mixing a potion) - the items sold by NPCs. This second group is mainly used to provide basic equipment to new players or supply of raw materials for other player crafting activities
We want to apply the economy manager to both items
Boundaries
We want to have a minimum and maximum variability of the prices, to avoid completely disrupting the economy based on some silly players actions. So the Economy Manager needs to have a % variance variable configured.
Let's say we have a sword which is costing 100 coins as base price. If that variable is at let's say 30%, then the economy manager can at maximum change it by +/-30%
Economy Manager Purpose
The price of an item is already influenced today by the following factors:
- quality of the item produced (which includes the player skills and the quality of the base materials used)
- time needed to produce the item
The Economy manager should be able to create a variance in prices based on the following factors:
- number of items present on the market and sold (supply/demand factor)
- affinity of the player to the merchants. We have a concept of 'factions' in game, which represents how the player is "friend" or "affiliate" of a specific race or social group. The 'faction' rating should be used to determine the price as well. We don't want to have the 'faction' changing based on the amount of items sold, but we want this to change with the quests completed.
- domain. The domain is nothing else than a list of merchants, which can identify a city or a location. We would like to foster trading between cities, by setting certain items as lower price in certain areas and higher in others. For example we want one city to have more gold, and so it will be exported, or more iron. We should decide if this has to be done only on raw material or also on items (like swords).
This will put a lot more variety into the economy, will allow trading and exchanges, and will motivate people to increase their skills in a certain faction to get items at a special prices. Also considering different players will have different faction standings, they could collaborate to get certain items at good price and then exchange between them.
Basics of Economy - Supply and Demand
http://www.investopedia.com/university/economics/economics3.asp
Cities Demand
I think the merchants, like Harnquist the blacksmith, should be both consumers and suppliers. As consumers they should represent the need of a city or a subset of it, which we assume is populated by other NPCs, not just the ones you see. So the first thing we will define are the domains which describe the demand in an area.
Example domain
- Name: Blacksmith-Hydlaa
- NPCs associated: Harnquist
- Type: Evolute city
- Number of people served: 500
In the example above we say that Harnquist the blacksmith serves the whole hydlaa city and 500 people.
Then we need to define how much each item is needed. My suggestion here to simplify the model is just to define this % on the item stat itself. So for example we have:
Knife:
- need_per_month: 0.5
0.5 means that there is a need of 1 knife every two persons per month. Or 0.5 knives per each person per month.
So now we easily know that Harnquist needs 250 knives per month (500 people served * 0.5).
When the player goes to sell a knife to Harnquist, he will check how many he bought already and if he needs it and based on that he establishes a price for it. If too many players try to sell knives to him, the price will float down and maybe at a certain point he will not buy anymore. Then after some days the city demand grows again and he buys that again at increase price.
Player Behaviors – Supply Side
For every item in the game, players are by their behaviors, defining a supply curve for every product they produce. For example:
In this chart stolen from the Net, the players will produce 10 Iron Ore’s per day if Iron Ore is $1 each, or produce 140 Iron Ore’s per day if it is $4 per day, as shown by the red bar.
The beauty of MMORPGs is that we do not have to set the supply curve explicitly for each item ourselves. This is determined naturally by player behaviors reacting to the prices set by the game. Demand curves are another story, however.
Economy Manager – Demand Side
For each item, we must define a demand curve such as the blue one shown in the graph above. Demand curves indicate in a system what ‘people’ will buy when offered items at a given price. For example in the above graph, the world will demand 40 Iron Ore’s if they are as expensive as $4 apiece, but will demand 100 Iron Ore’s if they get as cheap as $1 each.
In the PlaneShift instance, merchants are the demanders of products produced by players. The demand curve of the item is representing the hidden demand of an entire world of Yliakum residents. We design each demand curve to get the types of prices we want from the evident supply curves the players are displaying.
Each demand curve will be represented as a line. P = mQ + K. Each item stat record in the database with this feature enabled must store the downward slope of the line “m” and the offset to get the line where we want it, “K”.
Economy Manager – Finding Equilibrium
The EconomyManager is notified of every exchange made in the game. The purpose of this is to measure “Q” per period. The period will be set for 3 real-time hours but we can adjust this as necessary to get smooth behaviors. Q will be stored per period, per item and will be normalized by the average number of players online during the period, relative to 100 players.
At the end of the period, we evaluate our Demand Curve to determine the equilibrium price. (P = Stored m * Measured Q + Stored K) If the new P value is higher than the current P set for this item, we adjust the price of our items upwards by 20% of the difference. Thus, if players do not detect the change and hence do not adjust their behaviors in the next periods, the official price for this item will steadily and asymptotically march up to the equilibrium point, which is the Demand Price.
If, on the other hand, players start to notice the new higher price, they will respond by producing more of the item for our merchants. Thus Q is higher in the next period and the equilibrium price yielded by the equation is lower. This means that on the demand side our engine is seeking equilibrium and on the supply side, our players are seeking the same thing.
If our rules change, our players’ behaviors will change entirely—in effect creating a entire new supply curve for the item. This will result in a new and sensible equilibrium point for the item within hours of the rules change.