MUCK University Building Course Book0 -- Basic Syntax and Terminology Book1 -- Building 101 Book2 -- Building 102 Book3 -- Building 103 Book4 -- Building 104 Book5 -- Building 105 BookA -- Building Recipes -- Read the other books first. Final Project Guidelines You see a hardbound textbook. The cover says: MUCK Terminology & Syntax -=-=-=-=-=-=-=-=-=-=-=-=-=- by Feaelin Moilar 2004 April 6th -- ARR Type 'read book0=A1' to see what information it contains. Basic Syntax and Terminology for Builders By Feaelin Moilar When presenting the syntax of a command we will attempt to consistently use the following convention: '@example [optional stuff]' That is, the command will be enclosed in single quotes, any parameters that are _required_ will be enclosed in angled brackets/braces, and any optional parameters will be enclosed in square brackets. Additionally, I find it helpful to present this list of the official names of symbols: < > Either less than & greater than, or angled bracket/brace (left and right) [ ] Square brackets: left square bracket, etc. { } Curly-Braces ( ) Left and right parentheses ~ Tilde symbol ` Backtick ' single quote To read the next page, simply type 'next'. " double quote ! exclamation point @ AT sign # pound $ dollar sign % percent sign & ampersand * asterisk _ underscore - hyphen / forward slash \ backslash (or sometimes escape character) | Pipe (displayed as either single vertical line or a broken vertical line) + plus = equals : colon ; semi-colon . period , comma ? question mark a-z lowercase letters A-Z uppercase letters To read the next page, simply type 'next'. 0-9 digits 123 a number This is the last page of this chapter. You see a hardbound textbook. The cover says: MUCK Building Basics, 101 -=-=-=-=-=-=-=-=-=-=-=-=-=- by Wixenstyx@MUCK-U August, 2002 -- ARR Revised March 27th, 2004 Type 'read book1=contents' to see what information it contains. You turn to the contents page and read: Title Chapter --------------------------------------------------------- Introduction..............................A (3 pages) Section I (Database Item Overview)........B (4 pages) Section II (Types of DB Items)............C (3 pages) Conclusion................................D (1 pages) To read a chapter, type read book1=A1 Which displays chapter A, page 1. Chapter A: Introduction: "I can build, but I can't program..." I hear this statement (or statements along the same lines) from players all the time, and I can't help but chuckle. I know what they're trying to say -- that they understand the 'basic' Building commands, but the intricacies of MUF and MPI programming leave them confused. This is an understandable sentiment, but it reflects a very common misconception among the MUCK user population -- that 'Building' and 'Programming' are two different things. This differentiation between Building and Programming is probably simply a matter of terminology. Early MUCKers understandably used 'Building' to describe the aspect of MUCK programming focused on creating and directly manipulating the Database Items that constitute a MUCK, and 'Programming' to describe the scripting of these items using the FORTH language derivative MUCKs employ (AKA MUF). But the use of these terms has evolved to the point where players seem to erroneously assume that Building is a kind of game of folly that any moron can master, whereas MUF and MPI are serious programming which require superior intellect to understand. I'm here to tell you, as a MUCKer of no great distinction who has to varying degrees mastered all three, that neither of these statements could possibly be To read the next page, simply type 'next'. farther from the truth. Building isn't easy when it's done well, and MUF and MPI are not necessarily more intellectually challenging. All three are programming languages, and all three require creative thinking, an understanding of what you're doing and how to get there, and strange-sounding commands that produce an end result given various pieces of information. I would even go so far as to say that if anything, building is the hardest of the three to learn, and the most important; MPI and MUF are both useless to players who do not have a firm grasp on the ins and outs of Building. In fact, when I sit down to try and teach MUF or MPI to those who claim 'I can build, but I can't program', 99.9% of the time I find that the problem isn't in the player's intellect or some inborn lack of programming talent. Instead, the problem is that they are trying to write a MUF program with only a working knowledge of building commands. This is like trying to skip before you really know how to walk. This is why, on MUCK U, you HAVE to pass the building quizzes before you can enroll in any of the other courses. You'll note, too, that this includes Administration. Having been an administrator of a number of games and a player on countless others, I've come to the conclusion that one can NOT run a MUCK effectively without an understanding of how the gamesides of MUCKs are created and how they work. To read the next page, simply type 'next'. Building is Programming. And as with any Programming Language, learning how to build and building well is much easier when you have a good grasp on the basics. This book provides a detailed, builder's-view look at Database Items, the 'raw materials' of building. END OF CHAPTER A This is the last page of this chapter. Chapter B: What is a 'Database Item'? Database Items are, as stated previously, the 'raw materials' that make up the gameside MUCK. In their purest form, MUCKS are merely a collection of hundreds and thousands of Database Items that have been shaped and manipulated to look and behave like a little world. There are some qualities that all Database Items possess, regardless of type. They are: 1. A Unique Database Reference Number (AKA dbref#, dbref, ref#, etc.) 2. Name 3. Timestamps, Usecounts, and Memory Usage. (i.e., last modified date/time) 4. Flags (Type and Permissions determination) 5. Properties (Information Storage) Here's a more in depth look at each: 1. Database Reference Numbers Database Reference Numbers (dbref#s) are assigned to Database Items when they are created. They are unique and the most reliable way to access an item, especially if you aren't in the item's immediately proximity. To read the next page, simply type 'next'. One thing that is important to note: Dbref#s are unique, but they may be reassigned if the Database Item they belong to is recycled. Recycling a Database Item doesn't actually destroy it -- it really converts it into what is known as a 'Garbage' item. The next time a player -- any player -- executes a creation command, the dbref# is assigned to the new Database Item. This is an efficient setup; nothing is wasted. The only problem this recycling process presents is due to the fact that most MUCK Databases do not cross-check all dbref#s (locks, for example, are not checked) on existing Database Items when a given Item is recycled. As a result Players sometimes find their belongings locked to peculiar things without knowing why or how it happened. This is usually the result of one Item being recycled and another created that took its place. 2. Name Simply the name of the database item. Many database items can be referred to by name, although the item must be "present" either in the player's inventory, or in the same room that the player is located in. 3. Timestamps, Usecounts, and Memory Usage When an item is newly created, it is immediately stamped with the current date and time. Further, when the database item is modified, another timestamp is To read the next page, simply type 'next'. updated accordingly. Lastly, a database item has both a timestamp and a "usecount" that is updated every time the item is "used". What the server regards as "using" the item varies from type to type. A good example of "using" a database is simply connecting to your player. You'll find that while you are connected, your "last use" time will be the current time. Finally, the server keeps track of how much memory a given database item is using, expressed in bytes All of this information can be seen by using the 'examine' command: 'ex me' or 'ex #123', etc. 4. Flags Flags are probably the most enigmatic parts of MUCK Building. Simply stated, Flags designate who may do what with the Item, and how the Item behaves under various circumstances. (And yes, that IS about as simply as I could state it.) Flags are abbreviated using letters after the Item's dbref# when the dbref# is displayed. For example: Wixenstyx(#231PBJCMW4) In such displays, the first letter (P, in this case) is a "Type" flag. It designates what TYPE of Database Item Wixenstyx is..in this case, a Player. Type flags are permanent and cannot be unset or reset to something else. The other flags are toggled permissions flags.. Builder (gives Wix the permissions she needs to build), Jump_Ok (allows other players to teleport to her), Color (Enables color settings in GLOW), Meeper (allows her character to To read the next page, simply type 'next'. parse MPI commands), and W4 (Highest Wizard setting). These flags can be set using the command, @set =. You'll learn more about Flags in another course. 5. Properties Properties are, in the purest sense, information storage slots. A database item's name, its description, the messages displayed when it is used, its locks, etc. are all stored in properties. These properties are read and manipulated by the server, MUF programs, MPI programs or building commands. To see the full property directory on an object, type 'examine =/'. ----END OF CHAPTER B This is the last page of this chapter. Chapter C: The Five Types of Database Items Since most of us aren't in the habit of thinking of MUCK components as generic 'Database Items', I'd probably be smartest here to outline the various types of Database Items to make them easier to understand. There are, as the title states, five Types. They are: 1. Rooms 2. Players 3. Things 4. Actions / Exits 5. Program Objects The qualities that distinguish one Database Item Type from another include: A. Their Type Flag B. What they can and cannot 'Contain' without the use of a MUF program or MPI. C. What they can or cannot be 'contained by' without the use of a MUF program or MPI. D. How they behave with respect to a Player as destinations for triggered Actions/Exits. To read the next page, simply type 'next'. (Just to keep things simple, we won't worry about "D" right now.) Below is a rundown of each of the Types of Database Items and the other qualities they possess: 1. Rooms Rooms make up the 'virtual space' of a MUCK. They are designated with the Type flag 'R', and may contain anything, including other Rooms.** However, Rooms can only be contained by other rooms. 2. Players Players make up the reason for a MUCK's existence. They are Database Items controlled by incoming connections, and are designated by the Type flag 'P'. They may contain Objects/Things, but can only be contained by Rooms without the use of MUF or MPI. 3. Things Objects are the most 'basic' of MUCK database items. For this reason, they are the only Database Item type that has no Type flag. Things can be contained by rooms or players, but cannot contain anything themselves without the use of MUF or MPI. It is possible, however, to @teleport one thing into another, and some To read the next page, simply type 'next'. MUCKs do permit Things to be '@forced' to 'get' other Things. ** More on this in the 'Parenting' course. 4. Actions/Exits Actions/Exits are the basic manipulating bodies of a MUCK. They are responsible for moving things and players around and for triggering programs. They are designated by the type flag 'E', and are unique among database items in that they cannot contain or be contained by anything. Instead, Actions are located on a 'source' (which can be anything except for another action) and linked to a 'destination' (which can be anything including another action). 5. Programs or Files Program Database Items on MUCKs are basically inert and used only for storing information pertinent to the program, and as destinations for triggering Actions. They are designated by the type flag 'F' and can be contained by Players or Rooms, but not Objects except as stated above. However, they cannot contain any other database items themselves. ----END OF CHAPTER C This is the last page of this chapter. CONCLUSION.... Congratulations if you've read this far! You have just completed the most important (and, of course, the most boring) course in Building. Go take the Quiz in Tiny Hall, Room 101 to see how much you've learned! This is the last page of this chapter. You open the book and turn to the table of contents. It says: =============================================================== Title Chapter --------------------------------------------------------------- Introduction: Review of 101.........................A (2 pages) Creating Objects....................................B (1 pages) Customizing Objects.................................C (8 pages) Technical Information...............................D (4 pages) =============================================================== To read a chapter, type 'Read Book2=A1' Which will display chapter A, page 1. Chapter A: Introduction -- Review of 101 Before we launch into the practical exploration of Building, let's review what we learned in 101. The chart below displays the five types of Database Items and the properties discussed in 101. ====================================================================== Item Type TypeFlag Can Hold... Can Be Held By... ---------------------------------------------------------------------- Room R All Rooms Players P Things, Programs Rooms Things Things, Programs Rooms, Players, Things Actions/Exits E Nothing Rooms, Players, Things Programs F Nothing Rooms, Players, Things ======================================================================= Note that some of the hold/held by capabilities MAY be overridden using Administrative permissions, MUF or MPI. This chart reflects the standard setup for mortal builders without MUF or MPI conventions. We'll now move into a discussion of creation and basic setup for Things. To read the next page, simply type 'next'. *BZZT* I'm sorry..that is incorrect. Please try again. ------ End of Introduction This is the last page of this chapter. Chapter B: Creating Things -=-=-=-=-=-=-=-=-=-=-=-=-=-=- It's time to do some actual building, and we'll start with the most 'typical' Database Item: the 'Thing'. Please note that many MUCKs use the term 'Object' to mean 'Thing'. Unfortunately, they also use the term 'Object' for 'Database Item', resulting in much confusion. MUCK University's courses will use the terms 'Thing' and 'Database Item' exclusively. What follows is an overview of the steps involved in creating a complete thing. Following is a typical building script for a thing. You may wish to refer to the script as an example as you read through the overviews. Creating a Thing: @create [=] The @create command is used to generate a new thing. You may elect to use the argument to alter the value of the thing, but be warned that not all MUCK formats still respect this format. GLOW, for instance, will take away coins, but the value of the thing will remain unchanged. This is the last page of this chapter. No more pages to display. Chapter C: Customizing Thinngs (@Commands and @Messages) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Okay... This is the good part. On MUCKs, you can customize some aspects of your Thing using special commands called @Commands (@Link, @Lock, @Name, @Chown, @Chlock and @Flock). You can also customize the messages shown to Players who interact with your thing using @Messages (@desc/@idesc, @succ/@osucc, @fail/@ofail, and @drop/@odrop). A. @COMMANDS 1. @Name: @name = You'll only need to use this command if you decide to change the name of your Thing after it's created. It's handy to know, though. 2. @Link: @link = This command sets your thing's 'Home'. This is important, because the thing's home is where it is sent to when the thing is swept or some other casualty affects it. A Thing may be linked to a Room or a Player. The MUCK will usually default to set the thing's home to whatever room you're standing in at the time (if you own the room) or to your home (if To read the next page, simply type 'next'. you don't). Things set with the 'sticky' flag will go home when dropped. 3. @Lock: @lock = This command determines who may or may not pick up your Thing. Valid @Lock keys include: * Players (only named players can pick up the thing) * Rooms (Thing may only be picked up by players standing in this Room ) * Other Things ( Only Players carrying a specific Thing can pick up the Thing.) * MUF Programs ( More on this later. ) Lock Keys may include boolean 'switch' characters that enable you to compound to whom or to what the the thing is locked. These switches include: ! -- AKA "Not", | -- AKA "Or", and & -- AKA "And" Suppose, for example, you have an thing called "Stuffed Dog" that you wish to @lock so that only you and your friend, Joe, can pick up. You would set up the lock this way: To read the next page, simply type 'next'. @lock Dog=me|Joe Note that we use 'OR' there, not 'AND'. Using 'AND' requires that the prospective player fulfill BOTH qualifications, and let's face it..you can't be yourself and Joe at the same time. A quick note: If Joe is not in the room with you, using the command above will return an error of 'I don't see that here.' In this case, use the "*" symbol in front of Joe's name to instruct the MUCK to search for him outside of the room. @lock Dog=me|*Joe (Lock setup when Joe is not with you.) We'll go into more about Locking when we discuss Exits/Actions. 3. @Chown: @chown 'Chown' is shorthand for 'Change Owner'. You would use this command to 'claim' an thing that belongs to another player. Please note, though, that this command only works if two conditions are met: A. The thing has a Chown_OK (C) flag set, and To read the next page, simply type 'next'. B. You pass the thing's ChownLock key. Those are the commands you will most often need to know. The two that follow are special-case commands that need only be used under very specific circumstances: 4. @ChownLock: @chlock = This command sets the ChownLock key, thereby defining who may take possession of the thing when its Chown_Ok flag is set. The 'key' rules here are basically the same as those listed above for @Lock. @ChownLock is a comparatively new MUCK convention, and is available only on FuzzBall MUCKs and FuzzBall derivatives (Glow, NMC, Proto, etc.) 5. @ForceLock: @flock = This command, like ChownLock, is a Fuzzball convention. It determines which players may 'force' an thing to perform an action of some kind. Since @Force is an Admin-only command, though, @forcelock only has applications for players who are using the {Force:} command in MPI. Again, the 'key' rules are the same as those used in @lock. To read the next page, simply type 'next'. @MESSAGES @Messages fall into two categories (which will make sense as we get further into the explanation here). There are plain-old @messages, which are shown to the player who is interacting with the thing, and there are @Omessages, which are shown to the rest of the players in the room when a player interacts with the thing. There are several technical considerations to be recognized when dealing with @messages versus @omessages, however. You should be aware of them, even though many of them won't really be useful to you until later: All @Messages (@desc, @idesc, @succ/@osucc, @fail/@ofail, and @drop/@odrop. * Can be set as MPI commands, and will be parsed. * Can be set as MUF program calls, which will be executed. * May respect ANSI tags, depending on the MUCK version and local changes. @Messages: (@desc, @idesc, @succ, @drop, and @fail) * Are reported as typed, with nothing added or deleted. * Do not recognize or make use of %pronoun substitutions. @OMessages: (@osucc, @odrop, and @ofail) * Are reported with the name of the interacting player prepended to the message. * Recognize and make use of %Pronoun substitutions. To read the next page, simply type 'next'. @Messages can sometimes be the determining factor between a well-built Thing and a shoddily-built one. A good builder will use as many @messages as are applicable to the Thing. 1. @describe = This will set the message show to a player when he or she looks at the thing (look ). While it's good to be descrip- tive and detailed, keep in mind that the @desc field is fairly small. This can be extended using LSEDIT, if you prefer, but Players generally appreciate shorter descriptions. If they have to backscroll to read, most won't bother. 2. @idescribe = This message is only really necessary if you're planning to turn your thing (with MUF/MPI assistance) into a vehicle. The Idesc on an thing shows to players who are sitting inside it. (Think of how the inside of a car looks compared to the outside.) 3. @success/@osuccess ( @[o]succ =) Players will see these messages when the thing is 'successfully' picked up. The @success is shown to the player who picks up the To read the next page, simply type 'next'. Thing (AKA the 'effective player'), and the @osuccess is shown to everyone else in the room. Remember that the @osuccess will appear with the name of the effective player stuck onto the beginning (prepended). 4. @drop/@odrop (@[o]drop =) Players will see these messages when the thing is dropped. The @drop is shown to the player who is dropping the thing, and the @odrop is shown to everyone else with the effective player's name prepended. 5. @fail/@ofail (@[o]fail =) Fail messages are really only necessary if the thing is @locked in some way. These messages are shown to players who attempt to pick up the thing, but do not pass the lock (thus, 'failing' to pick up the thing'). Format for these is the same as described above. And that's it! Once you've created your object, set its value and its home, @locked it if necessary and set all applicable @messages, your Object is complete! Congratulations! To read the next page, simply type 'next'. Now, if any of the above seemed confusing, check out the sample Object Building script below. It will probably help make the @messages/@omessage formats easier to understand. Comments are in parentheses and would not actually be typed in. [----------------------------- EXAMPLE -------------------------------] @create Magic Ring @describe ring=You see a beautiful gold ring with a red ruby cabochon set into it. It glimmers in the light as you look at it. @idesc ring=You find yourself inside the ruby cabochon of the Magic Ring! Everything looks so...so RED! @lock ring=me (Only I can pick up the ring.) @chlock ring=me (Only I can @chown the ring.) @flock ring=me (Only I can Force the ring.) @succ ring=You pick up the ring and put it on. @osucc ring=picks up the ring and puts it on. @drop ring=You remove the ring and set it down. @odrop ring=removes the ring and sets it down. @fail ring=You reach for the ring, but find you cannot reach it! A kind of bluish force field zaps your hand when you try. @ofail ring=reaches for the ring, but a kind of bluish force field appears around it, zapping %p hand.* [------------------------------- END ---------------------------------] This is the last page of this chapter. Chapter D: Miscellaneous Concerns -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- A. %Pronoun Substitions Notice how the @ofail in the example script in section 2 includes a "%p" This is what is known as a '%pronoun substitution'. In any @Omessage, a MUCK will replace a '%_' with an word appropriate to that player, usually based on the player's gender. Other %substitution values may be used, but nearly all MUCKs recognize the %pronoun substitutions, as detailed below: =================================================================== %Pronoun Type of Pronoun Male Female Neuter Not Set ------------------------------------------------------------------- %s Subjective he she it Name %o Objective him her it Name %r Reflexive himself herself itself Name %p Possessive his hers its Name's =================================================================== If your %pronoun needs to be capitalized (as when it's used at the beginning of To read the next page, simply type 'next'. a sentence), just capitalize the letter: %S, %O, %R, %P ....TO READ ON, TYPE Read Book2=3B B. @Message/@Command Properties @Messages and @Lock strings are stored in properties on the object. If you're curious as to where the messages are stored, here's a quick rundown: ============================================= @MESSAGE ASSOCIATED PROPERTY --------------------------------------------- @lock _/lok: @flock @/flk: @chlock _/chlk: @desc _/de: @succ _/sc: @osucc _/osc: @drop _/dr: @odrop _/odr: @fail _/fl: @ofail _/ofl: @idesc _/ide: To read the next page, simply type 'next'. ============================================= C. Flags on Things As previously noted, Flags enable certain permissions to be toggled on and off. In some cases, they affect how a Thing behaves when a player interacts with it as well. The trouble with Flags is that they often change from one MUCK format to the next. Below are some flags typically availabe for use on Things and the effect they have: ======================================================================= Flag Flag Name Effect ----------------------------------------------------------------------- C Chown_Ok Enables another player to take ownership of the Thing. (See @chown and @chownlock above.) D Dark* Sets the object so that it does not appear in the inventory of the room or player that holds it. S Sticky When the object is dropped, it returns home. V Vehicle Permits the Thing to hold Players, enables the @IDesc. Z Zombie This makes a Thing into a kind of puppet that a player can control. Control usually requires To read the next page, simply type 'next'. the MPI {Force:} command or a MUF program, but Players who own Zombie-set objects can see what the object sees/hears. ======================================================================= * -- Only a Wizard can set this flag. The @set command is used to set and unset flags. To set a flag, type: @set = To unset the flag, type: @set =! ----- End Chapter D. This is the last page of this chapter. You open the book and turn to the table of contents. It says: =============================================================== Title Chapter --------------------------------------------------------------- Introduction: Review of 101.........................A (2 pages) Creating Objects....................................B (1 pages) Customizing Objects.................................C (8 pages) Technical Information...............................D (4 pages) =============================================================== To read a chapter, type 'Read Book2=A1' Which will display chapter A, page 1. You open the book and turn to the table of contents. It says: =============================================================== Title Chapter --------------------------------------------------------------- Introduction: Review of 102........................A (2 pages) Setting Up Players.................................B (6 pages) Setting Up Rooms...................................C (7 pages) =============================================================== To read a section, type 'Read Book3=A1' Which will display chapter A, page 1. Chapter A: Introduction -- Review of 102 This is just a quick rundown of the commands covered in 102 and their functions. Command Function @Create Creates a New Thing @Name Changes an Thing's Name @Link Sets the Thing's Home @Lock Determines who may pick up the thing. @Chown Changes the ownership of the Thing to another Player. @Chlock Determines who may @Chown the Thing when it is has a Chown_OK flag set. @Flock Determines who may use {Force:} commands on the Thing. @Success Sets the message the Effective Player sees when he picks up the Thing. @oSuccess Sets the message the rest of the room sees when a Player picks up the Thing. @Drop Sets the message the Effective Player sees when he drops the Thing. @oDrop Sets the message the rest of the room sees when a Player To read the next page, simply type 'next'. drops the Thing. @Fail Sets the message the Effective Player sees when he tries pick up the Locked Thing and doesn't pass the Lock Key. @oFail Sets the message the rest of the room sees when a Player tries to pick up the Locked Thing and doesn't pass the Lock Key. @set Sets and Unsets Flags on the Thing Most of these same commands apply when setting up Players and Rooms as well. So,without further delay, let us move on! ------ End of Introduction This is the last page of this chapter. Chapter A: Introduction -- Review of 102 This is just a quick rundown of the commands covered in 102 and their functions. Command Function @Create Creates a New Thing @Name Changes an Thing's Name @Link Sets the Thing's Home @Lock Determines who may pick up the thing. @Chown Changes the ownership of the Thing to another Player. @Chlock Determines who may @Chown the Thing when it is has a Chown_OK flag set. @Flock Determines who may use {Force:} commands on the Thing. @Success Sets the message the Effective Player sees when he picks up the Thing. @oSuccess Sets the message the rest of the room sees when a Player picks up the Thing. @Drop Sets the message the Effective Player sees when he drops the Thing. @oDrop Sets the message the rest of the room sees when a Player To read the next page, simply type 'next'. drops the Thing. @Fail Sets the message the Effective Player sees when he tries pick up the Locked Thing and doesn't pass the Lock Key. @oFail Sets the message the rest of the room sees when a Player tries to pick up the Locked Thing and doesn't pass the Lock Key. @set Sets and Unsets Flags on the Thing Most of these same commands apply when setting up Players and Rooms as well. So,without further delay, let us move on! ------ End of Introduction This is the last page of this chapter. Chapter B: Setting Up Players -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Now that you've mastered Thing setup, you'll find that the other Database Items are just variations on the theme. Players, for instance, are basically just jazzed-up Things. Setting up your Player involves many of the same messages and commands that you use when setting up an Thing. The difference is in how these messages and commands are handled, given the specialized nature of Players. A. Creating a Player: @Pcreate = The @PCreate command can only be used by Wizards, but I felt it important to note that @PCreate takes care of a number of small issues: 1. Sets the Player's 'value' to whatever the MUCK's designated 'Start_Pennies' value happens to be. 2. Sets the Player's 'Home' to whatever the MUCK's designated 'Player_Start' room happens to be. 3. Moves the new Player to Player_Start. To read the next page, simply type 'next'. Player_start and Start_Pennies are both MUCK attributes that Wizards can tinker with using the '@Tune' command. If you are pursuing the Administration program at some point, you will learn more about this there. B. Customizing a Player: @Commands and @Messages Again, Players are just customized Things, so most of the same @messages and @commands are used for setup. Because Players serve a modified purpose, though, some of the @commands use varied formats, and some of the @messages are shown at unexpected times. @Commands 1. @Name: @name me= Not all MUCKs allow players to rename themselves. If this command IS available, you will be required to present your password before it will work for you. 2. @Link: @link me= This command does the same for Players that it did for Things -- sets their 'home'. In most cases, Players may set their Homes to any room they own OR a room that has its "Abode" (A) flag set. An interesting thing to note -- To read the next page, simply type 'next'. players who are 'killed' in the game are sent home, and the 'Home' command on most MUCKs will also take you home. In both cases, any items your Player carries will also be sent to THEIR homes. 3. @Lock: @lock me= This is where Players begin differing from Things. Because Players cannot be 'picked up' by other players (MUCK Singles' Bars notwithstanding), @LOCK on players was modified. The 'Key' here will determine who may rob you of coins and who may not. The Lock rules remain the same, but most people just @lock me=me and leave it at that. To remove a Lock, type '@Unlock me' 4. @Chown, @Chlock, @Flock None of these commands have applications with Players. Players always own themselves, thus @Chown and @Chownlock are useless. @Forcelock has no effect, either. @Messages 1. @Success/@OSuccess Robbing isn't exactly a big sport on MUCKs these days, but if you happen to decide to try it (Rob -- if they're not @locked against you, you'll get a whole currency unit for your trouble.) and succeed, the @Succ and @OSucc of the player your robbed will be displayed to you and the room, To read the next page, simply type 'next'. respectively. 2. @Fail/@OFail You've probably guessed this by now. When you try to rob a player who has himself @locked to a key you cannot pass, the @Fail and @OFail are the messages you and the room will see. 3. @Drop/@ODrop As a throwback to the early days of MUCKs, when they were designed to be used as Text Adventure games, there is a 'kill' command that is part of the general makeup of a MUCK. Killing a player results in that player being sent home (and sometimes paid an "insurance settlement") and all of his or her belongings being sent to THEIR respective homes. Since Players shouldn't be 'dropped', the MUCK designers of old assigned Drop/ODrop the task of appearing when a someone kills your player. 4. @Desc/@IDesc These @messages behave just as they do with Things. The @IDesc isn't usually necessary, though, as Players just don't usually carry other Players around. It can only be accomplished with the help of an administrator. To read the next page, simply type 'next'. C. Player Flags As with objects, the flags available one some MUCK servers are not always availabe on others. Below is a list of the most commonly available offerings and what they do. Check your local MUCK's helpfiles for more information: Flag Name Flag Effect Author A Player sees dbref#s on objects, even those he does not control. Builder* B Gives Player permission to use Building commands. Color C Enables ANSI-capabilities for the Player (GLOW) Dark* D On some MUCKs, this will hide a player from the WHO list and the contents list of a room. Guest* G Player restricted to rooms set 'Guest'. (GLOW) Haven H Player will not receive Pages. In_Character I Player is listed in WHO listings as 'IC'. Jump_OK J Other players may use Actions/Exits to reach the Player. Kill_OK* K Other players may use the 'kill' command on the Player. Meeper* M Player may use MPI (Glow only.) MuckerN* MN Player has MUF programming capabilities. (N may range from 1-3 or so, depending on the MUCK.) Quell Q Wizard Player will be treated as a Mortal. To read the next page, simply type 'next'. Silent S Player will not see dbref#s, even on items he or she controls. Wizard* WN Player has administrative powers (N is a range from 1-3 or 1-4 on most MUCKs) * -- Denotes Flags that MUST be set by a Wizard in most cases. ----- End Chapter B This is the last page of this chapter. Chapter C: Setting Up Rooms -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rooms make up the 'virtual space' of a MUCK. They are, like Players, modified 'things' that make use of many of the same @commands and @messages as object. Their specialized function, though, means that not all @commands are used, and those that are function in unexpected ways. A. Creating a Room: @DIG Making a new room is, in itself, very simple: just @dig However, this brings us to a more complicated subject called 'Parenting'... Parenting -- An Overview As we've already established, one of the fundamental properties of Rooms is that they can only be contained by other Rooms. This begs the obvious question, though: why would you bother putting one room inside another? The answer is a phenomenon known as 'inheritance'. One room sitting inside another room creates what is sometimes called a MUCK 'environment'. The container room is called a 'Parent', and the room it contains is called a 'Child'. As with MUSH parenting (if you're familiar with that), the Child Room 'inherits' certain attributes from the Parent Room, namely: To read the next page, simply type 'next'. 1. access to Exits/Actions and 2. any information set in properties. What this means is that a player in a Child Room can take advantage of not only the exits/actions that are set on the Child Room itself, but also those set on the Parent room that holds it, the Parent's Parent, and so on up the environment. So..if Room A has an action called 'GoHome' on it, and Room A contains Room B, Players in Room B will also be able to use the 'GoHome' action. Parent Rooms are handy for organizing MUCKs into regions. For instance, if a MUCK is a Role-Play MUCK, MUCK administrators may elect to have one are of the game set up for OOC (out of character) interaction, while another part of the game is set up for IC (In character) interaction. By putting the OOC rooms in an 'OOC Parent', and the IC rooms in an 'IC Parent', the Administrator can control which commands players have access to depending on which area they are in. To set a room's parent, you simply need to @teleport the room into the appropriate parent room. (@tel here=) If you do not own To read the next page, simply type 'next'. the Parent room, you may need to seek the help of an administrator to accomplish this. (Make sure you have the owner's permission first!) You can also set a room's parent on creation by typing: @dig = B. Customizing your Room (@Commands and @Messages) @Commands: 1. @Name: @name here= Pretty obvious -- this renames the room, just as it does with other Database Items. No special parameters or arguments required. 2. @Link: @link here= This is interesting. @Linking a room to something (a Room or an Thing) sets up what is known as a "DropTo". This means that when a Player in the Room drops an thing, that thing will be transferred to the Room's 'DropTo'. There only exception would be an thing that has a 'sticky' flag set, as such an thing would be teleported to its home, not the DropTo. To remove a DropTo, type: @unlink here 3. @Lock: @lock here= To read the next page, simply type 'next'. @Locking a room determines who can and who cannot see the room's description. Strange, yes, but true. To remove a Lock, type '@Unlock here' 4. @ChownLock: @Chlock here= As with things, this determines who may @Chown the room if the Room has a Chown_Ok flag set. @Messages 1. @Success/@Osuccess These messages are displayed when a player successfully looks at the room. A caveat here -- @Osuccess messages on rooms tend to become very annoying very quickly, so most Builders do not use them. @Success, on the other hand, is very nearly always used, but only to trigger a MUF program that will display the Obvious Exits in a room. (@succ here=@$ObvExits, in most cases.) 2. @Fail/@OFail These messages are displayed when a player fails to pass the Room Lock. The room's description is not displayed when the player types 'look'. Locking a room against someone is rarely useful, though, so again, these messages are rarely used. To read the next page, simply type 'next'. 3. @Drop/@ODrop If a room has its Dropto set, the @drop and @odrop will be displayed when a player drops an object in the room and the object is transferred to the DropTo location. 4. @Desc/@IDesc @Describing the room sets the room description everyone sees. @IDescriptions have no practical applications on Rooms. D. Room Flags The following chart displays the flags that may be set on Rooms and their effects. As always, flags differ from MUCK to MUCK, so check your local MUCK's helpfiles for more information. Flag Name Flag Effect Abode A Any player may @link themselves to the room. Builder B Players may not use personal exits while in the room. Chown_OK C Players may take ownership of the room, if they pass the ChownLock key. Dark D Room will not display its inventory. Guest G Allows players set 'Guest' to enter. To read the next page, simply type 'next'. Haven H Players may not use the 'Kill' command in the room. Jump_OK J Players may use personal exits to reach the room. Link_OK L Players may link exits/actions to the room. Meeper M Room Desc/@messages will parse MPI commands (Glow) Sticky S If a DropTo is set, Objects dropped in the room will be transported to it only when all Players leave the room. Tinker T Wizards of lower levels may examine but not change Room settings (Glow) E. Sample Room Script [--------------------- Begin Example ---------------------] @dig My Room (should tell you the dbref# of your new room) @tel me=#1234 (dbref of My Room) @tel here=#1233 (dbref of your Parent room, if you have one) @desc here=You are in my room! @link here=My Briefcase @lock here=me @succ here=You look around. @osucc here=looks around the room. @fail here=You look around, but you can't see anything! @ofail here=looks around, but can't see anything! To read the next page, simply type 'next'. @drop here=You drop your object, and it disappears in a flash of light! @odrop here=drops something. It disappears in a flash of light! [----------------------- End Example ---------------------] In the next book (104) we'll discuss Actions/Exits! So stay tuned! ---- End Chapter C This is the last page of this chapter. You open the book and turn to the table of contents. It says: This book dedicated to Perelaai. Happy Birthday, handsome! July 7, 2003 Wix =============================================================== Title Chapter --------------------------------------------------------------- Introduction: Review of 103.........................A (1 pages) Exit or Action?.....................................B (1 pages) Anatomy of an Action................................C (3 pages) Setting up Actions..................................D (4 pages) Putting it into Practice I -- Commands..............E (3 pages) Putting it into Practice II -- Exits................F (4 pages) Other Considerations................................G (3 pages) =============================================================== To read a section, type 'Read Book4=1A' Chapter A: Introduction --Review of 103 Before we get into exits, let's review what we've learned about players and Rooms: Command Player Room ================================================================================ @pcreate Creates a new player object (wiz) -- @dig -- Creates a new Room (builder) @Link Sets a Player's 'home' Sets a Room's DropTo @Lock Determines who may 'rob' player Determines who can see the Succ @Succ/OSucc Shown when successfully robbed Shown when look is successful @Fail/OFail Shown when rob attempt is thwarted Shown when look is unsuccessful @Drop/Odrop Shown when Player is 'killed Shown when DropTo is triggered @Desc Sets the Player's description Sets the Room's description @Set Sets/Unsets Flags Sets/Unsets Flags Now that you've mastered the three major static building objects, it's time to move into the magical world of 'manipulation', that is, making Things, Players and Objects move around relative to each other within the game. For this, of course, you need to learn about Exits. This is the last page of this chapter. Chapter B: Exit or Action? ========================= Before we can get into the mechanics of setting up an Exit, it is important to clarify exactly what an Exit/Action really is. If you ask most avid MUCK players to define the term 'exit', they'll probably tell you it's a door that leads from one room into another. Given that A) they ARE called 'exits' and B) allowing a player to move from one room to the next is easily the most common use of these database items, this perception of them is not at all unexpected. But it is, in the strictest sense, incorrect. In fact, some builders even object to calling them 'exits' at all, though this is the accepted term for them. 'Exit' implies a kind of hole that allows Players to move back and forth from one room to the next. However, as you will see, this isn't at all how exits work, and this perception sets up new builders for a lot of confusion. For that reason, try to think of exits as 'actions'. The terms 'Action' and 'Exit' are used more or less interchangeably in building, but 'action' really is the most accurate description of what they are and how they work. This will (hopefully) be clearer as we discuss the various ways exits/actions work. This is the last page of this chapter. Chapter C: Anatomy of an Action =============================== Actions serve as connections between two other database items. Without them, Rooms, Things, Players and Programs would simply exist, with no other way to interact with each other. For this reason, the properties that apply to other database items (having a home, being able to 'hold' things, having a monetary value, etc.) do not apply to Actions. Actions always interact with two other database items. The first, called the 'Source', is the item where the action is actually located. The second, the 'Destination', is established using the @Link command, and determines what exactly the Action causes to happen when it is triggered by a player. The chart below details out exactly what happens when certain database items are linked to others via an action. When the Source And the Destin- This will happen when the Object is: ation Object is: action is triggered by a player: A Room Another Room Move the player into the next room. A Room A Player Will move the triggering player to To read the next page, simply type 'next'. where the other Player is. A Room An Object Will bring the object to that room. A Player A Room Moves the Player to the Room. A Player Another Player Moves the Player to where the other Player is. A Player An Object Brings the object to the Player. An Object A Room Moves the Player to the Room. An Object Another Player Moves the Player to where the other Player is. An Object Another Object Brings the Dest object to the triggering player, sends the Source object to its home. Anything A Program Runs the MUF program. Like other Database objects, Actions do use @messages, but the ones displayed when they are triggered depend on the Source and Destination. The general rules of thumb, though, are listed below: @Message When Displayed @Desc When someone looks at the action itself. @Success To the effective player, when the action is triggered. @OSuccess To the rest of the Source Room, or the room where the To read the next page, simply type 'next'. CampusNet>> 2013-May-10 08:09:54: Pangie says, "He's okay. No broken bones, even!" source is located, when the action is triggered. @Drop To the Player, when the destination is reached. @ODrop To the rest of the Destination room, or the room where the destination is located, when the action is completed. @Fail To the effective player, when a locked action is attempted. @OFail To the rest of the Source Room, or the room where the source is located, when a locked action is attempted. This is the last page of this chapter. Chapter D: Setting up Actions ============================= Because of the unique nature of Actions, setting them up can be interesting. Initially, you must make sure the following things are true: A. That you either own or control (if you're a wizard) your intended Source object. B. That either you own the Destination database item, or the database item has an L (Link-Ok) flag set. Once those requirements are in place, you can proceed. As it happens, there are two sets of commands you can use to set up an Action. 1. The @Action-@Link Combo This method was the earliest way to set up an action. It's also the least convenient, but probably the most easily understood. Format is as follows: @Action = @Link = Viola! A completed action. 2. The @Open Technique To read the next page, simply type 'next'. This command was developed later, as 'actions' became more widely known as 'exits'. The nice thing about @Open is that it sets up the source and destination in one step. The annoying thing about it is that it assumes the source you want is the room you're standing in, and there's no good way to convince it otherwise. @open = Other Action-related commands you should be aware of: 1. @Attach -- used to change an action's source. If you accidentally create an action on your character that was intended to be on the room, you can simply: @attach = 2. @Unlink/@Link -- Used to change an action's destination. If you accidentally @link an action to the wrong thing, you can simply: @unlink @link = 3. @Relink -- NOT supported by all MUCK formats, but this command actually combines the @unlink and @link commands into one command for To read the next page, simply type 'next'. setting a new destination for an action. @relink = Finally.. One last word about Action Names To trigger an action, you simply type the name of the action and you're off. But what if you don't WANT to type out 'North [n]' every time you want to head in a northbound direction? Action naming supports a wonderful feature called 'aliasing', which simply means that you can set up an action so that it can be triggered using any of several typed commands. For example: @action North [N];north;nort;nor;no;n;out;leave;exit=here @link North=#1234 (destination room) In this example, players wishing to go through the 'north' exit can type any of the following to move into the room to the north: 'north [n]' or 'north' or 'nort' or 'nor' or 'no' or 'n' or 'out' or 'leave' or 'exit'. Note that the MUCK's execution of actions is NOT case-sensitive. Only the inserver commands 'WHO' and 'QUIT' require case consideration. Also note that most MUF 'Obvious Exits' programs list the first alias of an exit only, so To read the next page, simply type 'next'. you'll want to make that the first alias the 'pretty' name of the exit. The rest won't show. This is the last page of this chapter. Chapter E: Putting It Into Practice I -- Commands ================================================= 'Commands' are basically any action that isn't an 'exit' that links two rooms. Suppose, for example, that you have set up your home and want to reach it from anywhere in the Game without using the 'Home' command. Here's the setup you might use: Example 1: GoHome Telportation Action ------------------------------------- @action gohome;gh=me @link gohome=# @desc gohome=Type this to go home, silly! @succ gohome=You snap your fingers and blip out. @osucc gohome=snaps %p fingers and blips out. @drop gohome=Lights flash, and you appear back at your home! @odrop gohome=suddenly appears beside you! Simple enough, right? Okay...suppose you make friends with someone named 'Bojo' who wants to hang out with you. You can make him a nice present by creating a 'Thing' and an action that brings him to you from anywhere he To read the next page, simply type 'next'. happens to be: Example 2: Teleportation Object -------------------------------------- @create Zapper @desc Zapper=You see a funny square object that looks like a remote-control. There is one large, square red button in the center that says "WIX!" You wonder what would happen if you it. @succ Zapper=You pick up the Zapper. @osucc Zapper=picks up the Zapper. @drop Zapper=You set down the Zapper. @odrop Zapper=sets down a Zapper. @action press button;press;gowix=Zapper @link press button=me @lock press button=*Bojo @succ press button=You press the button on the Zapper. There's a flash of light and your surroundings disappear! @osucc press button=presses a button on the Zapper. There's a flash of light, and %s disappears! @drop press button=The light fades, and you find yourself standing beside Wix! @odrop press button=appears in a sudden flash of light! @fail press button=You press the button on the Zapper, but nothing happens. @ofail press button=presses the big red button on the Zapper, but nothing happens. (And no, for the record, I don't actually know anyone named Bojo.) To read the next page, simply type 'next'. Keeping handy the chart in Section 2 can be very helpful when playing with actions that make commands. Read on now to learn about the most common use of actions -- as exits. This is the last page of this chapter. Chapter F: Putting It Into Practice II -- Exits =============================================== The use of actions to move players from one room to another is by far the most common, and for that reason it is important to understand why it is that calling an action an 'exit' is misleading. Imagine that you're standing in a two room house. There is a room to the east, and a room to the west, and a single wall dividing them with a door in the center of it. You are standing in the room at the east end of the house, and you want to move into the other room. What do you do? Well, of course, you go through the door.. But to do that you 'go west', passing through the door on your way. Once you're standing in the western room, you cannot 'go west' again to get back. You have to do something different...in this case, 'go east'. So, even though there is only one door, you perform two separate actions to use it. Building on MUCKs is very literal in this regard. When you @dig two rooms and you want to pass from one to the next, you have to create two different actions to make that possible. You do not actually create an 'exit' in the form of the two-way portal a doorway represents. Instead, the actual portal is purely To read the next page, simply type 'next'. incidental and only part of the description. What you actually make are the actions that make it LOOK as if you're using a portal. Take a look at this example: Example 1: Creating an Exit -- Basic ------------------------------------ @dig ThisHere Room @tel me=# @desc here=You stand in a room. Right here! Isn't it nice? There's a door to the west leading into ThatThere Room. @succ here=@$obvexits @dig ThatThere Room @open ThatThere Room ;west;wes;we;w;there=# @desc west=You see a doorway. It appears to lead into ThatThere Room. @succ west=You head through the west doorway, entering ThatThere Room. @osucc west=heads west, entering ThatThere Room. @drop w=** @odrop West=enters through the door to the east. You're only half done here, though. To read the next page, simply type 'next'. You type 'west' and see: You head through the west doorway, entering ThatThere Room. ThatThere Room(#1234R/M) You see nothing special. From here, you must now: @desc here=You stand in ThatThere room! There is a door in the east wall leading back to ThisHere Room. @succ here=@$obvexits @open ThisHere Room ;east;eas;ea;e;this;here;=# @desc east=You see a doorway. It appears to lead into ThisHere Room. @succ east=You head through the west doorway, entering ThisHere Room. @osucc east=heads west, entering ThisHere Room. @drop east=** @odrop east=enters through the door to the west. NOW you're done. Two actions, each leading in different directions, make one 'exit' as it were. Now, back to MUF-programmed Shortcuts. One obvious problem with this system is that inexperienced builders sometimes forget to make that second exit. As a To read the next page, simply type 'next'. result, anyone navigating through rooms they've built can end up trapped in a room with no way to leave it. To address this problem, some MUF programmers (Raven of FurryMUCK, for one) have programmed ways to make the whole thing complete (except for @messages) using one command. That command is called "@XDig" The command format is as follows: @xdig == Example: (assume you're standing in 'ThisHere Room', and you've not yet used @dig to create 'ThatThere Room' @xdig ThatThere Room=ThatThere Room ;west;wes;we;w;thatthere=ThisHere Room ;east;eas;ea;e;thishere The command will, then, @dig the room for you and create and link both exits in one full swoop. Very handy. ** Note that the @drop really isn't necessary on exits, as it appears immediately after the @success. Often, the @drop is used for exit-triggered MUF or MPI program calls, so setting an actual @drop message isn't necessary for the building to look complete. This is the last page of this chapter. Chapter G: Other Considerations =============================== Removing Actions (This is for you, Iris) @recycle @recycle # Renaming Actions @name = Actions and Parenthood One of the nice features of Actions with respect to Parent rooms is that actions whose sources are Parent rooms are available in all child rooms as well. This is true regardless of the destination of the action. Examples of ways in which this can be used include: A. HoloMUCK's 'center' command, which automatically transports you to 'Tanstaafl Center' from anywhere on Planet Holo. SPR's 'gopark' command works much the same. NarniaMUCK's 'GoOOC' works this way, too, but with MUF support that enables you to return to your point of origin when you use 'GoBACK'. (If you'd like the MUF program for this, just let me know. I'm pretty liberal about To read the next page, simply type 'next'. sharing mine.) B. Any actions that call programs (examples include NarniaMUCK's global combat commands, special variations on 'WHO', etc.) are all actions located on parent rooms that are accessible in child rooms. Action Priority Occasionally you might run into a problem where two actions that affect a given room have one or more of the same aliases. For instance, you might have a global exit on a parent room called 'Center;c' and then an exit on a child room that is called 'Chandellier Room;c'. When this happens, the default priority is given to the most local exit.. Thus, if a player typed 'C' while standing in the child room, the more local exit 'Chandellier Room;c' would be triggered and the 'Center;c' exit on the parent room ignored. This CAN be overridden, however. Say you have a global exit that you want to take precedence no matter what the aliases may be on child rooms in the environment. You can set priority using M- and W- flags, where each level represents a higher priority. An action set M1 overrides an action with no M- flag set. An action set M3 overrides an action set M1, and so on. This control feature is mainly to allow Wizards greater control over the game, but players who build for fun may find it useful as well. To read the next page, simply type 'next'. Fake Actions Actions can also be used to create 'fake' actions that APPEAR to do something when they really do not. Say, for instance, that you have created a stuffed bear, and you want it to react when someone 'hugs' it. You can set that up this way: @action hug bear;hug teddy;hug teddy bear=Teddy Bear @link hug bear=Teddy Bear @lock hug bear=me&!me** @fail hug bear=You hug the Teddy Bear! The Bear squeals with delight! @ofail hug bear=hugs the Teddy Bear! The Bear squeals with delight! Note that the source and destination are the same here, and that the action is locked to 'me&!me'. If you recall back to when we discussed @Lock, the '&' symbol requires that a player be able to fulfill BOTH qualifications before they can pass the lock. As no one can be 'me & not me' at the same time, locking anything to 'me&!me' effectively locks it against everyone, including you. You then set @fail messages to read as if they are @success messages, and you're done. This is the last page of this chapter. CampusNet>> 2013-May-10 08:48:38: Feaelin looks baffled. CampusNet>> 2013-May-10 08:49:03: papa says, "Good morning." Chapter 'H' not found. You turn to the contents page and read: Title Chapter --------------------------------------------------------- Using 'find' and its friends..............A (5 pages) Quality Building..........................B (6 pages) To read a chapter, type read book5=A1 Which displays chapter A, page 1. In the Stacks -- Building Wing =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The building wing of the Library consists mainly of study carrels and shelves of books. There are posters and blueprints on the walls showing the layout maps of various MUCKs, some well-known, some not. Someone has left a few books here sitting on a table. The front section of the library is to the west of you here. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= You can go: Back to the Front Area Contents: Book0 -- Basic Syntax and Terminology Book1 -- Building 101 Book2 -- Building 102 Book3 -- Building 103 Book4 -- Building 104 Book5 -- Building 105 BookA -- Building Recipes -- Read the other books first. Bulletin Board Final Project Guidelines I. Finding Database Items After building your one thousand room Palace, complete with servants, fountains, and the occasional stray chicken; you would probably be having problems keeping track of all the dbrefs, exits, rooms, and things. Fortunately, there are a group of commands designed specifically to help you find items. All of these commands have similar options which will be explained in more detail after explaining what the "default" behavior of the commands are A. @find [options] The first of these commands is @find. If you are a non-wizard, @find lists all the database items that you own. If you are a wizard, @find lists EVERY LAST database item on the muck, including database items that are "garbage" (recycled). B. @owned [options] For mortals, there is no difference between @owned and @find, both list every item you own. For wizards, it is a safer alternative to @find, since it only lists items they own, and can be used to list items that another player owns. C. @contents [options] @contents lists the database items that you control that are in the database To read the next page, simply type 'next'. item specified (or the current room if none is specified). You have to own/control the item to list its contents. D. @entrances [options] This command lists the 'entrances' to the specified database item, or the current room if none is specified. The command is handy to see what exits are linked TO the specified item. Options: @find will take an optional parameter that filters the list to the items matching it: '@find food' will list all the database items with 'food' in their name, regardless of type. '@find apples' will list all the database items with 'apples' in their name, regardless of type. You can also refine the search by using ? to match any single character: @find f??d will list items with the words 'food' 'feed' 'faad' in their name. To read the next page, simply type 'next'. Or use a * to match any number of characters: @find f*d will match 'fed' 'feed' 'food' 'foeruqoruweurworuwd' :) Refining the search further: Adding a = sign and a flag to any of these commands will filter the list by the flag. For example: @owned =E will list all the items you own that are exits/actions. @find apples=R will list all of your rooms with 'apples' in their name. @owned =C will list all of your items that are CHOWN_OK Additionally, you can use the flag % to find items that are 'unlinked', for example: @owned =E% will list all exits you own that are not linked. You can also use an @ sign to list items that haven't been used for more than 90 days: @owned =R@ would list all rooms that haven't been used for 90 days. To read the next page, simply type 'next'. Changing the Output Style: Normally these commands only list the name of the item and its dbref#. You can refine the output by adding a 2nd equals sign and specify the style. The possible styles are: owners, links, and location. For example, if you wanted to list all your database items, and what they're linked to: @owned ==links Or perhaps more usefully, all of your exits and what they're linked to: @owned =E=links. Another possibility would be to use the 'location' output to see where your items are, or perhaps what the parent of all your rooms are: @owned =T=location (All things, display their location) @owned =R=location (All rooms, display their 'location' which is their parent) Again, you can use these with @entrances or @contents as well: To read the next page, simply type 'next'. @entrances ==location (list all entrances to the current room, and their 'location' (where they come from). For mortals, the 'owners' option is largely unuseful. Since the only items these commands list are the ones a mortal owns, 'owners' would simply display your name and dbref over and over. For wizards, it can be more useful: @find food=R=owners (find all rooms with 'food' in the name, and display their owners) This is the last page of this chapter. Title Chapter --------------------------------------------------------- How to Create a Zombie....................A (6 pages) How to Create a Book......................B (6 pages) To read a chapter, type read recipe=A1 Which displays chapter A, page 1. Chapter B: The Role of Writing In Building The preceding books and sections have focused on the technical skills required for building. Technical skills are not the only skills needed for high quality building. Just as important is attention to aesthetic details and good writing skills. Every thing, zombie, puppet, player, room, and action/exit are composed of numerous pieces of text. These pieces of text can be as small as a success message or as large and complex as an intricately detailed description of a player. Using misspelled words and poorly thought out grammar is the most damaging thing you can do to your descriptive text or messages. Misspellings and bad grammar will prevent the reader from understanding what your text is supposed to say. Many readers will stop bothering to read the descriptions or messages if there are too many grammatical errors or misspellings. The mistakes lead the reader to believe that the writer doesn't deem the text important...and if the text isn't important to you, why should it be important to them? The text is very important. This is a text based game, after all. So when you're planning your project, whether its a beautiful outdoor garden, a house you live in, consider the scope of your project. Don't plan a huge design that To read the next page, simply type 'next'. involves so many rooms that you can't provide decently detailed descriptions to each room. It is easy to spin out a one-hundred room mansion, a vast collection of 'things' with very basic descriptions, and none of the other supporting text messages. Section 1. Required Properties There are several properties and messages that often need to be set on a given database item. Here is a list of database items and the the properties that are 'must haves' for that database item. Every database item should have a description. Even MUF programs should have a description...usually the description explains what the program does. Rooms: Rooms don't have as many different messages needed but often involve several exits/actions which do. Primarily, the room should have a well thought out description, with possibly additional details added through use of @object or @detail. Some mucks will need you to set a success message to setup the 'obvious exits' program for that mud. A typical example would be: @succ here=@$obvexits. University doesn't require this because the obvious exits program is 'built in'. Exits: Exits required several messages. They require a fairly simple description which usually gives some indication of where the exit leads. They To read the next page, simply type 'next'. should have at a minimum an success message, an osuccess message. If the exit is going to be locked (even part of the time) it will need fail and ofail messages set. It is usuallly appropiate to also set drop and odrop messages on an exit to parallel the success/osuccess messages. Things: Things also required a fair number of messages. They often need fairly detailed descriptions, sometimes just as detailed as a player or a room. If they can be picked up they need success and osuccess messages. If they can be picked up, they can be dropped and will correspondingly require drop and odrop messages to be set. If they can't be picked up even some of the time they will need to have fail and ofail messages. Section 2. Descriptions Rooms with descriptions such as 'The graveyard. Its spooky here' or things described 'A book about magic' aren't what we want in high quality building. We want rooms that have full descriptions, involving all the senses that make sense. Do not forget that our senses can perceive a wide variety of information. The database item you are describing can have unusual textures 'the wood feels rough and easily splintered' or colors, the very air the reader is 'breathing' could taste, smell, or even feel a certain way. Cool breezes, foul odors, sweet To read the next page, simply type 'next'. smell of flowers, a bitter taste in the air, etc. Text that tells the reader what his player should be thinking doesn't work either. For example, if a character description had: "And when you look into his terrible eyes, you tremble in fear". That makes the assumption that the onlooker is someone who is intimidated by the character...which won't always be the case. The character's description should _describe_ what is seen and nothing else. Don't make assumptions about the capabilities of the 'looker', other than they have eyes and can see the character. Another common mistake is to include material in a description that isn't description, but is instead an activity. The description that I used for years was in violation of this principle. The last sentence read '...and he turns to you and says, "Greetings". A nice friendly description, and completely, totally wrong. The character is apparently saying 'greetings' EVERY time someone looks at him. That doesn't really make sense. If I said "Greetings" everytime our eyes connected, you'd get tired of me pretty quickly. Again, a description should ONLY describe and nothing else. It is even easier to make similar mistakes with room descriptions, where the dividing line is more vague. A typical error is to put things or creatures in the description that can be carried off or walk off on its own. Which if it To read the next page, simply type 'next'. isn't there, then the description will be wrong. Probably the relevant question is: Is this something that can ever leave (in game only...there are certainly things we put into the description that we count on players not carrying off)? If yes, it should probably be made into a "thing" with appropiate messages. If no, then you can get away with putting in the description. Don't forget to use @object or @detail, if you want to have extra bit of description that won't fit into the main description. Try to avoid the use of second person in descriptions, especially for room descriptions. It feels so easily right at first, but after traversing the 35th room that begins with "You see..." it becomes pretty old. It is acceptable to use "You see" for things the player has to 'look at' (people, things, directions, etc.). I find it works especially well for exit descriptions, since the implication is that the player is looking off in that direction, so 'You see...' makes sense there. It is something of a writing- challenge at first, but I find reworking a room description to avoid 2nd person produces a stronger, more powerful description in most cases. The description should simply be what a player would see. It should be as detailed as possible, although I recommend keeping your description no more than 15-20 lines. Descriptions with page after page of description are not necessary, and typically annoy the reader. If necessary, one can add more To read the next page, simply type 'next'. detail on most worlds using a variety of techniques, which typically involve the reader issuing additional commands for the items or details they're curious about. Utilize the format function to format your text to an 80-column format. You won't be able to count on the player's terminal, telnet, or mud client being capable of wrapping lines. You can safely count on their terminal being a minimum of 80 columns wide and at least 24 rows tall so those are good boundaries to work with. This is the last page of this chapter. How to Create a Zombie/Puppet By: Napthalia Byrd I. What is a Zombie/Puppet? Ahh, so you want a poor defenseless creature to bow to your every whim, who will go to all the reaches of the universe just to report everything it sees straight back to you? You have come to the right place. Essentially, a zombie is a creature who will do that for you. You control it. You can make it talk, move, and it reports everything back to you. A. Creating the Zombie Database Item First create a thing, naming it whatever name you desire for your zombie. @create Let us create a cat named Kit-Kat. From here on out, the exact actions to set up Kit-Kat as a zombie will be in green. @create Kit-Kat B. Making Your Thing a Zombie To read the next page, simply type 'next'. Next you must set your thing as a zombie. This is done by putting an 'X' flag on it which makes the thing forcible. You need to do this to be able to control your zombie in the way you want. @set =X @set Kit-Kat=X Next you will want to force lock the zombie to yourself. Since your zombie is now forcible, you want to be the only one able to force it. If you so desire, you can designate anyone on the Muck to be able to force your zombie. @flock = @flock Kit-Kat=me D. Forcing the Zombie You /could/ go about forcing your thing now, but it is not a true Zombie. In order to see through the puppet, you have to set the Z(ombie) flag. @set =Z @set Kit-kat=Z For all purposes, your zombie is complete. You can now force it to do anything To read the next page, simply type 'next'. you want. @force = @force #406=:meows. If Kit-Kat's dbref # is #406, then that command will send 'Kit-Kat meows.' to the room she is in. (In order to check a dbref # on the zombie, type ex ). Now, there is an easier way to force your zombie than typing @force zombie= each and everytime you want it to do or say something. You can create an action that will shorten the process by a good length. This is helpful, especially when you use your zombie more than once or twice. You will first need to create an action of your choice. Keep it short and simple. Have it relate to the zombie without it being the zombie's name. For Kit-Kat, you could use the command 'kk'. @action =me @action kk=me You now have an action on you. You do not want your action to actually bring you anywhere, so first you must link it to a program that will do absolutely To read the next page, simply type 'next'. nothing. @link =$cmd/null @link kk=$cmd/null Now you must lock the action because you do not want it to actually do what it is supposed to (and that is absolutely nothing if you @linked it to the nothing program). @lock =me&!me @lock kk=me&!me When you @lock something to me&!me, it means that only you and only not you are the key to action. Since you cannot have an database item that is you and is not you, it is forever locked and will fail anytime you attempt it. This is what you want it to do. Now, you must tell it what to do when it fails. @fail = {force:,{&arg}} @fail kit-kat={force:#406,{&arg}} In order for your action to work, you also need to set it 'm' so it can use MPI and 'h(aven)' so it can accept an arguement. Trust me on this one, and type To read the next page, simply type 'next'. the following: @set =h @set =m @set kk=h @set kk=m Now to force your zombie, type the action command followed by whatever command you would normally type to control your character. kk look The command for Kit-Kat will force Kit-Kat to look around the room. D. Changing the Echo If anything happens in the room the zombie is in, the messages will be sent to you. It should have the zombie's name with a > following it. If you like that, you can leave it as is, or you can change it to be whatever you want. @pecho = To read the next page, simply type 'next'. @pecho kit-kat=* Now, whenever Kit-Kat sees anything, it is send to the owner's screen with a * prepending all the text. If you have followed all of the instructions here, you should now have successfully created your zombie. Don't forget to @desc and set all the @succ/@fail messages where appropriate. Congratulations and Enjoy. This is the last page of this chapter. I. Creating a Book In this recipe, you will learn how to create a book. If you are not familiar with what books are on the muck, then you are lying, because you are reading from one right now. Also, if you followed the instructions, you should have read all the other building books before this one, so then you are a liar and a cheat. Please don't be those things. Ahem. Also, to help in the process, I use yellow as an action item that you need to do and green as the example. A. Creating the Book Database Item First create a thing, naming it whatever name you desire for your book. The typical format is Book -- . That way, it clearly establishes the item is a book as well as incoporates the title. @create <name> Let us create a book of poems. @create Book -- A Book of Poems Oh, how clever of us. B. Describing the Book As with any object on the muck, you should describe what it looks like. It is important to use lsedit for the description of the book. Since you are using lsedit, you must set the object with the 'M'flag. @set <object>=M @set Book of Poems=M To read the next page, simply type 'next'. Now it is time to describe the book. Please remember, that the description refers to how the book looks on the outside. Important Reminder You do not see the contents of the book on the outside so thus, it is important to give your readers instructions on how to access the inside contents. Include the phrase "Read <object>=Contents" in your description so that the reader understands how to access the table of contents. Hopefully the example will better explain. lsedit <object>=<name of desc> <desc> Read <object>=contents lsedit Book of Poems=desc You see a dusty brown book. You can barely make out the letters scrawled on the binding 'A Book Of Poems'. The book looks old and wellread. Type 'read poems=contents' to see which wonderous poems this book holds! Do you see how in the example it tells you how to read the actual contents? Of course, do not forget to actually describe your book with the description you just edited. @desc <object>={list:<name of desc>} @desc Book Of Poems={list:desc} C. Creating the Content So now that you have a book with a description with instructions to the reader on how to access the table of contents, it's about time you actually create that table of contents, isn't it? Not exactly. The purpose of the table of contents is to show the organized display of the content that you have. Currently, you have none. So that would be silly. First, let's create content. To read the next page, simply type 'next'. Now, each book has chapters that are labeled by letters: Chapter A, B, C, etc. Essentially, you need to set the chapter and its name on the item. Let's start with the first chapter. @set <object>=a:<name of chapter a> @set Book of Poems=a:poema This essentially creates chapter a and names it 'poema'. Fantastic. Now let's put in some material! D. Adding the Content Now that you have a Chapter and it is named, you need to write the actual material to put in the chapter. You do this using lsedit. lsedit <object>=<name of chapter> lsedit Book of Poems=PoemA Here is where you insert ALL of the material for the chapter. Don't worry about the length. If it is exceptionally long, it will automatically create pages for you. For the example book I will insert this description: Roses are Red Violets are Blue I am writing abook And so CAN YOU! ~Napthalia To read the next page, simply type 'next'. It's a short poem. That's the entire chapter that I want so it will be a short chapter as well. Alright! Now, let's say you want to create a second chapter. Because an entire book with that short poem is a waste of a book (even if it is an exceptionally good poem). You do it very nearly the same way as you created Chapter A, only now, it's ChapterB @set <object>=b:<name of chapter b> @set Book of Poems=b:poemb And of course you have to edit the chapter the same way you did before: lsedit <object>=<name of chapter> lsedit Book of Poems=PoemB This time I am going to give it the description Oh for goodness sake Books are hard to make It may seem fun But when you're done Noone is awake! ~Napthalia Wow, I'm really cooking now. So now we have two Chapters: A and B. I am done writing poems for now. So let's say that's all the content we want to add. (We can always go back and add more content later - You would do the same for consecutive chapters with c, d, e, etc.). Time to tell people what chapters are what and how to read them! To read the next page, simply type 'next'. E. Creating the Table of Contents Do you remember way back when (in the good old days) when we created the description and you were supposed to put instructions in the description on how to access the table of contents? For example, the Book of poems says "Type 'read poems=contents' to see which wonderous poems this book holds!" But if I type 'read poems=contents' right now it will tell me No table of contents to display. Whoops. We should create one to display, donchathink? To edit the table of contents, use lsedit: lsedit <object>=contents lsedit Book of Poems=contents Easy Breezy, right? Not quite. There's a format you must follow and here's a good one: Title Chapter --------------------------------------------------------- <Name of Chapter>.............................~ast~A~len~ (~a~ pages) <Name of Chapter>.............................~bst~B~len~ (~b~ pages) <Name of Chapter>.............................~cst~C~len~ (~c~ pages) <Name of Chapter>.............................~dst~D~len~ (~d~ pages) To read a chapter, type read <name of book>=A1 Which displays chapter A, page 1. Which might make you say, WHAT?! Or it might not. But here's an explanation. You have the Title of your Chapter on the left (easy to understand) and on the right you have the names of the chapters: A, B, C. If you keep it in this format, instead of seeing ~a~ you will actually see how many pages chapter a has. Trust me on this one. It's neat. Also, the little blurb on the bottom is instructions on how to access the chapter. PLEASE include this or the reader may be lost on what to do next (just like in the description). So this is what I used for the Book of Poems: To read the next page, simply type 'next'. Title Chapter --------------------------------------------------------- Roses are Read................................~ast~A~len~ (~a~ pages) Limerick......................................~bst~B~len~ (~b~ pages) To read a chapter, type 'read poems=A1' Which displays chapter A, page 1. F. Conclusion That about wraps that up. If you do add more chapters later, please go back and change your table of contents to reflect the new content, otherwise, people will never know that other chapters are lurking there underneath. Hopefully that all makes sense. Enjoy and Happy Book making! OH! One more thing. Don't forget all your other lessons. The book is still an object like any other object. You should still set all the properties on it such as @drop, @odrop, etc. Be a nice builder and don't forget those things. This is the last page of this chapter. In the Stacks -- Building Wing =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The building wing of the Library consists mainly of study carrels and shelves of books. There are posters and blueprints on the walls showing the layout maps of various MUCKs, some well-known, some not. Someone has left a few books here sitting on a table. The front section of the library is to the west of you here. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= You can go: Back to the Front Area <W> Contents: Book0 -- Basic Syntax and Terminology Book1 -- Building 101 Book2 -- Building 102 Book3 -- Building 103 Book4 -- Building 104 Book5 -- Building 105 BookA -- Building Recipes -- Read the other books first. Bulletin Board Final Project Guidelines Builder Final Project Guidelines Note: These guidelines are a work in progress and may change...even during your evaluation. The final stage of the builder series of courses is a "final project". This project is intended to demonstrate your building ability. After you finish your project it will be reviewed by MUCK University staff. We will intentionally be tough in evaluating the project since you will have opportunity to fix any problems and re-submit the project. It will save your time and ours if you pay attention to details before submitting your project and/or getting a friend to double-check your work for you. Here are the minimum requirements for the project: * You'll need to have completed the following six courses and passed the corresponding tests: B101, B102, B103, B104, B105, and MPI 101. * A builder's final project should have a minimum of three rooms. More are permitted, but no more than six of the rooms you designate will be reviewed. * The rooms should be arranged logically and connected by appropiate exits. * There should be at least two 'thing' database items: One that can be picked up and one that cannot. * All exits, things, and rooms should be fully described and have all appropiate @msgs set. * There should be at least one room or thing that has additional detail provided by @detail. * There should be at least one room that has additional detail provided by @object. * Ideally, the project should have a theme, but the theme of the project is up to you. Anything time period, any setting, etc. etc. Its best if its something that inspires you! I want to emphasize that I will be as tough as I can without being mean with the evaluations. I will probably criticize every last nitpicky detail I feel is wrong. When you submit your project, feel free to submit any comments about the project, especially if you have made a creative choice against a standard way of doing things, I'll want you to back that up with an explaination. When you have finished your project and feel you are ready to have it evaluated send me page mail. If possible, I'll arrange a time that we both be on so we can go through your project together, or if you feel your project will stand its own, I will do the evaluation first chance I have to do so. Feaelin Moilar MUCK University Director Last Updated: 2005-May-13 14:02 CST