If you haven't read the previous articles in NPC Pricing series, give them a try:
-
---
-----
Introduction
Basically when setting a price based on
personal player behavior, it's very important to note the following:
- Players can abuse a price based on personal behavior if they ask a friend to buy something for them
- Players can abuse the personal behavior algorithm if they have multiple accounts
- Players can lend their gold or items to other people to influence algorithms based on such things
- The game designer / company needs to keep a reliably track of all parameters inside the player database to use them on algorithms
- It's important to explain to the players how the algorithm works, tough not necessarily in full detail
Having these
possible ways to bypass a personal behavior algorithm, the simplest solution to
avoid them is:
- Make any store bought good or service not transferable between players
Having said all that we can finally start
looking at Algorithms:
-----
---
-
Price as a function of Gold a Player has:
- Definition: Price includes Players Gold amount in the calculation
- Example 1: A Healing Potion costs 100 gold + 1% of Player current gold amount
- Example 2: Upgrading a piece of gear costs 5% of player's Gold
- How it's interpreted:
- Player's Perspective:
- "Saving Gold isn't advantageous since prices increases"
- Game Designer's Perspective:
- "Players won't be able to save up as much gold - I got a Gold Sink"
- Advantages:
- This kind of function is really good to control the gold levels on the server
- It offers a choice to avoid paying more, not save up gold
- Flaws:
- This kind of function can be bypassed if player can "lend" their gold to other players
- Spending gold because prices rises as you have more gold is a Negatively Reinforced Behavior
- This kind of function makes gold a less popular currency, so it must never be used in all stores
Price as a function of Gold earning rate:
- Definition: Price includes a calculation like ((Total Gold earned)/(Time spent playing)) - (arbitrary Gold earning rate)
- Example 1: If i state the ideal gold earning rate is '1', and a good costs Y. Then player that earns gold twice as fast will have to pay (Y)* k^(2-1)=Y*k^(1) i.e. price is multiplied by an arbitrary factor according on how much the player deviates from the arbitrary ideal gold earning rate. If he earned as much as we desired him to earn, then price would be (Y)*k^(1-1)=(Y)*k^(0) = Y
- Example 2: Instead of (Total Gold earned)/(Time spent playing) consider the Maximum (Gold earned in a specific run)/(Time spent on that run) the player has
- How it's interpreted:
- Player perspective:
- "They are charging more because I'm a good player"
- "They are charging less because I'm a worse player"
- Game Designer's Perspective:
- "We are charging prices proportional to players earning rate (salary)"
- Advantages:
- This kind of function is healthy economics-wise
- Flaws:
- This kind of function can be bypassed if player can "stand still" and your game doesn't detect this kind of behavior
- Spending gold because prices rises as you have higher earning rate is also a Negatively Reinforcer for Buying
Price as a function of Good Performance:
- Definition: Price includes some adjustment based on whenever players accomplished a specific challenge
- Example 1: If a player complete a quest or mission with superb performance (like doing it considerably quick, not getting hit at all or defeating all monsters) prices decrease:
- Algorithm Price = (Previous value) *(Factor)^(Flag)
- Factor in this case should a number smaller than 1
- Flag is a variable that is either 0 (player didn't meet criteria) or 1 (player met the criteria)
- How it's interpreted:
- Player perspective:
- "They are charging less because I'm a good player"
- "I need to do this mission again to get better prices"
- Game Designer's Perspective:
- "Some players will repeat this mission until they get better prices"
- Advantages:
- This function work as a Reinforcer for good playing (tangible reward Discount)
- Flaws:
- This kind of function makes you charge less from people that usually have more gold (more skilled players)
- Reduces the gold sink effect of the shop
Price as a function of Unskilled Performance:
- Definition: Price includes some adjustment based on how many times a player failed in trying to accomplish a specific challenge
- Example 1: If a player dies 3 times in a specific run a Shop that sells a temporarily Buff power increasing could charge less
- Example 2: If a players have to pay to be revived upon death, the fee could decrease if player has died recently (giving him less punishment)
- Example 3: If a player is doing poorly, failing mission too much prices on bad gear are decreased to allowing him to buy the necessary equipment
- How it's interpreted:
- Player perspective:
- "Well at least now I have a chance to progress in this hard stage"
- "Maybe I'll buy that buff to make it easier to pass this hard stage"
- Game Designer's Perspective:
- "Some players need an extra hand - let them waste not too much gold"
- "Maybe only unskilled player will see this buff as a valid option"
- Advantages:
- This kind of function tries to reduce the punishment a unskilled player has when he fails (Increases his fighting chances by allowing him to buy some good)
- This kind of price alteration can make some unpopular NPCs sell their good/services more often
- Flaws:
- This function is only recommendable with instantaneous buffs, weak gear or items with limit on how many you can carry
- Some players might not react as well when prices increase again or when they realize the prices decreased because they are unskilled
- Any of the goods that receive the bonus if a player fail might be seen by player as "Noob Buffs" and might be less used (and bought) by other more skilled players
Price as a function of Time spent playing:
- Definition: Prices increase steadily based on how long a player has been playing
- Example 1: If prices rise 4% for every 4 hours playing, after every 17,5 playing hours prices would double
- Algorithm 1: Price = (Starting Value)*(Factor)^(Number of hours)
- Factor a number close to 1 - 1,04 in the example
- Example 2: If prices rise 4% of their base value for every 4 hours playing, after every 17,5 playing hours prices would double, then triple at 35 hours, and so on.
- How it's interpreted:
- Player perspective:
- "Maybe I shouldn't spend so much time farming, since prices are rising with each playing hour"
- "Arggg now I need more gold to buy XXX"
- Game Designer's Perspective:
- "Well prices will scale as players with a reasonable indicator of player's gold earning rate - total playing time"
- Advantages:
- By increasing prices with playing time players have less incentive to spend time farming
- As player time increase they will end up earning less gold
- Flaws:
- If your game longevity is based on low drop rates, then this kind of function won't be useful
Price as a function of killing/defeating a monster
(type):
- Definition: Prices change based on how many kills (of a specific monster type) a player have (works best if combined with another function for price increase - like price increase with each bought good)
- Example 1: Each monster killed reduces gold costs by 1%
- Algorithm Price = (Starting price) *(factor)^(Number of kills)
- Factor = 0,99 for the above example
- Example 2: Only a specific monster category influences price (like bosses, some invading army or even the final boss - any category that would make sense story-wise)
- How it's interpreted:
- Player perspective:
- "I'll kill these monster to be able to buy good cheaper"
- "The Shopkeepers are glad I've defeated their enemies"
- "Killing monster is too boring, I'll just pay higher prices"
- Game Designer's Perspective:
- "As long the price reduction is compensated in another way, using this formula will incentive some player to kill some (specif or not) monsters"
- Advantages:
- Incentives player to kill monsters
- Makes players unwilling to kill many monsters to spend more gold when shopping
- Flaws:
- Needs to be fine tunned otherwise it will drop prices way too much (maybe an artificial cap or thresholds)
Prices as a function of story event:
- Definition: Prices change if a specific story even occurs (either up or down)
- Example 1: If the city was destroyed all shops charge 20% more
- Algorithm Price = (price) *(factor)^(flag)
- Factor = 1,20 for the above example
- Example 2: Only a specific monster category influences price (like bosses, some invading army or even the final boss - any category that would make sense story-wise)
- How it's interpreted:
- Player perspective:
- "Guess it makes sense prices to change after event X"
- "My second character will delay that story event to take advantage of better prices"
- Game Designer's Perspective:
- "Just immersion feature, can justify a price increase"
- Advantages:
- Helps immersion, prices changed for a "good reason"
- Can justify prices increase (and more gold sinking)
- Flaws:
- Might not affect players with several characters
Price as a function of Buying Behavior:
- Definition: Prices increases for each time that the player buy an item
- Example 1: If ap layer buy a potion all potions get a little more expensive
- Algorithm Price = (price) *(factor)^(behavior)
- Factor = a number close to 1
- Behavior = Buy an item (potion)
- Example 2: Each buy affect several item in same category - example all weapon a blacksmith sells become more expensive after you buy a weapon
- How it's interpreted:
- Player perspective:
- "Guess it makes sense prices to change after I buy a potion - Law of Supply and Demand"
- Game Designer's Perspective:
- "A jusfied way to charge more for frequently bought goods- A nice gold sink"
- Advantages:
- Reasonable immersion justification (Law of Supply and Demand)
- Can justify prices increase (and more gold sinking)
- Flaws:
- Might not affect players with several characters (or might affect them all at once)
Price as a function of amount of similar items:
- Definition: Prices increases based on how many of a given item a player is carrying or have (best for consumables or item that mimic "extra lives")
- Example 1: The price of health potion increase by 33% for each potion a player have more potions on him
- Algorithm Price = (price) *(factor)^(number of carried item)
- Factor = a number close to 1 (1,33 in the example)
- Number of carried item = Number of can item (potion)
- Example 2: Selling a stackable buff that increases damage (or decreases damage taken) by a fixed % - doubling price with each successive buy
- Algorithm Price = (base price) *(2)^(number of buffs currently applied to player)
- How it's interpreted:
- Player perspective:
- "Well since each potion is an advantage for the mission I can't just carry infinite of them"
- "Guess I can't just stack buff like no tomorrow"
- Game Designer's Perspective:
- "I'm using price to balance how much of something a player can carry into a mission"
- Advantages:
- Uses price as to achieve balance (adequate difficulty)
- Can justify prices increase (and more gold sinking)
- Flaws:
- Might not make much sense immersion wise - unless you justify it (Applying several buff is harder/more expensive - you don't buy more potions, but increases how many charges of "healing" a potion flask a player carries has)