I define "building" in MOO as manipulating and developing the MOO environment in a way that doesn't require or involve programming. Understanding building and how MOOs are structured is also essential for learning MOO programming.
This guide assumes your MOO is based on the LambdaCore.
A MOO is built from objects. Even your own player is an object. MOO is an excellent teaching language because you're actually programming it from within the same programming environment. You can view, alter, and execute code without having to compile anything or be interrupted in any way.
Every object in a MOO is uniquely identified by an object number. An object number is a data type, and is denoted by the pound symbol (#). #0, #1, and #8173 are all objects.
Objects can define properties and verbs. Properties are bits of data stored on the object, essentially describing the object. Verbs, which are usually called "methods" in other object-oriented languages, are programs written in MOO code that define what the object does.
In addition to the properties and verbs defined on an object, an object also has all the properties and verbs defined on its "ancestors." This means that not only can pieces of code be organized easily, they also don't have to replicated needlessly. Let's have an analogy.
We can say some things about all dogs. They have four legs, two ears, two eyes, fur. This is the definition of a generic dog. Of course, we can also be more specific. A collie has a specific coloration and physiology, which is different from that of a yellow lab. Yet both have all the qualities of a dog. We don't have to specify that a collie has four legs and fur; we already know that, because a collie is a dog. Similarly, a dog is only one type of mammal, and there are some things we can say about all mammals, whether they be dogs or monkeys. This sort of taxonomy is a good analogy for MOO object inheritance.
In the LambdaCore, a generic object that players can pick up, move around, and interact with is the Generic Thing (object #5, or $thing). One child of the Generic Thing is the Generic Container. It has all the same characteristics as a Thing: it can be picked up, etc. However, unique to the Container is that other things can be placed into it. This behavior of containing other objects is defined on the Container; the general behavior of being interactive is inherited from the Thing. Any children of Generic Thing do not need to be told how to interact anew; they'll inherit that behavior automatically. You can see how this would make a programmer's life easier.
Additional Information: In most object-oriented languages, a "parent" or "generic" object is called a class. This class inherits all the characteristics from its parent classes. A child of that class is then called an "instance"; it has all the characteristics of its class, but cannot define any new properties or methods. In MOO, every object is treated as a class. This is arguably rather wasteful, but also helps MOO's status as a good teaching language by simplifying things.
Every object you'll ever create will have a parent, specified by you, to define its basic behavior. You'll also specify a name and aliases. The name is what you see when you interact with an object. For instance, say object #1000 is "a shiny red ball". The aliases are other words that you can use to refer to that object. Thorough aliases for the shiny red ball would be "shiny red ball", "red ball", and "ball".
The syntax for creating a new object is:
@create <parent> called <name>,<alias1>,<alias2>...
For example:
@create $thing called a shiny red ball,shiny red ball,red ball,ball
A common mistake for new builders is to leave off the "a" or "an" article, or capitalize the object name (i.e., A shiny red ball). Obviously this is merely cosmetic, but if you want to look like you know what you're doing, stick to the sort of name used in the red ball example.