Building Tutorial #2

Written by Luigi@8BitMUSH
(A continuation of Building Tutorial #1)

Summary of Goals

In this tutorial, you will be taught how to create and decorate objects, use locks and success/failure messages on exits, objects and rooms; use exits as hidden commands, handle keys, and control where objects end up. We will also discuss a few exit tricks.

1. Introduction

In the last tutorial, I discussed the creation and decoration of rooms and exits. I also talked about DBREFs. If you’ll recall from the last tutorial’s introduction, there were two other types that existed in a MUSH: players and objects.

Let me say first off, that players are basically the same as objects. The difference being that players are actual, real people, connected to the game. While objects are things created by these players. I am not going to be discussing players in this tutorial (there isn’t much to say about them anyway).

Objects are always located inside of something else. Whether it is another object, or a room. For instance, in the last tutorial’s look example, we saw the following:

Living Room

A bright magenta room. The ceiling is really high up, and a small circle of glass in it follows the earth all day and night, serving as a sort of odd clock. There is a circular sofa surrounding the whole circular room, and it is deep purple with an embroidered golden "Universe". On the walls are paintings in gold frames and purple mats. Just a few of them are entitled "World" "Doomsday" and "Earth Ping-Pong". There are many doors scattered all around the room. A giant pole in the center of the room holds row upon row of books with poetic names like "White Bonnet." The carpet has a spiral pattern of purple, magenta, and gold.

Contents:

Sub Machine Gun

Oyster

Obvious exits:

Bedroom Out

The “Sub Machine Gun”, appearing in the “Contents:” list, is an object. The only object currently in this room.

So what are objects? What are they for? Objects are items that can be held and dropped, looked at, and smelled/touched/tasted/listened to. They can be used to decorate a room, giving explorers more to inspect than just the room’s description. They can be coded to do complex things, and they can even be used as keys in puzzles.

Using the above as an example, we could inspect the Sub Machine Gun by typing the following:
> l sub machine gun

Sub Machine Gun
A cool gun.
> smell it

It smells like gunpowder.

> touch it

You run your fingers along the shiny metal.

> taste it
It tastes like fingers and dirt.
> listen it

It isn’t making any sound.

You could even try to pick it up, like this:
> get sub machine gun

You pick it up.

> i

You are carrying:

Sub Machine Gun

You have 0 Coins.

Not every object will let you pick it up, and this will be discussed further in a bit.

The “i” command, which is a shortened version of “inv” or “inventory”, shows the objects you are currently carrying.

2. Creating And Decorating An Object

To create an object you use the command @CREATE. The syntax is “@create <object name>”.

An example:

> @create Stick of Dynamite

Created: Object #8063.

Now if you type “i” you’ll see that it has been created and is in your inventory:
> i

You are carrying:

Stick of Dynamite(#8063ScSoToTaSu)

Sub Machine Gun

You have 0 Coins.

You’ll notice the object has a DBREF, #8063. Following that number, there is a series of colored symbols. Each of these two-letter codes refers to something that needs to be set on the object.

Objects can be decorated in many ways. First, just like exits and rooms, objects can be described with @DESC. The @desc is what people see when they look at the object.

> @desc Stick of Dynamite=A red, wooden stick of dynamite.
Stick of Dynamite/DESCRIBE - Set.

> l box

Stick of Dynamite

A red, wooden stick of dynamite.

Also, just like we did in the last tutorial to rooms and exits, you can use @NAME to rename objects:

@name stick=Stick of red dynamite

Objects can have four “senses” set on them. When someone tells you to “sense your objects”, this is what they mean. The senses consist of smell, taste, touch, and sound. They are set with @SCENT, @TASTE, @TOUCH, and @SOUND.

Example:

@scent stick=It smells like gun powder.

@taste stick=It tastes like old miner’s fingers.

@touch stick=You run your hands along the stick of dynamite, it’s very smooth.

@sound stick=It isn’t making any sound.

3. Locks, Success, And Failure

There are two more important messages you can set, but before we get into them we should discuss Locks.

Some objects allow you to get them (pick them up and put them in your inventory), and some do not. What determines this is the object’s lock. Likewise, some exits allow you to go through them, and some do not. What determines who can go through an exit and who can’t? Its lock.

Locks can be set with the @LOCK, and locks can be used on players, objects, exits, and even rooms. When something has no lock set, anything may get it (or go through it, if it’s an exit). This is the default.

If you remember back to the last tutorial, we discussed @SUCC. @SUCC, when used on exits, shows you a message before you go through the exit, like so:

@succ east=You walk east.

> e

You walk east.

@SUCC stands for “success”, and can be used on anything. When a lock is checked against a person, and that person `succeeds` (passes the lock) the @SUCC message is shown to them. On objects, the @SUCC message is shown when somebody get’s the object. On exits, the @SUCC is shown when somebody goes through the exit. On rooms, the @SUCC is shown when somebody steps into the room. On players, it is the same as on objects (though players are usually locked to prevent them from being picked up).

So, for our stick of dynamite, let’s set the @SUCC to:

@succ dynamite=You pick up the stick of dynamite.

Now whenever someone gets the object (via the get command) they’ll see “You pick up the stick of dynamite.” instead of the default message, which is “Taken.”

Up until now everything we’ve used has had no lock set on it, so @SUCC is all we have had to worry about. There is an opposite command to @succ that we will discuss now. First, let’s set a lock.

Locks are set with @lock. @lock takes the format:
@lock <something>=<key>

Where <key> is what specifies what can pass through this lock. You can tell it that only people carrying a certain object can pass the lock, or that only a certain player can pass the lock, or that only a certain DBREF can pass the lock, and so forth. You can use combinations, specify NOT and AND operators, and more. Locks can get very complex.Here are some examples:

@lock dynamite=#1234

Locking something to a DBREF makes it so only that thing (#1234) or someone carrying that thing can pass the lock

@lock dynamite=+#1234

Locking something to a DBREF with a plus in front of it makes it so only someone carrying that thing can pass the lock.

@lock dynamite=+gloves

Locking something to a name of an object also works just like above, but that object must be in the same room as you, or in your inventory. This example locks the dynamite to someone carrying the “gloves” object.

@lock dynamite=#0

Locking something to a DBREF makes it so only that thing (#0) or someone carrying that thing can pass the lock. Since #0 is a room, owned by the game, this lock prevents anyone from passing it. Including you.

@lock dynamite= =me

Locking something to “=me” (note the two equals signs) locks something to only you. If you were to leave off the second equals sign, it would lock it to “you or anyone carrying you”.

@lock dynamite=$#1000

Locking something to a DBREF with a dollar sign in front of it locks something to that DBREF and everything it owns. So you would want to put the DBREF of a player.

@lock dynamite=$*Luigi

Same as above, you can use “*<player name>” to specify by the player’s name instead of their DBREF. It will be changed into their DBREF on the actual lock, though, so if the player changes his name in the future it won’t break the lock.

Using the above syntaxes, you can combine them with the following symbols:
! not

| or

& and

() grouping parenthesis

So for example:

@lock dynamite=$#1000 | #400

This locks to “#1000 and everything #1000 owns, or #400”. This demonstrates the “|” (or) symbol.

@lock dynamite=#1234 | #1235 | #1236

This locks to “#1234, #1235, or #1236 (or anything carrying them)”.

@lock dynamite=!+#1234

This locks to anything not carrying #1234. So they will have to drop #1234 before they can pass this lock. This demonstrates the “!” (not) symbol.

@lock dynamite=+#1234 & +#1235

This locks to anything carrying #1234 and #1235. They must be carrying both. This demonstrates the “&” (and) symbol.

The grouping characters, the left and right parenthesis, can be used to group a series of locks. For instance:

@lock dynamite= =*Clammy | (+#1235 & +#1236)

This would make it so the player “Clammy”, or someone carrying both #1235 and #1236, could pass this lock.

SOOOooo…. Now that you know how to set a @lock, what happens when someone fails a lock? Well, they see the @FAIL message instead of a @succ message. If it’s an exit, they don’t go through it, and if it’s an object, they don’t get it. For example:

(object example)

> @lock dynamite= =#0

Locked.

> @fail dynamite=It looks like it’s about to go off, you better not touch it.
Stick of Dynamite/FAILURE – Set.

> get dynamite

It looks like it’s about to go off, you better not touch it.

(exit example, assumes you have an object named “small key” created)

> @lock east=+small key

Locked.

> @fail east=The door is locked.

east;e/FAILURE - Set.
> east
The door is locked.

> get small key
> east

You step through the door.

Players can have locks too, and they are the same as objects. Since if you pass a player’s @lock, you can pick him up.

Rooms can have locks, but failing to pass a room’s lock does not prevent you from entering it (that’s what exit locks are for). Instead, it simply shows the @fail of a room, instead of a @succ. The @succ/fail messages show up below the @desc, if a @desc is set. So for example:

wheat field

You are in a large wheat field north of the bazaar. There is a corn field to the West.

About a bushel of wheat can be harvested.

Contents:

bushel of wheat

> get wheat

Taken.
> l
wheat field

You are in a large wheat field north of the bazaar. There is a corn field to the West.

There's not much to be gleaned here.

So in this example, the room is locked to “+bushel of wheat”. The room’s @DESC never changes. When you don’t have the bushel of wheat, the @FAIL is shown, which is “About a bushel of wheat can be harvested.”. When you do have it, the @SUCC is shown “There's not much to be gleaned here.”.

Using room @SUCC/@FAIL messages like this is useful when designing puzzles. So is locking an exit to someone holding an object, and setting appropriate @FAIL and @SUCC messages.

4. Using Dark Exits
When making areas, puzzles especially, you sometimes want other players to be able to type something and get a message in return. Or perhaps you want people to be able to go through a secret exit, only hinted at in the description. To do this you can @OPEN (or @DIG) an exit, and set it DARK. Here are two examples:

> l
Small Garden
A beautiful garden with flowers in it. The dirt is very bumpy here.
Obvious exits:
out
> @open dig; dig around; dig in the dirt=here
Opened exit #8079
> @succ dig=You play around in the dirt.
dig; dig around; dig in the dirt/SUCCESS – Set.
> @osucc dig=plays around in the dirt.
dig; dig around; dig in the dirt/OSUCCESS – Set.
> l
Small Garden
A beautiful garden with flowers in it. The dirt is very bumpy here.
Obvious exits:
out dig
> @set dig=dark
dig; dig around; dig in the dirt – Flag set.
> l
Small Garden
A beautiful garden with flowers in it. The dirt is very bumpy here.
Obvious exits:
out

>dig

In this example we created a dark exit linked to the room, so that when they type it they don’t go anywhere. They will see the @SUCC message though (and other people in the room will see the @OSUCC).

> l
Monster’s Cave
A small cave with a torch in it.
Obvious exits:
out
> @dig Secret Room=pull the torch;pull torch,out;ou;o;leave
Secret Room created with room number 19561.

Opened exit #19715

Trying to link...

Linked exit #19715 to #19561

Opened exit #19747

Trying to link...

Linked exit #19747 to #10038

> @set pull the torch=dark
pull the torch;pull torch – Flag set.
> l
Monster’s Cave
A small cave with a torch in it.
Obvious exits:
out

> pull the torch
You pull the torch and a wall slides open.
Secret Room

Obvious exits:
out

This second example is similar, only this time we made the secret exit lead to a secret room.

5. More Exit Tricks
There are a few more little tricks you can use on exits.

For instance, if you type:
@set <exit>=transparent
When someone looks at an exit, not only will they see its @DESC, they will also see the contents of the room it leads to. If you do set an exit transparent, it’s usually best to set the @DESC to something like:
@succ east=In that direction you see:

Another trick is for builders using keys. You can have more than one exit in a room using the same name, each locked to a different key (remember, to lock to an object you use “+<key>”). If the player has just one of those objects, it will show them the success message for the first exit they successfully pass, and take them through that. Since there will be two exits if the same name, you will want to set one of them DARK, so that only one shows up in the “Obvious exits:” list. An example:
@open east;e;efbird=#1543
@lock efbird =firebird
@succ efbird =You drive the firebird east.
@osucc efbird =drives the firebird east.
@fail efbird =You don’t have a vehicle.
@open east;e;epinto=#1543
@set epinto=dark
@succ epinto =You drive the pinto east. It sputters a lot.
@osucc epinto =drives the pinto east.
@fail epinto =You don’t have a vehicle.

Ever wanted to move an exit without re-creating it? If you own it, you can type:
@tel <exit dbref>=<room dbref>
And the exit will be moved to the room specified

Lastly, some areas even work better when every exit in them is set DARK. This makes it so the people exploring it are forced to read the descriptions carefully.

6. Controlling Where Objects End Up

Allowing people to pick up objects is sometimes necessary when you are building a puzzle. But how do you stop them from keeping that object long after they are through visiting your area?

First, every object and player in the game has a “home”. The room you created your object in is your object’s “home”. You can use something called the “STICKY flag” to tell the game to send your object home whenever somebody carrying it @teleports, drops the object, or types “home”. You set it like this:
@set <object>=sticky

If for some reason you change your mind, you can unset the flag like this:
@set <object>=!sticky

To see what an object’s current home is, type “examine object”. If you want to change the home of your object, you can type:
@link <object>=here

(links it to the room you are standing in)

Or
@link <object>=#1234

(links it to #1234, which can be a room or a player)

If you want to keep the objects from leaving your area, you can set a lock against all of your key objects, on all exits leading out of your area. Something like:
@lock out=!+#1234&!+#1235&+!#1236

@fail out=You need to drop the puzzle objects first. Thank you.
This will make it so they have to drop the objects or @teleport to get out of your area, both scenarios resulting in the puzzle objects going home.