[DGD]Melville

Stephen Schmidt schmidsj at union.edu
Sun Jul 30 20:37:17 CEST 2000


On Sat, 29 Jul 2000, Darius AMJ wrote:
> Now, and this is my question, does anyone out there have any advice for
> the player combat system that I would like to code next?

Think very hard about the tradeoff between features and speed.

Presuming that you run combat in the more-or-less traditional
LPMud way, that is, using a two-second heartbeat, your combat
code will execute twice every two seconds (once for the player,
once for the monster) for each fight. More than that, if there's
more than one player or more than one monster (or both) in the
fight. How many fights are going on at once depends on how big
the mud is, how many players there are, and how long the fights
last; but it's certainly not impossible for five or six to be
going on at once, at least for brief periods.

On the other hand, the traditional LPMud combat is a bit boring.

  You swing at Beggar and miss.
  Beggar swings at you and misses.
  You swing at Beggar and strike a grazing blow.
  Beggar swings at you and misses.
  You swing at Beggar and miss.
  Beggar swings at you and misses.
  You swing at Beggar and pulverize its tuchus.
  Beggar staggers and falls down... dead.
  You have earned 6 experience points.

There are two common responses to this. One is to make combat less
important in the game world, so that people devote their creative
effort to other things and don't worry if combat is boring. The other
is to make combat more complicated, adding features like special
powers, multiple attacks, limb-based systems, and what not.

However, adding features makes combat run slower. Thus, the more
complicated combat is, the fewer combats you can have and the
shorter each one has to be, so they don't lag your mud into
oblivion. If you want people to spend a lot of time in combat,
then execution has to be quick and the design has to be kept
simple.

So think about the world of your mud and what players are going
to be doing in it. Is combat the primary activity of your mud?
Or do players do other things to which combat is only incidental?

If you want to have a mud which focuses heavily on combat, and
in which combats last for a long time, you must have the combat
code execute quickly. Then you can't afford to add features
willy-nilly; you have to decide what's truly important and
junk everything else.

If, on the other hand, you want more of a social mud or
problem-solving mud or creative mud, then you can afford
a more intricate combat routine. And, conversely, if a
really intricate combat routine is what you want for your
mud, then you have to figure out a way to design the -game-
that you're creating for players to play in such a way that
players spend most of their time outside of combat.

<soapbox>

More generally, I recommend that you not worry too much about
the design of your -code- until you've figured out the design
of your -game-. What are the objectives of the players? What
are their challenges? What tools do they have to solve those
challenges? How do the players interact with the game world?
Is the game world internally consistent? How do the players
interact with each other? Will the interactions be cooperative
or competitive or both? What feature of the game will make it
a fun game to play that will attract a core of dedicated 
players to bring the world to life?

In the last, oh, six or seven years we've seen muds drifting
in the direction of being multi-purpose computer operating
systems and away from the direction of being games. We could
debate whether that's a good thing or a bad thing, and I've
got my share of the blame (or credit) for that happening. But,
we have de-emphasized the nature of muds as -games- that
people play together in cyberspace. Personally, I think we
need to re-emphasize that.

</soapbox>

That said, four pieces of specific advice on combat:

1) Remember that some people can use aliases to send dozens
of commands in a single sentence. If you don't use the heartbeat
system, you have to limit the number of combat-related commands
the player can send in a given time period.

2) I like systems with lots of different guilds and lots of
different spells and powers and so forth. But they have to be
controlled (see point 1) and ensuring balance is tricky.

3) I also like systems where players can work together. Either
having a guild specialization where powers work best in combination,
or having some kind of tactical map where you have to work around
behind the monster to attack from the rear or what have you, is
cool. Even better is if monsters can work together that way, but
that's pretty hard to code well.

4) Keep combat short. Nothing's worse than sitting for two or
three minutes watching "You miss, Flea misses, you miss."
Whatever happens, have it be short and brutal. Then have
players focus on manipulating their powers, or equipment, 
or positions, or tactics, or what-have-you, in such a way
that that short moment of brutality goes their way.

And last, the Melville philosophy:

Decide what -you- want to do and code it the way -you- want it.
Don't just take someone else's code and use it with little or
no modification. In attracting players, creativity and game
design are everything and coding is not much at all.

My 0.02....

Stephen Schmidt



List config page:  http://list.imaginary.com/mailman/listinfo/dgd



More information about the DGD mailing list