If you are creating puzzle areas in TinyMUD (or other TinyWorlds), and you use some sort of keys to make the puzzle work, please be sure to keep the following in mind (this should be obvious to most of you):
1. Only one person at a time can successfully use your puzzle, unless you create duplicates of the keys. At best a small number can use it at once. 2. If someone steals the keys, your puzzle is useless.
With that in mind, be sure that you:
1. Keep your puzzle area distinct from the rest of the world. 2. Post a warning sign at the entrance, so that people can get out easily before they are committed. 3. Have a small number of exits from the area (one or a few) 4. Set your keys' homes to the appropriate places and make them sticky (@link key1 = someroom) (@set key1 = STICKY) 5. Lock all the exits out of the puzzle area against all of your keys! (@lock exit = !key1 & !key2 & !key3) 6. Set the fail message on the puzzle area exits to warn the person (@fail exit = You can get out of the puzzle while carrying any keys)
These precautions will ensure that nobody can walk out of your puzzle with your keys, that the keys will go the correct place when dropped, and that your puzzle will be reusable forevermore.
Rowan
P.S. To make your puzzle robot-proof, put a robot trap in the foyer. Make the foyer a room with just two exits: out and pizza (or other nonsense word). Make the description something like:
Puzzle Anteroom You are in a small anteroom to the foobar puzzle. To get out and avoid the puzzle, use the 'out' exit. To get into the puzzle, use the exit named after the flat Italian food made out of bread dough, tomato sauce and mozzarella cheese. You know, the stuff you get at Papa Gino's...
Human beings can get in easily, robots will be baffled and just go out.
Email br...@ima.isc.com "Dancing is not allowed in the Ballroom." Phone 617-661-7474 x206 Longfellow's Wayside Inn, 1990 Fax 617-661-2070 near the last bend in the Charles River
In article <16...@haddock.ima.isc.com>, br...@padouk.ima.isc.com (Brian R. Holt) writes:
> P.S. To make your puzzle robot-proof, put a robot trap in the foyer. > Make the foyer a room with just two exits: out and pizza (or other > nonsense word). Make the description something like: > ... > Human beings can get in easily, robots will be baffled and just go out.
That will work fine until someone says:
Julia, go pizza.
A better way to keep a Maas-Neotek robot out is to lock the door with a key that must be dropped in the next room. Vanilla Maas-Neotek robots won't pick up objects (to avoid disturbing puzzles).
The major problem with M-N robots in puzzles is that IF they can solve the puzzle, they'll happily tell people the answer, and spoil the fun.
Just be careful. Any trap that confuses most robots may very well confuse real people, too.
---------------- Dr. Michael L. Mauldin (Fuzzy) Center for Machine Translation ARPA: Michael.Maul...@NL.CS.CMU.EDU Carnegie Mellon University Phone: (412) 268-5293 Pittsburgh, PA 15213-3890
It has been noticed by many people, on many occasions, that robots can be very annoying. This is the fault of most, but not all, robots, and their complete lack of politeness. Unfortunately (for the robots trying to make friends with humans) the fact that most robots are annoying tends to cause many people to gag robots on sight. I propose the following tenets of the Robotic Code, so that at very least no robot obeying the code will be annoying enough to get toaded. 1) No robot should be left unattended unless debugged to a reasonable state. It is perfectly understandable that people wish to toad a robot that crashes often enough to cause logging in twice a minute. 2) No robot should say "I don't understand" out loud. The only person who cares (if him) is the person misunderstood, so whisper to him. 3) No robot should respond to anything not a) directed at him, b) said about him, or c) done by the last person to make a *comprehended* statement to the robot, unless such responses may easily be disabled by anyone who is annoyed (i.e. inane chatter like 'I'm off to wherever' should be disabled if someone says 'shut up') 4) Preferably, whispers should be answered in whispers or not at all. At very least, the statement 'I will be more quiet' should be whispered, to deal with a robot being whisper gagged. 5) Preferably, a robot should be able to ignore other robots. This is especially humorous if you tell one robot to say "pick that up" to another robot, and quickly leave the room. Then the robots will spend eternity saying "I don't pick things up, otherrobot" to each other. :) :) 6) If the robot is debugged and left to run unattended, a maximum of maybe four restarts a day should be performed. If a robot crashes more than four times a day, it is not debugged enough to be running unattended. And about four i/o timeouts a day is a reasonable margin of 'safety.' This is especially important as it may be the robot itself casuing the system to crash, or to kick it out. 7) Normal politeness is assumed, including the ability to be told to leave, unless taking notes or whatever, in which case the spoken output should be *minimal* in case people get sick of the robot.
Anyway, SpyBot is now in accordance with these rules, except #4 for certain commands (i.e. map requests) which are being converted. From the programmer of a once annoying robot to those of you with still annoying robots (including most vanilla Maas-Neotek bots), I bid you change your ways, or end up trying to connect to a toad... :) Brought to you by Bosk, and the people of Better Bot Business, Inc.
In article <8...@pt.cs.cmu.edu> m...@nl.cs.cmu.edu (Michael L. Mauldin) writes:
> In article <16...@haddock.ima.isc.com>, br...@padouk.ima.isc.com (Brian R. Holt) writes:
> > P.S. To make your puzzle robot-proof, put a robot trap in the foyer. > > Make the foyer a room with just two exits: out and pizza (or other
> A better way to keep a Maas-Neotek robot out is to lock the door with a > key that must be dropped in the next room. Vanilla Maas-Neotek robots > won't pick up objects (to avoid disturbing puzzles).
One apparently useful way to keep robots in the dark is to take advantage of the TinyMUD feature that if a player uses an exit name which is attached to more than one exit, an exit is chosen randomly. Putting a few exits like that into your TinyMUD is more than likely to keep most robots fairly baffled about that area of the map... CAVEAT: The probability distribution in TinyMUD as shipped is *not flat* -- the Nth exit is chosen with probability 1-2**-N . I wasn't sure whether this was a bug or a feature, although I suspect the former strongly, given the way the code looks. At any rate, it's flattened in my bits (can *you* find the algorithm which requires max. N swaps, not 2N ? :-).
In article <14...@reed.UUCP> b...@reed.UUCP (Bart Massey) writes: >... CAVEAT: The probability distribution >in TinyMUD as shipped is *not flat* -- the Nth exit is chosen with >probability 1-2**-N . I wasn't sure whether this was a bug or a feature, >although I suspect the former strongly, given the way the code looks.
Sorry, could you explain that again? It sounds like the first exit has probability .5 of being chosen, the second .75, the third .875, and so on, which I'm sure was not what you meant. Is it the first or the last exit which has the highest probability of being chosen? -- --------------------------------------------------------------------------- ---- Jim Seidman, Harvey Mudd College, Claremont, CA 91711. (714) 621-8000 x2026 DISCLAIMER: I don't even know if these are opinions, let alone those of anyone other than me.
Having robots always whisper is important. Another thing that could reduce "robot noise" would be for wizards to create the characters robot1 through, say, robot50, with the same password as their name. All of the robots would have their dark bit set so you wouldn't see them coming and going. If you want to run a robot you would find the next available robot and change it's name and password to what you want and off you go. Also, wizards should be willing to set the dark bit on existing robots.
There's one serious problem with this though; since the robot is dark and you won't see it enter a room, the owner could send it to a room to spy on players. --
-------------------------------------- rusty c. wright ru...@violet.berkeley.edu ucbvax!violet!rusty
In article <RUSTY.90Mar31161...@garnet.berkeley.edu> ru...@garnet.berkeley.edu (rusty wright) writes: >All of the robots would have their dark bit set so you wouldn't see >them coming and going.
........ Also, wizards should be willing to set the dark
>bit on existing robots.
>There's one serious problem with this though; since the robot is dark >and you won't see it enter a room, the owner could send it to a room >to spy on players. >--
Exactly! How does one go about persuading a wizard to set a robot's dark bit? This has MAJOR applications :).
Seriously, though, making a robot dark is not the answer. The problem with most robots is not seeing their annoying "Robot has left" or "Robot has arrived" messages, but rather having to put up with (especially with tinytalk-less players) their incessant chatter ("I'm sorry, I don't understand" or "well, Human, I've seen the last umpteen-billion players today. Here is a list..." or even better, "I'm sorry, other robot, I don't pick things up." -> infinite recursion) Simple comings and goings can be eliminated through modifying tinytalk to have a metagag function -- which eliminates EVERYTHING that player does from your screen. A major necessity is to enforce whispering to answer whispers and also, perhaps, in any room with more than say 5 humans in it. And also, error messages should NOT be said out loud!!!
In response to Random's recent, um, retaliation to robots (not quite a threat, more of a response to provocation) due to their annoying habit of cluttering the Nexus airspace, including the 'toad on sight' clause, may I ask if it is permitted for a robot to *pass through* and NOT linger, if such a pathway is deemed necessary, if the robot is set to treat such locations as sacred and necessary to avoid? Or is the problem the actual comings and goings? It is simpler to teach a robot to leave on entry rather than to never enter, especially if it is the first time an exit has been tried, and it just happens to lead to nexus. (A lot of exits do...) However, I am confident that exits, also, can be enforced as "taboo", once discovered. Along the same program, perhaps certain *players* could also be designated as "taboo," and the robot would flee contact with them... just a thought, could increase a robot's life span. :) :)
As for robots themselves, SpyBot now has the (limited) capability to tell (really bad) jokes, with the concurrent charging for punchlines. Also, he can accept verbal "programs" which can include loops, recursion, macros, and any statement that can legally be whispered in his ear by his owner. Also, he cancels execution on core dumps, so none of this "crash and look stupid, then reboot and piss everyone off."
:is sorry to take up your time talking about robots. "Just my two pennies worth, OK? :leaves in a huff and disconnects
In article <5...@jarthur.Claremont.EDU> jseid...@jarthur.Claremont.EDU (James Seidman) writes: > In article <14...@reed.UUCP> b...@reed.UUCP (Bart Massey) writes: > >... CAVEAT: The probability distribution > >in TinyMUD as shipped is *not flat* -- the Nth exit is chosen with > >probability 1-2**-N . I wasn't sure whether this was a bug or a feature, > >although I suspect the former strongly, given the way the code looks.
> Sorry, could you explain that again? It sounds like the first exit has > probability .5 of being chosen, the second .75, the third .875, and so on, > which I'm sure was not what you meant. Is it the first or the last exit > which has the highest probability of being chosen?
Oops -- that's obviously wrong. The correct probability is of course P(exit i of N) = 2**(i-N-1) I was trying to avoid the extra parameter and hosed up the math. And apparently it is supposed to be a feature -- my apologies for implying otherwise. So far this piece of code has been really impressive -- I haven't found an actual *bug* in it yet! Nice job!
|
