Public Builder's Guide

From Tapestries MUCK

Contents 1 Requirements for New Public Building 1.1 Fit Within the Mission of the Muck 1.2 Be Accessible to All Users 1.3 Unique Functionality to the Muck 1.4 Clearly Defined Mission and Theme 2 Public Area Rules 2.1 Wizard Approval of Rules 2.2 Posting 3 Staff and Enforcement 3.1 Maintaining a Staff 3.2 Permitted Enforcement 3.3 Zone Admin System 3.4 Recommendations 4 Good Building Practices 4.1 Linking to Other Areas 4.2 The "out" Exit 4.3 Intercepting Globals 4.4 Descriptions 4.5 Obvious Exits 4.6 Parent Rooms 5 Other Responsibilities of the Owner 6 Building Application Process 6.1 Application Steps 7 Property Transfer

This document attempts to explain the requirements for building a Public area on Tapestries MUCK and the responsibilities of the administrators of those public facilities. You will need to be familiar with Policy Builder before continuing.

Building a Public area (also referred to as a Zone) is not a right on Tapestries MUCK. The TinyMUCK FB server has a number of design limitations that cause a large MUCK like Tapestries to suffer resource issues. This means that additional quota can not be afforded to everyone for such projects.

With that in mind, public building on Tapestries MUCK is limited and regulated.

Requirements for New Public Building

Since building has to be restricted, what new building is allowed is for the good of the public and the mission of the Muck. It must meet these requirements:

1. A Public area must fit within the Mission of the Muck.
2. A Public area must be accessible to to all users of the Muck.
3. A Public area must follow good building practices.
4. A Public area must have a clearly defined mission and theme.
5. A Public area must provide something unique to the Muck.

This section details some of the high level requirements for Public areas.

Fit Within the Mission of the Muck

Public areas must fit within the stated Mission of the Muck. This can be found on the front page of this Wiki.

Be Accessible to All Users

All Public building must be usefully accessible to all users of the Muck. While you may cater to specific roleplays and kinks, you may not restrict people from accessing your areas with out having to making modifications to their characters.

Unique Functionality to the Muck

A Public area should provide something unique to the Muck, such as a different role-playing environment, or an area that caters to a specific kink or set of kinks. It should also fit within and serve the Mission of the Muck, as stated in the Policies.

This is not as hard as it may sound. For example, you may make an area that serves the same set of kinks another area does if the theme of the area is different. It is also acceptable to seek to do the same thing another area does if that area is abandoned, underused, or otherwise neglected.

Final judgment on this will come from the wizards.

Clearly Defined Mission and Theme

Your Public area should have a clearly established Mission Statement and/or Theme that is conspicuously posted, especially at the entrance to your area. This should give a good idea what the area caters to, both in Role-play, kinks, and socialization. (This is commonly included with the rules.)

Public Area Rules

This section documents what sort of rules a Public area may have. Limitations on Public Area Rules The most basic limitation is, with only a few exceptions, you may not restrict or allow behavior outside of what the Muck policies allow. Some specific points are covered below.

• You may restrict certain kinks and sexual acts within your area. However, these restrictions must allow for basic sexual and D/s play at a minimum in all areas.
• You may allow kinks that are otherwise not allowed in Policy Roleplaying and TinySex. If you do so you must make it very clear that this is the case. If it is global to your building it should be in the rules. If it is specific to a room or set of rooms, it should be clearly posted in those rooms and mentioned in the rules.
• You may establish rules of conduct for people choosing to take a IC role or position. However, taking one of these roles must not be required to make use of the area.
• You may not restrict characters from entering your area based on gender, species, sexuality, IC age, or other attributes that are legal in the rest of the Muck.
• You may not require a dress code, though you may suggest one to help fit in with the roleplay of the area.
• You may not restrict rooms to a subset of the Muck's population with these exceptions:
  • Small Administrative areas for Admins only.
  • Private residences connected to your area.
  • Lockable side rooms that people may go sequester themselves in for private roleplaying.
• You may restrict OOC behaviors and discussion. You may NOT restrict OOC discussions that are part of negotiating a scene or role-play.
• You may not have rooms that are OOC only.

Wizard Approval of Rules

Rules for a Public area must be approved by the wizards, as must any changes to these rules. This is to verify compliance with this document and the Mission of the Muck.

Posting

Public areas should have their rules posted as the theme is. These rules should be as clear and concise as reasonably possible. They should detail what behaviors are not allowed within the area, and any special behaviors that are expected. It should especially spell out any differences between what is permitted in relation to the Role-playing policy.

The rules must be available through a "rules" command anywhere within your area. You may either use the global rules command, or write your own.

Staff and Enforcement

Public areas that develop regular traffic will require a staff to maintain order in the area. It also will, at times, need to take action against disruptive individuals.

Maintaining a Staff

Maintaining a staff involves more than just recruiting them. You must also pay attention to how they handle their position, correct them if they step out of line, and even fire them if they can't handle the responsibility. This can be especially difficult if you chose your friends as staff.

You are, however, responsible for your staff. While the wizards will not hold you accountable for their every action, you are expected to step in if your staff abuses their position and violates your rules, or the rules of the Muck.

Permitted Enforcement

It is permitted to use the Zone Administration system to eject or ban people from your area for violation of your rules.

It is NOT permitted to use this system to discriminate against people based off gender, sexuality, kinks, religion, and other things protected by Muck policy.

Zone Admin System

The Zone Administration system is setup to help you manage groups of staff and what permissions they have. Please see @zoneadmin #help and @zoneban #help.

Recommendations

See the Public Building Suggested Enforcement Practices for some recommendations on how to handle this.

Good Building Practices

This section documents building practices that are required of Public Areas. Some of these are policy based, and some of these are technical issues required to make the Muck feel more cohesive.

