<!-- MHonArc v2.4.4 -->
<!--X-Subject: EVOLUTION response -->
<!--X-From-R13: pynjNahyy.arg -->
<!--X-Date: from fabius.globecomm.net [207.51.48.6] by mx01.ny.us.ibm.net id 858894292.49957-1 Thu Mar 20 21:44:52 1997 -->
<!--X-Message-Id: 3331b0081599002#msgSFO01,schwab.com -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, EVOLUTION response</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#null,net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00154.html">Previous</a>
| <a href="msg00155.html">Next</a>
]
Thread:
[ <a href="msg00155.html">Previous</a>
| <a href="msg00172.html">Next</a>
]
Index:
[ <A HREF="author.html#00156">Author</A>
| <A HREF="#00156">Date</A>
| <A HREF="thread.html#00156">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>EVOLUTION response</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI><em>Subject</em>: EVOLUTION response </LI>
<LI><em>From</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI>
<LI><em>Date</em>: Thu, 20 Mar 97 13:38:35 -0800</LI>
<LI><em>Reply-to</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Here's the post that Jon referenced:
Subject: EVOLUTION response [1/4]
From: cj841#cleveland,Freenet.Edu (Chris Steiner) Date:
1996/07/11
Newsgroups: rec.games.mud.admin
Four years ago I came to the conclusion that something
needed to be done with MUDs to improve them. On and
off, I tried to gather people together to write the
code for the MUD described below. When code was not
being written, I was doing studies and interviews,
determining what different types of people enjoy when
playing MUDs, and any related game. I have worked
hard on a balance and pattern which will not only
bring out what more players want in MUDs, but also
grow in ways which will continue to make it better.
And now I find the current trend towards doing the
work I have already done.
Here is the last written compilation I made of my
ideas. There is much more to it, of course, but I
haven't written it down. If you like it, I will tell
you more of what I have in mind.
To: gyinglin#voyager,commsys.com
From: cj841#cleveland,freenet.edu
Subject: AmalgaMUD
Well, I have everything done except for the specifics
on the structures, but I think you can figure that
much out since all of my other preferences are
described.
This is a first draft. You can send back gripes if
there are things you don't like.
Preface
0.0 The AmalgaMUD Concept
MUDs can be so much more than they are. Most MUDs are
limited by their implementors and their "Wizards" or
"Gods". Most MUDs are also limited by what activities
the players can attempt. I have seen too many MUDs
that are entirely hack and slash oriented, where the
only reasons a player has of interacting with another
player is to gang up to kill monsters or to auction off
items. I have seen too many devout players attain the
rank of godhood, only to be told that he or she must
not interfere with the players.
And so I propose a MUD where there is more than one way
to play the game. Gods are gods, and have their place
in interacting with the mortals and creating more of
the world. Merchants trade between cities and pay
attention to the times. Politicians vie for rule of
the cities and go to war occasionally. Adventurers
hunt down monsters or treasures, or occasionally other
players, for rewards given out by other players.
Seasons change, bringing new hardships, famine, and
reasons for people to work together. Characters grow
old and die, passing skills and property on to their
children.
And, hopefully, players sail on ships between islands,
traveling from one AmalgaMUD site to another, telling
tales and sharing new skills and treasures.
The purpose of an AmalgaMUD is to provide an
environment where players can chose from several
different lifestyles, interact with other players, and
be entertained. AmalgaMUDs are designed to grow and
change. The players themselves will shape much of
their world, and receive the rewards thereof.
An AmalgaMUD is not something that is to be controlled,
but rather enjoyed for what it is.
0.1 Layout of this Document
Since the purpose of an AmalgaMUD is aimed at having
several complex systems interacting, there is no good
way to arrange this document. I will start with
sections that are easily grouped together, and move to
more obscure ones as this document progresses.
Nevertheless, you will probably find the need to
re-read the earlier sections again to understand them
completely.
Section 1
Data Structures
1.0 Conceptions of AmalgaMUD data structures
Every structure in an AmalgaMUD is a linked list, and
there are three of almost every type of structure.
There is a Master List, which contains all of the
qualities of each specific object, the Record Lists,
which contain only listings of what is where and if it
is unique or not, and the Unique Structures. Master
Lists are global variables. There is a Master List for
Items, Mobiles, Plants, and Skills. These hold all of
the detailed information of the common objects
encountered throughout the MUD. Record Lists are
pointed to by rooms, mobiles, or container structures.
These keep track of what is where, and what temporary
effects apply to them. Unique Structures are pointed
to by structures in Record Lists. These only appear
when a single object is modified permanently.
For example, in the Master Item List, there is a record
called "backpack". Smythe, the Merchant, carries two
of these. In Smythe's Record Item List, there are two
entries that point to the structure in the Master Item
List called "backpack". He decides that he wants to
hide some of his wares, so he casts Invisibility on the
first one. An info structure is attached to the
structure in Smythe's Record Item List noting the
Invisibility and how long it will last. Smythe somehow
gets a spell that will permanently increase the amount
one of his backpacks can carry, and he casts this on
his first backpack. A unique Item structure is made
with the larger volume. The Record Item List changes
it's pointer to the unique Item structure just created.
Nothing need be done about the info structure noting
the Invisibility; it's still in the right place.
1.1 The Mobile Structure
Characters and mobiles use the same data structures.
Some of the fields are used differently for characters
as they are for mobiles. Every mobile is an individual
entity, but there is still a Master Mobile List, which
is accessed by plant structures on occasion.
Characters access an array of mobile structures. This
is the only array of structures in the code. The
maximum of this array is the maximum number of
connections the AmalgaMUD can support.
1.1.1 Mobile String Information
The Mobile Structure has several informational fields
that are all pointers to characters. These fields must
be freed and malloced every time they are changed.
Keeping the information as arrays of characters would
waste much memory and put limits on creators.
City: Characters select the city they belong to when
they create their character. The character, when
saved, is put in a directory which is their city, in
a file which is their name. Instead of pointing to
an individual copy of the city name for every mobile
from the city, this points directly to the zone name
of that city.
Description: Anything will do here. Characters can
define this themselves.
Hunting: This is the name of the mobile type a
character or mobile is hunting. Upon entering a room,
if a mobile of this name is present, the character or
mobile will immediately attack the hunted mobile.
Name: Characters choose a login name, which must have
no spaces, and must be unique in their city. Mobiles
can have spaces in their names and can be named the same.
Profession: A character's profession is chosen when
logging in, but can be changed during the game.
Mobiles can have any name here. If a mobile can
teach, it teaches better to those with an identical
profession.
Racename: This is entirely for descriptive purposes.
A character can have any racename, and so can a
mobile. When a player looks at a mobile, they see:
<name> the <racename> <profession>, among other
things. When looking at a room, players see other
mobiles like: <name> of <city> is standing here.
1.1.2 Mobile Statistics
The mobile structure has an array of 36 shorts that are
used for keeping track of common information that needs
to be accessed quickly. All stats have a function in
the game. I find it useless to have stats that only
effect how skills develop.
Food & MaxFood (0 & 1): This stat keeps track of when
the character gets hungry. The character is warned
at half, and if this score reaches 0, the character
begins losing Health. Mobiles do not suffer from
this, but if the score is 0, they will eat if they
have the chance.
Level (2): This is, if nothing else, used to keep
track of Deity permissions. Experience does not
raise a character's level, only guilds do. Levels
should mark significant changes in the role and
accessibility of a character, not just an increase in
skill.
Lives (3): AmalgaMUD characters don't last forever.
When this score reaches 0, the character is erased.
In mobiles, this is used as a flag for special
mobiles. If this score is 2, the mobile will be
moved to Heaven until a god does something with it.
LowVision & HighVision (4 & 5): This is the range
of light level in which the character can see.
Potential (6): This keeps track of how much a character
can learn right now.
Race (7): This refers to race type. Players will
never see this score. It is used exclusively for
coded actions, like riding and procreation. It could
also be used for race restricted exits.
Speed & MaxSpeed (8 & 9): This stat keeps track of how
fast the character or mobile can act. When it
reaches 0, the character or mobile cannot move.
Non-motion actions, like speech, bargaining, and
examining can still be performed.
Visibility (10): This is how obvious the mobile is to
others.
Water & MaxWater (11 & 12): This stat keeps track of
when the character gets thirsty. The character is
warned at half, and if this score reaches 0, the
mobile begins losing Endurance. Mobiles do not suffer
from this, but if the score is 0, they will drink if
they have the chance, even above eating.
Waste (13): This stat keeps track of when the character
needs to visit the bathroom. As Food and Water
decrease, this score increases. At half of maximum,
the character is warned that they need to relieve
themselves. At maximum, the character will begin to
lose Speed, and will run the risk of relieving
themselves involuntarily. Mobiles will relieve
themselves when the score reaches maximum, but only
if they are not inside a city or building.
Agility (14): This is the mobile's basic ability to
dodge and keep balance. Dodging is useful in combat,
and balance is sometimes checked when traversing
certain exits.
Endurance & MaxEndurance (15 & 16): This is the
mobile's ability to withstand damage. If this score
ever reaches 0, the mobile dies.
Health & MaxHealth (17 & 18): This is how fast the
mobile heals and it's ability to resist poisons. If
this score ever reaches 0, the mobile dies.
Intelligence (19): This is the only stat that effects
how the character learns skills. In mobiles, this
represents bargaining ability, etc.
Mana & MaxMana (20 & 21): This is the mobile's
ability to cast spells. Nothing happens if this
score reaches 0.
Observation (22): This determines what is noticed by
the mobile. This effects sneaky scores as well as
casual observation of an area.
Strength (23): This effects how much a mobile can
carry and it's base damage when attacking without a
weapon.
Head Damage (24):
Left Arm Damage (25):
Right Arm Damage (26):
Chest Damage (27):
Nether Damage (28):
Left Leg Damage (29):
Right Leg Damage (30):
Each of these is set to Endurance - d3 initially. If
HD of CD reaches 0, the mobile dies. If LAD, RAD,
LLD, or RLD reaches 0, that limb cannot be used until
it heals. If ND reaches 0, the mobile withdraws from
combat and cannot walk until it heals. If Endurance
falls below these scores, they lower to the current
value.
Carrying(31): This keeps track of how much the mobile
is currently carrying.
State (32): This is used to tell what the character is
doing right now.
Character Final Stats
Generic Counter (33): This is used by characters
throughout the code as a method of keeping track of
what the character was doing.
Previous State (34): This is used to facilitate
backing out of actions, like QUIT.
ActiveHours(35): This keeps track of how many hours a
character has been played. Fractions are dropped.
Mobile Final Stats
Track(33): This is used to keep track of where in the
mobile's list of planned actions it is.
(34):
(35):
Skills constructed in the game that alter statistics
will refer to these numbers, not the names, so it is
important that all sites use the same numbers to
represent the same statistics. Internally to a single
AmalgaMUD, this would not seem to matter, but when
skills travel between AmalgaMUDs with characters,
problems could arise.
Final Stats should never be altered by Skills, only by
code.
1.1.3 Mobile Flags
The mobile structure also contains an 32-bit integer,
each bit of which is to be checked as a flag. These
also can be altered by skills constructed in the game
and so must remain numbered as such.
Aggressive (1): A character with this bit not set has a
chance to flee if attacked. A mobile with this bit
set may choose to attack a character.
Amorphous (2): If this bit is set, the mobile is not
hindered by doors, selective, locked, or otherwise.
Blind (3): A character with this set should not
have any visual information written to their screen.
BreatheWater (4): Mobiles without this flag set
will not go under water. If a character with this
flag set goes under water, it will take damage on
every healing pulse.
Brief (5): A character with this set should not have
unnecessary information written to their screen.
Criminal (6): This bit can be set by Guard mobiles and
can only be cleared by a Deity or one holding the
Item of Office.
Deaf (7): A character with this set should not have
any auditory information written to their screen.
Deity (8): Some actions are reserved for Deities only.
They check for this bit.
Dumb (9): Mobiles with this bit set are not able to
speak or emote. This bit will be cleared for all
players every pulse.
Flying (10): This tells whether a mobile can fly, but
not if it is flying currently.
Guard (11): A mobile with this bit set should be able
to detect and alter the state of mobile's Suspect and
Criminal bits.
Hot (12): This is used to tell if a character can be
seen with infravision.
Imp (13): Some actions can only be performed by the
Imp. They check for this bit.
Infravision (14): When too dark to see and in a cold
room, a character with this bit set should be able to
see mobiles, and hot items. In hot rooms, characters
with this bit set should be able to see normally.
Invisible (15): A mobile with this set should only be
seen by those with the SeeInvis bit set.
Marked (16): A somewhat generic flag that can be
checked for plot or effect purposes.
Mayor (17): If this bit is set, the mobile may
withdraw, by percentage, money from their city's bank.
Merchant (18): Similarly, some actions are only
allowed to merchants and the like. These actions
check for this bit.
Player (19): This bit distinguishes characters from
mobiles. It also marks a mobile that is being
possessed by a player.
ResistAcid (20):
ResistCold (21):
ResistElectricity (22):
ResistHeat (23):
ResistMagic (24):
ResistPhysical (25):
ResistPoison (26):
These control what types of immunities the
mobile has.
Riding (27): This bit is set when a Mobile is riding
another Mobile. The Mobile being ridden does not
have this bit set. A Mobile with this bit set cannot
use normal movement commands until it dismounts.
This bit can be used to keep a non-riding mobile in
the same location.
SeeInvis (28): A character with this bit set should be
able to see invisible mobiles and items.
Sick (29): This is a somewhat arbitrary bit, but if it
is set, the healing pulse does not heal as much.
Suspect (30): This bit can be set or cleared by Guard
mobiles.
Teacher (31): All characters and mobiles that are
supposed to teach have this bit set. The Teach
command will not work without this bit being set.
Watching (32): Only if this bit is set is combat
information to be sent to a character's screen.
Leaving a room should clear this bit.
1.1.4 Mobile Pointers
The Mobile structure contains a limited number of
pointers, most of which are used just to hold
everything together.
Info *Effects: This points to the first node in a list
of Info *s. The main pointer in each node points to
a Skill structure (which at some point caused the
effect) and the short is used to keep track of how
long the effect will remain. When the short reaches
0, the effect is undone and that node is removed from
the list.
Info *Opponent: This points to a single Info structure.
The pointer points to a Mobile for various reasons.
For non-player Mobiles during combat, the short is
used to keep track of how much damage the Mobile
pointed to caused. For Characters during barter, it
is used to keep track of the current price.
Info *Languages: This points to the first node in a
list of Info *s. The main pointer in each node points
to the Name string in a Zone, preferably a city. The
short can be ignored.
Info *Skills: This points to the first node in a list
of Info *s. The main pointer in each node points to
a Skill structure in the Master Skill List. The short
in each node represents the character's proficiency in
that skill.
Info *Quests: This points to the first node in a list
of Info *'s. The main pointer in each node points to
the first Info structure of the quest on the
receptionist where it was aquired. The short in each
node is used to keep track of where in the quest they
are. (Note: When saving the character, do not save
any quests that have a 0 in the short of the Info
structure on the receptionist, as that structure may
dissapear.)
Info *Pending: This points to a list of actions that
the player typed in but the character's speed would
not let him do.
ItemList *FirstItem: This points to the first item in
the Mobile's inventory.
ItemList *Equipped: This is a list of the weapons,
items, and armor that the mobile has equipped, in that order.
ItemList *InBank: This is a list of monetary items kept
in the bank.
Mobile *Next: This is used to point to the next Mobile
in the list of people in the room.
Mobile *ListNext: This is used to point to the next
Mobile in either the Master Mobile List or the Master
Player List.
Mobile *Riding: This points to either the Mobile this
Mobile is riding, or the Mobile that is riding this
Mobile.
Mobile *Following: This points to whomever this Mobile
is following.
1.2 The ItemList Structure
There are two item structures: the ItemList structure
and the Item structure itself. The ItemList structure
is very simple, containing only 3 pointers and an
integer. The purpose of the ItemList structure is to
minimize the ammount of information a given mobile or
room contains while still maintaining enough flexibility
to make it appear that every item is kept in individual
storage.
ItemList *Next: This points to the next item in the
inventory.
Item *Item: This points to either an Item structure in
the Master Item List or a unique Item structure, or in
special cases is typecasted to a pointer to a Plant
structure.
Info *Effects: This operates exactly as it does for
Mobiles.
int Flag: This keeps track of the status of the item in
the inventory.
int Number: This displays the number of identical items
owned for Mesh items. For other items, it is
occasionally used for other purposes, like hit points
of Armor.
1.2.1 ItemList Flags
Like the flags for Mobiles, these numbers must remain
the same between AmalgaMUDs or problems with new skills
traveling between sites will arise. Also notice that
while the flags for Mobiles are alphabetized, the flags
for ItemLists are not. This is because many of the
flags are identical. Only the ones that applied only to
Mobiles were changed.
Armor
Crumble: When an item with this bit set is dropped, it
is erased from memory.
Cursed
Drink
Food
Immobile
Mesh
Plant
Weapon
(1):
(2):
(3):
(4):
(5):
(6):
(7):
(8):
(9):
(10):
(11):
Hot (12): This is used to tell if an item can be seen
with infravision.
(13):
(14):
Invisible (15): An item with this set should only be
seen by those with the SeeInvis bit set.
Marked (16): A somewhat generic flag that can be
checked for plot or effect purposes.
(17):
(18):
(19):
(20):
(21):
(22):
(23):
(24):
(25):
(26):
(27):
(28):
(29):
(30):
(31):
(32):
1.3 The Item Structure
1.4 Plant and Generator Structures
The plant structure is used for generating edible or
expendable materials and mobiles. They are called
plants because the origional version of one of these
was an tree that generated apples. It should be noted
that plants are only seen by Deities and sometimes
Merchants, as the defined in the plant.
1.5 The Zone Structure
1.6 The Room Structure
1.7 The Exit Structure
1.8 The Info Structure
The Info structure is a generic structure for keeping
simple lists. It consists of three things:
Info *Next: The next item in the list.
void *Ptr: A pointer to something. This needs to be
typecast when it is used.
short Bit: A value counter.
1.9 The Skill Structure
The Skill structure is designed to allow the Deities to
come up with new skills that the characters may learn.
The new skills will be targeted at altering the stats
and flags of items or mobiles in the same room as the
character.
/* hard code skill bit? */
Skill *Next: The next skill or effect in the Master
List.
char *Name: The word that activates the skill.
char *Description: Description of how to use the skill.
char *DisplayOthers: This is the string printed to the
screens of everyone witnissing the skill.
char *DisplayTarget: This is the string printed to the
screen of the target of the skill.
char *DisplayUser: This is the string printed to the
screen of the character using the skill.
char *FailOthers: This is the string printed to the
screens of everyone witnissing the skill failing.
char *FailTarget: This is the string printed to the
screen of the target of the skill that failed.
char *FailUser: This is the string printed to the screen
of the character using the skill that failed.
short Type: This is used to represent the type of
effect done. Damage, for example, is listed in the
values of the ResistFlags. I.E. a flame strike spell
would have ResistHeat here.
char Target: This single character defines what the
spell is supposed to effect. The contents of this
field can be either `S' for Self, `m' for mobile, `I'
for a single Item held or "on the floor", `i' for a
single item on a target mobile, `G' for a group of
Items held or "on the floor", or `g' for a group of
items on a target mobile.
Info *Effect: This points to a linked list of Info
structures. The pointer field a pointer to a string.
The first character of this string is either an `S'
for Self or a `T' for Target. This tells to what the
effect is happening.
The second character of this string is either an `s'
or an `f'. This tells whether a stat or a flag is
being changed.
The third character is either a `+', a `-', or an `='.
This tells how the stat is being changed.
The remaining characters of the string may either be a
single number or a ramdom number expressed in the
format: #d#+#.
The short value of the Info structure tells exactly
which flag or skill is being modefied.
For example, a cure light wounds spell would have the
Effects defines as such:
Effect->Ptr = "Ss-8", Effect->Bit = 20 (Mana),
Effect->Next->Ptr = "Ts+1d8+1", Effect->Next->Bit = 27
(Chest Damage).
This says that it will subtract 8 points from the
caster's Mana, and add 2 to 9 points to the target's
Chest Damage. Note however, that any effect targeting
the stat Chest Damage has an equal chance of effecting
any of the stats within the range of 24-30 (the Location
Damage stats). This is an effect particular to the 24th
and 27th stats.
It should also be noted that if any effect fails, the
skill will not proceed. This is why the subtraction
of Mana is listed before the healing. If that ammount
of mana cannot be subtracted, the skill fails and no
healing is gained.
1.10 The Master Lists
The Master lists are a large attempt to preserve
memory, but they also became very useful in
implementing certain procedures. For example, the
healing pulse simply traverses the Players and Mobiles
Master Lists, healing each as appropriate. These
lists are to be accessed as much as possible to
conserve memory. For example, the Name pointer for
non-unique mobiles should not point to it's own array
of characters, but rather to the exact same array of
characters of it's type in the Mobile Types Master
List. No matter how many "rabid mice" are scurrying
around the mud, there should only be one array that
contains the name "rabid mouse", with every rabid
mouse mobile structure pointing to it.
ItemTypes - A list of Item structures representing
each type of generic item in the MUD.
MobileTypes - A list of Mobile structures representing
each type of generic mobile in the MUD.
Skills - A list of Skill structures representing all
of the skills in the MUD.
Players - A list of Mobile structures representing the
current players.
Mobiles - A list of Mobile structures representing
each active mobile.
Section 2
Login and Character Creation
2.0 The Feel of Entering an AmalgaMUD
Logging in should have the atmosphere of the
AmalgaMUD. As soon as the players connect to the
site, they should be drawn in to the world. In mine,
the character begins floating in a dream like void. A
god-like being approaches and asks a few questions,
creating the character, then sends them down to the
planet below, getting an overview of the world as they
descend. The purpose of this is to let the player get
into the feel of the game right from the start We
want the players to be enjoying the game as soon as
possible.
Subsequent entries start in the dream-like void, but
instead of a decent to the world, the character wakes
up.
2.1 Individual Zone Entry
The players descend into their home city, receiving a
description of their decent and the city itself. This
description is entered, and can be modified by, the
Deity in charge of that city. Where the player
descends to can also be altered by the Deity of the
city. It is recommended that new characters land
somewhere quiet so they have a chance to figure out
what is going on before having to deal with other
players. However, they should not land so far out of
the way that they spend much time in search of other
players.
There are other factors that can be edited by the
Deity of a city, such as what races live there and
what professions and classes are available. I would
advise against being too limiting, as it will simply
cause players to choose a different city.
2.2 Races and Race Names
There are 9 types of races, which is hard coded into
the AmalgaMUD. These races affect the characters
beginning stats and some supplementary abilities. As
a Deity or Imp, you may suggest certain racenames for
the races in the city, but racename cannot be
enforced. The racename is simply a string that the
player can use to give the character some flavor.
Avians have a low movement rate, but are able to fly.
The stats of an Avian are as follows:
Food: 130
Water: 180
Lives: 9
LowVision: 70
HighVision: 200
Speed: 80
Visibility: 125
Agility: 40
Endurance: 25
Health: 25
Intelligence: 20
Mana: 20
Observation: 40
Strength: 25
Golems have the distinct advantage of not dying if
their Head Damage reaches 0. Instead they just go
blind and deaf. They also don't need to eat or drink.
However, they are very slow. The stats of a Golem are
as follows:
Food: 255
Water: 255
Lives: 10
LowVision: 70
HighVision: 200
Speed: 70
Visibility: 95
Agility: 15
Endurance: 40
Health: 40
Intelligence: 10
Mana: 20
Observation: 20
Strength: 50
Humanoids start with a special sight or magical skill,
chosen randomly. Infravision, see invisibility, and
healing skills are recommended. The list of options
can be altered by the Imp. The stats of a Humanoid are
as follows:
Food: 160
Water: 160
Lives: 9
LowVision: 80
HighVision: 190
Speed: 100
Visibility: 100
Agility: 15
Endurance: 25
Health: 20
Intelligence: 30
Mana: 50
Observation: 30
Strength: 20
Insects begin with a resistance to one of the forms of
damage, chosen randomly. The stats of an Insect are as
follows:
Food: 150
Water: 150
Lives: 9
LowVision: 70
HighVision: 175
Speed: 105
Visibility: 110
Agility: 30
Endurance: 20
Health: 15
Intelligence: 30
Mana: 30
Observation: 25
Strength: 45
Large Animals are the only player mobiles that can
have riders. Conversely, they cannot ride other
mobiles. The stats of a Large Animal are as follows:
Food: 180
Water: 180
Lives: 9
LowVision: 80
HighVision: 185
Speed: 125
Visibility: 115
Agility: 20
Endurance: 40
Health: 35
Intelligence: 15
Mana: 20
Observation: 20
Strength: 45
Reptiles can breathe underwater, and do not show up on
infravision. The stats of a Reptile are as follows:
Food: 150
Water: 200
Lives: 9
LowVision: 80
HighVision: 190
Speed: 90
Visibility: 100
Agility: 20
Endurance: 30
Health: 30
Intelligence: 30
Mana: 15
Observation: 25
Strength: 45
Shades can see in much lower light than any other
player race, but bright light can blind them easier.
The stats of a Shade are as follows:
Food: 170
Water: 170
Lives: 9
LowVision: 30
HighVision: 150
Speed: 100
Visibility: 80
Agility: 45
Endurance: 20
Health: 30
Intelligence: 20
Mana: 30
Observation: 15
Strength: 35
Small Animals are incredibly light, but have the
lowest Strength of all the races. The stats of a Small
Animal are as follows:
Food: 100
Water: 125
Lives: 9
LowVision: 70
HighVision: 175
Speed: 90
Visibility: 90
Agility: 35
Endurance: 20
Health: 20
Intelligence: 50
Mana: 15
Observation: 40
Strength: 20
It should be noted that the stats like Food,
Endurance, and Speed are actually their Max values.
The Max was left off to improve readability.
2.3 Professions
The list of professions is city dependent, created by
the Deity in charge of that city, and applies mostly
to guilds and training. Some suggestions for
professions are: Citizen, Cityguard, Deity,
Mercenary, Merchant, and Priest.
While professions aren't directly important to
character creation, it does (or should) control how
the character is allowed to advance in the MUD, and
what skills and equipment is available to him.
2.4 Classes
These, like race, affect the character's statistics.
Aside from selective exits and selectively aggressive
mobiles, there is not much else this controls. This
being the case, there should be guilds or some such to
make the player feel like it is more important.
Cleric - The stats of a Cleric are as follows:
Food: 0
Water: 0
Lives: 0
LowVision: 0
HighVision: 15
Speed: 5
Visibility: 5
Agility: 0
Endurance: 20
Health: 15
Intelligence: 10
Mana: 15
Observation: 5
Strength: 5
Craftsman - The stats of a Craftsman are as follows:
Food: 0
Water: 0
Lives: 0
LowVision: 0
HighVision: 10
Speed: 0
Visibility: 0
Agility: 5
Endurance: 5
Health: 15
Intelligence: 20
Mana: 10
Observation: 0
Strength: 15
Fighter - The stats of a Fighter are as follows:
Food: 0
Water: 0
Lives: 0
LowVision: 0
HighVision: 0
Speed: 5
Visibility: 0
Agility: 15
Endurance: 15
Health: 10
Intelligence: 0
Mana: 5
Observation: 5
Strength: 20
Magician - The stats of a Magician are as follows:
Food: 0
Water: 0
Lives: 0
LowVision: -10
HighVision: 0
Speed: 0
Visibility: 10
Agility: 10
Endurance: 0
Health: 5
Intelligence: 15
Mana: 20
Observation: 15
Strength: 5
Sage - The stats of a Class are as follows:
Food: 0
Water: 0
Lives: 0
LowVision: -10
HighVision: 0
Speed: 0
Visibility: 5
Agility: 5
Endurance: 10
Health: 5
Intelligence: 15
Mana: 15
Observation: 20
Strength: 0
Thief - The stats of a Thief are as follows:
Food: 10
Water: 0
Lives: 0
LowVision: -20
HighVision: -10
Speed: 10
Visibility: -10
Agility: 20
Endurance: 15
Health: 0
Intelligence: 5
Mana: 5
Observation: 15
Strength: 10
Wanderer - The stats of a Wanderer are as follows:
Food: 30
Water: 20
Lives: 0
LowVision: -10
HighVision: 0
Speed: 20
Visibility: 0
Agility: 15
Endurance: 5
Health: 20
Intelligence: 5
Mana: 0
Observation: 10
Strength: 15
These stats are added to the characters previous
stats, a random amount (d8) is added to each of the
stats except Lives, and the player is given a random
number of points (4d4) to add to the stats from
Agility down.
2.5 Initial Skills and Equipment
It is recommended that neither of these should be
given, as newbie equipment can clutter a MUD and
players feel better about choosing their own skills.
The Food and Water statistics should be set at their
maximums. It is also recommended that newbies begin
play with the Brief flag set, so less will be
attracting their attention, and their Agressive flag
cleared so they can survive surprises.
Section 3
Deities and Cities
3.0 A Different Type of Deity
In every MUD I have visited, a Deity or god or wizard
was either a player who played the game so much as to
"earn" they name by obtaining experience points, or a
player who asked another Deity, god, or wizard for the
ability to edit the MUD. Neither of these are, in my
opinion, characters that the players can have fun
with. I propose a Deity as a profession. A player
may start out as a Deity as soon as they begin the
game.
A first level Deity operates exactly as any other
player, with no special abilities other than the
ability to travel to Heaven (or whatever). (The
entrance to Heaven need only check for a specific
profession.)
A second level Deity gets all of their ResistDamage
flags set so they can explore the world without fear,
but they become unable to enter cities other than the
one they started in. Additionally, their native
language becomes "*", which means they can understand
and be understood by everyone. They also discover
that their Mana never increases. Only offerings to
them by other players will restore their Mana.
A third level Deity gets all of their ResistDamage
flags returned to normal, and is given the ability to
alter descriptions inside their home city. This Deity
is also given the ability to create and destroy rooms
and exits in Heaven, and in any part of the "real
world" that connects to Heaven. (A profession
selective exit inside of Heaven that leads to a
chaotic area that is connected by normal exits to the
"real world". This is recommended because other
players get to see what is created by which Deity, and
offer opinions.) Altering descriptions and creating
exits cost 1 Mana. Creating a room costs 5. (The
Deity must be allowed to edit both rooms an exit
connects when creating an exit.)
A fourth level Deity is given the ability to create
mobiles in Heaven, and finds that they are no longer
allowed to leave their home city. Creating mobiles
costs a variable amount of Mana depending on the stats
of the mobile.
A fifth level Deity is given the ability to create
items, either in Heaven or in their home city.
Creating items also costs a variable amount of Mana,
but in general is less than mobiles, because mobiles
can reproduce. Fifth level Deities are also allowed
into the inner or upper levels of Heaven, where the
quest I will mention later resides. In these levels
is a place where unique mobiles go when they die. The
fifth level Deity is allowed to send these back into
the "real world".
A sixth level Deity, only obtained by completing the
quest, is given their own "real world" zone to build a
city in. They are no longer allowed in the city they
started in as their new city is now their home city.
While in their home city, creation of rooms,
descriptions, and exits are free, creation of mobiles
costs 1 Mana, and creation of items costs the same as
it did before. They also find that they are allowed
to create plants, at the cost of 5 mana.
A Deity is promoted to seventh level when one of the
other city ruling gods decides that their city is
complete. At this point, new players entering the MUD
will be able to select this city as their home. A
seventh level Deity finds that they are able to walk
outside of their city once again, but still not into
other cities. The seventh level Deity's job at this
point is to create an Item of Office for their city
and to add rooms to the quest in Heaven representing
their city.
An eighth level Deity is given the ability to create
new zones outside of the cities, and to create
mobiles, rooms, exits, items, and descriptions in
these zones. (The Deity now can create an exit when
only "own"ing one of the rooms the exit connects.)
And, finally, the eighth level Deity is allowed to
enter other cities again.
With the exception of fifth level Deities, a Deity is
raised in level by another Deity two or more levels
above them, or by the Imp. Additionally, and aside
from fifth level Deities, a Deity is raised one level
if they have accumulated 300 hours of active time
since their last promotion. This is understandably a
very slow advancement, but catches those Deities who
have bad timing or are being ignored. It should also
be noted that a Deity of two or more levels higher
than another Deity can reset the other Deity's active
time without raising them a level. This allows for
control of unwanted Deities.
3.1 Cities and Struggles
The cities are not set up to be cooperative with each
other, but they can if they work at it. For example,
a famine might strike one city (either caused by
rabbits eating all of the food, or by raids from
mobiles, or by bad economical decisions. The populous
has several choices. The first is to raid another
city, taking all of their food and food producing
plants. Another is to convince another city to help
them out. Another is to send out hunting parties and
such. And, of course, there's always asking Deities
for their help.
3.2 Deities in the City
Deities, while they are in the city, are responsible
for maintaining the working os the city and building
public relations for themselves so other players will
be willing to sacrifice things to them. Deities are
supposed to interferre and help other players as much
as they can. It's not a nice world out there, and the
cities will need all the help they can get.
3.3 Player Killing
Player killing is allowed, provided the characters
have different home cities. This allows great wars
and cloak and dagger operations to exist between
members of different cities, yet makes it relatively
safe for newbies that don't want to get killed
immediately upon entering.
3.4 The Language Barrier
Initially everyone only speaks one language. This is
to further emphasize the feel of the cities actually
being different from one another. There is no
immediate provision for learning another city's
language. To be sure, a player or mobile can teach a
language as easily as teaching a skill, but there are
no initial mobiles that can speak more than one
language. This is one of the things the Deities are
supposed to work out.
When a mobile speaks, those that can speak the same
language have the message presented to their screen in
a normal state. Those that do not understand that
language receive a garbled version of the message,
with spacing and punctuation unchanged.
3.5 Overview of Profession Interaction
The initial setup is this: There is an easily located
guild for every profession. The enterance into the
first room of the guild is normal. Inside the first
room is a receptionist or task-taker. The purpose of
this mobile is to record quests presented by players
for members of this guild. There may also be a
buliten board, but what is on that will be controlled
by the inhabitants of the city. There will be a
profession selective exit from the reception to the
inside of the guild. There may be shops or storage
areas or whatever the local Deities desire for the
guilds, but there must be a master of that profession
in the guild. The masters need not be perfect at
every skill open to that profession, but they must
have every skill open to that profession. The master
has the special ability of being allowed to raise the
level of any character they can teach. Usually a
special quest is involved, but that depends on the
local Deities.
3.6 The State
Every city must have a mobile who's purpose is to rule
the city. On a normal day, this mobile wanders around
the city, first stopping at the bank and uses the Item
of Office to tax everyone 5% or their bank account.
Then he visits each of the guilds and gives them an
equal portion, keeping a share for himself. This
action is performed once every real day.
The Item of Office may be removed from this mobile by
a majority vote for a new leader by all those
currently in the city. The new leader is allowed to
tax the bank, by any percentage, while holding the
Item of Office. This, of course, will cause much
concern within the city. While 5% tax a day is bad,
in the "wrong hands" it could be so much more
unplesant. When the player holding the Item of Office
leaves the game, the Item returns to its mobile.
The character holding the Item of Office is also
allowed to pass judgement on those players brought in
by the cityguards for, well, any crime the cityguards
want to bring a character in on.
3.7 Heaven and the Quest
Heaven is divided into at least three levels. The
"lowest" level is accessible by non-deities. I would
represent it as a chaotic section of the world that
changes easily. The "middle" level, accessible only
by profession selective exits, is initially set up as
a lounge room for the gods. This level may be edited
as well, but is intended as a place for Deities to go
and relax. The "highest" level contains, amoung
whatever else the Deities decide to put here, the
enterance to the Genisis Quest.
The Genisis Quest is the search for the legendary
First Item. The quest is initially a series of
password locked and key locked doors, with clues along
the way as to what the passwords might be. The quest
is to be set up in stages, with each stage
representing a city. The passwords should be answers
to questions about the city that section relates to.
Key locked doors inside of a section should be
openable by items that normally stay within the city
that section relates to. (It would be unfair to have
a door locked by the Cityguard Master's amulet, only
to have that amulet wandering around on an oblivious
adventurer.) The final exit to each section should be
a key locked door openable only by that city's Item of
Office.
Upon passing through the last of the doors, the Deity
on the Genisis Quest finds the legendary First Item in
a rather dull room. The legendary First Item cannot
be picked up (because that part of the code wasn't
written when it was first created), but touching it
will raise the Deity's level. At this point, the Deity
will be asked what they wish the name of their city to
be, and a zone will be created.
3.8 The Imp
In the Beginning, it is the task of those people who
have access to Imp characters to go about raising the
first Deities to 8th level. Aside from that and
general housekeeping like dealing with annoying
players, the Imps should not try to control the game.
It is perfectly within the spirit of the game for an
Imp to cause catastrophes for cities in general, but
they should never be direct, intelligent assaults.
Just create some problems and let them loose. Imps
should be careful, however, that they are not focusing
on one particular player or city. Everyone deserves
some havoc.
Section 4
Sight and Movement
4.0 Looking Around
The look procedures are possibly the most complex
procedures in the game. I made no attempts to
simplify these procedures because several elements I
desired in a MUD applied only here. It did not seem
reasonable to me to limit them in other ways if some
were to be complex.
4.1 Brief Look
This is used for those who have their Brief flags set
when they enter a room.
First, the light level is checked. If the light level
is within 10 of the viewer's limit, the value used to
check observation is lowered by 50.
If the character can see, the room name and
description are displayed. Then some exits are
displayed, depending on a simple addition of the
Visibility of the exit and the Observance of the
character compaired with a predetermined value (the
Visibility of the room + 30). If the value is less
than the addition of Observation and Visibility, the
exit is displayed. The same is then done for mobiles
(and characters) and items, but with a check for the
Invisibile and SeeInvis flags.
If the character cannot see, but has the Infravision
flag set, exits are displayed only if the room on the
other end is lit or hot. Similarly all mobiles and
items that have the Hot flag set are displayed. No
check is made vs. the characters Observation.
Otherwise, a generic dark room description is
displayed, and any exits that have lit rooms on the
other end are displayed.
4.2 Normal Look
This is used for those who do not have their Brief
flags set when they enter a room, or characters typing
"look" with no arguments.
First, the light level is checked. If the character
can see but is within 20 of their limit, a modifier
based on how close to their limit they are is
calculated, producing a range between 2 and 40. The
room name and description is displayed. For each
exit, an Observation check is made as above. If the
check succeeds, the exit is displayed. If the exit is
open, mobiles and items of that room are displayed as
decided in Brief Look, with the modifiers for both
rooms and items having an additional 50 modifier
(harder to see). If the exit is closed, that is
shown.
Then, for each mobile and item, after Invisible and
SeeInvis flags are checked, two Observation checks are
made. The first check is against the room's
Visibility. The second is a check against the mobile
or item's Visibility minus the previously calculated
light modifier. If the check succeeds, the mobile or
item is displayed.
Finally, if the viewer is a Deity of 4th level or
higher, all Plants are displayed. If the viewer is a
Merchant, those Plants which are viewable by merchants
are displayed.
If the character cannot see, the light level is
checked for the rooms beyond each exit. For each of
these in which the character can see, the exit and
name of the room it leads to is displayed. If the
character has the Infravision flag set, mobiles and
items with the Hot flag are displayed.
4.3 Look Direction
If the direction being looked is a room the character
could enter, the room as would be displayed in Brief
Look. If there is no exit or the exit is closed, that
is displayed.
If the exit is a Window, the linked list of Info
structures is traversed. The pointers point to rooms
and the shorts are additional modifiers for the
Observation comparrison. In turn, the light level is
checked. If the character can see, the room name and
the mobiles and items (with a 50 modifier), are
displayed from each room, provided the Observation
comparrison succeeds and the SeeInvis and Invisible
flags allow.
4.4 Look At
First the list of mobiles in the room are checked,
then the list of items in the room, then the mobile
and item lists of adjacent rooms. As each pair of
lists comes into question, the light level of the room
is checked. If the character cannot see in that room
and has the Infravision flag set, the lists of that
room are considered with respect to the Hot flags. If
the character can see in the room, the lists are
checked with respect to the SeeInvis and Invisible
flags. If the mobile or item cannot be found, that
much is displayed.
If the mobile or item is in the same room as the
character, the information is displayed as such:
<name> [the <racename> <profession>]
[(Invisible)]
<description>
If the mobile or item is in an adjacent room,
Observation checks are made vs. the Visibility of the
room the character is in, and the mobile's or item's
Visibility. If this succeeds, the information is
displayed so:
<name> [the <racename> <profession>] to the <direction>
[(Invisible)]
<description>
If the viewer is a Merchant and no mobile or item
matches the name given, plants are considered. Only
plants in the same room are displayed, and only those
which can be viewed by Merchants. If such a plant
exists, it is displayed like this:
<name>
<description>
<name of generated>
[living ][age:<age> ][moveable]
4.5 Watching Combat
Bystanders observing combat is one of the largest
producers of lag on some MUDs. To counter this, when
there is combat going on in a room, bystanders simply
notice that it says <name> of <city> is fighting
<name>, instead of <name> of <city> is standing here.
If the bystander so wishes, they can type "watch
battle" or something similar, and their Watching flag
will be set.
Upon entering combat, a character's Watching flag is
set. When a combat action happens, all characters in
that room and in the immediate surrounding rooms with
their Watching flags set will see that action. Any
movement between rooms causes the Watching flag to be
cleared.
4.6 Observation
The purpose of the observation score is twofold.
First, it limits how much is displayed to players
running through rooms or otherwise uncaring about the
lists of information each room has. This should
reduce lag. Secondly, this allows for somewhat hidden
items. If a very low observation score is given, it
will be overlooked by most players. It also could
produce humorous effects that add flavor to the game.
4.7 Walking
Walking is to be done with simple N,S,E,W,U,D commands.
When the character enters the command, first it is
checked to see if they are fighting someone. If so,
and the Generic_Counter is set to FLEE (a defined
value for the parser), the character flees as below.
If the counter is not set to FLEE, it becomes set to
FLEE. If the character was not fighting, their
Watching flag is cleared.
The exit in the direction requested is checked for
existing and being open. If both are true, the
character is allowed to pass through. If the exit is
closed, but not locked, the character is allowed
through with an additional message saying he opened
the door and closed it behind him. Finally, if the
character's Speed is less than the value of the exit,
it is displayed that the character is too tired.
If the character is allowed through, their Speed is
reduced by the value of the exit. If the exit has a
traversing description, that is displayed with the
appropriate direction entered in, otherwise a bland
"You walk <direction>." message is displayed. In both
rooms, each player's Observation score is checked.
Those making their checks get the character's
enterance or exit displayed to the screen. Finally,
the appropriate Look function is called for the moving
character.
4.8 Running and Fleeing
Running is to be entered: run nnnsseenenw, or
something similar. This allows players who want to
get somewhere but don't care about what is in between.
On each step, exits are checked for existing and being
open as above with one exception. If an exit is
closed but unlocked, it stops the character and a
message saying they slammed into a door is displayed.
For all the rooms in the middle of the path, the name
of the room is displayed, and three Observation checks
are made. The first is vs. the room's Visibility. If
this fails, nothing about that room is seen. The
second is vs. the first mobile's Visibility. If this
succeeds, the first three mobiles are displayed. The
third is identical, but for items. After each step,
the character's Speed is reduced by one less than the
value of the exit. If this reduces the characters
Speed to 0, the character stops and is immediately put
into the REST state.
If the character manages to reach the end of their
list with no problems, the room they end up in is
displayed as it would when they were walking. If the
character gets stopped, the room they end up in is not
displayed.
Fleeing is much the same, but a random number of
random directions are put together, with the first
direction being the direction the player was trying to
flee. If the player typed: flee instead of a
direction, the first direction is random.
The Watching flag is cleared before running, and set
after fleeing.
4.9 Riders and Followers
The descriptions of the movement functions were
getting a little tedious, so I decided to put this in
a different section.
Whenever a mobile moves, be it through their own
commands or through some feat of magic or Divine
Intervention, if that mobile has a rider, the rider
goes with the mobile. Likewise, whenever a mobile
moves, with the exception of fleeing, all mobiles in
the room are checked to see if they are following that
mobile. If they are, they attempt to follow in the
same manner, be it walking or running.
This is, of course, a recursive effect. The room is
not checked for followers until after the origional
mobile is gone. This allows for two mobiles to be
following each other without causing problems.
4.10 Mounts
If a player is riding a non-player mount, the normal
directional commands are translated into orders for
the mount. The mount attempts to move as the player
ordered, taking the player along with as above. Speed
is reduced for the mount, but not for the rider.
Section 5
Object Manipulation
5.0 Object Creation by Deities
Since Deities are expected to be players instead of
the masters of an AmalgaMUD, their interface must be
at least to some extent user friendly. The command
line entry for a Diety creating a common item should
be as simple as:
create [new] [item|exit|plant|mobile] <object name|direction>
The optional arguments [item], [plant], and [mobile]
are there only for the case in which the item the
diety wishes to create has the same name as another
structure in memory.
5.1.1 Items
If only a name is given, it is first assumed that the
Deity is trying to create a known item. If no item
exists, the Mobile list is checked, then the Plant
list. If none of these exists, the Deity is informed
that no such object exists. This type of interface
should hold true for all Deity commands.
If the item, plant, or mobile exists, the Deity's Mana
level should be checked to see if he has enough power
to create the object. If so, the object should appear
at the Deity's feet and the apropriate ammount of Mana
deducted.
If the first argument is new, and the second is item,
the Deity is led through a series of questions about
what the item is supposed to be. At any level in the
questioning, the Deity should be able to enter a `?'
and get at least one line of information about the
question being asked. Once all of the questions have
been answered, the Mana cost of that item type is
calculated and the Deity is shown how much it would
cost to make. If the Deity agrees to make that item,
their Mana score is reduced by that ammount and their
MaxMana score is reduced by 1/4 that ammount.
I suppose the Deity should be warned about that
setback. There should also be some provision for
Deities to earn back their MaxMana. I would suppose
that would be through particularly valuable sacrifices
by other players.
5.1.2 Exits
If the first argument is "exit" and no direction is
given, or if an exit already exists in the direction
given, the Deity is complained at. Otherwise the
Diety's Mana level is checked, and the Deity is
prompted for a room number and a direction to connect
to. If all works out, a generic exit is created that
can be modified later.
5.1.3 Plants
If the first argument is new, and the second argument
is plant, a similar event happens as when item types
are created, but with the MaxMana being reduced by 1/2
the cost of the plant.
The Imp should be able to modify the costs of various
aspects of new items and plants.
5.2 Picking Up and Dropping Objects
The first thing that should be considered is if the
character is capable of seeing the item. This means a
light level check, just to see if it is within bounds,
and a check of the SeeInvis bit. If the light is too
dark and the Infravision bit is not set, say so,
otherwise check to see if the item actually exists.
Items can be dropped directly from the mobile's
Equipped list, but their inventory should be checked
first. If the item is found, proceed. If the light
is too dark, and the Infravision bit of the character
and the Hot bit of the item are both set, then
proceed. If the light is good and the SeeInvis bit is
not set, then check the Invisible bit of the item. If
that is not set, proceed. If not proceeding from this
paragraph, complain that the item could not be found.
Next if the character is picking up the item, the
weight of the item should be compared with the
Carrying and Strength stats. If the item is too
heavy, say so. If the character is dropping the item,
the Cursed flag should be checked. If the item is
Cursed, it cannot be dropped.
Then check the room to make sure it's not a Shop. If
it is a shop, picking up and dropping items can only
be done through the Shopkeeper. If all is well, move
the item from the room's item list to the mobile's or
vice versa and adjust the Carrying stat of the mobile
appropriately.
The checks are done in this order not to facilitate
speed, but to make the sequence of error messages make
more sense.
5.2.1 Moving Plants
Only Deities and Merchants (in some cases) should be
able to manipulate Plants. The command to get a Plant
is "dig [up] <plant>", and the command to drop a Plant
is "plant <plant>". In these cases, the plant is
stored in the inventory by type casting the Unique
pointer to a pointer to a Plant.
5.3 Equipping and Removing Items
Each item that can be equipped has a place where it is
supposed to be equipped. If there is no other
equipment in that space, the item can be equipped. If
the item is a weapon, it should be placed at the front
of the list. If the item is armor, it should be
placed after the last weapon. If the item is neither
weapon nor armor, it should be placed after the last
armor in the list. The reason for this is that during
normal combat, weapons will be checked frequently,
armor less frequently, and activated items only rarely.
When an item is equipped, half of it's weight (rounded
down, or >> 1) should be removed from the mobile's
Carrying stat, and added again upon removing it.
Additionally, any special characteristics of equipped
items should be added or subtracted to the mobile as
is appropriate. (Of course, cursed items cannot be removed.)
5.4 Throwing Items
This is a meathod of attacking a mobile in an adjacent
room. First the exit should be checked for being
open. Second an Observation check against the
Visibility of the exit is made. If this fails, the
thrown weapon is effectively dropped. If the
Observation check succeeds a normal To Hit roll is
made. If the hit succeeds, the thrown weapon is added
to the target's inventory. If the hit fails, the
thrown weapon is effectively dropped in the room with
the target.
5.5 Opening, Closing, Locking, and Unlocking
Characters should be able to open, close, lock, and
unlock exits and containers. For containers, the item
should be in the appropriate state (opened or closed)
and unlocked. For exits, opening and closing only
require the Door flag being set for that exit,
although the Opened flag should also be checked to
make sure the appropriate action is being performed.
In either case, locking and unlocking should require
the character to have the appropriate key in the top
level of his inventory, or in a container called a
"keychain".
The commands are nearly identical: "open <direction |
exit name>" vs. "open <container>". When looking for
the appropriate target to manipulate, first check
exits, then the mobile's inventory, and finally the
floor.
5.6 Sacrificing Items
A player should be able to sacrifice items to the
Deities, giving the Deity Mana appropriate to the item
sacrificed. This should only work in a Temple
(special room) or in the presence of the Deity being
sacrificed to. Sacrificing normal items should give
the Deity 1/4 the normal ammount of Mana it would take
to create the item. Sacrificing unique items gives
the Deity 1/16 of the cost to make the item in
MaxMana. In either case, the sacrificed item should
be erased from memory.
The command should be: "sacrifice <item> [to] <Deity>".
5.7 Containers
As well as opening and closing, characters should be
able to "look in <container>", "get <item> [from]
<container>", and "put <item> [in[to]] <container>"
Getting and putting should consider all of the checks
just as get and drop do, with one exception. If the
mobile is getting or putting to or from a container on
his person, weight should never be checked or altered.
When looking in a container, the light level and
SeeInvis, Invis, Infravision, and Hot flags should be
checked as if looking normally, but no Observation
checks are to be made.
5.8 Food and Drink
Finally, the character should be able to consume items
that either have the Food or Drink bits set. A random
value, no less than 1 and no greater than the value of
the consumable, is subtracted from the value of the
consumable and added to the appropriate stat for the
mobile. If this exceeds the mobile's MaxFood or
MaxDrink stats, the character is told that he is full.
If the new value goes 50 past the Max value, the
character is informed that they are sick, and the Sick
bit is set. If the value of the food or drink becomes
0, the item is erased from memory.
Section 6
Skills and Training
6.0 Hard Coded Skills
At the moment, I can only think of a few of the hard
coded skills. (Gee, I hope I'm using the right term
for that.) There should be a reasonable number of
these skills that are common on all AmalgaMUDs, but by
no means are all of them mandatory. These are simply
skills that do different things than just manipulate
statistics and flags.
These skills are stored on the character exactly like
diety created skills.
6.1 Climb
Origionally based on 1/10 of the character's Agility
stat, this skill is checked when the character
attempts to go through an exit that has the Climbable
bit set. If the check fails, the character cannot
pass through that exit.
6.2 Identify
Some MUDs give you all the statistics of an item when
identified, which players like, but it leaves no room
for discoveries once that simple action has been done.
Others describe every aspect but in vague phrases,
giving almost completely useless information to the
player if he doesn't understand the arbitrary scale
the designer implemented.
Unlike either of those, this form of identifying, I
think, would be much more entertaining. Every time an
item is Identified, the player gets one or more real
stats or flags about the item, chosen at random.
These first fact must be something tangible. If the
value to be displayed for the first stat or flag is 0,
another is chosen. After the first fact is displayed,
there is something like a 1 in 10 chance that another
fact is displayed, but no check is made to see if the
second fact is tangible. Each time a fact is
displayed, a check is made to see if another fact is
displayed. (E.G. 90% chance of 1 fact, 9% chance of 2
facts, .9% chance of 3 facts, .09% chance of 4 facts,
etc.) It is also never checked to see if additional
facts have already been displayed.
This makes it so that an item would have to be
identified many times for the player to be reasonably
sure of what it is, but the player would never be 100%
sure.
6.3 Weaponry
For each weapon type, a skill is available. Skills
should also be available for weapons that do not have
a type. This skill adds to your effectiveness when
using the weapon in question. When a weapon is
weilded, first the skill list is checked for the name
of the weapon being weilded, and then for the type.
The value of the greater skill (if both are present)
is placed in the weapon's Generic_Count to be used as
necessary by the combat routines.
6.4 Skill Creation by Deities
Skill creation is bound to be complex, so there will
need to be several commands involved.
The first of which should be "create [new] skill
<name>" which simply allocates a node in the master
skill list for that skill, provided a skill doesn't
already exist with that name.
During the modification of skills, Deities will want
to see what's going on. Therefore we need "show skill
<skill>", which displays every aspect ot the skill in
plain terms, not the code the skill actually stores
information in.
Finally, we need to be able to modify the skill. I
suggest commands like "skill <skill> sets <bit>",
"skill <skill> clears <bit>", "skill <skill> leaves
<bit>", "skill <skill> adds <value> [to] <stat>",
"skill <skill> subtracts <value> [from] stat", and
"skill <skill> leaves <stat>". In these commands, the
Deity is to type the normal names for the stats, and
the leaves function is to remove effects from the skill.
I hope I'm not assuming too much in my descriptions.
It would be a real pain to type everything out.
6.5 Teaching and Learning Skills
Any character may request training of any other
character or mobile, but if the teacher's and the
student's professions differ, the student can only
learn up to 1/4 of the teacher's ability.
6.6 Skill Development Through Use
When a character makes an exceptional check using a
skill, a point should be added to their Potential
stat. Furthermore, another check is made against the
skill. If the second check fails, that skill
increases by one point. The reasoning behind this is
that when the character made the exceptional move, it
could have been outside the relms of what he already
knew. If it was, then he learned something new.
Section 7
Combat
7.0 Normal Combat
Every combat pulse (perhaps every five seconds) all
combatants get a "normal" attack. This consists of
making a to hit check with whatever weapons are
equipped by that mobile at the mobile pointed to by
Opponent.
Someone used to playing a hack and slash MUD might
think this to be incredibly slow. I would rather put
the majority of the emphasis of combat on special
actions and detailed effects rather than have fifty
damage messages scroll by every second or less. This
is both an effort to make a higher quality MUD and an
effort to reduce lag due to combat.
Normal combat does not reduce the Speed statistic.
7.1 Armor
Armor is to serve two functions in combat. First, it
should reduce the chance an attacker has to do damage
to the wearer. Secondly, it should absorb some of the
damage done when a hit occurrs. The damage it
prevents should be a random number with the maximum
defined by the armor. 1/4 of this absorbed damage
(>> 2) is subtracted from the armor's Structure
Points. If this reduces the armor's Structure Points
to 0, the armor is unequipped or erased from memory,
as you see fit.
7.2 Weapons
Weapons main purpose is to cause damage to the
Opponent. Because most players will have around 60
Hit Points, no single weapon should be allowed to do
more than 35 points of damage in a single strike.
7.3 Who's Turn When
After the combat has been initiated, the mobiles
attack first. This is simply implemented by
traversing the Mobiles Master List, giving each it's
normal combat round, then traversing the Players
Master List doing the same.
All other actions in combat depend strictly on the
mobile's Speed statistic and when commands are
entered.
7.4 Guards
Every combat pulse, all mobiles with the Guard bit set
check the mobile they are Following. If that mobile
is in the COMBAT state, the guard attacks whoever that
mobile's Opponent is. This does not actually put the
guard into the COMBAT state.
Note: having a mobile guard itself is a way of giving
it two attacks a round.
Section 8
Merchants and Plants
8.0 The Role of the Merchant
The role of the Merchant can be just as influential as
the roles of the fighter and the Deity. The merchant
gathers material producting plants, builds shops in or
out of the city, and in general controls the economy
of the MUD.
8.1 Harvesting Plants
Merchants are cabable of gathering item producing
plants from outside the city to provide continuous
resources for their shops. The plants will renew
their supplies once every day. (AmalgaMUD days and
real days should roughly coincide. I had invisioned
AmalgaMUD days being 21 real hours long.) When this
happens, if there is a shopkeeper in the room, he will
empty the plant and put those items on display.
8.2 Plant Life and Reproduction
Item producing plants have life cycles. In the first
stage of their life, they do not produce anything, but
they may be moved without risk. In the second stage
of their life, they produce whatever items they are
supposed to. In the third stage of their life, they
produce only one of such item and they occasionally
check (once a day) the room they are in and the
adjacent rooms for a similar plant. If such exists,
it will generate another plant with slight mutations
possible, then (90% of the time) a bit will be set so
it cannot do so again. At the end of it's third cycle
of life, it is erased from memory. Each of these life
cycles are the same in length, and dependant upon the
climate of the room. (Note that if the plant's life
cycle is MAX_LIFE, it will perpetually stay in the
second stage of life.)
The mutations most of the time effect statistics about
the plant's life span (either increasing or
decreasing), preferred climate (moving one step
towards it's current locale), or the ammount it
produces (increasing is less likely than decreasing).
Those type of mutations are passed on to their
children. Occasionally, however, a mutation alters
the type of the item it produces. 10% of the time,
this actually alters the record in the Item Type
Master List. Otherwise, an Info structure is created
showing wich flag to alter and how, or an Info
structure designed to be attached to the item in it's
Effects list. Those type of mutations are passed on
only 33% of the time.
8.3 Shops and Shopkeepers
Merchants are allowed, on any room of type STREET, to
rent a shop by typing "rent shop [name] <direction>".
This creates a new lockable exit, a key (placed in
their inventory), and room attached to the room the
Merchant is in, owned by the Merchant and not the
Deity of the city. The Merchant in question is then
allowed to "rename shop <name>", and "describe shop"
just as a Deity would. Also, the Merchant can "price
[merchandize] <number>", which will influence the
shopkeeper's origional price for any Item. This
number can be anywhere from 0 to 100.
Additionally and only when inside his shop, the
Merchant is allowed to "hire shopkeeper <name>",
"rename shopkeeper <shopkeeper> <name>", "describe
shopkeeper <shopkeeper>", and "set merchandise [for]
<shopkeeper> <bit>" and "clear merchandise [for]
<shopkeeper> <bit>". This information is kept in the
Shopkeeper's Quest list, as it would be used for
nothing else. Only Items with that bit set can be
bought or sold by that shopkeeper. A shopkeeper with
nothing in the Quest list cannot buy or sell anything.
Both Shopkeepers and Shops require payment every
AmalgaMUD month. First, the money is taken from the
Shopkeeper himself, then if necessary, from the
Merchant's bank account. The Shopkeeper is checked
first. If the Shopkeeper can't be paid, he is erased
from memory. If the Sshop can't be paid for, it locks
itself (after shooing everyone out). If, by the next
month, the Merchant does not have enough money, the
Shop and it's contents are erased from memory.
Shopkeepers have the Riding, Guard, and Marked bits
set and are following themselves. Also, there is a
50% chance for each Resist Damage bit that it is set
for that shopkeeper. In this case, the Marked bit
marks the mobile as a shopkeeper.
8.4 Bartering
I had a couple thoughts about this. First, if the
player cannot understand the native language of the
shopkeeper, no bartering can take place. The second
thought was more difficult to figure out. I wanted
there to be no set price for any one type of item. I
also wanted there to be different forms of currency
available. This works out best in a system of
bartering, I thought. Simply check for the Money bit
on the offered item, compare the value of the money to
the item being bought and come up with a somewhat
random base number to work with. Then I thought of
the problem of people repeatedly initiating bater so
they could start with a lower price. Then there's
also a problem with other players buying an item one
player is currently bartering over.
The solution I cam up with was this: The player
enters the shop and types "buy <item> with <money>".
If the item exists on the floor, it is put into the
shopkeeper's inventory. If an Info structure exists
on the item (which would represent the value of the
last barter for that item in terms of coins with a
value of 1), the value is converted into the size of
coin the player is offering and bartering begins. If
no such info structure exists, one is made with the
estimated value being roughly 1.5 to the Xth power,
where X is the value statistic. And when I mean
roughly, I mean a function that returns a number
between (80+M)% and (100+M)% of the number passed to
it, where M is the priciness of the merchant's shop.
Therefore, a character wanting to purchase a velue 32
item with value 1 coins (in a 0 price shop) would be
offered a number between 517728 and 345152. There
should be some cut off point where the shopkeeper
scoffs at the size of coin offered, probably more than
300 difference, so the above example couldn't have
happened.
The character's Generic Gounter stat is set to 0.
Each time he types in "haggle", he makes a bartering
check. If the check succeeds, the cost of the item
decreased by up to 3%. If the check fails, the cost
increases by up to 2%, and the character's Generic
Counter increases by one. If this should make the
character's Generic Counter higher than the
shopkeeper's, the shopkeeper scoffs at the character
and drops the item onto the floor. The shopkeeper's
Opponent pointer is then set to the character. If the
character attempts to barter with the shopkeeper
again, he will be shooed out of the shop. Until, of
course, someone else offends the shopkeeper.
And the reverse in numbers happens when the player
types "sell <item>", but the shopkeeper gets to decide
for what type of currency.
If at all possible, haggling should be made fun.
Section 9
Special Rooms
9.0 The Language Barrier
Of course, none of these rooms should provide any
benefits if the character doesn't speak the language.
All hinderances apply, though.
9.1 Unloaded Zone Rooms
These rooms have the Unloaded bit set.
This is a further attempt to save memory. When the
MUD is initially loaded, only the cities, and the zone
named "Roads" are loaded. ("Roads" is supposed to
connect all of the cities together, containing only
the main paths between them and the more civilized
non-city zones.) As each of these are loaded and
arranged, there will be exits pointing to zones that
are not yet loaded. An Unloaded Zone Room is placed
there instead. When a player enters that room
(checked at the most primitive movement procedure) the
zone is loaded and arranged. If this zone attempts to
make a connection to another exit on a loaded zone,
currently pointing to an Unloaded Zone Room, the
Unloaded Zone Room is destroyed and replaced.
9.2 Generic Shops
These rooms have the Shop bit set.
Generic shops are the ones created by the Deity while
creating the rest of the city. The only difference
between these shops and ones merchants set up are that
the Deity should have it on his agenda to remove the
shops at one time or another so that Merchants have
their chance at it. In general, Generic Shops should
be somewhat bland.
In all shops, all items "on the floor" are
merchandise. Players are not allowed to pick up,
drop, or get from items "on the floor". The room
should be INDOORS and have comfortable lighting.
Other than that, it's a normal room.
9.3 Banks
These rooms have the Bank bit set.
In a bank, players should be able to type: "deposit
<number> [of] <coins>", "withdraw <number> [of]
<coins>", and "ballance". The first two move items
from the player's inventory to their InBank list and
vice versa, adjusting weight appropriately. The
ballance command should display the InBank list just
as the Inventory command.
Additionally, a mobile with the Mayor bit set may "tax
<percentage>". Provided that the mobile is in his
home city, this command goes through the list of
active players and takes that percentage out of their
InBank list and puts it in their InBank list, provided
they also are from that city.
9.4 Jails and Dungeons
These rooms have the Prison bit set.
At one point, I thought these should be special, but
now I can't concieve of what I'd do with them.
We have a Special pointer to work with though :)
9.5 Guilds
These rooms have the Guild bit set.
Guilds should have a receptionist mobile (with the
Marked bit set) that carries in it's Quests list a
series of grouped Info structures. The first
structure's pointer points to the name of the quest,
and the short value either contains a 1, meaning it's
a permanent quest, a 2, meaning it's a quest worthy of
raising a level, or a 0, meaning it's a player
designed quest that will dissapear when completed.
The second structure points to the name of a monetary
item and the value of the short display's how much.
The third structure points to a description of the
quest with the short marking the minimum level
required to accept it.
Players may "accept [quest] <name>", in which they
aquire an Info structure in their Quests list,
"complete [quest] <name>", in which the player get's
paid and, if it's a 0 quest, the quest structure is
removed from all players, or "post [quest] <name>",
after which he should be propted for the remaining
information on the quest. (Note: This will need some
work. Give me some time.)
Additionally, a mobile with the Mayor bit set may "pay
<percent>" or "pay <ammount> [of] <coins>", which will
transfer the money from the mobile's InBank to the
guild's receptionist's InBank list.
Guilds, since they should come with a restricted
access entrance, should offer special training rooms
and shops that are not available to other characters.
9.6 Restrooms and Outdoors
Restrooms have the Restroom bit set.
These are the only places where the commands to
relieve oneself work. Restrooms additionally should
have a buliten board named "wall" or some such.
Restrooms should be available! The difficulties
caused by the need to dispose of used food would only
be annoying if no easy way arround it existed. It is
a temporary idea that a character not willing to
relieve himself should have the act forced upon him
and a unique item created (that will decay in time)
with his name on it.
9.7 Inns and Homes
Ah yes. What to do with the character when the player
wants to rest?
Normally, the "quit" command would just save the
character and leave them sleeping in the streets. If
this is so, when the character wakes up, there is a 1%
cumulative chance per hour of sleep that an item was
stolen from them.
The character may instead opt to sleep in an Inn.
Inns have a set cost, determined by the local Deity in
charge. It should not be possible for the Inn to cost
nothing. If this were so, the effect of sleeping on
the streets would be meaningless. The command should
be simply: "rent [room]". A receptionist need not be
present as the cost of the room will be stored...
um... where?
Then there's Housing. In a room of the type
RESIDENTIAL, which is usually described as a street,
or in a shop the character owns, a character may
"build [house] <name> <direction>". This creates a
new room owned by that player, a lockable exit, and a
key in the player's inventory. This should be a very
high set cost which is similarly stored... um...
where? Inside his own home, a character may "rename
<name>" and "describe" just as a merchant in his own
shop. Additionally, the character may "evict <mobile>
<direction>", which will remove the named mobile from
his home and place it outside.
While inside rooms with the HOME bit set, players may
"quit" and return with no fear of missing items.
Hopefully, the main difference between a home and an
Inn with a cost of 0 is that the owner of the home
will want to store items in it while he is away, thus
the key.
9.8 Event Based Rooms
These rooms have the Event bit set.
Ideally, these help build Quests, but I'm not sure how
to implement them. I know this much, the Special
pointer should point to an Info list, that starts with
a pointer to the command which will initiate the
series of actions, the easiest of which should be
setting the appropriate Quest score.
9.10 Temples
These rooms have the Temple bit set.
These rooms should have grandiose descriptions to
impress the mortals. In these rooms, players can be
reincarnated ("touch altar") and items can be
sacrificed ("sacrifice <item> [to] <Deity>").
9.11 Deity Creation of Special Rooms
Causing rooms to be special rooms is done by the
command "set room <bit>", where the name of the bit is
used, and the Deity's judgement fills in the other
details, like shopkeepers and receptionists.
Section 10
Mobile Actions
10.0 Generic Actions
All mobiles will wander aimlessly, never crossing
zones. They will shut doors randomly, pick up items
occasionally, attack things if they are aggressive,
and reproduce.
10.1 Special Actions
Aside from Shopkeepers, who are ignored mostly because
they don't move, when a mobile moves it consult's it's
Quest list, which is a list of paired Info structures.
If the name of the room, or the name of another mobile
in the room matches the string of the first info
structure, the second of that pair is treated as an
action taken by that mobile.
For example, a janitor might have the pairs "*","get
all" and "Temple of the Can","sacrifice all to
TrashCan".
10.2 Mobile Paths
Most mobiles have nothing in their Pending pointers.
Those that do, however, do one of those actions every
normal pulse. These actions are stored as strings in
the Info structure's pointers. For example, the mayor
may have the list: "goto bank", "say my what a
wonderful day for taxes!", "tax 20", "goto Thieves
Guild", "pay 5", "goto Temple", "pay 5", "goto
Barracks", "pay 7", "goto Palace", "sleep 18", "emote
yawns.". "sleep 18" should mean sleep for 18 hours,
real time.
Each time an item on the list is done, that item is
moved to the end of the list. This way, your
programmed mobiles will keep doing what you told them
to in the order you told them to do it in. The only
exceptions to this are "partial actions", which may
make up larger commands. The only such actions
currently on my list are the directionals and possibly
the get, drop, and kill commands.
The mobile can be stopped in the middle of actions
like goto by something more worthy of their attention,
like combat. In this case, the list of partial
actions are removed and the last action is put back at
the beginning of the list.
10.3 Go To
Occasionally, you might want mobiles to go towards
something they're not explicitly programmed to. In
this case, a Digstra's Path formula is implemented,
using the name of the room as a goal and Info
structures temporarily formed in a part of memory not
attached to anything else, and the directionals are
appended to the beginning of the mobile's Pending
list.
Bear in mind that if you have more than one room with
the same name, you could confuse your mobiles.
10.4 Mobile Reproduction
If a mobile should walk into a room that does not have
the Public bit set, and recieves the reproduce
impulse, and if another mobile of it's type is in the
room, it will spend a random ammonut of time in the
Occupied state. After this time has ellapsed, if
neither was interrupted, a new mobile is created, with
stats no more than 5% off of the average of it's
parent's stats and skills.
The command "reproduce" in the Pending list will
prompt this action if conditions are favorable.
10.4.1 Character Reproduction
Characters also can reproduce, provided one is male
and the other female. When this action begins, all
exits in the room are closed and locked, if possible.
The characters are then put into the Occupied state
for a random duration ranging from half an hour to an
hour and a half. If both characters endure this state
for the full duration, a character is created as above
with one exception: skills of the parents are reduced
to 20% of the parent's average. The father is
prompted for the sex, profession, and racename of the
new character. The mother is prompted for the name,
password, and class of the new character.
The new character will follow the mother as a pet
until either she or it is killed, at which point it
will quit, saving itself as a real character. If it
was killed, it saves itself with 1 less Lives.
An additional benefit of this activity is complete
healing and uncursing of the characters involved and
their items, including a random ammuont added to the
hit points of armor.
10.5 Mobile Generating Plants
The only other way for mobiles to come into existence
without the direct help of a Deity is to be generated
by Plants. This happens only once every day, and the
mobile generated is only a close copy of it's mold.
Variences up to 5% are allowed in all stats and skills.
Section 11
Death and Reincarnation
11.0 Philosophy of Limited Lives
If a character is to be special to a player, the
player must believe that there could come a time when
that character will slip out of the player's grasp.
This, coupled with the though of living a complete
life in a city that has a dynamic economy and active
political concerns nearly completes the feel that I
believe could give MUDs so much more potential than
they have now.
I have had characters that, when they first entered
the MUD, continuously ran up to one of the tougher
mobiles and attempted to kill it. After something
like 60 deaths of the character, the mobile was
finally overcome, and the character raised 5 levels
immediately.
This is not only against the spirit of the game, but
it created a number of useless items, namely corpses.
Worse yet, when other newbies saw that it was
possible, many others started doing so themselves.
The type of heedless competition that led me to such
an action is exactly what causes MUDs to continuously
degrade. MUDs are supposed to be more entertaining
because they include a human element that no other
game has. Letting characters die makes the human
element more real.
Also, death shouldn't be something to be shrugged off.
The player should know that death is actually an
inconvenience.
11.1 Interaction While Dead
When a character dies, a container is created and his
inventory and equipped items are put into it. The
character record is removed from the list of mobiles
in that room, but the Room pointer remains pointing at
the room. The Riding and Following pointers are
cleared, their Lives score is reduced by 1, and a
message is displayd suggesting they find and touch an
altar.
When dead, the character cannot move, speak, or use
skills as normal. The character can "drift
<direction>", but not while his corpse remains in the
room. Or, he could follow a mobile again, hoping for
a ride to a temple. The character can "whisper
<mobile>", but cannot be whispered to or spoken to, as
he cannot be seen by any other players. Trying to get
or open an item only causes a chill in the room.
There is, in fact, very little the dead can do.
Quitting and returning while dead only causes the
character to be placed at the starting point in his
home city, still a ghost.
11.2 Event Induced Reincarnation
If the dead person with a positive Lives score manages
to get to a temple, they can type "touch altar", and
they will be brought back to life. Characters with 0
Lives touching an altar are told they can go to their
final resting place.
11.3 Deity Induced Reincarnation
Any Deity of 3rd level or higher can reincarnate a
dead person from anywhere in the MUD, provided he does
not have 0 Lives. If the character is "in" that
Deity's temple at the time, there is a 50% chance the
character's Lives score will be increased by 1.
11.4 Final Death
When the player quits, and his character's Lives score
is 0, he is prompted for permission to erase the
character. If he says no, the character will remain
for as long as it is used. In the monthly check for
characters that have not been used that month, ones
with 0 Lives will be erased.
Section 12
Communication and Bulletin Boards
12.0 Communication
This is the essence of the MUD, and one of the hardest
areas to work out. I have found that being on MUDs
where global communication was not possible was very
boring. I have also been on muds that had so much
global communication as to be annoying. I've decided
to try something different, staying within the relms
of what I consider "realistic".
12.1 Verbal Communication
There are basicly two forms of local verbal
communication: "say <text>" and "whisper <text>",
which are obvious in use. It has been my experience,
however, that "emote <text>" should be considered
verbal communication for how often it is used with
sounds in mind.
As for long range communication, I would rely on the
mail system and short range shouts. By short range, I
mean that when a person types "shout <text>", only
those within the same zone as they are will hear them.
This is a bit loud for realism, but it's close and
somewhat fair. This requires those that wish to be
involved with the goings on of a city to actually be
in that city.
In any case, any text broadcast in this manner that is
picked up by characters that do not understand the
language, get a garbled message instead. (In the case
of emotes, it is simply not displayed.) Garbling
consists of replacing vowels with random vowels,
nasals with random nasals, glides with random glides,
etc. Don't worry, I've already written a procedure
that aproximates this effect.
12.2 Mail
Mail is sent to players in the form of a Note, a
Unique value 0 Item with the text in the description.
Notes have the Crumble bit set, so they won't hang
around. I'm not sure if I want these to obey the
language laws or not. It occurs to me that there
needs to be some method of communication for confused
newbies.
How about this: If the character whom the mail is
being sent to is not currently loaded, it is appended
to their file. If the character is loaded and the two
characters speak a common language, or if the
character recieving the note is 1st level, the note is
sent unchanged. Otherwise, the note is garbled as it
is sent.
12.3 Restrooms and NotePosts
Buliten Boards! Would that I knew how other people
coded these. The effect desired is this: an Item that
can not be moved which contains signed and dated text
from whoever wishes to write it. Only Deities and the
author of the text are allowed to remove it. Text
over a year old is automaticly removed once a day.
I would rather these items did not take on the generic
appearance of buliten boards. It would be much more
flavorful if they fit the genere of the city or
location they were in. Thus the bathroom walls.
Section 13
Benefits of a Client
13.0 What I mean by a Client
I invision a program that will connect to a MUD,
recognize if it is an AmalgaMUD, and handle passing
information appropriately. Lines coming to the user
that are too long should be broken in between words if
possible. Commands typed in by the user will be
translated for quicker understanding by the AmalgaMUD,
editing out meaningless commands or commands that
won't work because of the character's current state.
The effects of being able to have more than one
connection and thusly being able to decide which
connection's input to view are not necessary, but
would be nice.
The client should not only make the game more
enjoyable, but speed the play for the other players.
13.1 Jumping Between Sites
The primary effect of the client would be it's ability
to facilitate travel between AmalgaMUD sites. I see
no reason to burden the rest of the players with the
lag of an AmalgaMUD server attempting to connect to
another site. Instead, if the client can open a
connection to both sites, it could directly pass all
of the information of the character without
unnecessary delays.
I know that this could cause problems with doctored
clients, but that is of little concern. Everything
else will be doctored to a certain extent anyway.
13.2 Macros and History
One of the advantages the client must have is the
ability to use the "!" to repeat commands. The
interface should be as close to normal Unix use of the
commands as possible. The reason for putting this on
the client is because it should not exist on the server.
The more useful the client is, the more players will
get used to using clients. Eventually, over many
years of development in the quality of players,
clients may be able to handle most of the processes,
speeding up the game even more.
--
J C Lawrence Internet: claw#null,net
----------(*) Internet: coder#ibm,net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00154.html">Re: Resets and repops</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00155.html">Garbage Collector</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00155.html">Garbage Collector</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00172.html">Re: EVOLUTION response</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00156"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00156"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><strong><A NAME="00187" HREF="msg00187.html">Old missing posts from old list</A></strong>,
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Mon 24 Mar 1997, 01:30 GMT
<LI><strong><A NAME="00168" HREF="msg00168.html">A perspective out of time - the mudreport document</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sat 22 Mar 1997, 10:19 GMT
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="00207" HREF="msg00207.html">A perspective out of time - the mudreport document</A></strong>,
claw <a href="mailto:claw#null,net">claw#null,net</a>, Wed 26 Mar 1997, 01:20 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00155" HREF="msg00155.html">Garbage Collector</A></strong>,
Artur 'Revinor' Biesiadowski <a href="mailto:abies#pg,gda.pl">abies#pg,gda.pl</a>, Fri 21 Mar 1997, 06:12 GMT
<LI><strong><A NAME="00156" HREF="msg00156.html">EVOLUTION response</A></strong>,
claw <a href="mailto:claw#null,net">claw#null,net</a>, Fri 21 Mar 1997, 05:44 GMT
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="00172" HREF="msg00172.html">Re: EVOLUTION response</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Sat 22 Mar 1997, 14:20 GMT
</LI>
<LI><strong><A NAME="00208" HREF="msg00208.html">Re: EVOLUTION response</A></strong>,
claw <a href="mailto:claw#null,net">claw#null,net</a>, Wed 26 Mar 1997, 01:43 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00147" HREF="msg00147.html">Sorry for the dups (again)</A></strong>,
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Thu 20 Mar 1997, 12:38 GMT
<LI><strong><A NAME="00143" HREF="msg00143.html">3D graphics</A></strong>,
claw <a href="mailto:claw#null,net">claw#null,net</a>, Thu 20 Mar 1997, 05:33 GMT
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>