|
|
|
|
||
ON KNOWING THE HOUSE RULES
ON THE REBEL IN THE SYSTEM
ON THE ART OF THE DESCRIPTION
ON FURTHER RESEARCH
ON THE MATTER OF ROMANCE
THINGS TO KNOW ABOUT TINYSEX [Guest Speaker]
ON THE DIFFERENCES BETWEEN TABLETOP RPGS AND MUSHES
PLAYERS CAN CARE AND FEED FOR MUSHES TOO! [Guest Speaker]
ON THE TYPES OF POWERPOSING
| ON THEME | ON CHARACTERS | ON CONSENT |
| ON ADMINISTRATION | ON CODING IDEAS | ON GEOGRAPHY |
| ON COMMUNICATIONS | ON ROLEPLAY | ON MAGIC |
| ON IC ORGANIZATIONS | ON TINYPLOTS | MAIN PAGE |
Send feedback on these pages HERE.
Intro: Example of why canning your speech can be a good idea
Sample Code: How to can your speech in one easy lesson
Further Advice: Some suggested standards of behavior
INTRO: EXAMPLE OF WHY CANNING YOUR SPEECH CAN BE A GOOD IDEA
A long time ago, when my mushing career was about two weeks old, I attended a scheduled performance on the mush where I had created my very first character. It was a one-woman musical performance (singing accompanied by guitar, I think). The singer had done a fine job of choosing an interesting - but obscure - ballad to perform, one which I didn't recognize and thus became interested in hearing the end of its story, and an equally good job of posing details of her changing facial expressions and tones of voice as she moved from one verse to the next. Of course, we couldn't "hear" the music, but she did her best to make up for that with the way she posed the introduction to each verse.
There was just one tiny problem: I think there was a pause of about 10 minutes (give or take) between each posed-verse and the next, which was a LOT more time than we of the audience needed to mutter comments to one another at our private tables in the restaurant where this was occurring. Of course - and I quickly realized this at the time - these long pauses must have occurred because the singer's Player was carefully typing out each pose, followed by typing in the next verse of the song, with the appropriate formatting commands to put each "line" of each verse on its own line on our monitors, etc. She would then hit ENTER, we got another chunk of her performance, and she carefully started composing the next chunk, etc. This took time - enough time to risk boring her audience with each lengthy wait, I'm afraid.
It has occurred to me that she was quite possibly accessing the mush via raw telnet from a PC, meaning there was no effective way to cut-and-paste the text of the song from the webpage where she had found it to the command line of her mush connection. Even that cut-and-pasting would probably have reduced the typing time of each installment by half, I should think, without doing any fancy "coding" at all.
I mention this because, despite the delays I had to endure at the time, I was sufficiently impressed by the general style of the performance (it looks better when you read the log all at once, after the fact, with no visible pauses) that I eventually began doing similar things myself - that is to say, creating professional musician characters on other mushes and having them sing the occasional song to add a bit of "flavor" to my roleplaying. However, by the time I had sufficient seasoning in the mushing world to do that for myself, I had also learned a few tricks that made things go MUCH faster and made my options in an unexpected emergency much broader. To wit:
1) I had discovered the meaning of using a "Windows-based Client" to connect to a mush. Most noteably (from my point of view) it was possible to cut-and-paste things, such as song lyrics.
2) I had become aware that it was really quite easy to store blocks of text on a coded object, arranged so that any given item (such as the first verse of "The Yellow Rose of Texas," as an example) could be triggered and displayed to my adoring public by typing a single command at a moment's notice. Once I had memorized the basic "format" for coding a single block of text, to be triggered by a chosen command, I could do it again and again with anything I thought I might want to use in the future.
SAMPLE CODE: HOW TO CAN YOUR SPEECH IN ONE EASY LESSON
The following approach will work on any Pennmush, TinyMush, or TinyMux site.
To simply store a block of text on an object, so that you can trigger an emission of the text by typing a chosen command, do this:
| &declare1; Harp=$declare1:@emit/room %r%tWhen, in the course of human events, it becomes necessary for one people to dissolve the political bands which have connected them with another, and to assume among the powers of the earth the separate and equal station to which the laws of nature and of nature's God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation. |
Once you have typed this in, then whenever you type the following:
declare1
and hit ENTER, this command will trigger the emission of the first sentence of the Declaration of Independence to everyone in the same room as yourself.
Obviously, if you want to use some other text and trigger for it, you should put whatever your trigger command will be in the spots where I put "declare1" and put the appropriate text after the "@emit/room %r%t" part. If you don't want the canned speech to be stored on an object called Harp, then create a suitable object and substitue its name for the word "Harp" in the code above.
If you want to emit poetry or the verses of a song, properly formatted so that each "line" actually does receive its own line on the screen, then you should do something like this:
| &yellow1; Harp=$yellow1:@emit/room %r%tThere's a Yellow Rose in Texas I'm going back to see%r%tNo other fellow loves her as half as much as me%r%tShe cried so when I left her, it almost broke my heart%r%tAnd if ever we do meet again we never more shall part! |
| &yellowc; Harp=$yellowc:@emit/room %r%tShe's the sweetest little rosebud that Texas ever knew%r%tHer eyes are bright as diamonds, they sparkle like the dew%r%tYou can talk about your Clementine and dream of Rosalie%r%tBut the Yellow Rose of Texas is the only girl for me! |
I used yellow1 has been used as the easy-to-remember command for the first verse of "The Yellow Rose of Texas," and yellowc is the command that will trigger the chorus. If I wanted to code more of the song, you could call the subsequent verses yellow2, yellow3, etc.
If I type yellow1, while holding a Harp which has had these attributes coded onto it, here's what my audience would see:
| There's a Yellow Rose in Texas I'm going back to see No other fellow loves her as half as much as me She cried so when I left her, it almost broke my heart And if ever we do meet again we never more shall part! |
Typing yellowc, of course, would trigger this:
| She's the sweetest little rosebud that Texas ever knew Her eyes are bright as diamonds, they sparkle like the dew You can talk about your Clementine and dream of Rosalie But the Yellow Rose of Texas is the only girl for me! |
What you need to know to format things the way you want them:
In mushcode, %r means "insert a carriage return into the text at this point." %t means "Insert a tab - which is 5 blank spaces - at this point." The percentage sign (%) is always taken to mean some sort of formatting command is beginning; and it doesn't care if you use it in a pose or to format dialogue inside quotation marks; the alert server will treat it as a formatting symbol either way, never as something to be displayed on the screen in a posed or spoken block of text. However, it is possible to overcome this by using two of them back to back. In this case, the server will send the second one to the screen.
So remember: if you ever try to say in dialogue, "I own 50% of that horse!" and you use 1 % sign, you will find that what is broadcast to the room after you hit ENTER looks like this: "I own 50 of that horse!" However, if you typed this:
"I own 50%% of that horse! <ENTER>
Then what goes out to your audience will be, "Soandso says, "I own 50% of that horse!"
FURTHER ADVICE: SOME SUGGESTED STANDARDS OF BEHAVIOR
2) Other uses of canned material.
3) You don't really need an object.
4) Cluttering up the database.
As a general rule, when I coded in the verses of a song, I tried to reduce each verse to 4 formatted lines of text wherever I could (there were some exceptions where each "verse" was so long that this was not practical, and 5 lines, or even 6 (shudder) were honestly needed, but I coped). For instance, in the Yellow Rose of Texas example I used above, if length in lines of text was no concern, I could just as easily have formatted it to come out like this:
| There's a Yellow Rose in Texas I'm going back to see No other fellow loves her As half as much as me She cried so when I left her It almost broke my heart And if ever we do meet again We never more shall part! |
After all, that's the way it's formatted in the online folksong database which I referred to in preparing this chapter, but there's a serious problem with doing such things routinely.
Some mushers use, by preference or by necessity, simple "raw telnet" links to access the mushes they play on. It is wise to assume the worst in preparing any sort of public "performance," i.e. assume that some people will only have the minimal conveniences that raw telnet provides. A "raw telnet" connection might only have about 20 lines of text visible in it at a time, and it is even possible that some of your prospective audience are using software that doesn't even let them scroll back to refresh their memories of something that has just been pushed off the top of the screen. Lyrics that gobble up almost half of their visible text at once could easily push off something said or done by another player which they hadn't yet finished responding to. This can create trouble - and hard feelings toward the person who just threw so much spam across their screens. 4 lines, or 5 if we count an introductory pose such as: "Taliesin softly strums his guitar, while his rich voice sings the first verse of an old song," is something that any musher has to get used to, even if it's not necessarily directed at him, but to go much beyond that on a regular basis - especially if several different people are gathered in a "public" meeting place, some of whom have nothing to do with your current roleplay - can be a bit too much. But circumstances alter cases. If you are alone in a room with a close friend, the rules can probably be relaxed since there's nobody else competing for space on your screen or hers.
OTHER USES OF CANNED MATERIAL
I dwelt heavily on the matter of song lyrics, since that was where I had the most personal experience. This does not mean that canned material is always or even frequently of no use to anyone but an aspiring musician. The important principle can apply to any situation: if there is a lengthy piece of text which you KNOW you will want to emit at a critical juncture in the roleplaying, you can code it in advance so nobody has to wait a few minutes for you to type it out when the roleplay is just starting to get interesting. Besides songs, other applications of this principle which I have done, witnessed, or merely heard about, include:
1) A lengthy public "performance" of any sort, such as a long speech to an assembled crowd. Suppose, for instance, that as part of a mush-wide TinyPlot, the local IC Ruler, King Joyse, is about to make a stirring speech to the masses in which he explains that war has been declared against a neighboring nation. Suppose that King Joyse's Player, and anyone he consults, drafts out a speech which runs about 50 lines of text (7 paragraphs of 7 or 8 lines each, perhaps).
We assume that his public speech will be, at least until he uses up the material, the type of Group Activity which I call "The Floor Show and the Audience," meaning that several characters will be in attendance, but only a few of them with special parts to play will be permitted to speak and pose ICly in a manner which is emitted to everyone in the room, until an OOC signal goes up saying, "Okay, the formal part of the gathering is now over. Everybody can ICly say and do whatever you please!" Naturally, the room selected for the occasion should have several separate Places or Tables (whichever they may be called) for small sets of rank-and-file Players to congregate at, so that they can exchange quiet IC comments with one another which are only heard within that Place/Table without spamming anyone else in the room.
Anyway, assuming all that, we also assume that King Joyse and Co. want to get the scripted part of the meeting out of the way as fast as possible, so that spontaneous group RP can break out, in reaction to the announcements the King has made. This being the case, they would do well to draft out the speech and then code it in several paragraphs onto a convenient object (or onto the King himself, if need be), using such easy-to-remember "triggers" as speech1, speech2, etc., so that he can emit the first long paragraph . . . wait a minute or two for people to read it and pose some IC reactions to each other at their private paragraphs . . . emit the second paragraph . . . wait a minute . . . and so on. This will go much faster and more smoothly than if the King insists on typing in each paragraph as he goes along while his audience sits on their hands waiting for him to get to the point.
It also has the advantage that if worst comes to worst (for instance, the King's Player is asked to stay late at his RL workplace that night and thus is unable to log onto the mush at the time of the scheduled Event after all, or he does log on and then his system crashes in the middle of the scene and he is unable to reconnect for technical reasons), then a trusted friend (a Wizard, perhaps) can carry on in his stead, emitting the King's IC presence and use the same triggers (speech1, speech2, etc) to make it appear, ICly, that he is still there uttering this oh-so-important Royal Proclamation.
2) Tutorials. I have seen both OOC Tutorials and IC Tutorials (lectures for brand new IC members of a powerful organization, for instance) done using "canned speeches" so that the Student Musher can study a subject even when no other Character is available to act as a teacher.
YOU DON'T REALLY NEED AN OBJECT
If you don't want to create an object for the purpose of containing canned material, perhaps because you have a very limited building quota, you can code these attributes onto yourself with equal facility. Supposing that your character's name is Christine, you would simply do it like this:
| &dream1; me=$Christine1:@room/emit %r%In sleep he sang to me, in dreams he came%r%tThat voice which calls to me, and speaks my name%r%tAnd do I dream again? For now I find%r%tThe Phantom of the Opera is there - inside my mind! |
And presto, you have coded the first verse of a song from Andrew Lloyd Webber's THE PHANTOM OF THE OPERA onto your character, to be "sung" to the room whenever you type dream1 from now on.
NOTE: The person who first told me about this self-coding option (and I have sadly forgotten who did so, because it's been so long) told me that in the early days of mudding it was generally considered rude, for some reason, to code such things onto yourself, but perfectly acceptable to code equal amounts of text onto an object which you kept in your IC pocket at all times. I forget what the reasons were supposed to be, but he stated that with new developments in coding, this old prejudice was fading fast and probably I wouldn't meet many people who would know or care which way I was doing it.
Some games find it necessary to set strict limits on how many kilobytes of memory a given character and his personal possessions (coded objects, rooms with lengthy descriptions, etc) can take up on the server. If this is the case, and if you go in for canned speeches in a big way, you may find yourself straining the limits of the tolerance of your local Wizards as you get to the point where 50K or more of text is "stored" on yourself or an object you created.
For starters, here's how to erase canned speeches that you don't need anymore. If you had followed the examples provided earlier for coding Verse 1 and the Chorus of "The Yellow Rose of Texas" onto an object called Harp, then you can erase those stored lyrics by doing this:
| &yellow1; Harp= &yellowc; Harp= |
You simply type the above, as far as the "Harp=" part, and then just hit the ENTER or RETURN key after each line. This effectively tells the server that the new value of that attribute is Nothing, therefore the attribute no longer exists. If you subsequently use the Examine command to look over your Harp, you will find that those attributes are no longer on it - and you have just cleared a few hundred characters' worth of clutter from the local database.
If you don't need something today, but may want to use it again later, you can @decompile the object and save the results as a text file (a log with your client, for example). The results are a list of all the commands which you would need to reenter to recreate the object from scratch if it was destroyed. You can do that at any time - or you can simply cut-and-paste the specific commands relating to items you subsequently deleted from the mush's database, but want to restore to a still-extant object. Of course, the text file with the decompile results will need to be saved on a floppy disk, or perhaps as an e-mail message to yourself, or otherwise preserved for future use.
