Aether the Odyssey - News: Building

Building

The following news files give instructions and explanations on various building commands. If you plan to do any building, please read each one carefully, and contact a member of the staff if you have any questions.

Introduction

Because of the nature of the game, there will be no room for players to create private/personal rooms. Those that would, thematically, have their own room (Captains and perhaps the Firt Mates) will already have that room built into the ship, though thoe players can submit their own decriptions.

For bigger projects, such as an island or a new land for a new race, you will need to send e-mail to staff, and include a brief history of the building, how you expect it to be used in RP, how many rooms you'll need, how much @quota you expect to use, and perhaps a rough description for the main room. You can send this with the TP application or it can wait until your TP/Race has been approved for play. If approved, you will be given either extra quota or a Builder character, and your place will be linked to the grid after it is complete. TP grids must be finished and approved before the TP begins.

Builders

These are characters whose sole purpose is to own public rooms and exits. They are not players. Their names should indicate which project they are working on, such as BridgeBLDR.

There are several advantages to this system. If you are building for a group of players, having a single character own everything removes ownership conflicts, and ensures that the project remain even if players leave the game. Also, the burden on an individual player's quota is reduced, and several people can share control and maintenance of the group's building. Builder characters are never in any danger of being purged for idleness if they are not logged on for months at a time.

It is highly recommended that you save a copy of your project--be it a building or code--elsewhere (i.e. hard copies or a disk). Thus, in the event of database corruption or some other unexpected catastrophe, you will not have lost all your hard work.

Quota

Extra quota will only be given out for projects that will be public or accessible to large numbers of people. It is advised that you plan your layout by means of an outline, picture, or map. Then calculate how much quota you will need (assume 3 quota per room). Once that is done, e-mail the building admin as specified in "news b-intro."

Private dwelling: These projects include a character's private room. 5 quota for each player.
Minor Public dwelling: These projects include places such as a shop and a home. 10 quota: 3 rooms, 1 object, or any combination.
Major Public building: These projects include a palace, a tavern, a park, etc. 15 quota: 5 rooms.

Room Guidelines

Names: Room names should be simple and informative. They should clearly state where you are as well as which area the room is connected to. The basic format should follow 'Room - Building - Region'. (Example: Courtyard - Castallia - Parnassus)

Theme: When describing a room, please keep the theme in mind. Only use imagery and materials that might be found in your particular location. For instance, chances are slim there would be a pine forest in the middle of the desert, so don't describe one there.

Descs: The main description should be just that--a description of the immediate area, be it a room or a forest clearing. Try not to mention all the exits and their destinations, since they're listed at the bottom anyway. Also avoid describing things that would not be visible in the current location, although backdrops such as water or mountains are fine. The descs should begin and end with %R, and use [space(5)] to indent.

Access: There is not much point to a room if no one is ever going to see it. Some areas may restrict access only to certain groups, but in general only personal rooms should restrict access to just one player.

Unnecessary Rooms: These are rooms that no one is ever going to RP in, and thus only take up database space. They include places such as kitchens, bathrooms, closets, etc. Unless you have a very good reason, keep your rooms limited to those that will be used with some frequency.

Teleports: Due to our heavy distinction between IC and OOC play, teleporting is discouraged on the MUSH. JUMP_OK flags should be used sparingly, and only set temporarily if possible. JUMP_OK flags found on the IC grid will be removed.

Exit Guidelines

Requirements: All exits must have the following basic attributes set on them for approval:

@DESC: This is a description of the exit. It can be as elaborate or simple as you desire. If the TRANSPARENT flag is set on the exit, the exit desc should prefix what is seen on the other side. Example 1: A door leading into a small dark house. Example 2: Looking beyond the archway, you see... (TRANSPARENT)

@SUCC: (Success) This is seen by the enactor and should describe the way in which they open or otherwise pass through the exit. Example: You step through the door into a comfortable room.

@OSUCC: (Others' success) This is seen by players in the original room from which the enactor departs. Example: Victor steps through the door into another room.

@ODROP: (Others' drop) This is seen by players in the destination room where the enactor arrives. Example: Victor enters the room from the hallway.

Locked Requirements: If a door is locked, or will be locked frequently, these exit commands are also required.

@FAIL: (Failure) This is seen by the enactor when attempting to use a locked entrance. An entrance is locked to anyone not on the lock. Example: You try to open the door, but fail.

@OFAIL: (Others' failure) This is seen by other players in the originating room when a player attempts and fails to pass through a locked exit. Example: Victor tries to open the door, but fails.

See also: help @lock

All building exits should conform to the following guidelines. The aim of this section is to provide uniformity and make it easier for players to move around.

Exit Names: These should normally indicate the place to which the exit leads. Exits should be named as follows:

@name Exit=Exit Name <D>;exit;dir;d;(out;o if applicable) Example: @name door=Front Door <FD>;front door;fd;o;out

The exit name is what is listed before the first semicolon. The names after it are the "aliases," or alternate names. Try to keep exit aliases simple and obvious.

Compass Directions: A shortcut direction is often placed between the <> symbols such as <S>, <N>, <E>, <W>, etc., indicating a point on the compass.

Example 1: Grassy Hill <W>;grassy hill;grassy;w;west
Example 2: Northwest Trail <NW>;northwest trail;northwest;nw

Remember that if you go through an exit in a certain direction, a corresponding exit in the destination room must lead back to the source room.

Maintaining directional logic is very important. If you go west to get into a room, you must head east to get back out.

Using Out: To help players navigate, there is a policy that one should be able to type "out," or "o" successively in a building or territory and eventually end up back at the entrance. Thus, every room should have one exit with the aliases "out" and "o." Out exits should always lead you closer to the area's main entrance, and there should never be more than one such exit per room.

Conflicts: Avoid using aliases that conflict with other aliases or directions in the same room, and also those that conflict with certain MUSH commands. Never use the aliases n, s, e, w, ne, nw, se, sw, u, d, or their expansions unless they refer to those particular directions. Avoid using ex (examine), i, in, or inv (inventory) and l, lo (look) as exit aliases.

Flags

DARK: If a room is set dark, then no items or exits appear when a character uses the "look" command. @Sweeps do not work either. This can be useful in a room which ICly has no light source. When an exit is set dark, it does not show up on the "Obvious Exits" list. Such an exit could be hidden or secret.

UNFINDABLE: When a room is set unfindable, all the players in that room do not show up on standard WHO and +who lists.