[MUD-Dev] Geometric content generation

Koster Koster
Fri Oct 5 22:06:40 New Zealand Daylight Time 2001

> -----Original Message-----
> From: Ian Collyer

> 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.

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

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

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 saya 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 typicalk 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

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.

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list