DARKOVER 2.1 Builder Documentation for Darkover MUD INTRO.TXT Written by Shalla and Eldritch of Darkover Last Updated: 12/17/00 INTRO.TXT Index: 1.......Darkover 2.......The Files in This Package 3.......Legal Stuff 4.......Introduction to Building 4.1.....Terminology 4.2.....Overview 4.2.1...Files 4.2.2...Zone Numbers 4.2.3...Virtual Numbers 4.2.4...Flags 5.......Text Files 5.1.....Text Editors 5.2.....Text Formatting 5.2.1...Indentation 6.......ANSI Usage 6.1.....ANSI Codes 6.2.....ANSI Tips 7.......Important Note on Building Philosophy 7.1.....Stuff to be Submitted With Your Area 1.......Darkover ---------------- Darkover MUD is a CircleMUD 2.20 derivative DikuMud currently running at darkover.isilm.net 5000 2.......The Files in This Package --------------------------------- intro.txt The file you are reading now. world.txt Documentation on the world file. object.txt Documentation on the object file. mobile.txt Documentation on the mobile file. zone.txt Documentation on the zone file. shop.txt Documentation on the shop file. alchemy.txt Documentation on the alchemy system. mobprogs.txt Documentation on the mobprog system. 3.......Legal Stuff ------------------- How many places do you know that will publish your work before running it past an editor? None? That's what we thought. Darkover will, of course, change what you submit. We usually do not change more artistic things like names and descriptions, but any object stats or other numbers are subject to total rewriting. Darkover has a single person in charge of area balance, and it is up to that person and no one else to assign stats to mobiles and objects in Darkover's world. You can (and are expected to) assign stats to your creations, but this is with the understanding that you are not an expert on game balance and are only making suggestions as to what you wish these stats to be. Don't worry too much about whether the stats you set are balanced or not. We will adjust them for you, and as long as you remain with Darkover, we can work with you to do things how you would like. Similarly, how many places do you know that will let you submit work, work with you to edit it, publish it, and then let you demand that they stop using it? None? Well, duh! If you submit an area to Darkover and we decide to use it, that decision is final. You cannot later demand that we stop using it and you cannot publish that area elsewhere without our permission. In exchange for this, you are granted an immortal character on the game and are allowed to take part in immortal discussions. However, there are rules to follow, and if you break those rules, you can lose your immortal character and we will continue to use your submissions. In practice, things are not this strict. If you request that we stop using an area, we will make note of that request and replace or remove the area when it is convenient for us to do so. This could be immediately and it could be never. There are usually a number of younger builders eager to replace such things and it can be done in less than a month. However, if no builder is willing to or capable of replacing your area, it can remain in Darkover indefinately. This is likely to happen if your areas were very important or very large. 4.......Introduction to Building -------------------------------- This Building documentation is for DarkoverMUD. Before reading this, it is assumed that you have played DarkoverMUD for a while and read the HELP BUILDING entry there. If you are not familiar with DikuMuds and general concepts like hit points, hitroll, damroll, and armor class, you should play Darkover more before considering Building. If you have built for other Diku or Circle MUDs in the past, you may have some familiarity with Building, but Darkover's database has many unique features that you are required to understand. You cannot simply submit an area designed for another MUD and expect it to work. 4.1.....Terminology ------------------- The following are some common terms and abbreviations which you will commonly encounter while building. Many of these are also used throughout these files. area: A term commonly used to describe a specific set of rooms, objects and mobiles. Do not confuse this with "zone". desc: Abbreviated version of 'description' flag: A bit-vector that tells the mud that a particular monster, object, or room has a certain quality. (See section 4.2.4) mob: A Mobile. Refers to monsters, guards, NPCS, etc. obj: An Object. Items players use, eat, etc. shop: A mobile which sells and buys items. tilde: A tilde (~) is used to signify the end of certain fields within a database file. vnum: A virtual number. Every object, monster, or room has a unique vnum. zone: A set of commands and instructions that makes the objects, mobiles, and rooms in your area work together. Do not confuse this with "area". 4.2.....Overview ---------------- In order to give an overview of an area for Darkover, we will be referring to an example area which we shall call "examp". In order to create an area, you must have some type of editor which is capable of saving pure text documents. A popular editor is MSWord for Windows. 4.2.1...Files ------------- Each area must have at least 4 separate files to fit into Darkover's database. The name of the area is commonly used as the name of the file, and a specific 3-letter extension is used to indicate the type of data included in the file. The files for the example area "examp" are: examp.wld All the data on room descriptions, doors, and exits. examp.mob All the mobiles (NPCs) in the area. examp.obj All the objects in the area. examp.zon Commands used to load the objects, mobs, and doors. Besides the basic 4 (wld, mob, obj, zon) files, areas may contain others. These are not necessary, but may be required if you intend to use certain features in your area: examp.shp Information for shop mobiles. 4.2.2...Zone Numbers -------------------- Every area consists of a zone, which is a number from 0 to an almost unlimited number (something like 4billion * 4billion). All the rooms, objects, mobiles and mobprogs in your area must fit within this zone of Darkover's world. For example, you may be assigned zone 118 to create your area. Your "zone number" is 118 and the vnums you have access to are 11800-11899. It is possible to be given more than 100 vnums (for example, 11800-11999), but each area still has only one zone number, in this case zone 118. You should get your zone number and vnums from Rall before you start Building. (You should already know this from reading HELP BUILDING on Darkover.) The documentation on the individual files (wld, mob, obj, zon, etc.) will tell you what to do with these numbers. 4.2.3...Virtual Numbers ----------------------- Every room, mob, obj, and shop must have it's own vnum, or virtual number. This number serves to identify that item from all the other ones of its same type. For example, there can only be one room 11800 and one object 11807. However, you can have both a room 11800 and an object 11800, because rooms and objects are two different things. If you are assigned vnums 11800-11899, please make sure you start your files with vnum 11800, not 11801. 4.2.4...Flags ------------- A flag is a binary value, either 0 or 1, off or on, which tells the mud that there is some special property to a room, mob or obj. The other files in this package list the flags you can set and what they do. This section describes what they are and how to set them. The following example is for room flags: NOTE: Please refer to world.txt for the up-to-date list of room flags. This is only an example. 0 No Flags ^0 Dark Player cannot see without a light. ^1 Death Death trap. Player dies instantly. ^2 No Mob No mob can enter this room. ^3 Indoors Player does not see weather messages. ^4 Not Used ^5 Not Used ^6 Not Used ^7 No Magic Players cannot cast magic here. ^8 Not Used ^9 Private Only 2 players may be in this room. ^10 God Room Only Gods may be in this room. ^11 Not Used ^12 Imp Only Only the Imps may be in this room. ^13 No Recall Players cannot recall from this room. To assign flags to a field, you simply list them, one after the other, with | symbols between them. To make a room Dark, use ^0. To make a room Dark, Indoors, and No Recall, use ^0|^3|^13. (Without the .'s of course.) To use no flags at all, use simply 0 without any ^ symbol. 5.......Text Files ------------------ As mentioned above, Darkover's database files are all text files. They are not MSWord files, Word Perfect files or anything of that sort. It is up to you to figure out how to create a text file with your computer and how to save it to the format Darkover requires. From this text file, the information will be stored in a mysql database, which the mud will read from for game play. We will provide the scripts to get your information into the database. 5.1.....Text Editors -------------------- MSWord and other word processors are capable of creating and editing text files, although you must specifically tell them to do so. Under MSWord, you must choose Save As to save the file, and specify its format as "Text with Line Breaks". Something similar should be available in any decent word processor. If you don't know what a text file is or what line breaks are, you probably shouldn't be building. 5.2.....Text Formatting ----------------------- Darkover requires each database file (wld, mob, etc.) to be formatted in a certain way, and we will not do this for you. The files must be saved to line-break at a certain column width, depending on which database file you are saving: wld, mob, obj 72 columns shp, qst 79 columns Even though these files are supposed to be formatted to set column widths, long descriptions on objects and mobiles can go to a full 80 columns. As a general rule, it's 80 columns for 1-line things and the specified column width for everything else. (In case you're wondering where these widths came from, 72 is for things you look at and 79 is for things that mobs would say to you.) zon files should never contain anything over 1 line long, so the number of columns is irrelevant when saving them. If you have used Windows and Macintosh interfaces for your entire mudding career, you might not even know what a line break or a column is. A brief explanation is that a "standard" screen is divided into 24 rows (everyone knows about rows) and 80 columns. Although graphical interfaces are capable of making characters that are all different widths, the standard is that all characters occupy one column, whether they be an 'i' or a 'W'. To duplicate this in most word processors, you must use what is called a monospace font. Monospace fonts have all their characters the same width, as described above. The most popular monospace font is "Courier" or "Courier New". Now, let's assume we're writing a wld file and want to make sure everything is formatted to line-break at 72 columns. Before writing anything, we select Courier as our font. Then we type the following 2 lines at the top of our document, hitting Enter at the end of each line: 00000000011111111112222222222333333333344444444445555555555666666666677777777778 12345678901234567890123456789012345678901234567890123456789012345678901234567890 If you are reading this intro.txt file with a monospace font, you should see two bars of numbers that line up to make a series from 01 to 80. We want 72 to be the last number on the right of the page and 73 to fall over onto the beginning of the next line on the left. This may require you to change your font size. If changing the font size isn't enough to get exactly 72 (it may jump from 70 to 73), you will have to adjust the margins of the page until there are exactly 72 monospace characters per line. A similar process can be used for those database files that must line-break at 65 columns. If you cannot do this, there is absolutely a 0% chance that your area will be accepted. You must figure this out for yourself and you must get exactly 72 and 65 columns. 73 and 64 is totally unacceptable. We will NOT do this for you. 5.2.1....Indentation -------------------- Some descriptions should be indented and some shouldn't. Indentation is always done with 3 spaces: not 4, not 2, and not a tab character. The only descriptions that should be indented are room descriptions. No other description should be indented for any reason. This includes mob descriptions and object and room extra descriptions. Just like bad formatting, improper indentation will result in the automatic rejection of your area. The one exception to this is if you are making some sort of sign or note in an extra description. You can make those look however you want, but if you are just putting in a normal text description, it must follow the rules. 6.......ANSI Usage ------------------ In order to use ANSI, you need to initiate the ANSI with the # sign and then a letter standing for a color. Use color must then be terminated by using ##. All of these commands should be entered within a description, before any tildes. An example is this: #BThis is blue.## To change colors in the same line, simply do this: #BThis is blue, #Ybut this is yellow.## Be sure to end your use of color with ## to prevent the color from bleeding into surrounding text. Do not try to combine colors, except in special cases. #Z can be combined with other colors to make them flash, and the background colors can be combined with the foreground colors. Other than that, combinations will do nothing. When combining colors, list first the foreground color, then the background color, then #Z for blinking if you want it to blink. For example: #P#b#ZThis looks hideous!!## For obvious reasons, this should be done rarely and preferably not at all. 6.1.....ANSI Codes ------------------ #Z Makes things blink ## Normal, non-bright, non-flashing, gray #_ # character. #K Black (usually invisible) #R Red #G Green #T Brown/Tan #B Blue #U Purple #C Cyan #D Charcoal #O Orange (bright red) #E Bright Green #Y Yellow (bright brown) #L Bright Blue #P Pink (bright purple) #A Bright Cyan #W White #k Background Black - Please use these background colors sparingly. They #r Background Red - may be useful for creating (for example) a brown #g Background Green - scroll with black lettering. If you think you are #t Background Brown - capable of using this appropriately, it may be used #b Background Blue - in room and object extra descriptions. Do not use #u Background Purple - it in short/long/room descriptions or anywhere else #c Background Cyan - that may be too visible. #w Background Gray 6.2.....ANSI Tips ----------------- Do not use too many colors. An object should generally have 1 or 2 colors, and mobiles should usually have only 1. Ansi color sequences do consume bandwidth and can be wasteful. There was an old forced standard of using what we call "broken ansi". Ansi is broken when you only highlight one or two words for no apparent reason. An example of broken ansi is: a shimmering #Wminion## A #Wshimmering minion## stands here, shedding light. Broken ansi looks annoying in eq lists, because players see splotches of color everywhere instead of a single line representing each item. Both broken and full ansi have their places. We ask that people use the following guidelines to help keep Darkover's coloring consistent: - Do not use color to emphasize words, as in, "This is #Wvery## powerful." If you can't use the English language to get the emphasis you want, you shouldn't be building. - When indenting a description, do not do this: WRONG: #G This is a forest. [insert 5 more lines of description]## Indentation should look like this: RIGHT: #GThis is a forest. [insert 5 more lines of description]## - Ansi codes should be used only when absolutely necessary to switch to a new color. The following is NOT acceptable: #RThe fire is an unnaturally deep red, and looks almost living. Flames #Rleap upward from the pit, leaving angry black scortch marks on the #Rceiling.## - If you use broken ansi, do not get in the habit of highlighting words for no apparent reason. Things should be colored the way they would appear physically. Do not color words just because of grammar, such as coloring every use of the word "Dwarf" cyan. Think of how the color will appear aesthetically in the game. Most importantly, do not color only the last word. That makes the color very "unbalanced" and displeasing. * Weird: A shimmering minion stands here, shedding #Wlight##. * Good: A #Wshimmering minion## stands here, shedding light. * Weird: a rugged velven #Lwarrior## * Good: #Ba rugged #Lvelven warrior## - When we suggest that you use no more than 2 colors, this is not an excuse to do disgusting things with those two colors. For example: * Good: #Ba rugged #Lvelven warrior## * Good: #Ba rugged #Lvelven #Bwarrior## * GROSS: #Ba #Lr#Bu#Lg#Bg#Le#Bd velven warrior## Do not alternate color between letters and do not color only one letter in a word (unless it is a leading capital). You should almost never switch colors in the middle of a word. - Room titles and room descriptions should each have a different color. Room titles can contain just about any color, but room descriptions should have something that is pleasant to read and look at. It is perfectly fine to make room title or descriptions (but not both) gray. Room titles should almost never contain more than one color. - Descriptions that are longer than 1 line should *never* be more than one color, except to highlight words that trigger extra descriptions. It is not necessary or recommended to highlight such words, but it is acceptable. - If a description contains two different colors, the "background" color should be darker than the foreground color. If both colors are of the same "brightness", that is fine also. For example: * Good: #Ra #Brune-covered #Rlongsword## (same brightness) * Good: #Ra #Ofire #Relemental## (background darker) * Weird: #Oa #Rfire #Oelemental## (background brighter, ick!) - Object short descriptions may not contain "broken ansi". You must color the whole thing or none of it, unless you are using gray as one of your "colors". - Mobile short descriptions may contain either broken or full ansi. The only thing that is discouraged is randomly coloring words, particularly the last word in the description. If you use broken ansi, it is probably best to color everything except leading articles like "a" and "the". - It is perfectly acceptable to use no ansi color on mobiles. In city type areas, this may look better than the alternative of coloring humanoids when no color seems appropriate. It is recommended that all (or nearly all) objects use ansi colors matching the color the object would have. - Object and Mobile long descriptions may use either full or broken ansi. Full ansi is often used if the description is supposed to add to the color of the scenery. It is recommended that long descs use no more than 1 color, unless they represent very special landmarks. If you use a bright color (particularly #P, #Y, or #E), it is probably best to use broken ansi to avoid a color overdose. - Avoid using #P on powerful pieces of equipment. It is generally considered to be a "silly" color. - And finally, yes Building is an art, and if you want to do something that breaks the rules, you can try it. Just be aware that these guidelines are here to help you. If your ansi use is considered "ugly", it will have to be changed before your area can be accepted. - New Builders nearly always use hideous ansi in their first area. If this is your first area, follow these guidelines and wait until you are more experienced to try something fancy. Use no more than two colors at once and don't try anything weird. 7......Important Note on Builder Philosophy (by Andaria) ------------------------------------------- 1) Okay, first and foremost: the point of being a builder is _not_ so that you can make bigger and better eq than all the other builders. Equipment should not be the goal of an area, it should be used as a tool to help further the story or theme of the area you are making. 2) Not every mob is divine. Level 50 no_bash mobs should be as rare as, well, Jesus in a dress (no offense intended =). If a mob in your area must be made difficult, then find other ways to do it. Fireshield + aggro + detect invis + sense life works very well on making a mob challenging. 3) Darkover is a world based (for the most part) on something that could exist in reality. All areas should have a consistent time setting, somewhat like the late medieval period, and should be consistent with the general world and feel of Darkover. 4) You shouldn't build an area just for the hell of making the mud larger. An area should tell a story, connect several other areas (roads, etc), or serve as a home town. You can't just make an area full of green unicorns and not back it up with some kind of explanation. 5) The point of building an area is _not_ to gain your immortal levels and new powers. You should only build an area if you enjoy building. If you create large amounts of low-quality areas, not only is this not going to get you a promotion, but it is likely to get your areas rejected or removed. 6) The total amount of rooms in an area should be proportionate to the number of levels a mortal could gain from the varying mobs contained therein. What I mean is, if there is a 800 room area, and all the mobs are the same level and are worth the same amount of exp, then it might as well be a 1 room area with 50 mobs loading in it. There is no point in making an area larger than 200 rooms unless it's a home town. 7.1....Stuff to Submit With Your Area ------------------------------------- When you submit your area, include a text file <your_area>.txt that contains within it: - the name of your area - the zone number - how large the area is - what levels the area is targeted for - the theme or idea of the area - what if any quests are involved with the area - what if any alchemy type stuff is involved with the area - if you know, what kingdom the area is going into - a brief blurb on the area - high level mob profiles The text will be accessible to players with 'legend <area>' or something similar, so write up a brief 'advertisement' that will make players interested in traveling to your area. Include interesting things like background history, local legends, and anything else that might lure players to visit. In regards to mob profiles, generally any level 45+ mob should have one. Of course, if the whole zone is full of level 45+ mobs, that isn't practical. Any mob that has a unique name and is higher level than the other mobs in the area should have some sort of profile.