-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- (07-24-98) | Dune III Building Guide | Dune III 1.3 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TABLE OF CONTENTS 1. Introduction 2. Builder characters 2.1 Scope 2.2 Quota 2.3 Zone Master Objects (ZMOs) 3. Building approval process 4. Building rooms 4.1 Parent room 4.2 Required attributes 4.3 Guidelines 4.4 Inspectable items 5. Building exits 5.1 Parent exit 5.2 Required attributes 5.3 Guidelines 5.4 Locks 6. Places code 7. Building aids 7.1 Webster 7.2 Builder tool 7.2.1 +dig 7.2.2 +open 7.2.3 Inspection commands 8. Further information -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 1. Introduction This guide contains all of the core information you will need to build rooms and exits according to the specifications set by the Dune III administration. Creation of other objects is not within the scope of this guide and is not covered. If you will be building anything on Dune III, please be completely familiar with the specifications in this guide. If you have any questions that are not sufficiently answered within this guide, please either contact a Builing Sphere Administrator (see 'news spheres') or send e-mail to the Administration at dune3-admin@fremen.org. The current version of this guide can be found at the Dune III web site under "Guides": http://www.fremen.org/muds/dune3/guides/. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 2. Builder characters --------------------------------------------- 2.1 Scope Builder characters are the only non-Administration characters on Dune III who have the ability to build new rooms and exits (see 'help builder'). Each faction on Dune III will receive its own builder character with the name FACTION-Bldr (ie, Atreides-Bldr) and aliased to FACTION (ie, Atreides). The builder character is responsible for building the embassies, home worlds, palaces, etc. for its faction. The Administration controls its own set of builder characters: Kaitain-Bldr, controls public IC spaces on Kaitain; OOC-Bldr, controls public OOC spaces; Guild-Bldr, controls spaceports and all space-related objects. Where these sets of spaces connect, the owner of the private space will own both connecting exits in most cases. If a private space owned by own builder needs to connect to one owned by another, please contact a Building Sphere Administrator. --------------------------------------------- 2.2 Quota Each faction builder character will start with a quota of 75 objects. The builder needs to exercise care when using this quota as increases will only be granted if you can make a good case for the purpose of current structures and future structures. If your builder requires more quota, contact a Building Sphere Administrator. Builder quota is subject to periodic review. See Section 3 for more information. --------------------------------------------- 2.3 Zone Master Objects (ZMOs) We recommend that builder characters set themselves ZONE (see 'help ZONE'). We further recommend that everything the builder character creates be zoned to a single ZMO (see 'help @chzone). For more information on the potential uses of a ZMO, read Section 7, Further Information. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 3. Building approval process --------------------------------------------- All rooms initially have the UNINSPECTED flag set. Until this flag is removed, RP using uninspected rooms and exits is forbidden. When you have completed a space, such as an embassy or a forest on the home world, contact a Building Sphere Admin (BSA). Do not contact the BSA for approval of a single room if it is part of a larger project. While building, do not visibly connect your space to approved spaces. Set exits DARK and lock them to only the builder. The BSA will examine your rooms and exits. If they meet the criteria in the following sections, the BSA will remove the UNINSPECTED flag, approving the space for RP. At this point, you can remove the DARK flag and unlock the exits. If your rooms and/or exits fail inspection, the BSA will send the room owner @mail listing the faulty object numbers. Each of these objects will have a field &BUILD_NOTES that will explain what is missing or incorrect. Players who have the authority to do inspections may not approve their own construction. They must have another BSA check their work. The BSA can initiate a periodic review of building objects. Objects found to not be within the specifications of this guide will have the UNINSPECTED flag reinstated if the builder character does not bring the object within minimum specification within two weeks of notification. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 4. Building rooms --------------------------------------------- 4.1 Parent room All rooms must be parented to the Dune III Parent Room (#62) or a room that has in its parentage the Dune III Parent Room. All rooms are required to contain a description in their @desc attributes. Tampering with the @conformat and @exitformat are only allowed to the extent that the final output must conform to the standards set by #62. The actual workings of the Parent Room code are beyond the scope of this guide, but the parent room is always set VISUAL to allow code developers to see how the code works. --------------------------------------------- 4.2 Required attributes Each room must contain the following attributes. Rooms will not be approved until these attributes are properly set. They are: * @desc: Each room must contain a description. See Section 4.1 for more information. * &info: Pragmatic details about a room can be removed from its desccription and listed in this attribute. &info shows details about a room such as its size, amount of traffic, other information which would be obvious to someone closely examining the area. * &arbinfo: This attribute shows more detailed information about a room, such as security measures. This field is accessible only by those players who are set ARBITER (see '+help +set'), and is used to help arbiters assess an RP situation (see 'news arbitration'). --------------------------------------------- 4.3 Guidelines Room descriptions should be concise enough to fit on a standard screen: no more than 20 lines for desc and list of exits. A description can be vivid without being overly verbose. Make use of the &info attribute and inspectable items (see Sections 4.2 and 4.4). Room names within a space should have a consistent suffix with the planet and space name in the form "-- SPACE (PLANET)". For instance, a conference room within the embassy of House Atreides on the planet Kaitain should named "Conference Room -- Atreides Embassy (Kaitain)." All rooms should be set TRANSPARENT, unless there is a specific and thematic reason for them to be otherwise. For an explanation, read Section 5.3. The number of exits in a room should be kept as small as possible and should never exceed 5. You should build only a very small set of rooms at a time. Limit to one room at a time if possible. Complete every aspect of the room before digging another. Also, it is a good idea to complete exits between rooms as soon as they are created. --------------------------------------------- 4.4 Inspectable items Certain items within a room's description warrant more detail than the total of 20 lines allows. Inspectable items are designed to cover this problem. Add an attribute called &inspect_ITEM, where ITEM is the item you wish to further describe. The command 'inspect ITEM' (see +help inspect) will return your description. In the description of the room, you should emphisize all inspectable objects with the emph() function (see +fhelp emph()). emph() uses the ANSI code specified if the looker has an ANSI flag or puts a string in all caps if the player is not ANSI. For instance: @desc here=You see a [emph(h,chair)]. &inspect_chair here=The chair is ornately decorated. Inspect works for other types of objects in addition to rooms. The object owner enters the inspectable information in the same manner on the object. However, viewers must use the syntax, 'inspect =.' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 5. Building exits --------------------------------------------- 5.1 Parent exit Parenting to the parent exit is not a requirement, but it can make your life easier. The Dune III Parent Exit is #58. A @describe is still required if you use the exit parent. However, the exit parent uses default @success, @osuccess, and @odrop attributes. If an exit would just have generic messages like, "@success: You walk through the door to the east," or "@odrop: descends the stairs from the north," you can use the exit parent to take care of the messages. The exit parent handles four types of exits: 'doors,' 'streets,' 'stairs,' and 'other.' The parent will try to identify the exit type from its name. If it cannot determine the type, it defaults to the 'other.' The parent can be forced to recognize the type by setting a &type attribute to 'door,' 'street', or 'stair.' If the exit is not of the three types listed, custom @success, @osuccess, and @odrop are prefered. Likewise, if there is anything special about the exit that makes the default messages inappropriate, use custom attributes. To see how the messages are generated, and to check for what keywords the code looks for in an exit name, examine the Dune III Parent Exit (#58). The object is set VISUAL. If the exit can be locked, @fail and @ofail still need to be set as specified in 5.2. --------------------------------------------- 5.2 Required attributes Each exit must contain the following attributes either on the exit iteslf or inherited from a parent. Exits will not be approved until these attributes are properly set. They are: * @describe: Each exit must contain a description. * @success: Shown to the player who passes through an exit * @osuccess: Shown to everyone in the room the player leaves * @odrop: Shown to everyone in the room the player enters If you intend to lock an exit (see Section 5.4), you will also need the following attributes set properly: * @fail: Shown to the player who fails to pass thought an exit * @ofail: Show to eveyone in the room when the player fails to pass through an exit If you intend to use the knock functionality, see '+help knock.' --------------------------------------------- 5.3 Guidelines Exits should be named by their type (Arch, Stone Door, etc) and horizontal direction on a compass (N, S, E, W, NE, NW, SE, SW) or vertical direction (U, D). They should also contain aliases of their directions (north;no;n). Exits leading to a more common space than the room that they are in should also contain out information in the alias (leave;back;exit;out;o). Exit names should have the form NAME . For instance, @name exit=Grey Plasteel Door ;north;no;n;leave;back;exit;out;o A player should be able to get back to the Subway Platform in a city section or the front door of an estate by going 'out' multiple times. Rooms should be set TRANSPARENT so that an exit will show the name of the room to which it leads. There may occasionally be a reason for this to not be the case. You will need to explain this reason to the Building Sphere Administrator who is inspecting your space before approval will be granted. If your exit is an some type of an open structure (eg, an arch) or is transparent (eg, glass), you will need to set the exit TRANSPARENT. This allows the description of the room to which the exit leads to be available when a player looks at the exit. --------------------------------------------- 5.4 Locks See 'help @lock' for information. There is not presently an Admin supported exit locking system on the MUSH. Feel free to ask the Admin Building and Coding Staffs for assistance. A system may be installed if enough player interest is observed. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 6. Places code -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 7. Building aids There are many on-line sources of information and help for a builder. The 'news,' 'help,' and '+help' are always available. Since these are fairly standard, they will not be delt with in detail here. Also available are Webster and the Builder Tool. These are each delt with in more detail below. For on-line help, type '+help +spell' and '+help +define' for Webster and '+bhelp' for the Builder Tool (+bhelp only works if you own and are holding a Builder Tool). --------------------------------------------- 7.1 Webster Before the BSA come to inspect an unapproved space, they expect that grammar and spelling have been checked. Any errors of these types can cause delays in getting the area approved. As an aid for these types of checks, the Webster Bot is connected to the MUSH. It is accessable to everyone at anytime (that it is logged on); his use is not restricted to builders. Webster can examine strings sent to him or object attributes for spelling errors. As a grammar aid, he can also provide defintions to words. Webster cannot actually check your grammar. It is advised that you have at least one human player proofread before going to the BSA for inspection. Since words from the Duniverse will show up often, there is an effort to include as many of these words as possible in Webster's dictionary. If Webster warns you about Dune words you think he should know, please send @mail to containing the word you think should be added with a dictionary-type definition if possible. Webster's +define command can then also be used by players to help them learn the Duniverse vocabulary. --------------------------------------------- 7.2 Builder tool All Builders will be given a Builder Tool (an object parented to #123). Use of the tool is not required. However, the Building Tool makes following the Building Codes easier. See the following subsections and '+bhelp' on you Builder Tool for more information. --------------------------------------------- 7.2.1 +dig This is the heart of the Builder Tool. The command syntax is, +dig =;[;...][,...] The structure is very similar to the @dig command, but the entries can be greatly simplified. The idea of the command is to allow people to +dig in 'shorthand' while automatically getting construction done to code. The following processing is done on the various pieces. * Room Names: All room names must be of the form, ' -- (,' the and of the room you are +digging from will be added appropriately. If you specify ' -- ,' the will be added. And of course, if you type a complete room name, nothing will be added. * New Exit: The exit to the room being dug should NOT contain the direction in the name. Instead, this is automatically added when you specify one of the aliases as a compass direction or up and down. Other aliases will be added verbatim. * Return Exit: This space can be left blank. The return exit automatically receives the same name as the previous exit, but with the direction automatically set in the opposite direction. DO NOT specify a direction for the return exit. Any arguments provided for the return exit will become extra aliases for that exit. * Out Alias: If no exit is given the alias 'o,' then the return exit will be assumed to be the 'out exit.' If either is given 'o' as an alias, it will be designated the out exit. The out exit automatically has the aliases 'out;ou;o;leave' added. For example, the following two commands are equivalent when digging from a room called 'Baron's Lounge -- Harkonnen Embassy (Kaitain),' +dig Baron's Sleeping Quarters=Purple Curtains;purple;curtains;sleep;e, purple;lounge @dig Baron's Sleeping Quarters -- Harkonnen Embassy (Kaitain)= Purple Curtains ;purple;curtains;sleep;e;east, Purple Curtains ;purple;lounge;w;west;out;ou;o;leave In addition, the room and exits will be properly parented and may have flags set. User custumization of the setup procedures for each type is supported. There are also seperate commands that will just do these setups, '+rsetup,' and '+esetup .' --------------------------------------------- 7.2.2 +open The +open command behaves just like the +dig command, except it is similar to @open; it opens exits between existing rooms. The syntax is, +open [;...];=[,...] The first exit and the final list of aliases are processed just like the 'New Exit' and 'Return Exit' described above in Section 7.2.1. The must be specified by its dbref. --------------------------------------------- 7.2.3 Inspection commands There two commands to inspect areas. '+rcheck' examines the room you are in and '+echeck' will examine all of the exits in the room. A report on the room summarizes (1) if it has been inspected, (2) if it has a description, (3) important flags, (4) zone, (5) parent, and (6) ownership. The exit report checks each exit for (1) flags, (2) lock status, (3) parent, (4) required attributes, @succ, @osucc, and @odrop, and if locked @fail and @ofail, and then checks that no names and aliases in the room overlap and verifies that one exit is aliased 'out.' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 8. Further information If you've never built on a PennMUSH before or would like to review, you may find the MUSHManual useful. You may also wish to read Marik's Building Memo, written specifically for planet-building on Dune I. It has excellent general application, though. Highly recommended. Both can be found at the Dune III web site under 'Guides': http://www.fremen.org/muds/dune3/.