A Data Driven Approach to Dungeon Rewards

Warning: There is statistics in the following post. If you want a TL;DR, read the Introduction, Concept in a Nutshell, and Conclusion. If you want a stats-less post, skip Setting a Baseline and Setting Priorities.

Introduction

Dungeon rewards are garbage. Let’s be honest. People run Ascalonian Catacombs all the time because the paths are easy, and the monetary reward is ridiculous. People just as often only attempt Arah Path 4 to finish off Dungeon Master or because they have the time for the extra challenge.

The problem is, how does ArenaNet assign proper gold rewards to a given dungeon path without immediately causing an economic glut as people flock to the actually-easy-but-not-tried paths? For that matter, how do they figure a proper risk/reward curve at all? Twilight Arbor’s Aetherpath is a textbook case of not worth it, but how to fix the problem?

The answer is something ArenaNet loves: data and metrics.

What Data and Metrics?

Consider the core complaint about dungeons: most of them aren’t worth the reward (chiefly, gold, which is all this suggestion will be concerned about) for the time spent to complete them. So the first data point is time to complete.

The other major complaint about dungeons is that some paths are difficult to find anybody for. You can start up a LFG, and it’ll take a long time to fill, especially if you’re off-peak. So the second data point is popularity.

One concern with any data set is outliers, things that are well outside the norm (imagine a bell curve, now imagine a point at the far right or left). So another thing to address is ignoring outliers. Content and rewards should be, for the most part, designed for the middle 75%, not the 12.5% on either side.

The Concept in a Nutshell

Every week, an algorithm crunches the numbers of how long every dungeon path took to complete, and how often it was completed.  Then based on the results, each path has its bonus end reward changed. Less popular or long completion time dungeons reward the most, and more popular and short completion time dungeons reward the least.

Think of it as a 2-axis graph:

Reward Graph

(For those mathematically inclined, my fudged numbers are inverse logarithmic, base 10. I’m trying to approximate the left half of a shifted x^2 curve.)

Setting a Baseline

To adjust dungeon rewards based on a given path’s time to complete and overall popularity, first there needs to be baselines in place. More specifically, what are the maximum and minimum gold values that a path should give? At what point is a path “too popular”? What about the time it takes to finish? (These latter two questions actually tie in to ignoring outliers)

Minimum/Maximum Gold

Based on ArenaNet’s own existing numbers, 1g should be the minimum for explorables, 50s for story modes. I suggest that the maximum be 5g/2.5g (very unpopular path, crazy-long to finish…sounds like Arah Path 4…or Arah’s story mode).

Popularity

Capping how popular a path is should be based on the total number of completions across all dungeons. Dungeons themselves likely fluctuate in overall popularity, so establishing a hard number isn’t future-proofing the system.

There are a total of 8 story paths and 25 explorable paths. Considering them separately, that means equal popularity for each would mean 12.5% per path for story modes, and 4% per path for explorable paths. Without having any hard numbers at hand, I’ll just say that double that popularity for a path is maximum popularity (so 25% of the total share for a story, 8% for an explorable).

Conversely, anything at half the average is minimum popularity (any lower still garners the same reward). That’s 6.75% for story modes, and 2% for explorables.

Completion Time

Speedruns are a thing, and while they are great, they are outliers, especially record attempts. Likewise, slower, methodical eliminations of everything that moves are rare.

To avoid having either affect the overall reward curve, only the middle 75% of times should be considered. By that I mean, the 12.5% lowest times and the 12.5% highest times should not figure into the number-crunch.

Setting Priorities

Rewards should be based on completion time first, then by popularity. For instance, almost no one runs Honor of the Waves Path 3, but when people do it, it still only takes a half hour. It shouldn’t get the same reward (nowhere close) as Twilight Arbor Aetherpath, which likely takes 2 hours (I haven’t done it since release, truth be told).

With that in mind, think of the overall reward total as being decided in two parts. The first part is the average completion time, which will set between a 1.5g and 4.5g reward in 7 increments (every .5g).

