Some advice for puzzle creators
Brian R. Holt
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
Michael L. Mauldin
>
> 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...@NL.CS.CMU.EDU Carnegie Mellon University
Phone: (412) 268-5293 Pittsburgh, PA 15213-3890
Benjamin Harrison
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.
-----...@sparky.eecs.umich.edu--------Bosk@{Tswat, Tusc, Thell}------
Bart Massey
> 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
>
> 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 ? :-).
Bart Massey
ba...@videovax.tv.tek.com
ba...@reed.bitnet
James Seidman
>... 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.
rusty wright
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
Benjamin Harrison
>All of the robots would have their dark bit set so you wouldn't see
>them coming and going.
>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.
>--
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
----...@sparky.eecs.umich.edu----Bosk@tinyhell/tinyUSC/tinySWAT
Bart Massey
> In article <14...@reed.UUCP> ba...@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!
Bart Massey
ba...@reed.bitnet
ba...@videovax.tv.tek.com