From the NannyMUD documentation
2000-12-16
NAME
guild development guidelines -DESCRIPTION
This document will attempt to outline a set of steps common to any guild development and what you as developer need to do in each step. This document is not intended as a de facto standard that has to be followed religiously, but doing so will make life easier for you and the guild coordinator. DEFINITIONS GM = Guild Master (responsible for running the guild) GC = Guild Coordinator (member of the admin) 1. Concept phase You have an idea about a guild. This is a good time to write down your ideas and the basic theme of the guild and notify the GC that you would like an opinion about them. Be prepared to describe how you think the guild will fit in NannyMUD. The possible outcomes of the concept phase is that either the idea has been rejected due to conflicts between existing guilds or some other reason, or that the idea is accepted for further exploration. Keep in mind that you do not need to be an experienced coder to complete this stage. 2. Initial design You should now write a preliminary guild document using the generic guild document as template. Using this template is very important to make the document informative and easy to read. At this point you need to decide on a GM to implement and maintain the guild when it is open. This wizard can be you (if you have sufficient technical knowledge to complete the task) or someone else that agrees to take on the job. When creating the preliminary guild document it is not important to have exact numbers for all aspects of the guild, a rough estimate is sufficient. The developing team must be able to work together as well as with the administration. Some guilds tend to stomp at this stage due to disagreements within the team. The results of the initial design is a preliminary guild document and the setup of the guild development team. The GC approves (or disapproves) the GM as head of the guild and the preliminary guild documentation. 3. Detailed design You will be given a guild directory to work in. At this point the GM should be well aware of the guild design standards that has to be followed. The guild document will be completed and experimental implementations can be made to find close approximations to guild figures. You should also create a board named "GUILDNAME_GH" with read/write access for all involved guild developers and the MUD administration. This board serves as the main communications medium between the administration and the developers. If you run into technical problems you can always ask the GC directly, post questions on your own GH board or talk to any other experienced wizard. The results of the detailed design are a formal guild document and a fully implemented guild code. The document will after modifications with respect to guild balance be approved (or disapproved) by the GC, and the guild code will be closely inspected with possible changes needed to ensure quality and compliance with the design standards. 4. Testing The guild needs to be tested by playing it, and stretching it to the limits. For this task you need to select a minimum of 3 and a maximum of 5 players to test your guild. These testplayers need to be dedicated to perform the testing and need to spend quite alot of time playing it. The three required testplayers need to be from these three categories: * A player that is rather new to the MUD, and probably hasn't passed level 10 with his/her character. * A player that has spent some time on the MUD and knows a little bit about how it works. This player probably hasn't passed level 17 with his/her character. * An experienced player. Either a wizard secondchar, level 19 mortal or a paragon is suitable for this task. You create testcharacters and give the names and passwords to the testplayers. The testcharacters also need to be registered as testchars for the guild (the GC can assist you with that). The above 3 players should play the guild from start to finish or as long as they possibly can reach until the testing period is complete. The time of the testing period depends on the level of confidence the developers and the GC has in that the guild is stable enough for opening. The problem in this phase is to find suitable testplayers who are willing to spend several days of full playing time on evaluating the guild. It is somewhat important for the testplayers to actually solve quests in order to advance levels because it gives good feedback on how the guild works. If this becomes too time-consuming, levels may be patched. As a general rule here, the guild will (after all testing is done) be opened with slightly less powerful abilities for an observation period of a few months. It's normally easier on everybody to upgrade a guild if it was deemed too weak than to downgrade a guild that was too strong. You may also want to add 1-2 testplayers who has great experience with the game and let them try out the guild at mid-level or max-level. Additionally, testing of PK is required (if the guild is powerful enough to compete in the PK scene) but should be done at a later stage of testing and between testcharacters of different guilds in a closed (simulated) playground. The results of the testing phase is a stable guild code. The GC will approve (or disapprove) the guild from opening to the public. You should also have your guild WWW page ready at this stage. 5. Open guild Once your guild is open to the public, lots of players will join. Now you will see how effective your testing really was, because quite a few undiscovered bugs will be discovered. You will also see that players find ways of using the guild powers in ways you never dreamed of. When a few players have reached the top, it's not uncommon that some aspects of the guild needs rebalancing when the true impact on the game has been observed for a while.