Setting Up the Database (cont't):

Using the Realms Wizard System:

Realms Wizards are players who have extended control over objects within a certain area of the MUCK... that is, in rooms parented to a common environment room. There are advantages and disadvantages to the realms wizards system, discussed below. Whether you are going to use the system is not something you must decide immediately, but if you are going to use realms wizards, there a few advantages to doing so from the outset.

In order to use the realms wizards system, the system parameter realms_control must be tuned to `yes'. The effect is to give the owners of rooms set Wizard extended control over objects in that room, and over objects in rooms parented to that room. A realm wizard can examine, set properties on, and link objects within his realm as though he owns them. He cannot chown objects belonging to others, unless the objects are set Chown_OK, and he can only force objects that are set xForcible and force locked to him, but — since he can @force_lock and set flags on objects in the realm — he can essentially chown and force anything in the realm as well. He can @teleport anywhere within the realm, just as a wizard can.

There are decided advantages to making your staff builders realms wizards. The extended control is a genuine help as they construct the area, and their realm wizard status may well be a motivating factor: they are lord in their realms, but that will only be meaningful if people use the areas, so they have good reason to make the areas as well constructed and attractive as possible. Once the area is built, they will be able to help players with matters such as linking homes. Also, making staff builders realms wizards rather than wizards avoids the problem of having several surplus wizards once the world is constructed.

The one significant disadvantage — or at least consideration — is security. Wizards have virtually unlimited control over the database, but they also have built-in accountability: all wizard commands are logged, regardless of whether log_commands is tuned to `yes' or `no'. Within their realms, realms wizards have comparable control, but their commands are not automatically logged. A clever and malicious realms wizard could set locks and flags on a true wizard who enters his area, and use these to directly or indirectly force the true wizard to do something destructive or harmful elsewhere. If (im)properly handled, the properties could erase themselves once they have done their job, leaving no evidence, and the logs would show the true wizard as the guilty party. The only real safeguard is the same safeguard provided against true wizards: accountability. If you want to use the realms wizard system, turn on command logging.

The realms wizard system works best if you set up a consistent, geographically structured environment tree. This is much easier if done when the MUCK is new. The following schematic shows how a science fiction MUCK might be set up to use realms wizards. Rooms `Starport Env. Room' and `Earth Env. Room' would be chowned to staff builders, and set Wizard. These players who own these two rooms would then have primary responsibility for and control over those two areas. Additional areas could be parented to IC Environment Room, and the two realms control rooms could also include environment rooms, perhaps with other players holding realms wizard control over those smaller areas.

                            Room #0
                               |
                     Main Environment Room
                     |                    |
            IC Environment Room    OOC Environment Room
              |              |                |
   Starport Env. Room      Earth Env. Room    |_ Guest Room
              |              |                |_ Player Start
              |_ Some room   |_ Some room     |_ Staff Offices
              |_ Some room   |_ Some room     |_ Help Room
              |_ Some room   |_ Some room     |_ MUF Vault
              |_ etc.        |_ etc.