Linking to Other Areas

You may not link to other Public areas from your Public area. Each public area must only link to: Core Building areas owned by Wizards, and approved by the Wizards, and to a limited number of Private areas, such as personal apartments and the like. The expected number of these areas should be included in your application.

Ocasional exceptions may be approved by the wizards to link adjacent or otherwise logically connected Public Building.

The "out" Exit

Typing "out" or "o" should always move you closer to the point that your area is linked into the Core building, such that continued typing of "out" will get you back to that point.

Intercepting Globals

Commands built into the Muck, or in the Globals list should not be overwritten with local commands, with the following exceptions:

• say, pose, and spoof - These may be intercepted to work with seating systems. They may also be intercepted in the location of your public teleport pattern to encourage people to move inside the establishment. (See the Fox Plaza teleport booth for an example.)
• rules, map - These may be replaced entirely. Rules must still print your area's rules.
• whospecies (ws), whodoing (wd) - These may be replaced by programs that provide the same functionality. It is required they list everyone in the room. This is commonly done to add a "role" or "position" column. NOTE: This will eventually be supported in the base command and this may change at that time.
• WhereAre (wa) - This is just an alias for LC and may be overridden. Commonly this is done to provide a local listing of who is in what public rooms.
• other - You must seek wizard approval for any other globals you wish to override.

Descriptions

Descriptions should be spell checked, and use reasonable English grammar. If you have difficulty with English, please enlist software or a friend to help you here.

They should also be kept to a reasonable length when possible.

• Important Rooms: 1000-2000 characters (half to a full 80x24 screen)
• Minor Connecting Rooms: about 500 characters (1/4 of a full 80x24 screen)

If you have more detail than can fit on a single page, try using "details". Mention the names of the details in your description surrounded by []. Such as "There is a [desk] here."

Obvious Exits

Obvious exits should be displayed unless there is a very good reason not to (such as a puzzle, for example.) The standard way is with the obvious exits program. You can use the program simply with "@succ here=@9". You can find out more in gen-obv-exits' documentation.

Parent Rooms

Public Building Zones must be contained in one Parent Room. However it is advisable to use sub parent rooms for most of your actual building. You should have a 'public' and 'private' parent room under your main one to contain areas that are public to your establishment, and the other for your personal rooms, and any apartments, etc. This is done so that the Location Count (lc) program can be tied to the public parent, thus not listing people that are not anywhere to be seen in your establishment. It is also useful for setting up autosweep not to affect people's homes.

Other Responsibilities of the Owner

Furthermore, the Owner (also referred to as the Administrator) of the Public area has a responsibility to maintain a good atmosphere within their facility. If this begins sounding more like a chore than something fun to do, you may wish to reevaluate the desire to build a public place on Tapestries MUCK. It is a lot of work, and has limited rewards, which mostly come as personal satisfaction from doing something for other people.

Building Application Process

The building application process is now setup to facilitate public and wizard review. The area must both show public support for it's goals, and be deemed to meet the goals stated in the requirements by the wizards to be approved for building.

Building applications will be managed through a program inside of the Muck.

Application Steps

1. Submit an Application. The application will contain the following elements:
   • Name of Establishment
   • Mission Statement - Short one-paragraph statement of the goals of the area.
   • Rules - Complete set of rules that the area will use at launch.
   • Overview of Building - Description of the layout and feel of the area.
   • Staff - List of the staff you will start with and their roles.
   • Lot Number and directions - Give the lot number that you desire to build on, and directions to get there so potential supporters can go look to see if it fits the area.
2. Obtain Public Support.
   • You must get ten (10) people to sponsor your project. These people may not be your staff. A person is defined as a separate human being, not character. This will be checked in the review process.
   • Advertising of your area must not be spammy or intrusive. On the on-line forums, it is limited to a posting in Building Applications. On in-game bulletin boards it should be limited to a single post, and only on boards where it would not be out of place. Please read the individual board's guidelines to see if they are excluded. Making public announcements in rooms, dropping signs in areas with out the area owner's permission, or starting contrived discussions about the area are all considered intrusive and disruptive to the Muck.
3. Wizard Approval - At this point it will enter a queue to be reviewed by the wizards. The wizards may request changes to the application, may request changes to the application or reject it outright. If the changes are serious enough, you may need to re-obtain public support. The things a wizard will look for:
   • Does the area fit within the Mission of the Muck?
   • Is the area accessible to all members of the Muck?
   • Does the area provide something unique and/or needed my the Muck?
   • Are the rules consistent with the rules of the Muck?
   • Is the theme of the area fitting to the location selected?
   • Does the owner have a past history of problems?
   • Does the proposed staff have a past history of problems?

   Applications will be evaluated by the wizards for how much benefit they offer to the Muck, and will be processed in that order.

4. Building - Once approved by the wizards, your are given access to an area to begin building in. Building should take no more than one month to complete. There will be a limit to the number of building projects under construction at one time. All other projects will be held in the waiting wizard approval queue.
5. Final Wizard Review - The area will again be reviewed by the wizards once it is complete. Building practices will be evaluated, and the rules will be rechecked.
6. Area Open - The area is allowed to open to the public.

Currently the building application system is implemented within the Tapestries MUCK Forums. See the Public Building forum as a starting point.

Property Transfer

Public Building may be transfered to another character. This transfer must be approved by the wizards. Wizard approval includes a background check on the new zone owner to see if the are considered able to run a public area.

There are two methods of actually accomplishing the transfer:

• Manual @chown - Once the transfer is approved, the two people can work out manually @chowning the property from one to the other.
• @toad Transfer - Optionally, the source user may opt to be @toaded and have all their property moved by this way to the other user.

Hopefully we will come up with a more gracefully way to accomplish this in the future.