If you haven't read the previous articles in NPC Pricing series, give them a try:
-
---
-----
Introduction
Unlike personal behavior
prices algorithm, Collective Behavior Algorithms can't be bypassed with a
simple trick like having someone else (or Account) to buy a good or service.
However this advantage comes with a price, it's much harder to predict and
control behavior at a collective perspective. So keep the following in mind
when deciding to use such algorithm:
- Prices will variate a lot with players entering or leaving the game servers (Variation in player's population).
- There's a massive effect of veteran's actions on the prices newer players will have to pay.
- Since the effect of each player's action is diluted price adjustment is much slower
- Not all player have the same inclination for farming and grinding gold. That means some services and goods will be unavailable to players that not earn as much gold (less hardcore gamers).
- Time has huge influence for this kind of algorithm, prices can change significantly over two weeks or a month.
- This kind of algorithm logic doesn't differentiate player who have 0 of Good X and a player who have dozens, so it's a sound idea to combine individual and collective behaviors in the same algorithm.
Another thing to keep in mind
is the three possible reasons for employing a Collective Behavior based
Algorithm:
- Immersion - Price increasing with each buy is a simulation of the Law of Demand and Supply
- Gold sinking - Adjusting prices help adjusting the gold levels
- Incentive the use of Real Money - If gold prices rise enough some player might spend some cash buying virtual goods (Some players might just look for another the game with lower Gold Prices tough)
-----
---
-
Application
First of all, most individual behavior player price
algorithms can be used taking a collective approach here a few
examples:
- (Variation of) total Gold all players have
- Pondered Gold earning rate between all players
- Total of Time spent playing
- Number of players with and without a specific item
These examples are quite similar to their individual
algorithm counterparts. However it's important to note that there are several way to compute how each player affect the price:
- Use the sum of each player value/behavior - Count all cases
- Do a ponderation - Count all cases then divide by the number of players
- Use a ratio - Divide the number of player in one case by the number in the other
- Consider just a segment of player population - like players at maximum character level or players that have played in the last week or even player with high Gold Earning Rates per hour
Having said all that we can finally start
looking at Example Algorithms:
Price as a function of the Relative Number of New
Players:
- Definition: Prices change depend on how much of the player base is new
- Example 1: Prices decrease or increase depending on how many players are new (have less 12 hours played)
- Algorithm Price = (initial price) *(factor)^(Player Ratio)
- Factor = a number between 0 and 1 (the price will be multiplied by this number if all players are new)
- Player ratio = player in new condition / total players
- New condition = individual playing time is less than X (12 in the example)
- Variant 1: Only consider the number of players active within the last week
- How it's interpreted:
- Player perspective:
- "Since people are new prices need to get a bit lower"
- "Since most players are veteran's price have increased a bit"
- Game Designer's Perspective:
- "Hopefully this algorithm will make the prices fair for new players, and gradually charge a bit more when most players are veterans"
- "By only considering the active players within the last week I can adjust the prices if some large number of player leave or come to the game"
- Advantages:
- Ability to adjust prices due the difference in the player demographics (how much time they invested playing)
- Prices Gradually increases as some player stay "faithful" to the game and others leave
- Flaws:
- Prices will gradually increase without new players joining the game
- Player who quit the game early (without playing it a lot) will push the average playing time down (along with prices) unless you use variant 1
Sales quota:
- Definition: Prices increase or decrease depending on how frequently player buy or sell a good:
- Example 1: I want to sell 2 good per day. For each sell outside the quota the prices are adjusted by 1.2 (+20% if up or -17% if down)
- Algorithm Price = (base price) * (factor)^(Number of Sold Units - Quota)
- Factor = a number close to 1 - 1.2 in the example
- Behavior = Buying from NPC
- Variant 1: Use a quota for a whole family of products instead of just 1
- Variant 2: Combine Single item quota with Item Group Quota (with different factors)
- Variant 3: Use a formula to determine the quota (like selling 1 unit per 200 players per day)
- How it's interpreted:
- Player perspective:
- "It's like demand and supply - the more sought a good is, the higher it's price is"
- Game Designer's Perspective:
- "It's like demand and supply - the more sought a good is, the higher it's price is"
- Advantages:
- Feels like a demand and supply emulation
- Price will quickly adjust to an adequate level, if too high player ill stop buying and it’ll decrease, if too low successive sells in the same day will increase it quickly
- Flaws:
- It’s needed to analyze the Demand very well to establish an adequate Quota. Be it a static value or a dynamic one.
Completed Mission per Player Base:
- Definition: Prices change for all players each time a player completes a dungeon
- Example 1: Each time a player completes the "Mithril Mine Liberation Mission" Mithril gear gets 3% cheaper (Price should probably rise with each new player around to balance this out)
- Algorithm Price = (price) *(factor)^(Times completed)
- Factor = a number close to 1
- Behavior = Number of player who successfully completed the mission
- Variant 1: Use the difference between player that completed and not completed
- Algorithm Price = (price) *(factor)^(difference between the number of players that completed and not completed the mission)
- Variant 2: Use the ratio of between player that completed and not completed
- Algorithm Price = (price) *(factor)^(the number of players that completed the mission divided by the number of players that didn't)
- Variant 3: Use the % of player that completed the mission and a fixed number (like 50)
- Algorithm Price = (price) *(factor)^(Percentage of players that completed minus 50)
- How it's interpreted:
- Player perspective:
- "It makes sense for prices to drop after having the Mine cleared"
- "Cool I've influenced the Virtual World when I did that Mission"
- Game Designer's Perspective:
- "I'll offset the price decrease with some other factor, but this is a cool feature to incentive people to do a quest/mission"
- Advantages:
- Provides some interesting immersion feature - Completing a mission affects the game world
- Can incentive player to complete a specific (optional) mission
- Allows the designer to set a higher initial price (and change the algorithm's factor later if needed)
- Flaws:
- Only adequate to justify a price decrease factor
Buying Selling Behavior:
- Definition: Prices increase each time any time a player buys from NPC and Decrease if he sells to the NPC (Guild Wars Rune Mechanic)
- Example 1: Each time a player completes buy a Health Potion it's prices go up 1%, each time he sell the price goes down 0,5%
- Algorithm Price = (price) *[(factor)^(Buying Behavior Count)] *[(factor)^(Selling Behavior Count)]
- Factor = a number close to 1
- Behavior Count = Count of how many times players have it
- Variant 1: Variate the price of a whole family of products instead of just 1 (like all potions not just the health potion the player bought)
- Variant 2: Make each buy/sell affect both the specific item and the item family (Buying health potion increases Health Potion price by 1% and Potion price by 0,75%)
- Variant 3: Buy and Selling prices are different but have a similar algorithm (with different factors and initial point)
- How it's interpreted:
- Player perspective:
- "It's like demand and supply - the more sought a good is, the higher it's price gets"
- Game Designer's Perspective:
- "It's like demand and supply - the more sought a good is, the higher it's price gets"
- Advantages:
- Feels like a demand and supply emulation
- You can offset lower demand on specific items if you use Variant 1 or 2
- Flaws:
- It's needed to control of drop chances very carefully and monitoring of player's demand and acquisition rate or the prices might fluctuate too much
- In the long run most prices will get pretty low due the lack of obsolescence of virtual goods and constant production (by farming)
-
---
-----
Closing thoughts:
Well, there are a myriad of different ways to variate price. I hope this series helped to clarify other possibilities to use instead of fixed prices. Here a few guidelines:
- If you release a new areas with 20% higher Gold earning rates, it might be good to increase the price of frequently used goods (consumables or highly sought services) by 10%-20% as well.
- If players aren't spending Gold (creating something similar to Inflation) you need to open up new NPC shops selling things almost any player would want. Selling monster/dungeon drops is very effective at burning gold.
- Rewards like gold (and what it buys), experience points or rare drops are ultimately reinforcements for playing. When a reward is no longer effective at reinforcing a behavior (i.e. a player isn't actively seeking it) you should stop giving it to them or you will have a problem with the supply.
- In other words If a player has all things he wanted to buy with gold he will end up accumulating a lot of gold and gold will become a bad currency (because Gold sinks aren't working)
- You must accept that people who farm too much will get "rich" (have too many game tokens)
-----
---
-
For next time, expect a discussing about a subject related to Drops, but not limited to it:
Designing Player's Luck: Introduction (Part 1)