****************************************************************************
 * [S]imulated [M]edieval [A]dventure multi[U]ser [G]ame      |   \\._.//   *
 * -----------------------------------------------------------|   (0...0)   *
 * SMAUG 1.0 (C) 1994, 1995, 1996, 1997 by Derek Snider       |    ).:.(    *
 * -----------------------------------------------------------|    {o o}    *
 * SMAUG code team: Thoric, Altrag, Blodkai, Narn, Haus,      |   / ' ' \   *
 * Scryn, Rennard, Swordbearer, Gorog, Grishnakh and Tricops  |~'~.VxvxV.~'~*
 ****************************************************************************

SMAUG is a heavily modified derivative of the Merc2.1 distribution.
The code close to four times the size of Merc2.1, and has major
changes to the inner workings of the code.

Some of the most noteable structural changes are:


- Double Linked Lists

Most of the previously single linked lists have been changed to double
linked lists.  For a minor memory usage increase, a large performance
increase is gained, as well as more flexability.
In original Merc code, to extract an object from the game, the code
had to traverse the entire list of objects in memory until it located
the object that was being extracted.  With a double linked list, all
that needs be done is point the next object to the previous object,
and the previous object to the next object.  This can generate significant
CPU savings when a player with many objects quits the game.


- Room exits are now a double linked list

In Merc and the original DikuMud, the exits in a room were an array
of six pointers to exit_data structures.  The position in the array
coresponded to the direction in which the exit led (n, e, s, w, u, d).
In SMAUG, we use a double linked list, and have added extra fields to
the exit_data structure, one of which being a 'virtual direction'
which is a number that coresponds to the original classic DikuMud exit
numbers.  With this new exit setup, we have the capability of having
more than one exit in the same direction.  We have also added some more
directions (ne, nw, se, sw and an exit 'somewhere' which doesn't lead
in any particular direction).
SMAUG exits also support many more flags, and the ability to set up
an exit that can be triggerred by simply typing a keyword, or exits
where you use commands like "climb", "enter" or "leave".


- String hashing has been completely rewritten

Simple string hashing was added to Merc, but seems to us a weird kludge
of confusing and restrictive code.  During the process of finding the
bugs in Merc, we removed string hashing completely, along with all the
cumbersome memory management techniques.  These routines made debugging
memory leaks nearly impossible, and many bugs were discovered after
removing this code.
After nearly a year after removing all the string hashing and memory
management, we created a string hashing system that is both restriction
free, and also allows releasing memory of strings that are no longer used.
(Note: the proper string handling functions must be used, and not intermixed
with non-hashing functions).


- Identical objects are grouped together

To save both memory and the processing during saving and loading player
files, identical objects are stored as one object (with a count field)
when placed in the same location (on the floor, in a container, in
a character's inventory).  For this to work smoothly, extra steps need
to be taken when dealing with objects.  If an object is to be modified
in any way shape or form (including being extracted), it must first
be separated from the group by a call to 'separate_obj( obj )'.
The grouping is already handled by obj_to_char(), obj_to_obj() and
obj_to_room().  (Note: when dealing with "all" of an object, there is
obviously no need to separate the objects -- ie: 'drop all', 'get all.potion').


- The note system has been replaced with boards

Due to the non-realism of Merc notes, and the fact that there was only
one list of notes encouraged us to create a better system.  The syntax is
entirely the same, but you must be in a room containing a bulletin board
to post, view or read notes.  There can be any number of different boards,
each with its own list of notes, as well as settings to how many notes
it can hold, and the levels for reading, posting and removing notes.

To retain the capability of private notes, a room containing a board
can be flagged as a post office, where all the notes (mail) are private.

Notes (comments) can also be posted onto players by immortals.


- The skill table and magic system have been revamped

The magic.c file was becoming a vastly huge mess of repetition.
The code for many spells was nearly identical other than a few minor
differences, (ie: the name of the spell, the damage done, the duration,
the dice roll, etc).  In light of this, we created generic spell
-- spell_smaug -- that could handle all the common spells, and added
several more fields to the skill_type structure.  We tried to make it
as flexable and powerful as possible to be able to replace at least
80 to 90% of the current spells, and only use hard code for very
unique spells.  Even new unique spells could be designed to use the
new skill_type fields so that they could be used by more than one
spell.  (See smaugspells.txt)


- The experience system has been completely revamped

Players now get experience based on damage done to a mob, as well as
during the use and learning of new spells and skills.  Also, a lot more
experience is required to gain levels, and this goes up with each level.
Experience requirements are also different for each class, and experience
given for mobs is determined by a complex formula involving the mobile's
stats, including spell affects, rather than by level alone.

---------------------------------------------------------------------------

As well as these major structural changes, which can generally make porting
over code from other Diku derivatives a non-trivial task, many code changes
and additions have been done without disrupting the inner workings too much.

Here are some of the most significant code additions and changes:


- Online building

This code has had over a year and a half of real time usage, testing and
development on one of the largest MUDs on the Internet.  Basically it's
been tested through conditions of 20 to 30 builders building along with
well over 100 players playing.

It has come a long way, and basically supports online editing and creating
of most everying on the mud: rooms, objects, mobiles, resets, mudprograms,
shops, repairshops, boards, clans, councils, guilds, orders, spells, etc.


- Skills have been removed from the command list (other than "bs" for
backstab).  Skills are now searched for in the skill table.
This also allows the ability to use the SMAUG spell code with skills.


- Command table has been removed

The old command table array is now just a memory... replaced with a hash
of 126 linked lists.  The commands and their settings are read from a file
upon bootup, and can be modified and saved online.


- Social table has been removed

The social table is now a hash of 27 linked lists.  Online social editting
commands are also in place.


- New item types

A lot of new items have been added, along with special code handling which
allows for many interesting twists and features to areas.
Some of these are: traps, levers, switches, pullchains, pipes and portals.


- Player controlling code

With a large mud comes many problem players.  Much has been learned through
experience, and many wizcommands have been added just to deal with players,
as well as room flags, and player flags.  A player can be put into a room
with flags that restrict them, log what they say to a file.  Rooms can be
flagged so that you cannot "get all" or also so you cannot "drop all".
Players can be litterbug flagged so that they cannot "drop all".
You can ban sites, restrict new players from a site, and the bans save
and load.  You can also loadup a player who is not online to do what you
please with them, and then force them to quit.