Content creation

This post came from MUD-Dev, where we were discussing violence in online games. The suggestion was made that camping should not be occurring in the large scale commercial games, because they should be able to afford to generate enough content for everyone…

I think it helps to view this ‘content race’ problem as a mathematical equation where, in order to meet demand for new content the following must be satisfied: ContentCreationRate * NoOfDevelopers >= ContentConsumptionRate

Rearranging gives:

NoOfDevelopers >= ContentConsumptionRate / ContentCreationRate

An interesting point to note is that this is independent of the number of users, which prompts me to question why everyone is discarding option 1 above so quickly. Surely with a sufficiently large paying user base simply increasing the number of developers is a viable option.

–Ian Collyer

It’s not independent. ContentConsumptionRate rises with number of users. Phenomena such as word of mouth (keep in mind that in the equation above, content is static content, not dynamic content) and cheat websites ensure that content is consumed faster and faster by users.

Also, don’t forget that ContentCreationRate can be expressed as multiple of ContentConsumptionRate, usually. A quest that takes 3 weeks to write, implement, and test takes a couple of hours to beat. A game that has a year of content in it is often sold as having 40 hours of static gameplay content.

Let’s go on a tongue in cheek useless math excursion! Ignore all errors for the sake of the rhetorical argument. 😉

The mud quest example is tricky. Let’s say an admin who spends 2 hours a night and 4 each day of the weekend, for a total of ( (5 * 2) + (2 * 4) ) * 3 == 54 hours of work. And two hours to first solution gives a ratio of 1:27 for player time:developer time.

The pro game example: Say a team of 10 content generators at 230 man days of work in a man year and 8 hours of work to the man day, that’s 18400 hours of development for 40 hours of content. That ratio is 1:460 because of all the code and art that goes into the content.

Now, the assumption is that each user does the content once, of course, which may not be valid but which we can generally assume to be true for certain types of content such as narrative experiences.

Not all users do the content in parallel, and I’m not going to try to analyze the typical content consumption patterns for a playerbase. But it’s worth pointing out that in a level-stratified content scenario, such as a traditional Diku-style mud, content needs to effectively be duplicated for each gross stratification of the playerbase. In other words, if you only have levels 1-5, you need to make less content for the game than if you have levels 1-100. (If your levels are for display purposes only and have no impact on statistics in any way, then this doesn’t hold true).

So many of the benefits you may have from non-parallel consumption of content go away because in practice, players who have distributed themselves evenly across the level range will in fact need their own content at each point. This would suggest that you can get by in the math with just taking the number of players, dividing by your max usage number, and then dividing again by the number of gross stratifications you have (I wouldn’t divide by the number of levels, say, but by levels/5–whatever your game system makes plausible) to figure out how much parallel content you need.

This would suggest that for a game with 1000 players, you’d probably get 20% or 200 online at a time. With say a 50 level mud, you’d need 10 “bands” of content, and each needs to support 200/10, or in other words 20 players simultaneously (This is radically erroneous because in a mature, stable-population mud you find that the typical player distribution is actually a hyperbola centered on your midrange. You can’t really count a mud as mature until the rightmost infinite term is located at your max level). Let’s take for granted that you had better be providing enough content for all 20 to be advancing in parallel, or else you’re suffering from a mud that doesn’t have adequate content at a given level. If we assume that players all consume content at the same rate, that’s the same as 1 player consuming 20 content units.

The 20 content units need to be the equivalent of levelling up 5 levels. Since odds are good that you have increasing amount of time to level up at each level, we’re going to have to pick an average time to advance across all levels, assuming a smooth advancement curve. With a game of 50 levels having an assumed “to max” lifespan of say, 6 months, with an average playtime of 20 hours per week or 80 hours per month, that means you need 80*6 or 480 hours of content total, or 48 hours of content for the average 5-level “band.”

The developer time for this, based on the 1:27 ratio for a mud, is 12960 hours worth of work. (In a non-level based mud, it’s only 480). For a typical mud founding team of five people, obsessed as they are and working 4 hours every night until the mud goes live, that’s around 1 3/4 years to make all the content for a 100-player-a-night mud, with nobody ever having to wait in line for a mob. That doesn’t sound out of line to me based on real world experience.

Calculating the commercial game equivalent I leave as an exercise, but suffice it to say that if you do it, you quickly see why a) camping b) launching without planned content or slipping the release date c) launching with multiple copies of the content i.e. servers or shards d) public testing (potential vast reduction in development time there–like, an order of magnitude) is pretty much a necessity.

The other tack, of course, is to algorithmically generate content. Approaches include artificial life, generated landscapes and narratives, dynamic environments, player-entered content, and player vs player dynamics (not playerkilling necessarily, just forms of player entertainment that are not about consuming design-generated content).