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
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:
/areas/<Kingdomname>/<Areaname>/c
__________________|__________________
| |
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.
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:
if(condition){
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) etcIt makes the code much easier to read
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" :)
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.
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) );
}
else
{
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 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.
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.
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 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.
All spell enhancers have to be approved by LAW.
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.
If the armour is 75% of max ac/db, it should have some kind of limitation on it, and get LAW approval.
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.
Cost Value Strength Ratio cost:str Beer 12 6 3 3:1 Special 40 20 10 4:1 Firebreather 120 60 25 6:1Be 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.
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.
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.
LAW: