[MUD-Dev] Geometric content generation

[Ian Collyer]

Matt Mihaly wrote:

> It's been a bit quiet lately, so I thought I'd just write down
> some thoughts I've been having tonight. They're probably not
> original thoughts, but perhaps they're worthy of some discussion.

> This list seems to accept the maxim that you can't generate
> content fast enough to keep up with player consumption of
> it. Surely, though, that can't be true. There doesn't seem to be
> any inherent relationship between player consumption rates and
> developer generation rates that would raise consumption rates as
> generation rates are increased, so there doesn't seem to be any
> barrier, in principle, to attaining this.

> There are a couple ways to do it that I can think of, and I
> differentiate between the creation of breadth and the creation of
> depth, for reasons below.

> 1. Simply outspend the users. Put more and more developers on the
> project.

>    - This seems like a financially infeasible solution, so it's
>    not really worth considering. It can, of course, be used to
>    increase both depth and breadth.

> 2. Increase the power and capability of development tools.

>    - A long-time, on-going process, but tools seem to be a lot
>    more effective at breadth creation rather than depth
>    creation. Algorithmic content has so far been shallow.

> 3. Increase the complexity of the game/world.

>    - The example that made me think of this is chess. Chess is a
>    simple game, but the rules interact in such a way as to create
>    a game of sufficient complexity that it's never been
>    solved. It's not possible to talk about an optimum strategy in
>    chess (at least yet. It'll be solved eventually, presumably.)
>    >

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.

However, if your revenue doesn't meet the cost of employing the
required number of developers (or if you'd simply like larger
profits ;) ) you can either increase the 'ContentCreationRate' with
option 2, or decrease the 'ContentConsumptionRate' with option 3.

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