Builder Rules
These rules are requirements for anything being built. They must be satisfied before the zone will be put in game. Please do not ask for an audit before reviewing this list and ensuring your zone meets these standards.
Become a Builder
This is covered in the Become a Builder section. In short, you need to show that you can write high quality, descriptive rooms, mobs and objects. If you have no representative sample, you can be set up as a test builder and make something small in the test zone to show your writing skills.
Zone Approval
Prior to building a zone, it must be approved by Jaeger, the head builder. No exceptions, as Jaeger will have to create a zone before you can start anything anyways. Before a zone will be created, the following criteria must be met satisfactorily (according to the judgment of the head builder):
- A written document detailing the zone's purpose, it's layout, its target audience (mid-level player hunting, darkling race, etc.) and any pertinent history relating to the zone already in game.
- Some form of map (be it text, grid, or drawing) of the room layout of the zone, and the number of rooms necessary for the zone.
- A written document with the zone's quests, its higher-level mobs and objects, and any special rooms (i.e. ones with non-Euclidean geometry, or traps, or puzzles).
This zone proposal process is extensive because it's too easy to come up with a great idea for a zone but get stuck with a mediocre zone in the end because of poor planning. Also, if design considerations are approved ahead of time in the zone proposal, those do not need to be negotiated at a later point. This avoids already-built parts of a zone needing to be rewritten or removed before the zone is put in game.
Rules of Room Creation
Descriptions
This section applies to all descriptions - rooms, mobs, and objects, and even emotes and rechos in mob/object/room scripts. Descriptions must be well-written without spelling mistakes in grammatically correct English. Descriptions should be in full (non-run on) sentences. And they should follow these rules:
- Do not use the word "you" to describe the feelings or revelations of the player. Your description should encourage that emotion/realization in the player, not just say that it has happened (i.e. show, don't tell).
- Do not write in dynamic aspects like weather, time, season, etc. unless it is something consistent. For instance, a wind may always blow down the tunnel because that's the way the air flows in that region, but do not write a zone that describes the setting sun.
- Do not write sentences into the room description that will do better as objects or mobs in and of themselves. If your room describes a bed in any detail, it is better to have a bed sitting in the room. Things like architectural features should stay in the room description.
Titles
Titles should be in title case with a leading article unless it is a named room, and it should have no punctuation. Some examples: "Garland Temple", "A Storage Room", or "A Closet in the Wall".
Layout
Rooms are expected to be correct in Euclidean geometry - i.e. distances between rooms in the same region should be the same, and there shouldn't be inexplicable curving of paths that don't match the actual geography of the rooms.
Scripts
With very few exceptions, there should be no deathtraps, or rooms without exits.
Rules of Mob Creation
Descriptions
Mob descriptions should follow the rules of room descriptions.
Scripts
Rules of Object Creation
Descriptions
Object descriptions should follow the rules of room descriptions.
Scripts
Zone Audits
After a zone has been completely built on the development port, the builder requests a zone audit from the head builder. She will examine the zone carefully, using the standards above, in addition to the zone proposals and other documents the builder has submitted regarding the zone. The builder should be available (through email is acceptable) to answer questions about the zone, and describe the reasoning for any unclear aspects. At the end of the audit, the head builder will have a list of any changes that need to be made, as well as optional changes. When the builder completes the necessary fixes and any other fixes, the head builder will do another audit. The proces will continue until both the builder and the head builder agree on the quality of the zone, and the zone will be putin game.
Zone Maintenance
For any and all zones a builder gets into the game, the builder is expected to respond in a timely manner to request to fix or improve the zone. All typos, bugs, and mistakes found in the zone must be fixed by the builder responsible for the zone.
Intellectual Property
ScryMUD respects the intellectual property of its builders and players. During the design phase, before any zone has been created in game or on the development port, if a builder wants to withdraw consideration of the zone, he may. All drawings and descriptions authored by him will no longer be used, and ideas which are clearly his will not be used. Co-authored zones will be considered on a case-by-case basis.
As soon as the builder actually builds any zone or part of a zone in ScryMUD's online creation, that zone is the property of Scry. Requests to remove the zone will be considered, but it is no longer the say of the builder who created them. The rationale behind this is that once content is built, it is in the Scry system, and must be maintained by both the coders and the builders should anything cause a problem. Also, tt is not acceptable for obvious reasons to remove existing zones from the game world.
