[MUD-Dev] Cans of Achievements and Quests

Sasha Hart Sasha.Hart at directory.reed.edu
Wed Sep 4 09:41:14 CEST 2002


[Sean Kelly]

> The combination of non-linearity in MUD quests combined with the
> fact that in persistent worlds you don't want players to level as
> quickly means that by necessity the players have to re-do quests
> multiple times in order to advance to the point where they're
> capable of doing the more difficult quests.  This means a lot of
> busywork and (to me) boredom.

Console RPGs have repetitive random encounter battles filling much
the same role (e.g., giving the opportunity to reach level before
moving onward and upward). LOTS of people like this format,
though... anyone heard of "Final Fantasy"?

> I grant that coding such a system would likely be an incredible
> amount of work, but that is the kind of persistent world I'd like
> to see.

I'm not so sure that it would be all THAT much work, but I'm also
not so sure that the work is always the point.

There is a cost problem.  By default, it would also be an incredible
amount of memory and disk space. That's important for a pay game,
and CRUCIAL for a free game!  Finding out what data structures to
use, and particularly what data can be cheated and how, is really
necessary for resolving this to the extent possible.

There is a reliability problem.  Such a scheme can be a real pain to
deal with in debugging. If the database goes insane, you have to
roll back anyway (of course, this doesn't go over well). Every bug
you write has a chance of screwing up the data and requiring the
database to be healed, sometimes when such a thing is impossible.
So each additional feature of this kind puts a little more pressure
on the resilience of the code. Even if you can get the bugs licked
really well, data have other ways of being corrupted - deliberate
exploitation by users, bad memory and disks, etc...  and EVERYONE
hates game failures.

There is a problem with the result.  The other class of problems I
see is that people (here I mean designers more than anyone) don' t
necessarily WANT that kind of persistence. It is desirable to you &
I, but the consequences are not 100% milk and honey, even correctly
and fully implemented. What does any given bit of persistence _do_
for us?

I think *small-scale* proofs of concept are going to be very useful
in getting this kind of feature out of the head and into the
games. I am not a genius, I'm not about to juggle all of these big
problems at once before I even know how it will turn out.

Sasha

_______________________________________________
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