[MUD-Dev] The grass is always greener in the other field

Sellers Sellers
Fri Dec 17 14:21:57 CET 1999


Adam wrote:
> On Fri, 17 Dec 1999, Greg Miller wrote:
> > J C Lawrence wrote:
> > > Locked doors on houses were fine with percentage chances at picking
> > > the lock -- until someone noticed that even a 0.0001% chance
> > > requaled a ~100% given a pick-lock macro playing endlessly.
> > 
> > This is one reason I dislike random numbers. Ideally, I prefer a system
> > that would, at most, *appear* mostly random due to the number of factors
> > involved in calculating success. Of course, it's not always easy to come
> > up with reasonable formulae that make things variable enough.
> 
> The system which I have proposed here before, and in fact which I use
> myself, is seeded randoms.  The chance to pick a lock, hide in a certain
> room, or do other actions which need a hint of randomness but which the
> player should not be able to "spam" until they succeed, is based upon a
> seed for that location.
> 
> So a given lock-picker will either not be able to pick a given player
house's
> lock at all, no matter how many times they try, with their current skill
> level; and then once they can, they can do it every time, prompting the
> player who owns the house to buy a new lock if they find that someone
> who can gain access to their house does so on a regular basis.

Adam, I believe I've seen this before expressed as:

seed = location seed + (obj ID | activity ID) + your skill level
randNum = rand(seed)
if (your skill > randNum) success = TRUE;

So you use the location, activity or object involved, and your skill to
build seed for the random number.  As long as one of these doesn't change,
your success or failure won't change either.  This also allows for critical
success/failures if you want that sort of thing.

Is that essentially what you were talking about?


Mike Sellers



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list