Wizards, Creators and Code -------------------------- The following are notes about the politics, rules and regulations of being a creator. I've found is nescesary over the years to make this information public, so everyone knows the rules under which Heaven7 runs, as from August, 1995, from salvation.com [CONTENTS] 1.00 INTRODUCTION. ============ 2.00 CREATOR LEVELS. ============== 2.01 Security and Levels 2.02 Where do I begin? 2.03 Promotion 2.04 Quality Control. 3.00 PROGRAMMING & THEMES. ==================== 3.01 Code and You 3.02 Domains and Variant Themes. 4.00 LEGALITIES & MUD POLICY. ======================= 4.01 Copy Right. Who Owns My Code? 4.02 Do's and Don'ts. 6.00 CONCLUSIONS. =========== 1.00 INTRODUCTION. ================= Being a creator is not a right, it is a privilege. It means hard work, and a constant craving to code, and improve upon not only his/her own coding ability, but improve upon the mudlib as a whole for players. Without players, we do not have a mud. Remember that it is for players that you are coding. So when you code, think like a player as to what you would like to see, what you would like to be able to do in a room, with an item, or with a suggested action. Then, balance that out with what you know is allowable by the administration. Here, at Heaven7, you are also coding for the whole world. Heaven7 is available from public domain, so anyone can access it and use it. For this reason, a high quality of code is expected from all creators. Take pride in your work, and do the very best you can. That's all the administration can every expect from you. 2.00 CREATOR LEVELS. =================== 2.01 Security and Levels ======================== Table 1: Structuring Title Security Access Level --------------------------------------------- ASPIRANT 10 APPRENTICE 20 CREATOR 30 SAGE 40 LORD 50 SENIOR 60 ELDER 70 ARCH 80 ADMIN 90 -------------------------------------------- The security system is set up such that it gives creators access to those files which fit his job description. If you don't have access to a file, then don't worry, it's most likely because you don't even need to worry about it. Those files which you don't have access to will usually appear as a '?????'. An access.c object is placed in each creators home directory (i.e. /players/name directory). This can be changed to give other creators access to your files or directories. Either valid read, or valid write access can be altered in this way. Each creator also has a '/private' directory. Here, a creator can place his toys, special (private *wink*) objects, which he uses himself. Items which players use are NOT to be placed in this directory. Creators found with illegal items here will have their creatorship terminated. Creators attempting to subvert the security system will have their creatorships immediately terminated. 2.02 Where do I begin? ===================== All creartors begin at ASPIRANT. At this level you are required to read the documents outlining the do's and don't of coding and player interaction. A week is given to do this, no less. To proceed to the next level title is a contract to work and code for the mud. Failure to do so means removal into the player population. After this time you may choose a DOMAIN, or, to work on part of the existing MUDLIB which exists apart from the domain structure. In any case, a workroom an access file, and a directory will be given to you. At this time you will be promoted to an APPRENTICE. Some helpful abilities are granted to you at this stage to allow you to help in debugging your items. 2.03 Promotion ============== All creators loved to be rewarded for their coding efforts. The following are the criterion for promotion to a higher status within the muds heirarchy. We all have to start off coding rooms, monsters, and armour, proving we are capable of programming, and working as a team. To be granted promotion you must meet the following criterion and have it approved by an ARCH. Promotion can be granted within DOMAIN work, but still must be approved an ARCH creator. Coding Wizards: -------------- CREATORS. A promotion to CREATOR is given when a QC (explained later) approves a creators first area, placing it into player access. SAGES. A promotion to SAGE is only done on request. To be promoted to SAGE within a DOMAIN framework you must do the following - 1) He/she must show his/her understanding of LPC through written examples, which are shown to the LORD of the DOMAIN. 2) He/she must have a complete understanding of the documents which outline the restrictions placed on items of code such as weapons, armour, rooms, and other items. 3) A written request must be made to the LORD, with carbon copies (cc) going to all creators greater than (and including) ARCH. This can either be done through mail, or by a written file (with mail indicating the files' name). The LORD then will decide upon the promotion, and notify the ARCH+ of his decision. Those Creators who work outside the DOMAIN structure can be granted promotion in the same manner, but instead must notify creators of ARCH+. LORDS. As a LORD is the owner of a DOMAIN, promotion to this level is only done if there is room (memory wise) to open a new large area with a new theme. Promotion to this security level is only done if the creator can show the following - 1) That he meets the requirements of the SAGE promotion. 2) That he can assure a completion of a small amount of the DOMAIN (enough to assure that it grants visiting players an idea and feel for the new domain) will be completed within 1 month. 3) That he has 3 more creators who are willing to work on his team. These creators can not be currently working on any other project, or domain. LORD positions are granted by ADMIN only. A petitioning LORD must mail the ADMIN in the same way a SAGE does. Administration Positions: ------------------------ Administration positions can only be granted by the ADMIN. Mail regarding a wish for promotion hence must be given detailing the following: SENIORS. A SENIOR creator must meet the requirements of SAGE as well as: 1) Have shown consistent and working knowledge of LPC beyond that of normal CREATORS. 2) Have a complete understanding of the files contained in the manuals for monster, armour, and weapons. 3) Be able, and willing to help ALL CREATORS of any security level with their problems with coding. ELDERS. A creator who wishes to become an ELDER must meet the requiements of SENIOR, and have done so for a period of no less than 2 months. As with all other promotions a petition must go to the ADMIN outlining the reasons for the wish to be promoted. ARCH. An ARCH is one of the highest security levels to attain to. The aspiring creator must have an extensive knowledge of LPC, and the MUDLIB and its workings. He must be able to understand everything from error tracing on a mud wide scale, to strict types in LPC, to being able to help with code as SENIORs do. This level is never able to be petitioned for, but is granted ONLY by ADMIN. ADMIN. Those who show wisdom on mud matters, with players, creators, and the mudlib, are granted this security access. Only on special occasions is this level granted. No creator can ask for this level. QC. QUALIY CONTROL. Quality Control Officers form an important part of the mud and its running. All areas are subject to the approval of a QC. Promotion to QC is given by the highest security QC, or by ADMIN. There is normally one QC per DOMAIN, usually a SAGE, petitioned by a LORD (on the SAGEs behalf), and approved by the head QC. On occasions it is necessary to temporarily promote creators during a crisis, or if someone plans to go on holidays/is doing exams/etc/ and needs someone to fill his place, etc. Sometimes, promotion is performed by ADMIN to extend powers to a creator to perform special tasks or functions within the mudlib. Promotion may be given on rare occasions to those who show a particular 'keenness' towards certain aspects of the mud, even though they may not fulfil the requirements of the level. For some people, this is the best way for them to learn. 2.03 Quality Control. ===================== Qualty Control measures for coding are listed in the manual QC. QC are simply responsible for the greatest duty on the mud; putting areas into player access. Hence, the ruling of a QC is final. If an item is illegal, incorrectly coded, or not to the specifications required by the ADMIN, then they have the followingn rights: 1) If the item is not available to players, then they will notify the creator who coded the item, asking them to fix it. 2) Since a QC will approve an area, the main reason an item may be found to be 'illegal' is that it was altered AFTER implimentation. Hence, a QC has the right to change such items without the creators permission. He will, however, notify the creator concerned of the problem, and what was done to rectify this. 3) If code has major problems such that it is not readily fixable by a QC, then a QC may close all entrances into the area, without notice, and will then mail the creator involved, out lining the problem with the area. Only when a QC has re-approved the area in question can it be re- attached to player access. 4) ELDER, ARCH, and ADMIN also have the same rights as QC with respect to the above situations. Each DOMAIN also has a QC, who approves areas within the DOMAIN. A QC can be selected by a LORD, but only granted QC status by either the head QC, or by ADMIN. Since a QC is charged with the responsibility of checking whole areas, and placing it into player access, a QC must have knowledge of the manuals regarding monster, armour, weapon, and room requirements. Knowledge of code is not nescesarily needed, but is handy. If items in an area are constantly over looked by a QC, then this forms ground for his removal from this position. 3.00 PROGRAMMING & THEMES. ==================== 3.01 Code and You ----------------- A creator is welcome to code anything in his player directory, as long as it does not attempt to bypass his allowable privileges granted to him by his current security access. Those who attempt to are have their player file removed immediately. Some creators wish to code items for players as a part of the main theme of the mudlib, which is a typically AD&D-like in its atmosphere. All creators code is an 'addition' to existing code. It must fit in with its surroundings, and must be both aesthetically pleasing as well as to 'play' with. Simply deciding that you wish to code a McDonalds when there has been no provision made for future/modern themes will not be tolerated, or approved. You must have an idea of what you wish to code, and where it would look the best. Only those who meet the requirements of LORD may open up new themes and areas of his own design (see above section PROMOTION) 3.02 Domains and Variant Themes. ------------------------------- The mudlib contains different themes, embraced in what is known as domains. These are concepts different from the main mudlib, where fantasy and medieval tradition from europe evolve, or from any other theme expressed in other domains. To code in one you should simply ask the LORD who controls the domain. You are then required to code under his/her supervision, and under the guidelines set out by him/her. The code that you supply this person must be the same in style, and theme, as the surrounding code. 4.00 LEGALITIES & MUD POLICY. ======================= 4.01 Copy Right. Who Owns My Code? ---------------------------------- The mud driver code, and related code, comes under FSF's, and Lars Penji's copy right. Since the code comes under Public Domain, its impossible to say its copy righted. The basic idea is that this mudlib has been developed in a different direction to other mudlibs like Mudos, TMI, Nightmare. The mudlib has been developed to work in Compat Mode on the amylaar, 3.1.2, OK312-MSDOS Drivers. It is still under development, as such it is available for release as are the above mentioned Mudlibs. Since all creators and administration are coding for public domain and mudlib release there are no copy right privledges retained by the creators. A problem that has arisen before, is that some creators for some reason or another decide to leave, but consider on-line code as their right to remove. This is not so. The creator has control how they want their code distributed throughout the mud. Basic control of who may or may not see it. But once it is placed and used as part of the mud, it should stay there. This will stop unsavory reverberations occuring, on the creators leaving. Code Stealing is a NO!! If you are going to use someones code (especially from other muds), ask them. Put an appropriate thank you in it (where its from), and everyone is happy. If they don't want you to use it, then bad luck....you will have to code it yourself. The general policy is to let people to see, and use you code. This is so people can learn how to code, and how to code better. Since it is possible that anyone in the world may eventually see your code, it should be neat and tidy. Commented on the tricky bits. It should be a real show piece. Creators still retain the right to refuse the copy of their code by other creators, but does not retain the right to have their code excluded from being seen by those who have been given the access to view it. One directory has been set aside to keep items in where no one but yourself, the ADMIN and QC, can read it. Items here are for your own personal use, and as long as they don't interfere with the mudlib. This directory is a ~private dir off your root dir. It is your responsibility to keep copies of your code for your own personal use. If, for some reason, the code is lost, removed, or the mud shuts down and you have lost access to your files, then the ADMIN is under no obligation to send it to you, or recover your files. 4.02 Do's and Don'ts. -------------------- Do's and Don'ts can be found in the dosanddonts manual for creators. It contains a comprehensive list of creator ethics, what you can and can't do. Check this manual for those details. 6.00 CONCLUSIONS. ================ It is in your best interests to know what is contained here within this file as this outlines many important aspects of the access/security within the mud, and how you fit into it as a creator. If anything herein is unclear, or you wish to discuss items of uncertainty, please see an ADMIN or ARCH creator. (c) Angel, August 1995.