>
> With the increased usage of clients, also comes the usage of triggers
> or actions. From the players view, they are nice, they remove some of
> the monotony of having to do certain things, though, when you introduce
> a player killing atmosphere, it is no longer who is better skilled
> player, but rather who is on the fastest connection with the quickest
> and best programmed triggers.
>
> To avoid this type of thing, I was wondering what other Implementors
> have done as far as code goes to remove trigger problems. I'm not
> looking for code mind you, just ideas. After awhile of thinking about
> it, I thought maybe I could send a "blank" ascii character ever few
> letters. Something like this:
>
> Where & = blank ascii character:
>
> You s&ense &a tra&il we&st fr&om he&re!
>
> Which would show to the characters as:
>
> You sense a trail west from here!
>
> The problem with using something like this is taking into
> consideration each type of client and making sure that the ascii
> character doesn't show up on any of them, which is a near impossible
> task. Which, brought me to writing this post. Any ideas, suggestions,
> or comments would be greatly appreciated.
>
Randomizing responses by the MUD ("you move west", "you travel west with
your huge gametes trailing"...etc) is one possibility. NULL (0) ASCII
character. Randomizing amt. of spaces between words (1-3 spaces).
Randomizing common keywords (changing west to [w]est or West or WEST ...)
In any case, as long as the output of the same commands entered multiple
times are inconsistent (that is to say, the commands are not functions),
triggers become less applicable.
Another idea would be to randomize the punctuation. Although most programs
don't depend on punctuation, but rather keywords.
A slightly less viable idea would be to equalize lag times by accounting for
connection speed differences (ie: delaying data transfer depending on PING
rate)...for example: Joe's ping is 20ms, Jane's is 100ms, and Blake's ping
is 200ms. You could delay all output to Joe by 180, to Jane by 200, and
send to Blake ASAP. Of course, you should limit this to no higher than a
250ms delay (arbitrarily chosen, generally people begin to notice after 1/2
of a second...so why not make it 1/4?) This is a more communistic solution
to the "quicker connection/faster triggers". Another would be to order the
processing of the commands by ping rates...lowest latency=last processed.
This may acquire a nasty queue of all the fast connections when anyone drops
from the MUD. Hey, it reminds me of Gore's targeted tax return approach!
;-)
Anyway, those are a few ideas--maybe not the best, but they are ideas.
Treker
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT