[MUD-Dev] Geometric content generation

[gamaiun at yahoo.com]

--<cut>--
Note: This message was written via the list web archives.  There is
no guarantee that the claimed author is actually the author.
--<cut>--
Original message: http://www.kanga.nu/archives/MUD-Dev-L/2001Q4/msg00124.php

On Mon,  8 Oct 2001 16:55:17 -0700 (PDT)
"Ian Collyer" <i.collyer at ntlworld.com> wrote:

> So your average developer will create 'ContentCreationRate' new
> areas per month, whilst your average user will explore
> 'ContentConsumptionRate' new areas per month. This will still hold
> no matter how many developers or users you have.
 
>   [It's just struck me that 'consumption' is perhaps a bad choice
>   of word here as the point is that the content is _not_ consumed
>   and once created it can be experienced by any number of users at
>   no incremental (creation) cost.]
 
> So if your average user explores four new areas a month and your
> average developer can create only a single new area per month you
> need four developers creating new areas to satisfy demand
> regardless of the number of users.

Ian has a great point here. We need to take a closer look at Content
Consumption and whether it depends on the number of users.

Let's take some example numbers. Say we have one developer on a mud,
who creates one area a month. Let's also say that it takes a month
for an average player to 'use up' the area - thoroughly explore it,
solve the quests, slay the monsters, hunt in it, and eventually
become bored with it.

If we have 500 users on the mud, how long will it take for them all
to use up the area? About a month... What about twice that, 1000
users? Still, about a month. (This is, of course, assuming that the
area scales well to the number of users -- the quest can be solved
by each user (as opposed to the first one who gets there), the
monster ecosystem is sturdy enough to handle many players hunting
there at once, etc). So, in this particular example, content
consumption does not depend on the number of users.

Let's take a look at some other content. A new item. Or a new type
of monster.  Or a new skill/spell/ability. Again, an average user
will 'consume' it in a constant amount of time. That is, the average
user will rise to the sufficient level to get item/skill/spell, or
meet the monster; raise up enough money/xp to purchase it; explore
its interaction with the rest of the game; develop it to the highest
level they can; become thoroughly bored with it.  And again, the
consumption rate of the new monster/skill/spell/item does not depend
on the number of users.

It looks like for some types of content, you really _can_ throw more
developers on it and come out ahead regardless of the user base.

Now, is there content that does depend on the user base?
Certainly. All the examples above were examples of 're-usable'
content, which could be enjoyed by every player. Unique content,
such as one-of-a-kind events, quests, or items, as well as things
like secrets, bragging rights to be the first on top of a mountain,
etc, definitely depend on the number of users.  Say you're
organizing a small subplot in which only 7 players can participate.
Or you have a unique NPC which, once killed, stays that way. Or a
truly unique item/spell/skill (only one person can ever have it).
Once this piece of content is used up, that's it. The rest of the
user base cannot 'consume' it.

Yet even in these scenarios, unique content, if designed right, can
be cost-effective.

Say you create a unique NPC which carries a one-time prize. Many
users can be involved at once in hunting it down! The rumours,
investigations, progress reports, infighting and bickering between
different parties out to kill it, the spectators at the battle, the
stories told afterwards -- even a 'consumable' or 'non-reusable'
piece of content can generate enough entertainment to make it
worthwhile!

In short, option #1, 'Throw more developers at the problem' might
actually be a viable solution.

Dmitri Z

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev