QC Documentation

This file is to give you some guidance what to look for when you QC an area. The guidelines for structure etc have been set to make it easier to read the code and debug it later. There are several reasons for using these guidelines. The most obvious is balance and to make it easier to find and fix bug, under- stand the code when you QC it etc. Another less obvious reason is that this is a good place to learn coding for real. If you just code for a game, you haven't won much, but if you acquire coding skills you can use professionally later, you have gained a lot :)

The purpose of QC'ing and area is threefold. You are supposed to make sure it has a high enough standard to be let out as an open area for the mortals to visit and enjoy the area and it's monsters, and for us wizards to look at, find our way in and debug, items etc shall be balanced with the rest of the kingdoms, and the area is supposed to be bugfree.

The most important thing to keep in mind when you QC is that the wizard has spent hours and hours working with the area. Being a very tough QC means you're a very good one since the area will be much better, but remember praise, praise, praise. And try to give and many constructive ideas and suggestions as possible.

Remember I can never teach you to QC. I can give you hints and ideas but being a good QC comes with interest and experience. Good luck and don't hesitate come ask me if you have any questions.

// Ceril


The person or persons who have coded the area
QC/area arch
An arch responsible for quality control and the maintenance and development of the areas.
A limit that limits the use of an item to a certain group. The limit could be that you have to have a certain skill, stat, alignment, guild, citizen of a certain nation, being a King, Duke etc.
Something that impairs the effectiveness in use of an item. It can be that you get - in a stat or skills, or loose hp at regular intervals etc.

File structure

The first thing to look at is structure. Unless the structure looks fine, it is no use to continue QC'ing it. Never ever accept code that doesn't look neat and according to the standards. It is a pain to find bugs in an area that looks like a mess. No open code is ever to be kept in a wizard's home dir, but it should be moved to a domain dir under your Kingdom dir. Only the dirs o, c, open, log, Doc and perhaps a include dir are to be kept under ~Areaname. The only file that is to be kept here is the castle.c Only open files are to be put in the o dir and all other code in the c dir. The code is to be developed and then moved over to the o dir.

Under the c (o) dir the files are to be divided into subdirs. If the area is relatively small it is enough to divide it in Armour, Monster, Object, Room and Weapon. Some prefer capitalized first letters and other lower case. It doesn't really matter, but is has to be consequent. The dirs under ~Areaname (Doc, c, o, open, log should be called exactly that though so it is easy to find what you are looking for.) Try to make the dirs stay as close to this standard as possible since it will help in finding the right file for debugging later. If the area is a bit larger you may want to divide it into subdirs like Castle and Forest etc first and subdivide it further later on.

Example of a structure:

               |                                     |
            Castle                                  Town
   ____________|______________          _____________|____________
  |        |       |    |     |        |       |       |    |     |
Armour  Monster Object Room Weapon  Armour  Monster Object Room Weapon
Subdividing by wizard name (of the domain members) has been tried in some domains in the past and it has inevitably ended in total chaos. Please don't allow this. Same goes for naming of dirs. Make sure the dir name describes what is in it. Call it Town instead of t, Castle instead of c, Object instead of stuff etc.

The files should also be named after what the contain. room1 to room23 doesn't say anything about what the files contain, and it is a total pain to find the right file when debugging. LPC files should be in lowercase and end with a .c, files to be included should also be in lowercase and end with a .h, and textfiles should have no special ending at all or .txt.


In the Doc dir the following files should exist:

Code structure

At the top of each file there should be a head describing who coded the file, when and where it has been changed. If the file is more complicated than a basic room or weapon etc, it should have a description of what it does. If the file is more complicated also make sure there are comments in the code as well.

Please make sure the wizard has made a def.h file with all paths in it ie #define ROOM "/areas/WestLars/Harbour/c/Room/" etc and is including it in all files. Also make sure they include it with a relative path is #include "../../def.h". If they don't they will have to change all paths in all files when the move it from the c to the o dir and again if we move the area to some other Kingdom in the future (like dividing the current Kingdom into 2). It is for this reason recommended that the file is located in ~Areaname/c and ~Areaname/o, respectively. This makes it easy to move files between the open and closed parts of the domain.

Make sure all code is type casted. There are three main reasons for this: The mud will run faster and smoother that way, you find more bugs when compiling that would appear as runtime errors otherwise, the code will work when we change to the new driver, and it is the proper way to code :)

Make all monsters, and items separate files, don't clone standard files and set the variables in them. There are of course times this is for the best. If you have 5 guards and just want the name and long in them to be different, then it is better to make one file and patch it with different longs.

Please make sure the wizard is using set_long, set_short, add_item, add_exit etc instead of setting the variables directly. This is for forward compati- bility.

Please make sure that for all objects except monsters and doorroom, you use create_object instead of reset. Each time reset is defined, an alarm is created and it lags the mud. Don't define it unless you need it. If reset is used, call it from the end of create_object.

Don't allow any special solution ie own doorrooms etc. If they have features that needs to be added, add them to the existing files instead. Entire areas have bugged out due to special monster.c and doorroom.c files.

Make sure the strings are broken so you with ease can read them using more from inside the mud, and that the code is indented.

Make sure the {}'s are aligned under each other and that the +, -, ==, >, <, =, >=, ||, && etc have spaces before and after them ie

Use the syntax:

	if (condition)
          array = ({ "no 1", "no 2", "no 3" });
Instead of:
          array=({"no 1","no 2","no 3"});
This is simply to make the code easy to read.

Variables are to be in lowercase, global variables may have a capital first letter, but make sure it is consequent. Functions are always in lowercase, with words separated by underscores, and #defines always in uppercase. There is no special reason for this other than convention. This way, you can recognize #defines, functions or variables, and reduce the risk for misunderstandings. Variable names and names of #defines should be descriptive of what the #define or variable is used for. Apa and bepa aren't very good variable names. i, j, k, l are generally used for counters (in a for loop for example), but other variable names shouldn't be that short. Same goes for function names :) And please make sure function and variable names etc are in English :)

Check so the creator uses the syntax:

	if (bed_made) instead of if(bed_made == 1), 
	if (!bed_made) instead of if(bed_made == 0) etc
It makes the code much easier to read

The areas

Lots of talk before we even get to the part the mortals will see. By now the file structure should look fine and the code look neat. Don't look at anything specific before the creator has done that, it will just be a waste of time :)


It is up to you to decide if you feel the theme fits your Kingdom. You are the one with the plans for it. But some general "Kingdoms guidelines". It is a fantasy mud. Don't allow anything that will wreck that feeling please.

About an area in general

Require the area to be of high quality. The area should be fun to explore and play in.

Please make sure passive skills are asked for ie climb, attune, runes, lore, swimming etc.

Check for skills and/or stats before patching reduce_hit_points. If a block of stone is falling on you, check if the player can dodge it, if it is a magical trap check vs resist etc. Also keep in mind you can play with temporary penalty, crits and bleeding.

Don't allow anything lethal without a proper warning. Don't allow the players to get trapped without a chance to get out. As Kaan once said: "A mud is more nice than real life. If you fall into a dark well, you can be sure there is a secret passage out" :)


The language used on Kingdoms is British English. Please take an extra look at the spelling (armour vs armor, harbour vs harbor etc), and make sure all the logs are in English. It is hard for other wizards to read the logs later on if they are in Swedish for example. For the same reason please make sure variable names and comments are in English.

Please make sure the language is civil enough, the text is correctly spelled, and the syntax is correct. Note that despite certain things approved in the past, foul words should never be used any place in the mud. This might seem unnecessarily restrictive, but helps to promote a civil and friendly feeling on the mud.

Common bugs to look for

When you look for potential bug please keep in mind that the players are very clever and will find any way to abuse the code. Try to test every possible way to abuse the code and any possibility that will bug.

