[MUD-Dev] Re: MUD-Dev digest, Vol 1 #142 - 4 msgs

Marian Griffith gryphon at iaehv.nl
Sat Aug 21 10:38:04 CEST 1999


In <URL:/archives/meow?group+local.muddev> on Tue 17 Aug, Wes Connell wrote:

> I read it on Raph's Design Laws page that said something to the effect of
> no matter how complex the system is players will, through trial and error,
> learn every nook and cranny about the system. 

> So even if we have super cool ecologies and economies the players will
> always find the best way to do things and stick with those. In turn
> sorta making the rest useless.

As an architecture student one of the first things you learn is that the
design problem is a puzzle, but one that has no 'right' answer. There is
too much possible  and there are too few constraints  to ever be able to
say that something is the 'best' solution.
The same must apply to a simulated ecology or economy.  If it is shallow
and easily optimised then yes,  most of the effort put in the system  is
wasted.  However,  if the ecology is very deep and broad,  with too many
variables to ever optimise, then the players can better immerse themsel-
ves in the game, and more so, they can not 'beat' the game.
Part of the problem is that in muds there is only a single problem to be
solved: combat. The variables to optimise are equally simple: +hit, +dam
and speed. If you can balance those right you get what is the best char-
acter in the long run.  (Of course  some muds may have systems  that are
more or less complicated). What if, as a player you had to worry about a
lot more than just combat. Suppose that if you want to run a campaign it
is important to bring soldiers along  (non-players).  These must be fed,
armed, transported, and so on. Suddenly, as a player you have a lot more
things to worry about and the local ecology is going to be -very- impor-
tant all of a sudden.
Or make some minor changes to the combat system so that it no longer is
relying quite so much on attrition of hitpoints but more on tactics. In
such cases  the 'right' equipment can vary a lot more  than is the case
with common muds.  When going against a heavily armoured knight you may
want to have that big shield to block the blows of his mace.  That same
shield  would do you no good against a thief with a rapier,  for he can
probably strike at you and jump out of reach  before you can bring that
heavy shield around. Wearing a light shield will get you slaughtered in
both cases, so averaging is clearly not going to help you. And when you
go against a dragon  you best have something fireproof  (which would do
you no good against a water sprite). Even with minor changes to the way
combat is handled the job of optimising equipment is suddenly much har-
der, and the same applies to economies and ecologies.

> Of course this depends on the type of player (another thing about the four
> types of players discussed on Raph's page). If you have a PowerGamer then
> the above will happen. If you have a RolePlayer then probably not.

Probably not, though it depends a -lot- on what type of roleplaying you
are refering to.  Even if you are playing a role it can still be impor-
tant to know how the game works.

> On the other hand, the super cool ecologies and economies can be quests in
> themselves. The players work hard to disect the system, learning the game,
> and advancing. Which is what we want. The end result may be a bunch of
> players runnning around the same area with the same armor, but hey thats
> when we add new players. =]

The best reason to have simulated ecologies and economies  is that they
give breadth and depth to the gameworld.  When done properly  they also
make the world more predictable and thus easier to play with.

Marian
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...

Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list