A Note on Building
|
| It's important to remember that you absolutely do not have to build something onto the grid. It's assumed that you live somewhere or are staying somewhere that provides you access to Oahu. You do not need to build a home for yourself on grid to be considered as someone that lives on Oahu. Your PC can use the OOC Lanai as their home without an issue, or even the Quiet Room.
As this site makes use of the +getaroom command (A command that allows the creation of fully desc'd temprooms), no homes will be built onto the grid permanently. Just be sure to check the +housing list to see what sort of expense you're looking at in terms of where you would like to live and be sure to create your +getaroom in an area you can actually afford. (3 stars means you need Resources 5 to likely afford the place, or some combination of Resources and stunts.)
Likewise, the +getaroom can be used to create businesses for the purpose of RP. If you create a business that ends up being exceedingly popular, generates much in the way of RP, and employs multiple active PCs, you can put in a +request to have the business built permanently onto the grid.
Make sure you think through the new addition to the grid before you submit the +request to staff to build it, as we'll be discussing it with you before we actually create it.
Thanks!
- Loa
|
A Quick Overview
|
- Enter a +request/build with the idea for the rooms and the number of rooms desired. Wait for Staff to get back to you.
- When approved, grab the think num(here) ID for each room and each exit.
- @desc each room
- Tend to the exits: @desc, @osucc, @succ, @odrop, @fail, @ofail
- Complete the list in the Building Room
- Note back in your +job that the items have been completed.
- Wait for Staff to get back to you with either a big thumbs-up or a request for more detail.
|
A little Introduction
|
| If you are not sure what type of places might be available to live in in Oahu, take a look at the +housing command on the MUSH. Of course, you can always look at the property listings and different apartment rental guides online for places to live in Oahu as well.
PC-owned rooms are for more than just simply new places for role play. They tell their own story which enhances the world of Tenebrous Isles. So how do you do it?
First, think it through and make sure that your idea really will benefit the grid. As fun as it is to own a room, or to add a room to the grid, we probably don't need 30 beach bars, or even 10. We likely don't need 10 dance clubs, or 10 restaurants. Part of getting your idea for a permanent build approved will be discussing it with staff.
Second, enter a +request to "Build". Let us know in brief what you're looking for. We don't need a long, detailed explanation, just the idea.
For example, “Bill wants to open a dance club, the Blue Pigeon, that caters to the average person” is perfect. You can also put in a request for "I'd like a business built on grid, 3 rooms total please, in <name Grid area> of Oahu. It will be an MMA training studio and gym called 'Flocking Fighters, Inc.'." This is also perfect. Go ahead and give us details about what kinds of rooms you want, which room attaches to which, how many rooms and similar details for the endgame. Staff will get back to you.
Staff will “build” it for you, with the right rooms and exits between them. They will not yet be connected to the full grid, only the Building Room.
|
Basic Room Prep
|
| Once Staff has built your rooms you'll be given access to them, and then it's your turn to get to work.
Every room needs its own description, just as every character needs its own description. Write it up as detailed as you can, but without taking an entire screen to do it – PCs love having information to play off of, but no one wants to be stuck reading for five minutes figuring out where they are. Be sure to use the %r and %t commands to format it nicely.
- %r moves the cursor to a new line.
- %t creates a uniform tab.
It is also good practice at this time to record the database reference numbers for each room. Simply put yourself in one of the rooms and type:
- think num(here)
...and the MUX will spit out a multi-digit number with a trailing letter. Write it down somewhere. You can ignore the trailing alphabetic, you only need the number.
Once all your rooms have @desc in place, they will be considered “finished.” Please add to your Build +job that you believe you are done.
If you want to do more, you can!
|
Working with Exit Descriptors
|
| You can look at your exits, and - using the database number or the exit name - describe them.
...to look at the exit. The MUX will provide you with something like:
- Lounge Room;LR;lounge(#432E)
- You see nothing special.
Write down the given database number (in this case #432, ignore the E) just as you did with with the rooms.
You can @desc the exit. You might type:
- @desc LR=A velvet rope protected by a bouncer.
From now on, when looking at the exit, rather than “You see nothing special,” the PC will now see, “A velvet rope protected by a bouncer.” Before moving on, prove to yourself that it has worked.
|
|
Using Exits in Detail
|
When a PC leaves a room, the MUX standard only states a bland:
- (PC) has left.
When a PC arrives in a room where other PCs are already standing around, the MUX standard only states a bland:
- (PC) has arrived.
Let's say you want the departure to be more interesting and dramatic. You would use the command
- @osucc
This means a Success of using the exit (a PC went through it, which is what will happen 99% of the time).
What do you want to happen when someone moves from a room? What do you want everyone in the room to see when someone leaves? Perhaps you would type:
- @osucc LR=is allowed past the velvet rope.
Now when a PC leaves, everyone sees:
- (PC) is allowed past the velvet rope.
- (PC) has left.
If you want to get even more specific, you can even detail what people see when they use an exit. This would be:
- @succ (as opposed to @osucc)
You might type:
- @succ LR=The bouncer allows you past the velvet rope.
This causes the MUX to emit (“say”) to the PC (as you probably guessed):
- The bouncer allows you past the velvet rope.
The only person to see that note is the person using the exit.
What do you want people to see when someone enters a room? You might use:
- @odrop LR=flops into the lounge.
on the exit leading into that room. The MUX will fill in the name information. This will cause the MUX to emit to anyone already in the Lounge Room:
- (PC) flops into the lounge.
- (PC) has arrived.
What if something is impassable? Perhaps a locked door? Maybe in this case the PC is not allowed into the room for one reason or another on a coded basis (i.e. not just a pose). You'll rarely see this, but why not tie everything in a bow? Use:
- @ofail:
...as in:
- @ofail LR=is pushed back by the bouncer.
Now when the PC tries to get into the other room, everyone in the room will be met with:
- (PC) is pushed back by the bouncer.
Lastly, and probably not surprising, you would use:
- @fail LR=You are stopped by the bouncer
...to indicate to to only the person failing to exit.
Now when the PC tries to get into the other room and fails, they will see:
- You are stopped by the bouncer.
|
Summary
|
- Think through what your idea really is.
- Place a +request to build the rooms, with details for Staff to follow when building.
Assuming that the project gets the thumbs-up:
- Put yourself in a room (any of your rooms).
- think num(here)
- Record the number, ignore the alphabetic.
- @desc here (or #number, or name)=A description, using the %r and %t format commands. Describes the room. End it with a %r.
- Pick any exit.
- look exit (where “exit” might be LR, in this example)
- Record the number, ignore the alphabetic.
- @desc (exit)=Gives a description of what this side of an exit looks like.
- Define what people in this room will see when someone uses an exit (i.e., leaves).
- @osucc (exit)=Gives a description of what people in the room see when someone successfully uses an exit. Note that it is proper format to begin the description in lower case, immediately after the equals sign. I.e. =back-flips..
- Define what the player sees when using an exit successfully.
- @succ (exit)=Gives a description of what only the player sees.
- Define what people in the next room (i.e. on the other side of the exit) will see when the PC enters the room.
- @odrop (exit)=Someone (does something). The MUX will fill in pertinent name data. Again, note that this is what people in the other room will see.
- What happens if someone can't pass through an exit due to a coded reason (not simply role play)?
- @ofail (exit)=Gives a description of what happens to the person when they can't pass. Note that it is proper format to begin the description in lower case, immediately after the equals sign. I.e. =can't open the door.
- What happens to the person who can't pass through an exit?
- @fail (exit)=Gives an exit failure description to the PC only.
- Make sure that you have set it IC (&status here=IC)
- Make sure that you have set the location of every room on the map. (&map here=<grid reference>)
- Note in your +job that all of these things have been tended to.
- Wait patiently while Staff reviews.
|
|