When you want to clone an item on a player, make sure the player can carry the item ie.

	object parchment;

	parchment = make( FORO + parchment );
        if (transfer( parchment, TP ))
	  W( "You find a parchment but can't carry more, so "+
	     "you drop it on the ground.\n" );
	  S( TP->QN + " finds something among the remnants "+
	     "and drops it on the ground.\n" );
	  transfer( parchment, ENV(TP) );
	  W( "You find a parchment which you hurriedly "+
	     "pocket.\n" );
	  S( .....
Make sure there is a reset function that will reset the room, item if it is supposed to reset. It is very easy to forget and in that case the thing, or whatever can only be found once per reboot.

Make sure reset is called from create_object.

Do every stupid thing a player can possibly do to try to find bugs.

Make sure things that are given are only given once per reset/reboot. Have a variable and set it and test for it. This is a bug very easily created.

Make sure you don't get any overflow bugs from money or experience, that you can't pay negative money, that you have the amount of money that you try to pay on you etc.

Use ob->destroy(); instead of destruct(ob);, where 'ob' is an object. The former updates light etc, the latter doesn't.


Please don't let corridor rooms into the mud. Make sure the rooms are filled with actions and items. Try to give as many suggestions for new items and actions as possible. Help the creator develop his area.

Please make sure all items mentioned in the long and other items are added as new items.

Make sure all standard items like floor, wall, walls, ceiling, ground etc are added. And that if you have an item as plural is walls, you also add it as a singular ie wall.

The long desc is used for describing what the room looks like and conveying the atmosphere of the place to the player. Please make sure that the long desc is at least 4 lines long (there can of course be exceptions if you have a special reason, but those should be _special_ cases). If the creator can't make the desc at least 4 lines long, you should perhaps question if that room has a real purpose or could be deleted. Longer long descs are very welcome. If the creator cannot come up with a longer description for the room, please ask him to consider if the room is really necessary or if what he wants the room to do can be done in some other room.

Each room should be different. Identical rooms are really booring.

If skip_obvious is used, make sure it is used in the entire area and that you easily can make out the exits from the long. Make sure the exits are the standard exits as far as possible. Preferably use the points of the compass (n, s, e, w, nw, ne, se, sw, u, d) as far as possible, and enter and out if applicable. The main reason is that typing long exits is a pain, and that the players can't wimp out from there.


Allow the wizard an amount of (0.5 x # of rooms) that you get for just walk- ing around in the area, and an additional (0.5 x # of rooms) to (1.0 x # of rooms) for finding secret passages and more difficult explore. Make sure you never have to get hurt to get exploration, and avoid once per reset explore. The exploration has to be approved by a QC arch, but you are to approve it first. Hopefully the arch will just look at it and say ok after you are done with the area :)

The exploration shouldn't be grouped in smaller groups than 5 points per room, and never ever give different amount of explore for different actions in the same room. It is ok to give it for different things, but then the amount has to be the same.

Items in general

Please make sure all special items use lore, and that all items with magical abilities use attune, runes, channeling etc. Lore is a great way to build atmosphere.

We have a huge problem with money in the mud. Try to keep the values low. Look at armour.list and weapon.list for guidelines, but keep in mind low ac/wc equip should have lower value than that.

Please make sure that the equipment used by a monster fits it's level. A lvl 15 monster shouldn't have top equip etc.

All items that are top equip should have a limitation. If the piece of equipment is good, it should have a drawback as well.

Take a look at the material and make sure it is an existing material. Look at /doc/build/property/materials.list. If you need a material added, ask an area arch to help you.

All things you can pour should have property "pourable", and fluids the property "fluid".

Stat and skill enhancers

All stat and skill enhancers should have a limitation (see above) and the good ones should have a drawback as well.

Stat and skill enhancers other than the "standard types" that is belt, armband, earring, and headband, should if they are approved be uninnable.

All stat and skill enhancers have to be approved by LAW.

Spell enhancers

Spell enhancers that are better than *8, +10 or *5/+5 must have a limitation on it. No spell enhancer may ever be better than *15 or +20.

All spell enhancers have to be approved by LAW.


Make sure the types make sense please. Battle axes with type longsword is just ridiculous.

Also take a look at the material so it makes sense.

Good weapons should have some kind of limitation and if they are very good also some kind of drawback.


As in weapons above, check the type so it makes sense, and the material. We don't want steel cloaks, do we? :)

If the armour is 75% of max ac/db, it should have some kind of limitation on it, and get LAW approval.


As said earlier, don't allow special solutions to code that already exist. If you want chats, use the ones inherent in the monster if possible, don't allow multimonsters or code that does the same as monster.c but is a new copy of the same thing. Inheriting monster.c and adding things is of course ok :)

Make sure the monsters eval to at least 100% using the wiztool. Monsters with equip should eval more, and monsters with no armour or weapons could eval slightly less.

Make sure the spell attacks make sense. You don't want any "The monster fires a crossbow at you", "You resist the magic". Encourage the creator to code special attacks of his own if you want the monster to do something the standard monster cannot do. Make sure he doesn't duplicate existing code though :) Make sure you check for passive skills and/or stats before you patch any damage though. A good way to implement own attacks is to use set_spell_mess1("#functionname"). See /doc/build/monster/fun/set_spell_mess1 for more info.

Food & Healing

Examples from the pub in Lars for appropriate strength vs cost.
		Cost		Value		Strength	Ratio cost:str
Beer		12		6		3		3:1
Special		40		20		10		4:1
Firebreather	120		60		25		6:1
Be very restrictive with healing for other things than food for temporary penalty, hit points, crits and bleeding for normal medicine. If the creator codes food of his own, please make sure he uses the /std/healing/soft_drink, alco_drink, food or if that doesn't work out, patches stuffed, soaked or satuated.


They should inherit /std/obj/container

The ratio between what the container contains and the weight of the container should be 5:1 to 6:1. The larger container the smaller the ratio. A normal bag has a ratio of 6:1. If the containers are better then that, they need QC/LAW approval. Please keep in mind that large containers enable the players to carry lots of things around with them. If they are better then that they should be uninnable or have other restrictions on them.


Preferably there should be a brave way and a smart way to solve a quest. Low level quests should be solvable with a minimum of violence and higher level quests be solvable with brains to minimize the amount of violence.

Please make sure the hints along the quest are enough to solve it. It is fun to get help, but it shouldn't be necessary. You should be able to solve it on your own.

Try to make sure you don't have to wait for items to reset. The ultimate quest can be solved by anyone at any time. Make sure you don't have an unlimited amount of any item though.

Make sure you have to go through all stages in the quest to solve it so you can't just get the final item from someone else and solve it.

Try to flag parts of the quest or make the items innable so you don't loose it all and have to start all over if the mud crashes.

Some type of things have to be approved by a LAW or a QC arch.