Building Guide

Better formatting, as well as editing and expansion, would be greatly appreciated.

If anything isn't clear, please leave a question next to it, and someone will clarify it.

Contents

[Basic Concepts]

[Basic Walkthrough]

[Easy Editing Commands]

[Useful Shortcuts]

[Creation Actions]

[Action-Specific Commands]

[Describing Things]

[Success Messages]

[Setting Up Failure]

[Checking Commands]

[Spiffy Things]

[Fake Exits]

[Parent Rooms]

[Program Listing]

[Noise Program]

[Puppets]

[Whereare Setup]

[Advanced Things]

[MPI]

[MUF]

[Reference Links]

Basic Concepts

When you build an area, you are creating rooms, creating exits to link those rooms together, and perhaps furnishing those rooms with objects or programs that have special abilities. Each of these, in building terms, is called an "object." Each player is generally assigned a set number of objects he or she can build; this is known as a "quota." For ease of reference, the MUCK will assign each object a reference number, sometimes refered to as a "DBref." In addition, it is possible to create other references, known as "registrations,' to save time. For ease of building, each object can have flags and properties that help dictate how different objects behave with respect to each other. One technique that many builders will use in order to collect objects with common flags, properties, and programs is to create a "parent room," in which all the other rooms will reside, thus saving time and space. More information continues below, including links to other, more detailed, guides.

To summarize:

• Objects - everything is an object, there are a few types.
  • Room - what you are in. Generally represents spaces.
  • Player - what you are. The object that represents your directly controlled character.
  • Exits - what lets you move between rooms and do all kinds of other things. Also known as actions. Can be slapped on rooms, players, and things.
  • Things - stuff you can pick up and hold in your inventory. Represents items.
  • Programs - basically, programs, outside the scope of this guide (but you can link to them for specific effects in building, see 'Spiffy Things').
• Quota - how many objects you can have, including all of the above object types. Check with @quota, see a Function to get it increased.
• DBref - what number an item has in the MUCK's database.
• Parent room - a room used by other rooms to borrow properties and actions from.
• Registration - a way of setting an object to have a name on yourself that you can easily use instead of the object's dbref number. Registered things are referred to by $(name).
• Flags - help flags

Basic Area Creation Walkthrough

Refer below to information on specific commands. This is only a general guideline as to process.

1. Plan out what your area will be like. It helps to brainstorm with people about it. Find out who owns the room you want your area linked from by doing ex here in that room, then talk with them about your area idea.
   1. You might want to write the whole area out first: think about continuing themes throughout, being as succinct as possible, edit your descriptions a little. Make each room mean something. Edit the whole, then do the technical implementation.
2. Create your first area room, using either editroom or @dig. (see Creation Commands, also Easy Editing Commands)
3. Set up that room's description using editroom or @desc and lsedit (Describing Stuff).
4. Possibly register your room if you haven't already.
5. Set up any look-traps, fake objects, dead-end commands, programs, or MPI, etc. you want (covered under Spiffy Things and Advanced Things).
6. Create another room and the actions linking to that room. Can be done with roomedit and such. +dig is a very nice, quick way of both creating a room and creating the linking actions at once. (Creation Commands)
7. Set up the linking actions with at least a base minimum of success, osucess, and odrop messages. Preferrably also a desc, I personally get slightly annoyed when I do 'look (action)' and get 'You see nothing special.' (Describing Stuff, Success Messages, Setting up Failture)
8. Describe and set up that linked room, register it if you need, create more rooms and actions, etc. until you have all the things you want to do finished. You don't necessarily have to do all those steps in the previous order listed, but it helps to do things as you go instead of putting them off.
9. Bug a Function to give you more quota if you run out of quota during step 8, then resume step 8.
10. Check over your stuff, looking at it for typoes and also using the @check command. (Checking Commands)
11. Contact whoever owns the room you want a link from and tell them you've finished it and want it linked in. Probably that person will want to check over your area first.
12. Once all the above've been done and your area linked to, congratulations! You've created a new part of the Mess. Of course, you probably will later find errors to fix, changes you want to make, etc.

Easy Editing Commands

• editroom #help - Do-it-all room editing command. Easiest way.
• actionedit - Do-it-all action editing command. Last I heard, this was buggy/broken, but that might have changed. Could someone provide an update on this?

It's entirely possible to do building without the above tools. Styles differ. The above two commands cover a lot of the individual commands explained below, if not all.

Useful Shortcuts

• @reg #help - registers something with a shorter name on yourself/something else as '$(name)' so that you don't have to remember and type out its dbref all the time.
  • Example: @reg #me here=courtyard.

• 'here' and 'me' are common shortcuts.

