|
 |
|
 |
||||||||||||||||||||
|
|
Building Wheel of Time themed areas: The WoTmud IV Building Guide (II) A great zone has variety, interacts with the player and oozes atmosphere. Above all, and most importantly, it makes the player want to come back time and time again.. Contents:-
X. Common zone problems
XI. Some hints to make your zone stand out from the crowd A good zone has variety, interacts with the player and oozes atmosphere. Above all, and most importantly, it makes the player want to come back time and time again, and in fact, if players are not interested in your zone, it should tell you something. As a player myself, there is nothing more boring than going through a zone where having been there once, I have no reason to return. I feel as if I have seen it all. The key is to make players feel precisely the opposite, to make them want to come back for things that they feel they missed. People will soon tire of the mud if there is no unpredictablity, or if players feel they have done it all. Hence the emphasis on unpredictability, and on putting adventures in the zone, and on more content than straightforward rooms with straightforward exp. That way, people will feel that there is a reason to come back. A good way to start making an otherwise predictable zone more interesting is to divide it into different areas. Take, for example, the Braem Wood. It is a forest for newbie xp - potentially a dull as hell 10x10 grid. Instead, it has a stream, the undergrowth, a statue, lots of little different interconnected forest areas, a valley, a plateau, a trail through the centre, a secret temple, paths going up, paths going down ... you get the message. The idea is to mess with the person's mind who plays in your area; to get them to suspend their disbelief, to stop thinking of the game's geography in terms of grids on a game-map but as a physical place with features, hazards and characters. They should be made to think that they are actually there. Start off by drawing a map on a piece of paper of the zone that you are about to write. PLAN! Taking some time at this point to carefully think things through will save you immense grief later on. Don't just jump in, start building like a madman only to change your mind after 50 rooms. So make the plan as detailed as you need, and include arrows pointing to features in the zones next door. You will nearly always need more rooms than you think, and planning them first overcomes that particular hurdle. A good plan showing the nearby and main features is very useful for making the longdescriptions, ie "The snowy peaks of the Dragonwall stretch far to the east" and for making the join between the zones as seamless as possible. There is nothing worse than to see two interconnected zones with totally different styles, lengths and detail in descriptions, with room descriptions that point to non-existent features. Think it through from the player's perspective. Why call a room "Towards a Forest" when the player may be leaving the forest? If it is near a human settlement, make a few hidden areas where shadowspawn can hide during raids, or areas where horses load, or if it is the back of beyond, places with food and water. If you want to provoke confrontation, make the zone such that there are few 'arteries' through it, thus making meetings inevitable. Equally, make your mobs yell if they are being threatened or killed, or make them send tells to other mobs nearby who then react on this using MOBOL to say, rally some soldiers. If you want unpredictability, use 'mobloader' rooms, not otherwise connected to the game, that have 6 exits to places in the zone that the mobs walk out into. If it is a forest in human lands, stick a couple of rogue trollocs there. Other points to consider are the layout of rooms, a crucial yet oft-overlooked feature. It all boils down to design: say, for example, you have a particularly tough mob that everyobody seems to want to kill using sneak/flee, to the extent that it becomes easy. Consider putting an exit nearby that leads to other tough mobs, so that the player is less tempted to do so. Equally, if you have a bunch of tough mobs in a small area, use the nomob roomflag to keep them isolated and together, to prevent people waiting in one of the rooms just to pick them off one by one. Room keywords are features that are often under-used, but can be called in to help convince the player that they are actually there. If, in a room, you mention a lamp on the ceiling, it is simply good form to include a keyword lamp with more information about it. If not, then were the player to 'look lamp', they would see 'you do not see that there'.... rather silly, no? Room keywords can also be used to give clues to adventures, or clues to clues as in the case of waygates. True, not everybody looks at them, but they are one way to tell the men from the boys in the building department. Make sure that you put a story into your zone, which you can then make into a MOBOL adventure/quest to attract players there. It does not need to be difficult: a map of the area to be given to mob Y back in Caemlyn, or object X to be given to mob Z. A good zone should be alive, should do unexpected things, and above all, it should interact with the player, with as little as possible to give away the fact that it's all just a game. Equally, the mobs in your zone should all do or say something special. "I would not go in there if I were you" is bound to catch the player's attention, as is a story starting "Heard of the secret treasure buried in the woods?" Remember, you can use room keywords to spice up particular features in rooms, or to give clues for MOBOL quests. For example, say a player looks at a sword that's said to be hanging on the wall (via the room description), and the sword is "old and rusty, and stained with blood", perhaps the farmer in the room could whisper to the player a story of its origin, or why he never cleaned the blood off, hinting at an adventure in another zone ... perpetuating the truly interactive, never-ending online adventure, where people don't get bored and feel as if they have done it all! Finally, before you put your zone up for evaluation, reread this document and check that you have followed the correct style. It is extremily tedious and disappointing to see a zone with obvious mistakes that should have been spotted. Then, get one of the other builders to have a walk through and to proof it for you. It is exceptionally difficult to spot your mistakes if you are not aware of them, and a fresh eye will often point out things that you yourself may miss! Writing a good zone is an artform. I would encourage you to browse the other building links listed on the main help page for some great advice. After all, you want your zone to be praised and visited, don't you?
XII. Help, I'm stuck for ideas! ...so am I. All the time. Nobody has infinite creativity or a never-ending well of ideas, so you're far from alone. There are, however, several tricks to help you get round this.
This field sets the conditions of a room, and you need to be in the room and have zone access to use it. A room sectored inside and flagged indoors will always be lit. Rooms can have more than one flag, but generally the fewer the better, and such things like noweave rooms should have a good justification for their use. To undo a room flag, enter it in again.
Note:- * = needs good reason to be approved. Example: > /room flag 1 (sets the room to dark) Common errors:
| Back to Table |
This flag sets the general terrain of the room.
Example: > /room sector 5 (sets the room to mountainous) Common errors:
| Back to Table |
This sets the name of a room. Note the building guidelines for setting a room name. Room names should not be too specific (Third House on the Left) or irrelevant (Fluffy White Clouds). Example: > /room name Knightsbridge Court Common errors:
| Back to Table |
This puts you in the editor to set the description for the room, as set forth in part I of the building guide. In general, this should describe the room as it appears in the absence of external effects (changing daylight, weather, emotions and so forth). Common errors:
| Back to Table |
This replaces a word, or group of words, in a room description with the phrase supplied. The parenthesis (") are required. Example: > /room replace "colour" "color" Common errors:
| Back to Table |
This defines a keyword set and places you in the editor to enter whatever you wish to be displayed if a player looks at one of the keywords in the set. All objects mentioned in a room description but that do not load should be keyworded, or else players will see "you do not see that here" when they try and look at an object mentioned in the keywords. The keyword set should also contain all the words a player might conceivably type to look at what you're describing, ie in the case of a rusty old lock mentioned in a room description there should be a keyword entry for "lock locks keyhole old rusty". There is currently a limit of four keyword sets, though as shown above each set can contain many words which are used to access it. Example: > /room keyword corn stalk plant The battered corn has been overcome by a growth of yellowish fungus. Common errors:
| Back to Table |
Syntax: (/room door) <direction><Lock #><Key #><Find %><Open %><Pick %><aliases> This command installs only 1 side of the door, and the other side must also be installed. Doors have 2 sides! One sided or one-way doors are better done with code, and need approval beforehand. <direction> Which direction the room is that will be the other side of the door. To make a door, you need to have made the exit first. <lock> Three choices, namely: 1] means open/close/lock/unlock/pick (needs no key, and is pickable) <key> Virtual Number of the key that unlocks the door. If no key is used, use 0. <find><open><pick> These percentages are in place to prevent players from being able to open a door just by narrating to find out its name, as a min search is required to find and to open it (even if the name is known), and a minimum pick skill is required to pick the lock of the door. Should all be set to 0 in the case of a perfectly normal door or gate that's always visible. You should not put the % sign in, just the number, ie 50 50 50. <aliasses> There are words that can be used to open the door. The first word in the list is what will be displayed on 'Exits', and should therefore be entered as you wish it to appear in the game (caps, etc.) Examples: > /room door n 2 1200 50 50 0 Greatdoor Sets an unpickable (2) greatdoor to the north that needs key 1200 to be opened, and needs 50% search to find and open it. > /room door w 1 0 0 0 0 Frontdoor Sets a frontdoor to the west that is visible to every player, and needs no particular key or skills to open it. The bogstandard door or gate in the game. > /room door s 1 50 50 0 0 Cupboard Sets a cupboard to the south that only players with 50% search can see and open. > /room door e 1 0 0 75 0 Grate Sets a grate to the east that only players with 75% pick can open, but everyone can see. Note: needs to be locked using coms! Common errors:
| Back to Table |
This deletes a door that has already been previously set. You need to kill off both sides of a door. Example: > /room nodoor north Common errors:
| Back to Table |
This creates a one-way exit from a room into another room. Note that, except in strange cases in which you have a return path in a different direction, one-way exits are frowned upon, as they needlessly confuse when mapping or in PK, and are usually inappropriate. There are, however, times and places when they are perfectly fine, ie if you wish to simulate a tunnel or hole in the ground that players cannot climb back out of but have to continue exploring. However, as a matter of good form and courtesy, there has to be another way out somewhere else, ie it's not just a pointless hole that people get stuck in. Example: > /room exit n 1799 Common errors:
| Back to Table |
The most common command used to make exits, this creates a two-way exit from the room into a specified second room. The exit from the second room to the first is in the opposite direction. Example: > /room biexit n 1459 Common errors:
| Back to Table |
This removes one side only of a room exit. The exit from the connecting room must also be removed. Example: > /room noexit n 6430 Common errors:
| Back to Table |
This allows you to enter an exit description for a previously defined exit, which will be seen if a player looks in the direction of the exit. Mandatory in the case of deathtraps, it is also very effective in mazes and dark flagged areas. Note, this will work only for physical exits that exist. If you want to set an exitdescription for north where there is no exit north, use a keyword instead. Example: > /room exitdesc n The old wooden planks of the bridge look worn and rotton. Common errors:
| Back to Table |
Deletes an exit description. Example: > /room noexitdesc n Common errors:
| Back to Table |
Saves only the information in that room. Useful if you want to correct a quick spelling mistake, but not so useful in building as it will not save information in other rooms. /zone save is generally more useful. Example: > /room save Common errors:
| Back to Table |
Syntax: (/com add) <if><# times><chance %><room/zone/world> /at <room #><command> A com adds a game command to the zone, so that when it resets, it loads mobiles, objects or closes doors etc. More mistakes are made in the /coms of a zone than anywhere else, and a thorough read of this section is recommended. Machine memory is always an issue, and it is better to undercom than to overcom. Note that all coms must be in ascending order by room number. <if> The 'if' flag determines whether or not the execution of a com depends upon the one before it. A 0 (zero) in this position indicates that the com will always run at every zone reset (whether it succeeds is another matter, that depends on the other components of the com). A 1 (one) in this position means that the com will only run if the previous com ran successfully. Its main use is to prevent an item or kit loading at every reset of the zone, thus generating mobs that have 25 rare swords. Because the com that kits a mob generally follows immediately after the com that loads the mob, use a 1 flag to kit the mob. Using a 0 flag would mean that the mob gets another kit at every reset of the zone, thus leading to mobs that are carrying 20 swords, etc. <# times> The number of times determines how many times to run a command. Thus, if it is desired to load two guards to a room, a 2 would be entered here. This works in conjunction with the if flag. Therefore, it is possible to load and kit five guards, for example, with two coms, as the second com, kitting the guards, will run after each loading of a guard. <chance> The percent chance of occuring determines how likely it is that a com will succeed at any given zone reset, in a range of 1-100%. If a given com does not succeed, any dependant com will also not run. <room/zone/world max> This next flag determines how many of a given item/mobile can exist, and is entered in the form x/y/z where x is the maximum in the room, y is the maximum in the zone, and z is the maximum in the world. A 0 (zero) in any field indicates an unlimited number, and is the normal worldmax entry for all standard mobs such as deer and farmers. Note that for all coms which relate to kits, doors, forcing, etc (non-mobile/object loading) all three fields should be set to 0 (zero). Its most important uses are to limit the number of mobiles in a zone or room, and to prevent specialised mobiles loading all over the place. Great care should be taken with these entries, and they should be worked out before doing the com list as it is a real pain to say, have to go round all the soldier loading coms because you forgot to add the two that you wanted to load in room xx99 to the zonemax at the start. It also has huge memory implications, and generally the fewer mobs the better, although there are obviously major exceptions to this rule as the objects and clothing that mobs possess must not be too easy to get, nor should there be too little exp about as that will just deter players from your zone. /at <room #> Set /coms only for your zone! Putting them, by accident, into other zones may very well mess them up (ie zonetotals), and can crash the game. They are also difficult to remove, as you may inadvertedly set it into a zone for which you do not have the level needed to remove it again. The god command to achieve a particular end. The typical commands are listed below, but any god command can be executed.
Examples: > /com add 0 1 100 1/14/0 /at 6481 /l m 7805 Always (0 1 100) tries (0 1 100) once (0 1 100) to load a taardad warrior (/l m 7805) to room 6461 (/at 6481), but will not succeed if there is one there already (1/14/0) or if there are already 14 (1/14/0) in the zone. As a technicality, if coms preceding this one in the comlist (each gets numbered) have made the number in the zone up to 14 by the time the game reads this com, it will not run successfully. In other words, coms with a lower number succeed more times because players may have only killed one of these mobs in the zone. In that case, after the first com in the zone which loads one has successfully run, by the time the game reads the next com there will already be 14 in the zone, the zonemax, so no more are made. This is an important point to note when making mobs that wander, as it could inadvertantly lead to mob pileup in the rooms that the low-numbered coms of the zone target. > /com add 1 1 100 0/0/0 /at 6481 /kit aiel/warrior taardad This com directly follows the com above in the list. Thus, if a taardad warrior has been loaded successfully (1 1 100) it always tries (0 1 100) to run once (0 1 100), granting the taardaad (taardad) his clothes and weaponry (/kit aiel/warrior). Note the (0/0/0), a standard setting used for kitting coms. > /com add 0 2 100 2/22/0 /at 6481 /l m 6407 Always tries to load two mobile 6407s to room 6481. > /com add 1 2 100 0/0/0 /at 6481 /kit aiel/warrior maiden
Runs only if the previous com has succeeded, (the one above) and kits up two maidens. > /com add 1 1 5 0/0/0 /at 6481 /eq 120 maiden
Runs once only, and only if the previous com has succeeded, (the one above). It gives a 5% chance of equipping the first maiden with itemnumber 120. This is good to supplement her standard kit with a rare item. By implication, this com may only run once during every reboot, as it is dependent on a com that itself that only runs again during any session if that mob gets killed. > /com add 0 1 3 0/0/0 /at 6481 /eq 120 maiden
Gives a 3% chance at every zone reset of equipping the first maiden with itemnumber 120. This com makes it likely that it will happen late during any reboot. The difference between this one and the above is that this runs every time the zone resets. > /com add 0 2 100 0/0/0 /at 6481 /force maiden follow taardad Forces the maidens to follow the taardad warrior in the room. Note: force all.maiden does not work. > /com add 0 1 100 0/0/0 /at 6481 /force maiden yell I hear you, stranger. Prepare to dance... Forces the first maiden to yell "I hear you, stranger. Prepare to dance..." at every zone reset. Useful if you want to provoke players into combat or alert them to dangers, or just make the zone seem a bit more alive. > /com add 0 1 100 1/0/0 /at 6481 /place 105 Places object 105 in room 6481. > /com add 0 1 100 1/0/0 /at 6481 close door w Closes the door called door, on the west wall, of room 6481. > /com add 0 1 100 1/0/0 /at 6481 close door e Closes the door called door, on the east wall, of room 6481. Even if both doors are named 'door', close all.door does not work. > /com add 0 1 100 1/0/0 /at 6481 /lock door e Locks the east door of room 6481, and makes any 'close' com for that door unneccessary, ie the previous example. Common errors:
| Back to Table |
Syntax: /com switch <number of first /com><number of second /com> Swaps two coms in a com list. Note, you can only switch the last com that you added to the list. Handy for correcting wrong coms: you com /add it first, then switch it with the wrong com thus keeping it in the correct place, then delete the wrong one which will now be last in the list. Example: > /com switch 53 18 Common errors:
| Back to Table |
Syntax: /com move <number of first /com><number of second /com> Moves a /com elsewhere in the com list. Note, you can only move the last com that you added to the list. Handy for inserting extra coms in the right place. Example: > /com move 59 7 Common errors:
| Back to Table |
Syntax: /com kill </com number> This command will remove the specified /com from the current /com list for a zone. All coms below this point will then be moved up in position. That is, an empty hole will not be left in the vacated position. Example: > /com kill 15 Common errors:
| Back to Table |
Syntax: /com list This highly useful command lists the coms which affect the current room, assisting in debugging and determining what is happening in a given part of a zone. You must be in the room to do so, although the /at xxxx routine works also. Note: you need to com save a new com before it will show up in /com list. Example: >/com list | Back to Table |
Syntax: (/at XXXX) /com show These commands list all defined /coms for the current zone in their execution order. /Com show shows the straight commands as they were entered (minus the /com add prefix) while /com show t gives verbose information about what each /com is doing. Example: >/com show | Back to Table |
Syntax:/com find <M->mob, O->obj> <vnum> This command is used to find a specific mob or object vnum in the current zone's /com list. This might be incompatible with the new com system. | Back to Table |
Syntax: /com save This command saves the /com list for the current zone. /zone save will not save the coms, and vica versa. | Back to Table |
Syntax: /show mobs This command shows all the mobs that are actually present in your zone. Very useful in conjunction with /com show, to verify that the coms are actually doing what they should and to check against inadvertant cases of mob pileup etc. Example: >/show mobs | Back to Table |
Syntax:/kitlist <directory> This command lists the currently defined kits. Any file which ends in a slash (/) is a directory, which can be viewed with /kitlist <directory>. Thus, a hierarchy of kit types exists. A seperate directory is available for every major category of mob. Example: > /kitlist people | Back to Table |
Syntax: /kit <kitname><mob to be kitted> This is the standard command. /kit is used to load a set of equipment upon a mob (or player). The kit specified by <kitname> will contain a number of items which will be automatically equipped on the target and/or items placed within standard inventory. In this way, standard equipment sets can be given, usually via /com, to mobs rather than loading each item individually, saving on the total number of coms you need to do for your zone. Kits are available for just about all generic mob types. Note: for special items, it is better to augment the kit with a subsequent dependant /equip com that gives a lower probability. Example: > /kit peasant/innkeeper Saml | Back to Table |
This displays information about the zone, such as its resetmode, current age, lifespan, creator, name, and sunrise/sunset messages. | Back to Table |
This sets the time between zone resets, in minutes. In general, values between 60 and 120 are used. Example: > /zone lifespan 90 | Back to Table |
This sets the resetmode of a zone. values:
Note: These conditions are only looked at if the zone lifespan has been reached. So, once the lifespan is reached, then it will be reset if it is deserted (in the case of mode 1). Resetmode 1 is the preferred value. Example: > /zone resetmode 1 | Back to Table |
Syntax: /zone reset . Resets the zone immediately, causing the com list to be read. Used to test the com list before putting the zone into the game. | Back to Table |
Syntax: /com save This saves the entire zone (but not coms) and sends a global echo. As with all saves, this is important to do or all changes will be lost at the next reboot or crash.
|
| ||||||||||||||||||||
 |
|  |
