Aether: News - Building

News

Building:

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

Introduction:

Building is a privilege, though not an elite one. You do not need to be a master of MUSHcode to build. However, builders are expected to comply with the rules and guidelines outlined here, in order to promote a high-quality, highly atmospheric roleplaying environment.

All new construction will happen in the Building Nexus off of the main OOC room. There are @chownable exits available for private rooms, and once the room is desced, you may @mail the building admin for inspection before having the room linked to the grid.

For bigger projects, such as shops or taverns, you will need to send e-mail to the building admin, 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. 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.

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 DelphiBLDR.

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 the introduction.

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.
Example: Lyceum - Delphic Citadel - Haven

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 Aether. 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:

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.

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.

@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.

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.