This tutorial is intended for new builders, or non-builders who wish to take their building test. It is not a substitute for the online reference manuals.
A few conventions are used consistently throughout this tutorial:
A builder is a player who is able to extend the game by creating and altering scenery and commands. When UglyMUG was started, there were only about 250 objects in its database. Now there are over 60,000. Almost all of the other objects were created by Builders, extending the game.
We strongly suggest that you spend some time looking around UglyMUG and the manual before you request a builder's flag. There's little point just building yourself another poorly thought out, badly-described house and bedroom; there are plenty of those around already. Try thinking of something original to build. See Guidelines for Building Good Areas below.
To get a builder's flag, ask a wizard who is online or MUD-mail a wizard. They will probably ask for some kind of evidence that you could build and that you have read and understand (at least bits of) the manual.
The wizard will also ask for an email account; they don't hand out flags without an email address, so don't ask. This email address is only visible to admin, who use it for two purposes:
The wizard will give you some building points for you to start. If you need more, be prepared to justify why you need them (see Getting More Building Points below). For large projects that will need lots of building points, talk to a wizard. They sometimes hand out experienced-builder (X) flags for that purpose.
Every night, a program runs on the UglyMUG server that emails out various information. Much of it goes to the admin, and some of it is even useful.
When you become a builder, UglyMUG will start emailing you a HUH log. This lists things people have typed in your area that UglyMUG could not understand. Some will be pretty useless (a misspelled tell command, for example). Others are more useful - you'll find out pretty quickly about any commands people want to run that you haven't provided. Please look through your HUH logs on a regular basis, check for commands that you don't yet offer, and add them.
Don't be surprised if you don't get HUH logs every night. If nobody has typed anything in your area that UglyMUG didn't understand, you won't get any email that night.
When you first become a builder you will be given a few building points. These are to allow you to build something interesting, so use them to do this. If you run out of building points and need more, there are two ways to get some:
If you need ask a wizard, expect them to look around your area with a critical eye. If it's good, they'll give you more building points and a gold star. If it needs work, they'll point out what parts could do with some attention but won't hand out more BPs.
This isn't an exhaustive list, but think about the following when you're building an area.
Creating an object always costs building points one way or another.
Object type | Command | Cost (BP) |
---|---|---|
Room | @dig | 10 |
Thing | @create | 10 |
Exit | @open | 1 |
@link | 1 | |
Command | @command | 10 |
Property | @property | 1 |
Array | @array | 1 |
Dictionary | @dictionary | 1 |
Fuse | @fuse | 10, +1 every time it fires. |
Alarm | @alarm | 0 (Wizard only), +1 every time it fires. |
Non-player Character | @npc | 1,000 |
The reference manual is fine if you need the syntax of a command, but it's a bit bewildering when you don't know what any of the ideas mean. This section sets out to restore the balance, by providing a (hopefully) simple introduction to building On UglyMUG.
I'll start with a small example: a study. It's a room with a way in and out to a landing, a desk, a chair, a computer on the desk and a chiming clock.
The first thing to do is to work out roughly what you want in the room. In this case, I've already done that - it's the list shown above.
The next thing to do is to have a think about each thing you want to build, and work out what type of UglyMUG object would be best suited to it. There are many kinds of object in UglyMUG: Alarms, Arrays, Commands, Dictionaries, Exits, Fuses, NPCs, Players, Properties, Rooms and Things. Most of these are intended for use when you're programming, and we'll only cover Rooms, Things and Exits in this part of the tutorial. In this tutorial, I'll always use a capital letter when I mean an UglyMUG type - Room rather than room, for example.
When do you use each type? Here are some rules:
Looking at our simple example, we can see that the study should be a Room, the ways in and out should be Exits and everything else should be Things. We can see how to do most of it, although making the clock show the right time and/or chime could be troublesome.
It's quite possible to dig a Room and pretend it's in the middle of a vacuum --- in fact, if you don't do anything else to it, that's where it will be. Newly created Rooms are just empty spaces, with no relationship to anything else in the game. So:
The system told you the room's ID. An ID is a unique number that's assigned to each object in the system when it's created, and stays the same until (unless) the object is destroyed. In this case, our Room is object number 244 in the database, so we can refer to it as #244. Even if there's no other way of referring to an object, you can always use its ID.
You own anything you create, so you can examine this new room using examine (ex for short):
So the new room has no contents, no ways in or out - in fact it's a perfectly normal piece of empty space.
Now that we've got our Room, the next thing to do is to make it something other than an empty shell. Real rooms, such as the study we're trying to represent, don't just have a name. They're not all uniform, cubic, unlit grey spaces. So it is with the study we've built. It needs:
You can set the description of a room using @describe (@desc). Long descriptions can spread over more than one paragraph. Just as in a word processor, you should type a paragraph so that it's all on one line. UglyMUG will then format the paragraph appropriately for each player's screen.
If you want a multi-paragraph description, or you just want a newline in a description, you need to put a backslash (\) just before the newline. If you don't do this, UglyMUG will assume that you've finished telling it the description and will set it. This trick works for all input in UglyMUG, by the way. Try it using say or emote:
So our study could be described as follows:
There are several things to note about this description:
We have now set up an isolated room. It has a description and (if you've followed the section on physics) it's the right size. However, we still have to connect it up to the rest of the MUD, and we still have to fill it with Things for the players to play with. Read on...
An isolated room isn't much good to anybody; it needs linking into the rest of the game. There are two parts to this:
In real life, spaces aren't isolated. People group them into things that are more useful to talk about. Rooms are grouped into houses or offices; buildings are grouped into streets; streets are grouped into towns.
UglyMUG has the same approach. Any Room can be put into an Area. An Area is simply another room - there's nothing special about it except that it happens to hold some other Rooms. Area rooms can be put into other area rooms, and so on.
Apart from general tidiness, why would you want to do this? There are a number of advantages:
The area approach carries on further than this. UglyMUG has its own area hierarchy, containing Sandyville, High Vulcan, Idlesville and the other towns. Ultimately, these are all parts of Top Area (#2). Once you have your own top area, ask a Wizard to place your top area into the main area tree. This helps both you and the admin team.
Let's use an example to illustrate this. Here, we'll create a house, place it in an area, then get a wizard to place it in 'Top Area'.
The first step is to dig a 'top room'. This room won't have any entrance or exit; it's the container into which you place all your rooms. Other than that, it's just an ordinary room:
#25000? Just lucky, I guess. Now we dig the other rooms in the house:
At the moment, none of the rooms of this house are in an area. Commands like silly will not work, and we won't be able to @open any Exits from any of them.
This is an important point: you have to control the room's area (and it must have one!) before you can open exits from it. If you try anyway, UglyMUG will respond You don't control (whatever), where (whatever) is the name of the area containing the room. If the room isn't in an area, *NOTHING* will be displayed instead, leading to one of UglyMUG's craziest error messages: You don't control *NOTHING*.
To place the rooms in #25000 (my top area), I use the @teleport (@tel for short) command:
Oh yes, we'd better put the study in that area as well:
The first number is the ID number of each room; the second is the ID of our top area.
Now we can @open exits from these rooms to make the house navigable, and we can put commands (see later) in #25000 that will be available in all the rooms.
There's one more thing to do. Wandering around my little house, we still can't use commands like 'silly'. We need a wizard to @tel #25000 into the game's geography for us.
That's all there is to it! The area structure now looks like this:
Top Area | ||||||
| | ||||||
... | ||||||
| | ||||||
My top area #25000 | ||||||
+----- | ----- | -----+----- | -----+----- | -----+----- | ----- | -----+ |
Bedroom | Garden | Landing | Study |
Now that the room's been placed in its correct area, we can set up ways into and out of it. Let's assume that we've already built the landing of the house, and described it. We want to create a doorway that's the way out to the landing. We use an Exit for this job.
Exits are created using @open. This requires a list of exit names. Each name in the list is separated by a semicolon (;). The first name in the list is special - it's the one that is displayed in the list of 'Obvious exits' when you look at the room. If a player types any of the exit names, (s)he tries to go through the Exit. So, to create a door to the landing:
This looks like a very long list of possible names, but don't panic. It was made up by using the following rules:
The exit is created in whichever Room you are at the moment. If this happens to be the wrong one, don't panic; you can pick the Exit up using get and drop it in the correct place.
Now that we've created the exit, we can link it to the landing. As UglyMUG doesn't understand 'landing' unless you're in the room, you need another way of referring to it. The usual way is to use the ID of whatever you're referring to (it's the number preceded by # when you look at something you own). This number is unique to the object and is guaranteed to refer to it at all times. So, if the landing is printed as:
then you can link the door to the landing using @link:
If you now examine the Exit, you will see:
Exits work in one direction only. Just because we've created an Exit from the study to the landing, it doesn't mean we can get back again. To do that, we need an Exit going in the other direction as well. It's time to take a look round our study, remember its ID (we'll need it to link the Exit from the landing) and step outside:
Now that we're on the landing, we can create our Exit into the study. It should re-use as many of the names from the 'out' Exit as possible. Since we already know the ID of the Room we're linking it to, we can open the Exit and link it all in one command:
We've had to alter the exit names slightly, as there will be other cheap doors from MFI going to other Rooms. This one is the one on the left, so we've called it that. We've also fixed the other names so that they include 'left' where needed.
Just to make sure, we can now go back to the study:
Just as Rooms are different, so are Exits. It's not just their names, either; you may wish to change:
Going back to our study, we might decide that the door is closed except when somebody opens it to go through. Since it's a cheap, tacky, wooden door, nobody can see through it. To make this kind of Exit, you set it OPAQUE:
If an Exit is OPAQUE and a player looks at it, they see the Exit's description. If you've not set anything else, they'll be disappointed:
So we'd better set a description for the door:
Since the door had better be OPAQUE both ways (it's not a one-way mirror, after all), we should do the same thing to the Exit from the landing:
If we hadn't done this and somebody looked at the door, they would see straight through it and into whatever Room is at the far end. This works well for open bits of land (or open-plan houses), but it's not so good for doors.
The OPAQUE flag controls whether you can see through an Exit or not. Later there's an example of a command that will open and close a door, setting OPAQUE accordingly.
If we look at the study now, the Exit announces itself but no longer says where it leads to:
[TODO: look]Most of the time, an exit should announce itself like this; but what about less obvious exits? In our case, how about a fire escape:
gives us an exit through the window to the garden. Since it's not going to announce itself, it doesn't need a fancy label as the first part of its name. All we need to do now is to make the exit a hidden one, using the DARK flag:
We don't want this exit to be OPAQUE, since we want a Player to be able to see through it into the garden if they happen to look through the window. This serves a double purpose: as well as the fire escape, we've now answered what will happen if someone notes that there's a window in the room's description and tries to look at the window.
We've now set up the static parts of the Exits, but haven't really thought about what happens when a Player tries to go through one. First of all, can they go through the Exit at all? This may sound silly, but things like a toughened glass window are pretty hard to get through - yet, with an Exit, you can see what's on the far side. And, even if you can get through, what do you need? A hammer? A key?
Access through an Exit is controlled by the Exit's lock. Look in the online help for @lock for the kinds of things you can do with locks. For now, let's just note that you can lock an Exit to any logical expression involving bits of the game. Since we want to be able to get through the window (a quick route to the garden while we're building things), but we don't want anyone else to, we can lock the Exit so that we're the the only object that can open the lock:
This says that if anyone other than us (that's the me in the command) tries to use the Exit, they'll fail.
If you want to unlock an Exit, use @unlock:
When someone tries to use an Exit, the Exit's lock is checked. One of two things can happen:
The text below here still needs rearranging. It's garbled and, in some places, incomprehensible. Don't bother looking. No, really, don't.
TODO: Erm, I'll fill this in afterwards
Success is of course the opposite.
TODO: See @chpid and @unchpid for the moment.
This is a command that will be executed whenever you logon to the game, it must be on you, in an object you are carrying, or in the room that you are in. This is the only special thing about it, otherwsie it executes the sames as any other command. If there is another command in the area called ".login" then this will execute as well as your own one, afterwards.
This is similar to .login except it executes on QUIT from the game.
This command is executed when a person leaves an area. As with .enter they are fired all the way up the area tree.
"drop Variable = Object" will attach a variable to an object. To attach it to a room type "drop Variable". To get a variable back you must specify its full name, ie "get the-thing:fred".
You can construct variable names out of expressions involving other variable names by surrounding the constructed name with braces (`{' and `}'). Braces can also be used when a colon just after a reference would otherwise screw things up. NB - Anything within {...}'s is executed as a command, therefore use "{@?desc var", rather than "$var"
TODO: Urm you sort of use them.
Originally started by The Ozzard of Wiz, sometime around late 1991.
Modified by ReaperMan.
Added to by a cast of tens. Thanks to ReaperMan, Flup.
Converted to HTML (XHTML 1.0) by The Ozzard of Wiz, March 2002 (ten years on!).
Extensive reworking by The Ozzard of Wiz, March-April 2002.