[MUD-Dev] Persistent Worlds

John Buehler johnbue at msn.com
Sun Feb 18 21:55:45 CET 2001


> Travis Casey

> I think a better way to put this is that a gameworld should be
> "self-healing".  Backstory can be relevant to a game without problems,
> but if there is no way to generate new challenges for characters when
> old ones are overcome, or to continue the game if a particular NPC or
> item is lost, then the game has not been well-designed.

I agree that the story must adapt as circumstances dictate.  I've suggested
that there be story planners for game worlds who are responsible for this
very thing.  To suggest that the game must adapt implies to me that the
story can be affected by the players, but only to a certain extent.  If the
players can actually control the story line (assassinate all the
ambassadors), then we get into a case of the game company fighting to keep
control of its own world.

To return to the topic of backstory, however, I was attempting to point out
that having backstory really isn't all that useful to players.  This is a
bit like having documentation for software.  Nobody reads the stuff, and
software needs to be easy to use anyway, so why bother except with reference
information?  I believe backstory fits the same mold.  Having a backstory
written down is handy for those who like fiction, but it's pretty much a
non-issue for the mainstream player, who just hops into the world and plays.
In their case, only the bits and pieces of the world's activity that they
witness or people tell them about will be of any interest at all.

Backstory has the nasty characteristic of setting expectations rather high
as well.  Flowing prose and expansive imagery suggests to players that this
is how the game world will be.  But only uninterrupted prose can match that
expectation, and a game, whether textual or graphical, cannot do the job.
Let the player experiences set player expectations for the evolving plot
line.  Particularly if you think that you might not be able to do everything
that you hoped you could when you started out.

> I agree with this part.  :-)

Don't *do* that.  I can't deal with public agreement.

JB

_______________________________________________
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