Going back to the data, after throwing out the outliers, the reward should be based on where the completion time is compared to the average of all paths. Here’s a fudged example of it, using the increments 50%, 75%, 100%, 150%, 200%, 250%, and 300% of the average completion time:

Completion Time Graph

Having gotten the base reward, popularity is allowed a 1g “swing”, .5g up or down. 5 increments this time, allowing for even numbers. NOTE: the following graph is logarithmic. I’m assuming that popular paths have more LFGs, causing more people to join runs and creating a runaway effect compared to less-popular paths.

Popularity Graph

Combine the two, and the reward range of 1g to 5g exists, with potential values at every .25g level.

The same idea can be applied to story modes, with all values halved.

Other Implementation Possibilities

The suggestion as presented assumes a week-by-week reward adjustment. There are several other ways that the idea could be implemented:

  1. Computed daily, taking into account the past week’s data. This is a smoother adjustment, creating the effect of a rolling average. The downside is that the “reward meta” is less likely to change as players are slow to “catch the wave” of good rewards.
  2. Computed weekly, taking into account the past 2-3 weeks’ data. Bumpier than the first, but gives more time for players to adjust the meta with popularity shifts.
  3. Computed daily or weekly, taking into account all data ever with a weighted average. This is a far more complex (and more demanding) way to run the numbers, but it leverages the full dataset. I think this would be complete overkill, but it’s a possibility.

Advantages

There are a lot of advantages to changing a dungeon’s bonus gold reward based on how the player base itself completes them:

  • It smooths out the risk/reward curve, or in this case, the time/reward curve. With the right data, it won’t matter what path a player picks, it will reward roughly the same as another path with a different time to complete.
  • It rewards speedrunners while not adjusting the system based on them. A speedrun team will finish a path _faster_ than the average group, but they’ll get the _same_ reward. And due to their speedrun, their actual completion time stands a greater chance of being ignored by the algorithm when generating the next week’s values.
  • It dynamically adjusts to the capability and interest of the player base. Other than fine-tuning, implementing something like this is fire-and-forget. If everyone binges on dungeons one week, then barely touches them the next, the algorithm will adjust to proper values on its own.
  • Due to the factor of popularity, paths may change in vogue from day to day as players try to maximize their reward. This could create a “rolling meta” of which dungeon paths are popular and which aren’t.

[Example: if the Aetherpath is 5g in total reward this week, a good number of people will try it, upping its popularity, and maybe even dropping its completion time. Next week, it could be 4.25g instead, while Arah Path 4 comes back to 5g since everyone dropped it (at 4.5g) in favor of Aetherpath.]

Programming Difficulties

Like any suggestion, implementing adjusted dungeon rewards will take development time. In this case, the difficulties revolve around data and number-crunching:

  • Right now, the number of times a dungeon path is completed and how long it took to complete may not even be tracked. Adding these in as metrics to track would be the single hardest obstacle.
  • Establishing an automatic server process to crunch the numbers at an appropriate reset time and readjust the reward values for a given week. The upside on this is that raw number-crunching is a computer’s forte, and wouldn’t take that long at all to execute once built.

For the core idea, that’s it. Creating the database and tracking the data, then crunching the numbers once a week.  Maybe if the resulting numbers don’t match what ArenaNet would like to see there would need to be some adjustment to the algorithm, but beyond that, it’s relatively simple to create.

But since there’s a good chance this data doesn’t already exist, the algorithm will need to be seeded with a decent pool of data. Turning on the tracking a week or two before the rewards actually adjust would accomplish this.

Conclusion

Dynamically adjusting the amount of gold a dungeon path rewards based on how long it takes to complete, and secondarily how popular it is, will help reduce (or even eliminate) the cries of dungeons not being worth it, or of certain paths being way out of line for what they reward. By applying the player base’s own metrics, it leverages the advantage of taking such metrics by providing better rewards to that same player base.

Advertisements

3 thoughts on “A Data Driven Approach to Dungeon Rewards”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s