[MUD-Dev] Geometric content generation

J Todd Coleman coleman at wolfpackstudios.com
Wed Sep 19 11:01:13 CEST 2001


----- Original Message -----
From: "Matt Mihaly" <the_logos at achaea.com>

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

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

While there is a large difference between "depth of content" and
"depth of game system," there are some areas that seamlessly blend
the two.  Our answer to this was "user-driven content" -- over time,
as people play the game, the result & history of that gameplay
becomes engaging content for new players to interact with.  A good
analogy here would be the world wide web... Netscape (and MS, of
course) didn't set out to create the web itself (with five
billion-odd unique webpages); no one organization could possibly
have hoped to create enough content to keep the web-browsing public
interested.  So instead they create foundation technology (browsers,
servers and site creation tools) that would enable the users
themselves to create the content that would make the web an
interesting experience.

A solid concept, I think (though it presents it's own set of
challenges.)  The way we tackled this was to create in-game tools
that would allow players to mold the game world itself (think
"personal housing on steroids"): players use various windows to drag
& drop city walls, buildings, gates, towers, city guards,
pets/mobs.. players are, to a large degree, enabled to do many of
the functions of world design themselves.

The concern here, obviously, is one of expectation.  You can't
expect every one of your players to be a great level designer.
(Look at the disparity between the quality of website design, for
instance.)  Even worse than that, MUD players -- being anonymous,
clever, and more often than not, entirely self-serving -- will, if
you allow them half a chance, go out of thier way to build things
that don't mesh with your "game vision" at all.  ("I'm going to
build my fantasy city to look like the starship enterprise!") As
such, any system like this has to contain strict constraints for
building (otherwise people will write out fifty variations of the
phrase "screw you" in castle wall segments, etc.)

That's the delicate line to walk, I think : giving the players
enough freedom and technology to create content they are happy with
(and other players will enjoy interacting with) while at the same
time putting in enough constraints that they can't build content
that harshly breaks the vision of your world.  NwN recognizes the
power of "player-driven content" as well, but is taking a slightly
different slant than we are: they are going for the flexibility and
power end of the spectrum, and in doing so have abandoned the need
to maintain a "common vision" in the universe as a whole.  ("You
want to make a star trek game?  heh, okay, sure. have fun and good
luck.  I won't be logging into your world.")

I'd be shocked if all of the upcoming "next generation" games don't
include the capacity for player-driven content to one degree or
another (sims, sw:galaxies, etc.) It seems, to me, like the natural
"next step" for tackling the depth of content problem.

Todd Coleman, "Warden"
Wolfpack Studios, Inc. - Shadowbane


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



More information about the mud-dev-archive mailing list