<!-- 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>