Re: MUD essential features (fwd)

From: Patrick Dughi (
Date: 08/30/00

> 1. Combat
> Partially, this has to do with my belief in Role Playing, but I think
> on any MUD combat needs to be more dynamic and exciting then just
> this.

        Before you start, the worst part about computer-based combat
systems is because they're the opposite of those found in any paper RPG.
If you want to do something in a computer system, it has to be
specifically coded.  If you want to be able to aim for the eyes with your
bow, or roll a boulder down a mountain to crush your enemies, it all has
to be coded.  A well run RPG though, anything is possible.

        The end result of this is that no matter what you do, it is
difficult to make combat dynamic and exciting based on the actual combat
alone - everyone quickly figures out exactly what you can and cannot do.

> -- Mapped Combat
> In combat, players get a little ASCII map, 8x8 or so. Different weapons
> have different ranges, charging and dodging are now more possible...
> Most importantly, how do you code all this? What does this do to your
> memory requirments?

        I wouldn't worry about memory requirements, so much as how you
intend to display this.  Wouldn't you need an update every time something
in your combat theatre moved?  You'll probably have to stick with
scrolling, as many clients don't support a full compliance with vt100/etc
cursor control codes.  Bleh. That would suck.  Everything else is just a
2-D algorithm problem, easily solved with junior-high level trig.

> -- Combat Style
> Players can assign different combat 'styles', most likely based on
> varying the proportions of three or four key factors (ie agressive vs.
> defensive, power vs. finesse, etc.) How do you balance all of
> this? Again, how do you code this?

        How do you code/balance it?  Well, there's no one formula for
balancing everything for every mud.  You have to find your own balance.
If you want a combat to take 5 rounds, and it takes 10, you're unbalanced.
Other people may want that 10 rounds.  In anycase, the coding itself is
pretty simple.  The hard part is explaining what you are going to do.
I'd sit down for a long time and write out the exact definition of each of
the styles (some call them stances; defensive, offensive, etc).  Play with
it on paper and get a good idea from that first.

        As for code, I'll write a follow up document on how some
programming ought to be done....

> -- Scissors, Paper, Rock I'm sure you all know the game. In an
> overanalytical, bad martial-arts movie sort of way, it is a commentary
> on life. This sort of situation would work well in a MUD, (IMNSHO) as it
> would basically force players to co-operate, and would contribute to
> game balance.
        Frankly, this is an oversimplification, especially considering
that you have a computer at your command.  Unless you have about 10-20
'hands', each being able to make one of several hundred
rock-paper-scisor-apple-car-dog-abraham lincoln-etc shapes, with less of a
one to one correlation (ie, car beats dog, only if previously car was
paper, and lost to abraham lincoln, etc), well... then it's going to be
even more simplistic than the stock combat system.

        Then, what happens when 4 people attack one?  Where does
experience or skills come into play?  How does this make people cooperate,
or balance the game?  I understand what you're saying, but I don't see
immediate applications for any combat design which is immediately usable.

        If you're going to develop a system from scratch, no matter what
it is, you should spend alot of time flushing it out 'on paper', and then
put it in.  Something many people do is start from a system they already
know works, and modify it till it ends up at what they want.

> 2. Atmosphere
> Problem, though: The older a MUD gets, the more 'distributed' it seems
> to become. I know for the first few months of operation, my MUD will be
> basically controlled entirely by me. Without imposing utterly draconian
> controls (unless I really HAVE to) on builders, wizzies, etc, how do I
> keep the MUD within the historical framework I have set for it?
        You have a firm idea on the history, mythology, and what-have-you
for your world.  Usually maintaining the backdrop scenery like zones,
mobs, items, and code-dependant issues (spells), is pretty easy.  Just say
something like "You can work on whatever you want, but nothing goes 'live'
in the game till I've had a chance to evaluate it for correctness".  This
causes the builders to work for you (if it's not what the boss wants, it
won't go in), instead of _with_ you (I have as much say as what goes in as
they do!).  Really, that's what you want.

        It may also be a good time to institute some policies for your
immortals to follow.  Many admins cause problems with their
immortal-heirchary.  They have a well-developed mythology which present
day admin/immortals are a part of.  The problem is that these same
characters are not on to 'play' gods, so much as to administer the mud,
build, code, whatever.  Having Zeus or Odin jump down from the heavens and
scold you for public use of foul language sets up the same sort of discord
that having a Coke vending machine in the middle of midgaard would.  I'd
recommend you seperate your god-immortals (those that play gods), from
those who are janitors, secretaries, and police (those that do actual
work).  You should probably make any transaction between the workers and
players minimal as well - in fact, only the disciplinairy group should
have any contact of any type.

        It also never hurts to find admin who share your identical view of
the mud, and where it should progress to.

> 3. Atmosphere, Part II
> One of the things that's always irked me about many MUDs is the
> 'transparent' nature of the items and spells. I mean by this that many
> people know exactly what 'a jade knife, glistening in the light' is, how
> much it's worth, what its bonuses and penalties are, etc. When this
> happens it ceases to be 'a jade knife, glistening in the light' and
> starts to be '+1 to STR, +30 to HP'.

        Well, back in the days of D&D, you usually wouldn't know the stats
on an item, unless you had a crap DM.  If I remember, the 'identify' spell
took something like a month to cast, during which time the caster could do
nothing else requiring actual effort, etc, and had to remain in contact
with the item.  In part, that's what made a weapon so desirable, and
things like curses or personality-imbued items so exciting.  If you have a
longsword +1, flame tongue, it's boring.  If you have a regular sword
which will burst into flame on command, it's _magic_.  The downgrading of
a magical historal relic to a mere item is a huge loss.  Knowledge that
'Excalibur' is actually a 25d4 +5hitroll/+5damroll sword isn't as
impressive as saying "I wield the Excalibur!" and having to leave it at

        To give a funny example of the excitement vs. boring knowledge.

        The problem is that everyone out there is now innured to this sort
of instant identification system.  If the mages don't have it, usually the
scrolls are on sale cheap.  Everyone expects that they will know the stats
on all their equipment, and on their own person.  They don't have to play
for a while and suddenly realize - Hey, this sword seems to be really
effective against magic-using, and regenerating creatures!  It also
doesn't help that once one person knows what an item does, everyone then
on can potentially just learn it from them.

        It would be nice to remove the majority of this knowledge from a
player, or only reveal the information which they would have as a
character instead of a player.

> 4. Keep stuff secret
> When players know they have 70 hp left, they're inclined to virtually
> whip out their calculators, punch in the numbers, and know exactly what
> the odds are. It's fairly radical, but why not get around this by simply
> not telling players exactly what the numbers are?

        Simply switching things to things like "beat-up" when you're at
20% of your full life, and the sort is one of those one-step forwards,
two-steps back sort of move (IMHO).  This setup works well for hitpoints,
mana, mv, etc... but others like strength, dex, etc...

        How does a player know they're "Godlike" strong, or "Average"
intelligence?  If your world has some sort of standardized testing, that's
great.  One mud had a fair with games, each one was stat dependant
mainly.  Your score/ability in the game showed up over time pretty well.
If you got a cupie doll from the hit-the-mallet-to-hit-the-bell test, you
were damn strong.  Normally though, a person would only know how good they
are by comparing their actions to those of another person, and evaluating
over the set of all people in the world :)

Look at
for a discussion on automated stat generation and ideas on how to make
stats useful, but not letting a player know too much.


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/11/01 PDT