Creation Commands

• help @dig - creates rooms.
• help @action - creates exits. Short: @act
  • You can actually create exits with multiple names, as in climb;ladder;up. This sets up an exit with more than one possible command to use it.
• +dig #help - creates a room as well as the actions to link to it and back to the room you're in.it and back to the room you're in.
  • +dig versus @dig/@act: +dig creates exits and rooms at one go, but @dig and @act will let you register shortcut names for the rooms/exits at the same time you make them.
• help @create - creates 'things', basically items you can carry around and the like. See below for 'stuff to look at in rooms that aren't actual things'.

Action-Specific Commands

• help @link - sets where exits go to. See below for 'exits that go nowhere' or room-commands that don't take the player to another room.
• help @attach - only necessary if you want to stick the exit onto something else than what it was on when you use the @action command.

Describing Things

• help @desc - sets descs.
• lsedit - use this to create the sort of long descriptions you can achieve with editroom.
  • For instance, lsedit here=desc
  • Then @desc here={eval:{list:desc,here}}.
    • That funny stuff's some basic MPI, see below.
    • It can be used for making a longer desc for anything that takes MPI.
      • lsedit here=looktrap
      • then setting {eval:{list:looktrap,here}} in the look-trap's description.
• help @name - changes the name of something already created.

Success messages

Most often used on exits.

• help @success - sets the message that will be seen by the player who successfully uses the thing. Short: @succ
• help @osuccess - same as @succ but for everyone in the room not the using player. Short: @osucc
• help @odrop - used to set the message seen by everyone in the room the using player arrives in. Skip this if the exit doesn't lead to another room.
• help @drop - almost never used. In the case of exits, it's usually redundant with @succ.
  • However, you can use it to achieve particular effects, such as doors closing behind you after you arrive. First, you see the @succ message (in this case the door opening and you going through), then the room description and contents, then the @drop message (the door closing behind you). The others in the destination room would see the @odrop message (in this case the character arriving as the door closes behind *r).
  • Another idea: ships docking. @succ would be boarding the ship and then disembarking at the destination. @drop would be the ship leaving, or starting loading up, or whatever, after the character's gotten off.
  • In general, @drop is used for what happens after the character has already arrived at the destination. This is rarely needed, thus why @drop is so rarely used. But it can be useful.

Setting Up Failure

• help @lock - sets up the conditions under which things won't work. Most commonly used for exits.
• help @fail - the message seen when the player tries to use an action that's @locked so that it won't work in that particular instance.
• help @ofail - as @fail, but is seen by others in the room.

Checking Commands

• @quota gives you an idea of how many objects you have used, and how many more you can use.
  • If you don't have enough (and if you're building anything larger than a couple of rooms, you probably won't to start with), just ask a Function to bump it up. XOR or OR, primarily XOR who is the building Function.

• @check is DAMN useful, it allows you to tell what messages are missing on your rooms' actions and such.
  • Just doing @check runs it on the room you're on, you can also specify a dbref or registered name.
  • In general, ignore errors from 'things'. You won't need @succ/etc. messages on things unless you have something particular in mind.

• @find basically sifts through everything your player-object has.

Spiffy Things

The above are a lot of

Fake Objects

• Look-traps are basically things that you can do 'l (thing)' to see descriptions for. They're used largely for adding details to scenery only mentioned in the main room description. They don't show up in the contents listing, so you will have to mark them out in the room description, usually with surrounding characters of some sort ([ ] and < > being popular).
• Fake objects are similar, except that they will show up in the contents listing with [fake] after their names. They are what you see in warp squares, for example.
• look #help fake - information on setting up those.
• look #edit will let you set up those fake objects interactively.

Fake Exits

• Commands that don't go anywhere, just display a message or do something with MPI, or whatever.
  • Toss an @action on whatever you want the exit on
  • Do @link (name)=$nothing to make it not go anywhere ($nothing is basically a program that does, well, nothing).
  • Then set @succ and, if needed, @osucc and @lock and @fail and @ofail.

Parent rooms.

• If you have something that's the same on a lot of rooms, such as the same property or the same exit or whatever, using a parent room can save you a lot of work and a lot of quota.
• @dig a room, set the properties and actions you want all rooms in an area have.
  • Set those rooms' parents using one of:
    • roomedit
    • @teleport (short: @tel)
    • creating them with the parent in the first place with @dig.
• All rooms with that parent will automatically inherit all properties and exits, counting as if they had them themselves.
• You can have a chain of parents, each giving properties to the next. In fact, most of the MUCK commands are on the #0 object, a room, which contains EVERYTHING else on the MUCK through long chains of parentage.
• You can overwrite parent rooms' settings by putting the same property or action on the child room.
• If you look at the logical conclusions of both of the last two bullet items, you can do some evil things. Ask Grace if you really want ideas.

