With the Nightmare Mudlib 3.2, level and position are almost irrelevant
Level is a value only relevant to players (and marginally so at that).  Once
someone has creator powers, level plays no part in determining anything.
Position has two uses:
1) People with the position "high mortal" or "player" DO NOT get creator
   powers.  Everyone else does.
2) It is an administrative tool to denote who serves what function in the
   structure.  In itself, position does nothing at all with respect to
   people with creator powers.  A person with the "administrator"
   position can do no more than a person with the "creator" position
   *in virtue of* the position.  Instead all access and command availability
   are set through the groups file (to which only people in the superuser
   group have access).
Nightmare comes with documentation about how its power structure is set up.
You do not need to match this structure in any way to get your MUD
running securely.  In our experience, however, which goes all the way
back to the original Genesis, this power structure based on one from
IgorMud provides the greatest long term stability.

So, in order to give out creator and administrative access on your MUD, it
is best to decide first what positions you want to have on your MUD.
It is likely to best start with just admins, arches, and creators then
later expand upon that structure when you have the personel to do so.
Once you have decided upon this structure, you must do the following:

1) "xmote playername position" or if you use levels to mean something as well,
   "xmote playername level position".
2) Add them to the appropriate group on the file /adm/db/groups.db.
   "arch" type people should be in the group "assist" and "admin" types
   should be in the group "superuser".  More on how the groups file
   works later.

Note that creators do not need special access.  The default access for
a person not found in the groups file is defined as the group "all" in
/adm/db/access.db.

Now, these other people should have the access they need.  Remember to
make home directories for them.

How the access and groups files work:
The access file defines the access that a group of users of euids (see the
document "Security" for information on euids) has.  For example,
the line:

(/adm/save): (all)[n] (assist)[r] (superuser)[rw]

says that people in the superuser group can read and write to the
directory "/adm/save".  People in the assist group can read that
directory, but they may not write to it.  People not specified (all), have
no access whatsoever.  The model for access.db lines is:

(directory): (all)[access] (group1)[access] (group2)[access] (groupn)[access]

Where "directory" is the name of a directory.
Where "all" is anyone not otherwised specified in that line
Where "access" is one of "n:, "r", "rw", "w meaning respectively "no access",
   "read only", "read and write", "write only"
Where group1 through groupn are any number of groups you want to specify
   access which differs from the access granted to "all".  A group
   group may be any group specified in the file /adm/db/groups.db or
   any individual, or any euid.

Note: with Nightmare Mudlib 3.2, creator objects DO NOT have the same
access as the creators themselves.  The euid of the player "descartes"
is "descartes", but his objects all have the euid "descartesobj".
This differs from previous releases of the Nightmare Mudlib and all other
UID based security systems.  Use the SimulEfun owner_euid() whenever you
need to allow creator objects some sort of access like their owners.

The groups file determines what users and euid's belong to a group.  For
example:

(superuser): descartes forlock shadowwolf lassondra

puts the creators "descartes", "forlock", "shadowwolf", and "lassondra" *as
well as* any other object on the MUD with their euid into the group
"superuser".  This allows you to group people together with similar access.
No objects on the mud should be allowed to take the euid of a player or
creator unless those objects have a uid of system.  Read the security
document to find more about uid's and euid's.

The model for a line in the groups.db file is:

(groupname): euid1 euid2 euid3 euidn

Where "groupname" is the name of a group.  This name should be banished
   so that no player may take on that name.
Where "euid1", "euid2", "euid3", "euidn" are all euid's which should have
   all the access that group has.  Note that creator's euid's are simply
   their names.

Now you should know enough about the mudlib to give out appropriate access
to the creators, arches, and administrators who are going to build you
MUD with you.  If you have not already done so, you should become
familiar with the layout of the mudlib.  In addition, as you deal with
individual features of the mud, you should read about them in the features
subdirectory.