-=[ The Levels and Life of a Creator ]=-
1.01 Introduction
Being a creator is not all it is cracked up to be. 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.
2.01 Promotion.
There are many things you can do for the mudlib, and many areas you can
work in. But we all have to start at the bottom, and work our way through
the hierarchy. No one can simply start at ADMIN (accepts the MUDLIBs creators).
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 atleast 2 ARCHs or an ADMIN.
Promotion can be granted within DOMAIN work, but still must be approved
by 2 ARCHs or one ADMIN creator.
CREATORS.
If you are working within a DOMAIN structure PROMOTION may be granted for
well coded items, competent coding, and HARD WORK. CREATORS may advance
in this manner up to security access of 29.
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 the ADMIN. This can either be done through mail, or by a
written file (with mail indicating the files' name)
Those Creators who work outside the DOMAIN structure can be granted promotion
in the same manner, but instead must notify the ADMIN solely.
Promotion within SAGE is based on the same outline as promotion within
CREATOR; hard work and a continual showing of competent coding.
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.
In the same way that an upcomming SAGE notifies the ADMIN, so does an
upcomming LORD.
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 /doc/guidelines
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 requirements of SENIOR,
and have done so for a period of no less than 3 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.
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.
Advancement is always possible for hard work between the minimum and
maximum levels of your current title. Such is usually granted, although
sometimes your ADMINs need reminding about your progress. It is your LORD
and SENIOR/ELDERs job to remind them of these things.
2.03 Structuring.
Title Security Access Level
---------------------------------------------
ASPIRANT 10
APPRENTICE 20
CREATOR 30
SAGE 40
LORD 50
SENIOR 60
ELDER 70
ARCH 80
ADMIN 90
--------------------------------------------
ADMIN usually run most of the mudlib on its entirety. Reviewing the code,
and updating it so it works more efficiently for players as well as
creators. The ADMIN have the final say in everything, make mud policy,
and generally run the mud, making it run smoothly. All code that is to
go into 'creator usage' is subject to approval by the ADMIN before it
is included in the global MUDlib.
If you have something to include into the global mudlib that will affect
important items (player.c living.c master.c base_obj.c etc) then it is
important to inform ADMIN before you include it. Sometimes new versions
of these files are being coded, and your additions will be forgotten, and
not included in the replacement. Sometimes the copy you have of the file
involved will be an old copy which will not have important new functions.
Because of these reasons, it is imperative that you notify the ADMIN in
writing, and seek approval BEFORE you place your new code in.
ARCH, ELDERS and SENIORS have specific duties within the global mudlib.
An ARCH usually overseas all these duties and aids the ADMIN in fixing
and altering code on a global level. An ELDER and SENIORs primary job
is that of QC, working under a knowledgable ELDER. Other ELDERs and SENIORs
jobs include -
1) Working on differing systems applying to players, such as spells,
quest systems, party objects, etc.
2) Working on differing systems applying to creators, such as new
ways of making files, new ways to approach LPC coding.
All code that goes into 'player use' is subject to approval to an ELDER,
even if an ARCH, or ADMIN codes it. He may alter it himself if it is not
according to guidelines, without the approval of the coder involved, or
if it is a particularly involved problem, mail the creator, informing
him of its problems, and comment the item out of play.
A LORD is simply in charge of all that goes on within a DOMAIN. He is
responsible for all the code therein. Although he has no power to approve
an item/area into player usage, he controls all code within. He may appoint
a SAGE to the QC team, promote, demote, discipline creators as he sees fit,
as long as he abides by the guidelines set out here.
A SAGE is a LORDs 'right hand man', often responsible for a SENIORs job
within the mudlib, performing QC work therein. His job within a domain
is dictated by the LORD that promoted him. His work outside a domain is
simply a form of reward for work well done.
Each new security access title is still made by the promotion details
outlined above.
2.04 Where do I 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.
From here, dependant upon your coding ability, and contributions to the
mudlib, you may enquire about promotions (see above section 2.01)
2.05 Quality Control.
An ELDER heads the team of creators who check areas constantly, helping
out all creators with their coding, and approving code so that it may be
used by players in the mudlib, either domain or otherwise.
One SAGE from each domain is represented here. He/she is the one who is
granted access to all domain files (within his domain only) to check them
for incorrect coding practices, illegal items (monsters/armour/weapons/etc),
and to make sure the domain's code is up to standard. Once a SAGE has ok'd
an area, he must have an ELDER approve it.
SENIORS are those creators who approve and keep watch over the general
code of the mud produced by all creators, hence they have read access to
all /players/<name> 's files accept those within a ~private directory. He
has the job similar to a QC SAGE, as well as that of aiding other creators
whenever they need it, with their coding.
When any area is ready to be opened to the public, it must be checked by
a creator of no less security access than an ELDER. No code is to enter into
the hands of the general playing populace without his/her approval.
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.
Here, magic and might rule. Mages, however, have devised a way to travel
to other places in time and space via the aid of powerful beings from the
elemental plane of time itself. This is how inter-domain travel works.
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 2.01).
Anyone is welcome to add files to the main mudlib theme. This is simply
done through your own player directories. The adding of such code is still,
however, approved only by an ELDERs, although SENIORS can always help with
the code, and reminding you what you can/can't/should/shouldn't code.
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.01 Copy Right. Who Owns My Code?
Some comments removed.......
Note: Zilanthius - I don't think words 'copy right' is the right?
The mud driver code - and related code comes under
FSF's, and Lars Penji, and so on. And 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 not for release as are the above mentioned Mudlibs.
Most of the mudlib is counted as closed, and not for
general distribution. Though, I have made a limited
release of a DOS version to Elders, and above.
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 people are going to see your code, it should
be neat and tidy. Commented on the tricky bits.
It should be a real show piece.
.......comments continued
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, and the ADMIN, can read it. Items here are for your
own personal use, and as long as they don't interfere with the mudlib
retain their copy right (?? Zil) to you. 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.
5.01 Do's and Don'ts.
As a creator you are expected to code. If you fail to do so within a
month of being granted your creatorship, then you will be placed back
into the player populace at the approximate level you entered left it.
Your code should stick roughly to the guidelines set out by the ADMIN.
If it does not, then it will not be allowed to be used by players.
ELDERs approve code. Code must be approved by them before it is allowed
to go into use by players.
You are expected to involve yourself with players. Talk to them, watch
them fight. Enquire about their skills and spells. Even have a beer with
them once in a while. You are not allowed to alter anything within the
players skills, levels, abilities, weapons, armour, killing or playing
abilities (which includes titles, alignments, etc). Anyone found doing
this will be instantly placed into the player populace.
You should not divulge information about the strengths of monsters, or
other items (such as weapons, armour, etc), or information about quests,
or special areas of players play, as players have their own way of
gathering such information about these things. You may, however, if someone
asks you about it, give a 'vague' idea perhaps.
> Rincewind asks: How much is my ac?
> stat rincewind
> Rincewind the Utter Newbie (Lawful Good)
Wc: 3, Ac: 1, ...etc
> Angel says: It could be better
> Rincewind wears platemail
> Rincewind asks: How about now?
> Angel says: Much better Rincewind
Angel knows that wearing platemail means he is better protected, without
even using a stat. He could have said 'better than before', or tell him
something he would/should know himself like 'you still don't have much
armour on. perhaps you could do better with more?'
You should not use your privileges to annoy players or creators. Nor
should you use them to invade their privacy. If someone wants to be
left alone, then leave them alone.
Test characters are always helpful. But he should never be allowed to be
a higher level than other players currently playing, nor should he be used
by anyone else but yourself. If you ask other players to help you test
your code you may not alter their stats, or current playing abilities.
You may heal them before and after. They may not, however, take unapproved
items into the general mudlib. They may keep any exp granted to them by
the test. If you accidentally kill them, then fix their stats, and exp, if
you can, and mail an ELDER or ADMIN about it. If you can't fix it, ask
someone who can.
If you 'dest' someone accidentally, and their equipment disappears then please
see to it that a higher security level creator sees to this problem. If
there are none, then see that the player receives most of the items back.
If you think that the items are excessive for the player then explain that
the item is rare and that you cannot give it to him/her. He will have to
'quest' and 'search' for it again.
Money problems are always a nightmare. Never give a player back money that
he has apparently lost. Explain that this is simply not mud policy to do so.
6.01 Conclusion.
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, December 1993. All Rights Reserved.