Planning the MOO: Know your breed of MOO

Policy decisions

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.

Players/restricting access

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.

Choosing Wizards/Administrators

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.