December 1999
- Neural Networks as the AI system for a MUD? PartyG2816@aol.com
- Neural Networks as the AI system for a MUD? claw@kanga.nu
- Neural Networks as the AI system for a MUD? Marc Bowden
- Neural Networks as the AI system for a MUD? Lo, Kam
- Neural Networks as the AI system for a MUD? Marc Hernandez
- Neural Networks as the AI system for a MUD? Kræn Munck
- Neural Networks as the AI system for a MUD? Hans-Henrik Staerfeldt
- Neural Networks as the AI system for a MUD? PartyG2816@aol.com
- Neural Networks as the AI system for a MUD? Hans-Henrik Staerfeldt
- Neural Networks as the AI system for a MUD? Andrew Norman
- Neural Networks as the AI system for a MUD? Mik Clarke
- New member IronWolf
- Scenarios Chris Lloyd
- ColdStore J C Lawrence
- New AI Engine released Fabian
- New AI Engine released Steve Houchard
- New AI Engine released Bruce Mitchener, Jr.
- New AI Engine released Elysium
- AI's in MUDS and Online Gaming IronWolf
- AI's in MUDS and Online Gaming Matthew Mihaly
- AI's in MUDS and Online Gaming IronWolf
- AI's in MUDS and Online Gaming Ryan P.
- Garbage Collection Miroslav Silovic
- Capture of players. (was: Fair/Unfair? Scenarios) Kræn Munck
- Capture of players. (was: Fair/Unfair? Scenarios) J C Lawrence
- Capture of players. (was: Fair/Unfair? Scenarios) Chris Lloyd
- Biosystems (was Fair/Unfair? Scenarios) Richard Ross
- Biosystems (was Fair/Unfair? Scenarios) Philip Loguinov -- Draymoor
- Biosystems (was Fair/Unfair? Scenarios) Mik Clarke
- Biosystems (was Fair/Unfair? Scenarios) J C Lawrence
- Biosystems (was Fair/Unfair? Scenarios) Greg Miller
- Biosystems (was Fair/Unfair? Scenarios) Dundee
- Biosystems (was Fair/Unfair? Scenarios) Travis S. Casey
- Biosystems (was Fair/Unfair? Scenarios) Douglas Couch
- Biosystems (was Fair/Unfair? Scenarios) Marc Hernandez
- Biosystems (was Fair/Unfair? Scenarios) J C Lawrence
- Biosystems (was Fair/Unfair? Scenarios) Mik Clarke
- Ideas for dynamic worlds Nolan Darilek
- Ideas for dynamic worlds Chimera
- Ideas for dynamic worlds Ilya, Game Commandos
- Ideas for dynamic worlds J C Lawrence
- Ideas for dynamic worlds Nolan Darilek
- Ideas for dynamic worlds Joe Kingry
- Ideas for dynamic worlds David Morgan
- The GTS Library J C Lawrence
- Combat systems Neil Edwards
- Combat systems Kylotan
- Combat systems Kylotan
- Combat systems Chris Lloyd
- Combat systems J C Lawrence
- Combat systems Marc Spoorendonk
- Combat Systems Ben
- Combat Systems Raph Koster
- Metakit J C Lawrence
- Commercial Online Roleplaying Games (fwd) J C Lawrence
- Mud-Dev FAQ Marian Griffith
- Mass bannings (was The grass is always greener in the other field) AR Schleicher
- Game Balance: Statistical Analysis in MPORPGs Lovecraft
- Game Balance: Statistical Analysis in MPORPGs Koster, Raph
- Biosystems & simulation [RAMBLE] Ben Greear
- Souveniers Douglas Couch
- Souveniers Lovecraft
- Souveniers J C Lawrence
- Souveniers Raph & Kristen Koster
- Souveniers J C Lawrence
- Souveniers Raph & Kristen Koster
- Ideas for dynamically generated worlds Cynbe ru Taren
- Ideas for dynamically generated worlds J C Lawrence
- Balancing between anxiety and boredom (was Fair/Unf air? Scenarios (fwd) ) Sellers, Michael
- Online Migration and population mobility in a virtual gaming setting - Ultima Online J C Lawrence
- lockpicking Matthew Mihaly
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Sellers, Michael
- Optimized Object Storage Matthew Mihaly
- Optimized Object Storage J C Lawrence
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Sellers, Michael
- Optimized Object Storage Ian Macintosh
- The Habitat Papers are missing J C Lawrence
- Waving Hands -- Debian's Spellcast for Linux J C Lawrence
- Waving Hands -- Debian's Spellcast for Linux Dan Shiovitz
- Waving Hands -- Debian's Spellcast for Linux Travis Casey
- Waving Hands -- Debian's Spellcast for Linux J C Lawrence
- Upload to ftp.kanga.nu J C Lawrence
- Farewell again Ilya, GC
- Telnet Protocol and Winsocks method
- Telnet Protocol and Winsocks J C Lawrence
- Telnet Protocol and Winsocks cg@ami-cg.GraySage.Edmonton.AB.CA
- Telnet Protocol and Winsocks Ilya, GC
- Telnet Protocol and Winsocks J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Ben Greear
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Christopher Allen
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Christopher Allen
- MUD source licensing: beyond GPL? (fwd) J C Lawrence
- MUD source licensing: beyond GPL? (fwd) Matthew Mihaly
- Classes and Races and more (a BIG list) (fwd) J C Lawrence
- Originality/Points of Reference (was Classes and Races and more (a BIG list) (fwd)) Richard Ross
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Justin Rogers
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Justin Rogers
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Christopher Kohnert
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Matthew Mihaly
- Collecting ideas for a MUD server... (fwd) Jon A. Lambert
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Wesley W. Terpstra
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Wesley W. Terpstra
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Originality/Points of Reference Ian Klimon, Esq.
- Job Openings - Mud Engineering Christopher Allen
- PGP player certificates (was: collecting ideas...) Wesley W. Terpstra
- PGP player certificates (was: collecting ideas...) David Bennett
- Re[4]: The grass is always greener in the other field Travis Casey
On Wednesday, December 22, 1999, J C Lawrence wrote:
> On Mon, 20 Dec 1999 21:53:12 -0500 Travis Casey <efindel@io.com> wrote:
>> On Saturday, December 18, 1999, J C Lawrence wrote:
>>> On Sat, 18 Dec 1999, Ian Macintosh <iman@issystems.co.nz> wrote:
>>>> I would suspect that you would just keep track of the last one
>>>> attempted per player (ie, player.last_picked_lock or whatever).
>>>> That'll stuff the macro's up. And that's all you really want,
>>>> isn't it?
>>> No go. All that happens is that the macro people change the
>>> macro to be:
>>> Go to house X and pick lock Go to house Y and pick lock Repeat
>>> until success.
>> Which may be enough, if you simply don't want someone to spam the
>> lock to quickly pick it. The real problem here is not the ability
>> to keep trying to pick a lock until you succeed -- it's the fact
>> that each attempt takes so little time.
> Disagreed. All that really means is that my macro spinner takes
> longer to pick the lock it doesn't change the fact that despite the
> probability of any one pick being successful being tiny, when
> repeated ad-infinitum they approximate 1.
Is that a disagreement? I didn't say that it solves that problem -- I
only said that it may be enough if you simply don't want someone to
spam the lock to quickly pick it. My "the real problem" note should
be taken in that context.
If that's not the problem you have, then it may not be enough -- but
that doesn't change the fact that it may be enough if your problem is
simply people spamming locks.
>> In the real world, lockpicking is a variable activity -- sometimes
>> picking a particular lock takes me just a few seconds, sometimes
>> it takes me a few minutes. Almost any key-type lock can be picked
>> by someone who knows how to pick locks, given sufficient time --
>> it's that time that's important, though. The longer it takes to
>> pick a lock, the greater the chance is that you will be noticed.
> Conversely, the problem with a game is that "notice" is a much more
> manipulable fact than IRL. There are social structures and routines
> built into RL that deal with "suspicious activities" that don't
> exist or particularly pertain to MUDdom.
Of course, one could go on from that, and wonder why people are using
defenses that rely on such things for their true effectiveness if they
do not have such things in their muds. The fact that a solution does
not work for problem X doesn't mean that it's useless for all problems
-- only that it's useless for that problem.
>>> The lengths players will go to to automate and chart their game
>>> worlds are extreme. Look at the lengths players have gone to to
>>> empirically determine what UOL's base formulae are by carefully
>>> graphing the observed behaviours, and then tweaking the forumlae
>>> until they match the graph for damn near all the skill growth
>>> curves, combat curves etc.
>> Has it? You keep bringing up UOL as an example of this, but their
>> formulas are rather simple, and they expose many numbers to the
>> players.
> I quote UOL as one of the better documented examples. Additionally,
> for some of the tables that have been derived (and this can be
> extrapolated all the way down to the reverse engineering of the UOL
> client protocols and data structures) considerable empiracle work
> was required to go as far as they did. Yes, UOL provided an easy
> initial start, but I don't see that this minimises the the magnitude
> of the actual work done.
> Heck, at one point I graphed and derived most of the base curves for
> SimCity after I got sick of trying to ghost-feel for the sweet
> spots...
I think the thing that tweaks me isn't your raising UOL as an example,
but the way in which you raise it (or, I should say, the way that it
seems to me). It seems to me that you raise it not as a "think
carefully about how much work you want to put into this -- it may take
much more than you think" warning, but as a "this won't work".
>> These two factors make it much, much easier for players to figure
>> out their formulas.
> While I can't give an example, I also recall seeing traffic in RGM*
> reverse engineering the apparent base formulae for MUDs which hid
> the numbers behind cute phrases.
If they're doing a one-to-one mapping of numbers to phrases, like the
paper RPGs FUDGE and MSH (the original, not advanced MSH), then it
wouldn't be too hard. I'm thinking more in terms of many-to-one
mappings of "real" numbers to displayed values.
>> To my knowledge, no mud has yet tried hidden numbers and
>> deliberately obscured formulas -- and while it makes no sense to
>> assume that such an attempt would be 100% successful, it also
>> makes no sense to assume that it would be 100% unsuccessful.
> True. However given a successful game (commercially, or of a player
> base size sufficient to represent a commercially successful game),
> it appears reasonable to assume that such an attempt would be
> successful.
However, not everyone wants to have a game of such magnitude. For
those interested in smaller playerbases, and especially those more
focused on roleplaying (who are less likely to attract large numbers
of players, and whose players are arguably less likely to be
interested in such number-crunching), such solutions might still be
attractive.
I'm not saying that it *will* work, or that it would be some sort of
panacea -- all I really want to say is that I think there are useful
techniques that could be discussed, but that repeatedly bringing up
UOL as a "counterexample" may be having a stifling effect on such
discussion.
A few ideas on techniques:
Use multiple random variables, with them changing at different
times. E.g., one could have a random "biorhythm" for each character
-- when a character is logged in, the system generates random numbers
for its mental/physical/spiritual/etc. potency, then uses them in
further calculations. These only change between logins, so any series
of tests run in a single login will be skewed.
Combine multiple values in levels displayed to players. E.g., a mud
might internally use a linear system in which attributes average 50
and range up to 200 for some attributes, but range up to 500 for
others -- but remap all of them to show 5 as "average" to players and
10 as "maximum".
Another way of doing this might be to display compound attributes --
e.g., the old Star Frontiers roleplaying game had pairs of related
abilities: Strength/Stamina, Dexterity/Reaction Speed,
Intuition/Logic, and one other pair I can't recall. The two abilities
within a pair had to initially be within a certain distance of each
other. A mud might use such pairs internally, but show each pair to
players as being a single ability.
The system might either lie about attribute values or might "scale"
them differently for different characters. For example, a mud using
textual descriptions might describe a human's strength as being
"excellent" -- but that might be weaker than an ogre with "fair"
strength, because the descriptions are scaled by race.
Use multistage processes, with the interior stages hidden. For
example, the paper RPG _Fantasy Wargaming_ divides casting a spell
into two or three stages:
Stage 1 - caster creates a magical link to the target
Stage 2 - the target, if magically active and aware of the link, can
try to resist by sending a magical command to "desist" back
down the link
Stage 3 - the character sends the spell down the link, and the
spell's success or failure is determined
This could all be presented to players as being a single action -- the
casting of a spell. Since multiple die rolls are involved, skills and
attributes are used multiple times, different environmental factors
affect the different stages, and stage 2 may or may not come into
play, this could be a difficult knot to untangle.
This could turn out to be a case where it's possible to create a
simpler equation that will match most cases -- but it also might not.
Testing would be necessary to ensure that it isn't.
There could be nonobvious inputs -- using _Fantasy Wargaming_ as an
example again, its magic system is based on the medieval astrological
System of Correspondences -- and thus, a spell that is governed by
Taurus will be more effective during the hours governed by Taurus, or
more effective when cast in a field full of cattle. (Of course, one
can argue that if this is so, it should be known -- mages should have
figured it out generations ago. However, there are world setups in
which such factors might logically not be known.)
The inputs for a particular calculation might vary -- to take a simple
example, the system might take the best or worst two of several
possible inputs. If you're being truly nasty, the inputs might vary
randomly or on some sort of bizarre pattern.
Outputs may vary as well -- for example, an equation might produce one
output, which is then "split" through another calculation (possibly
involving random inputs) to produce multiple dimensions of an output.
To bring this back to lockpicking, one might split a result into how
long the attempt takes, whether or not it succeeds, how much noise is
made, and whether any visible evidence of the lockpicking is left
(e.g., scratches on the lock).
This is just a sampling of ideas -- there are many more possibilities,
I'm sure. The point is that if you want to obscure how the system
works from players, there are many ways to do it. Whether the effort
is worth it, but in terms of effort and likely player annoyance, is
something that different mud designers will have to answer for
themselves.
--
|\ _,,,---,,_ Travis S. Casey <efindel@io.com>
ZZzz /,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_) - Re[4]: The grass is always greener in the other field J C Lawrence
- Re[4]: The grass is always greener in the other field Adam Wiggins
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Wesley W. Terpstra
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) J C Lawrence
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Marc Bowden
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Greg Miller
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) cg@ami-cg.GraySage.Edmonton.AB.CA
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Hans-Henrik Staerfeldt
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) cg@ami-cg.GraySage.Edmonton.AB.CA
- PGP confusions hopefully resolved (was: collecting ideas ...) Wesley W. Terpstra
- MUD-Dev digest, Vol 1 #237 - 9 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #237 - 9 msgs J C Lawrence
- MUD relevant references (was: The grass is always greener...) Ola Fosheim Grøstad
- Re[6]: The grass is always greener in the other field Travis Casey
- Embedded languages, object persistance... ack. Joe Kingry
- Embedded languages, object persistance... ack. cg@ami-cg.GraySage.Edmonton.AB.CA
- Embedded languages, object persistance... ack. Laurent Bossavit
- Embedded languages, object persistance... ack. Kevin Littlejohn
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. Jay Carlson
- Embedded languages, object persistance... ack. Jay Carlson
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. icecube@ihug.co.nz
- Embedded languages, object persistance... ack. Kevin Littlejohn
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Rahul Sinha
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Ola Fosheim Grøstad
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Kevin Littlejohn
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Phillip Lenhardt
- Storing tokens with flex & bison Dominic J. Eidson
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Chris Jones
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Ola Fosheim Grøstad
- Storing tokens with flex & bison Per Vognsen
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Chris Turner
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison Greg Miller
- Storing tokens with flex & bison J C Lawrence