Before setting up the MOO itself, you should plan ahead.
There are some things you should clear up before
starting. Numerous MOOs have been started and simply allowed to
develop haphazardly, resulting in un-thematic and uncontrolled growth.
Themes generally provide a metaphoric structure for development
and often reflect the purpose of the MOO. A given thematic structure
also helps to focus development in such a way that "teams" or "project
players" can development MOO resources wisely, rationing
valuable DB. So you want to set a theme and/or make guidelines for a
few things before starting the MOO.
As stated above, purpose is closely related to the theme or themes of the
MOO and should be the guiding principle of development. For example,
Connections
is a MOO where teachers can bring their classes;
MediaMOO
is a professional conferencing MOO;
DaedalusMOO
supports teachers using DIWE; and MOOs such as Diversity University,
and LinguaMOO
are primarily MOOs dedicated to educational research and development;
there are also other social/educational combinations such as
AussieMOO,
DaMOO, and
MOOtiny.
While many of these purposes overlap, each MOO has its own communities
tied to an overarching purpose.
So get the purpose down on paper as a set of guidelines, outlining and brainstorming
what the MOO is for, what's allowed and not allowed, and any other parameters
you can think of at this point. The more clearly you define the
purpose of the MOO, the more clearly the themes are set up and defined,
the clearer you will be on your server needs as DB growth is closely
related to purpose and theme.
A central theme should be announced and clearly explained in the main
hub
or welcome room of the MOO. For instance, a country
farm house, a kindergarten, a Boeing 747, might or might not fit into
the overall theme of the MOO depending on the central theme. If there
is a building plan, that should also be made clear from the outset as
the central theme may, once again, affect how areas are to be set up
and developed, how rooms are to be connected, and even what types of
rooms may go where. This will ensure that the MOO's structure is
built according to the guidelines, and you will then get
a coherent MOO with a plausible topology.
This will put some limitations on what players can build, but if the theme
is broad enough, others ought to be able to discover ways to develop their
topics or specialized areas of interest.
An example would be a space model, where different sub-themes can be developed
as different planets. All planets
could be linked together with a space shuttle or a teleportation system.
Clearly, caravans or camels would not be thematic in this context.
Yet, a given planet "area" could support desert rooms which in turn
could logically use camels for transport.
You might want to restrict the use of the MOO for some people, or just
want people from some special place or field. This really should be determined ahead of time. Perhaps you want only educational people, or people from some
science degree or some other field. Sometimes restrictions on who can use the MOO is largely determined by the limits of your equipment. If you must limit the size of the data base, limiting player access is a relatively simple way to
keep
the MOO at a reasonably small size with the additional factor of usually
ensuring that the MOO is used for its intended purpose. The MOO can also be restricted so that only idividuals from your local net have the permission to connect.
A MOO has a set of wizards
who have access to any field in the MOO.
They are the ones who run it and maintain it. They fix the errors
that may come up and keep it running. But to administer a MOO you
don't have to have wizards doing all the work. You can use other
players as well by providing their characters with the ability to perform the tasks needed. For instance, admins may need to make sure everybody plays by the
rules; they may need to protect players from harassment; they may need to provide different types of help for
players as well as working behind the scenes with administrative tasks such as quota review.
However, even if you opt for an admin class, you will still need some
wizards who can fix all the different things
in the MOO that can break such as code and values,
and who also can program or port new verbs or objects needed for the MOO to
fulfill its purpose.
Make sure some of the wizards know how to run the MOOserver.
You will need some experienced wizards who know what to do
and how to fix things easily. Pick some who have been wizards at
other places. You may also want to have a few new wizards, people
without wizardly experience who can be taught how to do things and
can learn under the
watchful eyes of the more experienced wizards. The number of
wizards/administrators you need on a MOO depends on how much time each of them
can commit to, how big the MOO is/will get, how fast the MOO will
develop and so on. Start out with a reasonably small amount of wizards,
four to eight, and add more if you feel the need for more help, that is,
if the wizards feel they can't accomplish all the tasks they should do.
Choose your wizards and other administrators
wisely. Make sure you have confidence that they will not do
anything to harm the MOO on purpose.
Back to the implementation index.