MUCK Building Basics, 101
-=-=-=-=-=-=-=-=-=-=-=-=-=-
by Wixenstyx@MUCK-U
August, 2002 -- ARR
Revised March 27th, 2004
Type 'read book1=contents' to see what information it contains.
You turn to the contents page and read:
Title Chapter
---------------------------------------------------------
Introduction..............................A (3 pages)
Section I (Database Item Overview)........B (4 pages)
Section II (Types of DB Items)............C (3 pages)
Conclusion................................D (1 pages)
To read a chapter, type read book1=A1
Which displays chapter A, page 1.
Chapter A: Introduction: "I can build, but I can't program..."
I hear this statement (or statements along the same lines) from players all the
time, and I can't help but chuckle. I know what they're trying to say -- that
they understand the 'basic' Building commands, but the intricacies of MUF and
MPI programming leave them confused. This is an understandable sentiment, but
it reflects a very common misconception among the MUCK user population -- that
'Building' and 'Programming' are two different things.
This differentiation between Building and Programming is probably simply a
matter of terminology. Early MUCKers understandably used 'Building' to describe
the aspect of MUCK programming focused on creating and directly manipulating
the Database Items that constitute a MUCK, and 'Programming' to describe the
scripting of these items using the FORTH language derivative MUCKs employ (AKA
MUF). But the use of these terms has evolved to the point where players seem
to erroneously assume that Building is a kind of game of folly that any moron
can master, whereas MUF and MPI are serious programming which require superior
intellect to understand.
I'm here to tell you, as a MUCKer of no great distinction who has to varying
degrees mastered all three, that neither of these statements could possibly be
To read the next page, simply type 'next'.
farther from the truth. Building isn't easy when it's done well, and MUF and
MPI are not necessarily more intellectually challenging. All three are
programming languages, and all three require creative thinking, an
understanding of what you're doing and how to get there, and strange-sounding
commands that produce an end result given various pieces of information.
I would even go so far as to say that if anything, building is the hardest of
the three to learn, and the most important; MPI and MUF are both useless to
players who do not have a firm grasp on the ins and outs of Building. In fact,
when I sit down to try and teach MUF or MPI to those who claim 'I can build,
but I can't program', 99.9% of the time I find that the problem isn't in the
player's intellect or some inborn lack of programming talent. Instead, the
problem is that they are trying to write a MUF program with only a working
knowledge of building commands. This is like trying to skip before you really
know how to walk.
This is why, on MUCK U, you HAVE to pass the building quizzes before you can
enroll in any of the other courses. You'll note, too, that this includes
Administration. Having been an administrator of a number of games and a player
on countless others, I've come to the conclusion that one can NOT run a MUCK
effectively without an understanding of how the gamesides of MUCKs are created
and how they work.
To read the next page, simply type 'next'.
Building is Programming. And as with any Programming Language, learning how to
build and building well is much easier when you have a good grasp on the basics.
This book provides a detailed, builder's-view look at Database Items, the 'raw
materials' of building.
END OF CHAPTER A
This is the last page of this chapter.
Chapter B: What is a 'Database Item'?
Database Items are, as stated previously, the 'raw materials' that make
up the gameside MUCK. In their purest form, MUCKS are merely a
collection of hundreds and thousands of Database Items that have been
shaped and manipulated to look and behave like a little world.
There are some qualities that all Database Items possess, regardless of type.
They are:
1. A Unique Database Reference Number (AKA dbref#, dbref, ref#, etc.)
2. Name
3. Timestamps, Usecounts, and Memory Usage. (i.e., last modified date/time)
4. Flags (Type and Permissions determination)
5. Properties (Information Storage)
Here's a more in depth look at each:
1. Database Reference Numbers
Database Reference Numbers (dbref#s) are assigned to Database Items when they
are created. They are unique and the most reliable way to access an item,
especially if you aren't in the item's immediately proximity.
To read the next page, simply type 'next'.
One thing that is important to note: Dbref#s are unique, but they may be
reassigned if the Database Item they belong to is recycled. Recycling a
Database Item doesn't actually destroy it -- it really converts it into what is
known as a 'Garbage' item. The next time a player -- any player -- executes a
creation command, the dbref# is assigned to the new Database Item.
This is an efficient setup; nothing is wasted. The only problem this recycling
process presents is due to the fact that most MUCK Databases do not cross-check
all dbref#s (locks, for example, are not checked) on existing Database Items
when a given Item is recycled. As a result Players sometimes find their
belongings locked to peculiar things without knowing why or how it happened.
This is usually the result of one Item being recycled and another created that
took its place.
2. Name
Simply the name of the database item. Many database items can be referred to by
name, although the item must be "present" either in the player's inventory, or
in the same room that the player is located in.
3. Timestamps, Usecounts, and Memory Usage
When an item is newly created, it is immediately stamped with the current date
and time. Further, when the database item is modified, another timestamp is
To read the next page, simply type 'next'.
updated accordingly. Lastly, a database item has both a timestamp and a
"usecount" that is updated every time the item is "used". What the server
regards as "using" the item varies from type to type. A good example of
"using" a database is simply connecting to your player. You'll find that while
you are connected, your "last use" time will be the current time. Finally, the
server keeps track of how much memory a given database item is using, expressed
in bytes All of this information can be seen by using the 'examine' command:
'ex me' or 'ex #123', etc.
4. Flags
Flags are probably the most enigmatic parts of MUCK Building. Simply stated,
Flags designate who may do what with the Item, and how the Item behaves under
various circumstances. (And yes, that IS about as simply as I could state it.)
Flags are abbreviated using letters after the Item's dbref# when the dbref# is
displayed. For example: Wixenstyx(#231PBJCMW4)
In such displays, the first letter (P, in this case) is a "Type" flag. It
designates what TYPE of Database Item Wixenstyx is..in this case, a Player.
Type flags are permanent and cannot be unset or reset to something else.
The other flags are toggled permissions flags.. Builder (gives Wix the
permissions she needs to build), Jump_Ok (allows other players to teleport to
her), Color (Enables color settings in GLOW), Meeper (allows her character to
To read the next page, simply type 'next'.
parse MPI commands), and W4 (Highest Wizard setting). These flags can be set
using the command, @set <item>=<flag>. You'll learn more about Flags in another
course.
5. Properties
Properties are, in the purest sense, information storage slots. A database
item's name, its description, the messages displayed when it is used, its
locks, etc. are all stored in properties. These properties are read and
manipulated by the server, MUF programs, MPI programs or building commands. To
see the full property directory on an object, type 'examine <item>=/'.
----END OF CHAPTER B
This is the last page of this chapter.
Chapter C: The Five Types of Database Items
Since most of us aren't in the habit of thinking of MUCK components as generic
'Database Items', I'd probably be smartest here to outline the various types of
Database Items to make them easier to understand. There are, as the title
states, five Types. They are:
1. Rooms
2. Players
3. Things
4. Actions / Exits
5. Program Objects
The qualities that distinguish one Database Item Type from another include:
A. Their Type Flag
B. What they can and cannot 'Contain' without the use of a MUF program or
MPI.
C. What they can or cannot be 'contained by' without the use of a MUF program
or MPI.
D. How they behave with respect to a Player as destinations for triggered
Actions/Exits.
To read the next page, simply type 'next'.
(Just to keep things simple, we won't worry about "D" right now.)
Below is a rundown of each of the Types of Database Items and the other
qualities they possess:
1. Rooms
Rooms make up the 'virtual space' of a MUCK. They are designated with the Type
flag 'R', and may contain anything, including other Rooms.** However, Rooms
can only be contained by other rooms.
2. Players
Players make up the reason for a MUCK's existence. They are Database Items
controlled by incoming connections, and are designated by the Type flag 'P'.
They may contain Objects/Things, but can only be contained by Rooms without the
use of MUF or MPI.
3. Things
Objects are the most 'basic' of MUCK database items. For this reason, they are
the only Database Item type that has no Type flag. Things can be contained by
rooms or players, but cannot contain anything themselves without the use of MUF
or MPI. It is possible, however, to @teleport one thing into another, and some
To read the next page, simply type 'next'.
MUCKs do permit Things to be '@forced' to 'get' other Things.
** More on this in the 'Parenting' course.
4. Actions/Exits
Actions/Exits are the basic manipulating bodies of a MUCK. They are
responsible for moving things and players around and for triggering programs.
They are designated by the type flag 'E', and are unique among database items
in that they cannot contain or be contained by anything. Instead, Actions are
located on a 'source' (which can be anything except for another action) and
linked to a 'destination' (which can be anything including another action).
5. Programs or Files
Program Database Items on MUCKs are basically inert and used only for storing
information pertinent to the program, and as destinations for triggering
Actions. They are designated by the type flag 'F' and can be contained by
Players or Rooms, but not Objects except as stated above. However, they cannot
contain any other database items themselves.
----END OF CHAPTER C
This is the last page of this chapter.
CONCLUSION....
Congratulations if you've read this far! You have just completed the most
important (and, of course, the most boring) course in Building. Go take the
Quiz in Tiny Hall, Room 101 to see how much you've learned!
This is the last page of this chapter.