Introduction
A MOO – what is it anyways? MOOs are the grand-daddies of the MMORPGs so enjoyed / despised by millions of people every day on this planet. MMORPGs are incredibly difficult to create, due to the graphical and engine requirements.
Although the engine section could be fairly entertaining, the graphical side is beyond the reach of most coders. MOOs, on the other hand, require only that you can describe the world in text. This, combined with a fairly easy-to-use, Pythonesque language means that new features are relatively painless to create.
MOO (MUD Object Orientated) coding is incredibly entertaining, mostly due to (I believe) the fully object orientated nature of the environment. Everything within a MOO is an object – you, me, the rock, the tree, everything. Even more abstract things, like the generic room, or the string utilities. A player could, were one careless, steal the string utilities and run off with them.
That would probably be without consequences, unless someone else had coded a way to destroy objects. Your string utilities could be gone forever.
To make this more exciting, the MOO is coded while it’s up and running. You interact directly with it, instructing it to create objects and then coding them inside the MOO. Objects that you create can be interacted with immediately (or potentially stolen halfway through coding). This is the part that generally has the most appeal for coders – playing with what you make, immediately.
So how do you get started?
There are a couple of classic, excellent introductions to MOO coding – Yib’s Pet Rock and Yduj’s Wind Up Duck will put you far along the track fairly quickly. They’re both written with the general population in mind though, rather than someone who is already familiar with coding.
These tutorial will aim to get someone who is already a coder up and running as quickly as possible, as well as show a couple of different things to do in a MOO that weren’t covered in the previous two tutorials.
We’ll start with how to carve out a little piece of paradise, then move onto the coder’s introduction to coding. Let’s get stuck in.
You @dig it?
Rooms are objects, same as everything else. In particular, rooms are objects with a parent of $room, by default.
Rooms are connected to other rooms via directional exits. Typing the verb associated with the exit (“north”, for example), activates that exit which then moves you to the room on the other side of the exit.
There’s no strict geographical requirement for these rooms to be located near each other, in the same way that there’s no concept of geographical (or strict). A loose idea of how the rooms should fit together will probably help the curious adventurer, but it’s by no means a requirement.
The easiest way to create a new room is to use the @dig command. The format is fairly simple,
1 |
@dig <exit-spec> to <new-room-names> |
Here, exit spec describes the name of the exit that will be used to get to the room. It has the standard format of <name>[,aliases]. In addition, you can put a | symbol and describe the route back from that room to the room you’re currently in.
For example,
1 |
@dig north,n|south,s to "Wall" |
This will create an exit named north, with an alias of n, to a new room. “The” will be automatically appended, giving the new room the name of “The Wall”. The Wall will have an exit south (with alias s) that leads back to your current room.
One thing to note is that if you don’t own the room you’re in, the exit / entrance will not be created – you’ll need to ask the owner of the room to add them when he’s around. The object numbers of the entrances and exits are printed out when you create them – then the owner simply needs to use @add-entrance <entrance number> and @add-exit <exit number> .
It’s all in the details
Once you’re in your new room (and now can freely create subsequent rooms), you’ll probably want to give a couple more details on the room. In the same way that you described yourself (hopefully), you can describe the new room as
1 |
@describe here as "Ice crunches underfoot and stretches all around you. From up here you can see for miles, but it's the same white barren landscape as could be seen from lower down." |
The description sets the tone of the room, and gives the other users some ideas of what to expect.
The exit and arrival messages can also be customized, allowing you to expand your room to interactions that make it seem more vivid as people come and go. These support the standard pronouns (see help pronoun-example ). For example, if someone arrives from the south (and knowing that the name is prefixed):
1 |
@arrive south is "arrives from the south, breath steaming and snow crunching underfoot." |
These expand your ability to describe the room, and how it is accessed from other rooms.
Although not directly related to rooms, objects can be made to integrate with the room and allow the users to examine parts of your description in more detail. These can be set via the @integrate_room message – more on objects later though.
Carry on and carve a unit – we’ll make beasties that move around them next.
Leave a Reply