Program Listing

• programs lists 'public programs' which you can use for added functionality.
  • Usually it's just a simple matter of setting particular properties and possibly @linking an exit to the program in order to use it,
  • Do whichever command (@view or @list) is listed on the 'docs' column on the DBref number used in the first column in order to get instructions on using that program.

Noises program

• I decided to mention this programs specifically, as it's one of the more useful ones. It helps to add a bit of 'life' to rooms that really should have visible activity. Basically, the noises program displays random room messages.
• @view #295 gives the program's documentation.
  • @set here=_listen:295 (run the noise program when something happens in the room)
  • @set here=noise/chance:10 (1 in 10 chance that a noise happens)
  • @set here=noise/sleep:30 (wait 30 seconds after noise is triggered to actually "sound")
  • lsedit here=noise/list (creates the list of 'events')
    • you can just copy and paste from a text editor then enter .end
• You can do something like @set here=_listen/noise:295 instead of _listen:295, so that you can add more than one program or message under _listen/(directory).
• For examples in action, see the Night Gardens, or AgonyEcstasy Emporium's main vein and court.
• I will note that I had noise/chance and noise/sleep set on the parent (environment) room for the entire AgonyEcstasy Emporium, so I only needed to set _listen and the noise list on the individual rooms.

Puppets

• It's ALIVE, it's... Ehehe. Puppets are items that you can remote-control. Useful for common 'NPCs' and whatnot. Here are the exact steps to take in order.
  • @create [puppet name]. Creates the puppet. It helps to @reg the puppet-item.
  • @flock [puppet name]=me. Sets the puppet so that only you can force it to do actions.
  • @set [puppet name]=x sets the flag that lets it be controlled.
  • @set [puppet name]=z sets the flag that relays what the puppet sees to you.
    • This also makes it show up on whospecies but not whereare.
  • @act [control action name]=me. Creates the action you'll remote-control the robot with.
  • @link [control action name]=$nothing. Secures the action to do nothing but run the messages set on it. This is one of the MPI-related uses of this kind of action.
  • @succ [control action name]={force:[dbref or registration name of puppet],{&arg}}. Sets a success 'message' that has MPI embedded in it. This MPI takes what you type and turns it into a command sent to the puppet. And you're all set with your own remote-control thingy!
    • Note that you need to use the dbref or $[registration name] because you will be controlling it from afar, which means that just using the thing's object-name won't work because that only works in the same room.
  • To use your robot-controlling action, just type [control action name] <what you want the robot to do>. So if you did @act z=me, you would type z :bounces and says, "Hello, I am a puppet."

Whereare Setup

• It's easy to set your room to show up on wa (whereare). See wa #help
• wa #set will set the room's short description on wa.
• wa #setdir will set what wa #dir shows. Please set this so we can find your room.

Advanced Things

MPI

• A programming language, simpler to learn than most. MPI can considerably fancy up things, but in-depth knowledge is beyond the scope of many builders. One can easily pick up just little bits and pieces to add jazz, though, it doesn't require as much wholesale learning as MUF and can be inserted into any text where MPI will work. You don't have to know much about MPI to start using it.
• If you want to start learning, info mpi-intro, info mpi-intro2.
• For reference on specific MPI functions, info mpidocs and info mpidocs2 are big data-dumps suitable for saving to a big file or printing out
• mpi allows you to selectively query on particular functions.
• @mpi can be useful for testing, as well as just creating an action linked to $nothing and setting its @succ to whatever code you want to test.
• Things that take MPI are @descs and @succs and @ofails and such. A few programs take it, too.
• Things that don't take MPI: species and sex properties, say and osay settings (I've tried it, just shows the raw code).
• If you just want to get a particular thing done without bothering to code it, you could always ask around and see if you can get a code-snippet to toss in or such.

MUF

• Another programming language; requires Function permission before you can write it.
• 'programs' will let you search through the MUF programs that have been written and installed in the muck; there are many useful ones.
• MUF will take rather more work to learn than MPI. It does have more power (part of that is more direct access to the underworkings of the MUCK).

Reference Links

• [Mink] - a larger reference. Includes sections on building and on MPI.
• [Fuzzball MUCK homepage] - the Official Home of the software Puzzlebox runs on. Documention galore. And links.

You know, I wanted to write an enormous, authoritative document for Building on FuzzBall. But what I may want to create is a busy little wiki full of people who can point their friends to it when looking for an autoritative source of tips, tricks, commandments, and ideas for building things. Who'd like to help? -- Echo