**************************************************************************** * [S]imulated [M]edieval [A]dventure multi[U]ser [G]ame | \\._.// * * -----------------------------------------------------------| (0...0) * * SMAUG 1.4 (C) 1994, 1995, 1996, 1997, 1998 by Derek Snider | ).:.( * * -----------------------------------------------------------| {o o} * * SMAUG code team: Thoric, Altrag, Blodkai, Narn, Haus, | / ' ' \ * * Scryn, Rennard, Swordbearer, Gorog, Grishnakh, Nivek, |~'~.VxvxV.~'~* * Tricops and Fireblade | * * ------------------------------------------------------------------------ * SMAUG is a heavily modified derivative of the Merc2.1 distribution. SMAUG 1.4 is close to six times the size of Merc2.1, and has major changes to the inner workings of the code, hence making porting of code from other Diku-derivatives non-trivial to the non-coder. This document discusses some of these changes. 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. There are also helpful macros (LINK, UNLINK and INSERT) for easy dealing with double-linked lists. - 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, and cannot be accessed via a directional command). 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 a 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. Most of these changes involve giving more control over the mud to high-level gods, making the code more flexible and optimizing its performance. Here are some of the most significant code additions and changes: - Online building This code has had over two and a half years 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 300 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 table 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 table 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. - Global Setting Control Sometimes it's hard to determine how best to tweak certain values and settings, and often you'd like to give the ability to make adjustments of how things work to non-coders. We've added the "cset" command to allow high-level gods to make adjustments to some global settings that we thought were important to control. (Of course you can add more of your own). These include modifiers to some skills, modifiers to damage, restrictions and levels of some features and internals of commands.