How to summon RNG?

G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

I'm on very early stage of RL development. Actually I was trying to get
some pseudorandom numbers. The effect is 2^34 (probably / should be)
sequence, but it's slightly unbalanced. I don't know whether it is fast
or slow, good or bad.

I'm looking for some points how to make good and simple rng.

--
Milesss
m i l e s s s @ i n t e r i a . p l
www.milesss.mylog.pl
"/0"
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Milesss wrote:
> I'm on very early stage of RL development. Actually I was trying to get
> some pseudorandom numbers. The effect is 2^34 (probably / should be)
> sequence, but it's slightly unbalanced. I don't know whether it is fast
> or slow, good or bad.
>
> I'm looking for some points how to make good and simple rng.
>

What's yer lang of choice?

I use Mersenne Twister. You can google for source in C#, C++ and
probably a few others.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Heroic Adventure napisa³(a):
> Milesss wrote:
>
>> I'm on very early stage of RL development. Actually I was trying to
>> get some pseudorandom numbers. The effect is 2^34 (probably / should
>> be) sequence, but it's slightly unbalanced. I don't know whether it is
>> fast or slow, good or bad.
>>
>> I'm looking for some points how to make good and simple rng.
>>
>
> What's yer lang of choice?

L:C++;

>
> I use Mersenne Twister. You can google for source in C#, C++ and
> probably a few others.
>

I downloaded it in C, but there is main() function in source. Is it
allowed to alter? Moreover it must be fine feeling when you make the
whole game from scratch.

--
Milesss
m i l e s s s @ i n t e r i a . p l
www.milesss.mylog.pl
"/0"
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Heroic Adventure wrote:
> Milesss wrote:
> > I'm on very early stage of RL development. Actually I was trying to
get
> > some pseudorandom numbers. The effect is 2^34 (probably / should
be)
> > sequence, but it's slightly unbalanced. I don't know whether it is
fast
> > or slow, good or bad.
> >
> > I'm looking for some points how to make good and simple rng.
> >
>
> What's yer lang of choice?
>
> I use Mersenne Twister. You can google for source in C#, C++ and
> probably a few others.

Or you can use Python and have it come with the standard library. :p
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

If you are only working with 32 or 64 bit integers, a linear
congruential generator would probably work well enough. A linear
congruential generator is one that satisfies the following recurrence:

x_n+1 = ax_n + b mod m.

You have to "seed" the generator with an initial value for x_0, which,
for game applications, can be done by capturing the low order bits of
the system clock.

a = 16807 = 7**5, b = 0, m = 2147483647 = 2 ** 31 -1 works very well
for 32 bit pseudorandom numbers.

If you are really interested in in pseudorandom number generators
(PRNGs), then start by reading the appropriate sections of _The Art of
Computer Programming_. If you're a little interested, play with the
formula I wrote above and check out its properties. If you're not at
all interested, just use the PRNG that comes with your compiler,
unless/until it proves inadequate.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Milesss wrote:
> I downloaded it in C, but there is main() function in source. Is it
> allowed to alter? Moreover it must be fine feeling when you make the
> whole game from scratch.

Yeppers. Nothing beats the feeling of playing a game after thinking it
up, hand-etching and assembling a bunch of chips and other hardware
whose materials you mined out of the earth with your own bare hands
(using a homemade tomahawk for the etching), toggling in the program
code and all OS type stuff, and all that. Hands tapping the keyboard;
legs pumping the stationary bike you constructed to power the thing;
stomach digesting the food you grew yourself... yup. Nothing beats
making the whole game from scratch with zero assistance. Just be sure to
set aside ninety or so years to finish it in. ;)

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Milesss <milesssREMOVE@interia.pl> scripsit:

>Heroic Adventure napisa?(a):
>> Milesss wrote:
>>
>>> I'm looking for some points how to make good and simple rng.
>>>
>>
>> What's yer lang of choice?
>
>L:C++;
>
>>
>> I use Mersenne Twister. You can google for source in C#, C++ and
>> probably a few others.
>>
>
>I downloaded it in C, but there is main() function in source. Is it
>allowed to alter? Moreover it must be fine feeling when you make the
>whole game from scratch.

Erm, yes, it's allowable to alter.

It is a fine feeling when you make a whole game from scratch.
However, random number generation isn't really part of the game. You
may have a greater sense of accomplishment if every line of code used
in your game was written by you, but at what point do you stop? Do
you avoid using standard library routines, since it's possible to code
your own replacements? Do you write your own programming language?
Do you design your own OS? If you want to actually finish your game,
you have to decide what the cutoff point is. I wouldn't worry about
the low level things such as random number generation and string
manipulation unless you really want to.

Okay, but say you still want to write your own random number
generator. If all you want is for the implementation to have been
written by you, you can download the Mersenne Twister algorithm
(<http://home.ecn.ab.ca/~jsavard/crypto/co4814.htm> has a nice
overview) and write your own implementation from that. Or Google for
any of the other popular algorithms and use one of them. If you
really want to develop your own algorithm, there's not much help I can
offer you. I did develop one once, but the basic concept was an
extension of a pre-existing algorithm, except my version was less
efficient, and had no measurable improvement in randomness.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Milesss wrote:
> Heroic Adventure napisa³(a):
>
>> I use Mersenne Twister. You can google for source in C#, C++ and
>> probably a few others.
>>
>
> I downloaded it in C, but there is main() function in source. Is it
> allowed to alter? Moreover it must be fine feeling when you make the
> whole game from scratch.
>

It might be, but I don't know the first damn thing about creating a
reliable RNG from scratch. I leave that to the folks who enjoy that sort
of challenge, so I can get on with my game.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

neokosmos@gmail.com wrote:
> If you are only working with 32 or 64 bit integers, a linear
> congruential generator would probably work well enough. A linear
> congruential generator is one that satisfies the following recurrence:
>
> x_n+1 = ax_n + b mod m.

This is false. Roguelikes use numbers in sequences; With a LCG,
the sequence repeats too quickly. In practical terms, if you
have a lot of "layered" probability rolls, then you will quickly
"run out of numbers" and your probabilities will become skewed
or, in the worst case, predetermined.

Use the Mersenne Twister code, or even a lagged-fibonacci generator
with a long period.

See the "what's wrong with the Random Number Generator that came
with my system?" part of the FAQ.

Bear
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Uzytkownik "Ray Dillinger" <bear@sonic.net> napisal w wiadomosci
news:iRdke.1697$W51.12260@typhoon.sonic.net...
> This is false. Roguelikes use numbers in sequences; With a LCG,
> the sequence repeats too quickly. In practical terms, if you
> have a lot of "layered" probability rolls, then you will quickly
> "run out of numbers" and your probabilities will become skewed
> or, in the worst case, predetermined.

I would consider this a feature. People playing adom (myself included)
love the subtle twists the game presents (some things seem more
probable in specific cases), and I don't really care if it's planned
or just a side-effect of a poor RNG. Creating a game that can surprise
you with huidden dependencies can be very rewarding, and it allows
players to develop a "feel" for what's going on.

regards,
Filip
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

"Filip Dreger" <fdreger@amiga.pl> wrote:
>I would consider this a feature. People playing adom (myself included)
>love the subtle twists the game presents (some things seem more
>probable in specific cases), and I don't really care if it's planned
>or just a side-effect of a poor RNG. Creating a game that can surprise
>you with huidden dependencies can be very rewarding, and it allows
>players to develop a "feel" for what's going on.

You haven't seen some of the items of speed that cropped up in Angband
2.7.8...
--
Martin Read - my opinions are my own. share them if you wish.
My roguelike games page (including my BSD-licenced roguelike) can be found at:
http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
bounce. bounce. bounce. bounce bounce bounce bounce.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

neokosmos@gmail.com napisał(a):
> If you are only working with 32 or 64 bit integers, a linear
> congruential generator would probably work well enough. A linear
> congruential generator is one that satisfies the following recurrence:
>
> x_n+1 = ax_n + b mod m.
>
> You have to "seed" the generator with an initial value for x_0, which,
> for game applications, can be done by capturing the low order bits of
> the system clock.
>
> a = 16807 = 7**5, b = 0, m = 2147483647 = 2 ** 31 -1 works very well
> for 32 bit pseudorandom numbers.

I used 4 LCGs interlaced randomly by the 5th one.

[...]


--
Milesss
m i l e s s s @ i n t e r i a . p l
www.milesss.mylog.pl
"/0"
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Twisted One napisa³(a):
[...]

OK: ...it must be fine feeling when you code...

Make too.

--
Milesss
m i l e s s s @ i n t e r i a . p l
www.milesss.mylog.pl
"/0"
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Ray Dillinger wrote:
> neokosmos@gmail.com wrote:
> > If you are only working with 32 or 64 bit integers, a linear
> > congruential generator would probably work well enough. A linear
> > congruential generator is one that satisfies the following
recurrence:
> >
> > x_n+1 = ax_n + b mod m.
>
> This is false. Roguelikes use numbers in sequences; With a LCG,
> the sequence repeats too quickly. In practical terms, if you
> have a lot of "layered" probability rolls, then you will quickly
> "run out of numbers" and your probabilities will become skewed
> or, in the worst case, predetermined.
>
> Use the Mersenne Twister code, or even a lagged-fibonacci generator
> with a long period.
>
> See the "what's wrong with the Random Number Generator that came
> with my system?" part of the FAQ.

I have two comments about the FAQ.

1. It took forever to find it searching Google groups, mostly due to a
certain poster/Genrogue creator having the string "FAQ" in his .sig.
At the very least, I'd suggest the author or current maintainer make a
monthly posting so it shows up highly ranked on such a search.

2. The section on RNG's is pure hogwash.

I don't think 1 will generate a lot of controversy, so I'll focus on 2.

First, let me concede that, as far as theoretical properties of the
output stream go, MT is going to kick the pants off of x_n+1 = 16807
x_n + 2147483647. Where the LCG is going to win is in speed and ease
of implementation, because it's so simple.

I'd also like to correct a mistaken assertion in my previous post.
While this LCG does have a period of 2**31-1, it is *not* suitable for
generating 32-bit pseudorandom numbers. The reason is that, since it
has period 2**31-1 and the outputs range from 0..2**31-1, you can never
get a repeating subsequence such as "1, 1", which is something you
would want from a PRNG! Proper use of this generator would be to take
the top 16 bits and use it as a 16-bit PRNG (which would still have a
period of 2**31-1).

Now, on directly to the FAQ entry.

Let's say we have a particularly bad system PRNG with a period of
2**31-1 (and, thus, 32 bits of state). Essentially, what this means is
that there are 2**31-1 possible games that your roguelike's code can
produce, modulo user actions. (Obviously, for example, choosing to be
one class versus being another class can significantly affect the
outcome and unfolding of a game.)

Let me think. When was the last time I played a game 2**31-1 times?
How about... never?

What if the PRNG did repeat on me? The significance of the value
0xDEAD is going to be quite different in the context of the level
generation algorithm than in the context of the combat system.
Furthermore, even with a period of 2**31-1, it'll take an awful long
time to get the PRNG to repeat. If, calling the PRNG takes 1
microsecond (10**-6 sec), in order to make it repeat, you'd have to
spend 35 minutes doing nothing but calling the PRNG and discarding the
result.

What is the PRNG used in nethack? On Linux, cygwin, windows, and
MacOS, by default (that is, if you don't edit any header files other
than #defining the appropriate system platform macro), it's... lrand48,
a LCG with modulus 2**48. I have not verified it, but, assuming the
constant terms are chosen correctly, its period should be 2**48. Now,
nethack does have some random number generation problems, but those
problems are really in how the generator is used rather than the
generator itself. When was the last time you saw a post on
r.g.r-l.nethack saying the PRNG was "too predictable"?

In principle, the FAQ entry is correct, though. If I knew all the
probabilities involved, and which PRNG algorithm was being used, there
is the possibility I could deduce where in the pseudorandom number
stream the generator currently was, and, therefore, predict the future
output of the generator. The size of this problem is inversely
proportional to the length of the PRNG period. That is, using a simple
LCG with period 2**31-1, I'm more likely to be able to, in principle,
carry out this operation, than if I am using the MT algorithm with a
period of 2**19937-1. It's a simple consequence of the fact that the
MT's period is 10**5992 times longer.

(Note: one can mitigate this (theoretical) problem quite a bit by using
several independently seeded PRNGs for different subsystems of the
game. For example, one can use a combat PRNG, a level-generation PRNG,
an item-generation PRNG, etc. It's also quite possible to construct a
LCG with period 2 ** 19937-1, but I don't know how its efficiency would
compare to MT.)

Has anyone done this analysis for nethack? Why? Because it's too hard
to be worth it. There are easier ways to cheat.

Various people over time have created patches for nethack which replace
the PRNG with a stronger one, such as MD4. None have made it into the
3.4.3 source tree. Why? Because lrand48 is generally good enough.

Finally, if you want a REALLY long period PRNG, MT is small potatoes.
There exist efficient, well-tested PRNGs with periods up to 2**131086.
[3] I'll provide the C source here (credit to Dr. Marsaglia):


static unsigned long Q[4096],c=362436;
unsigned long CMWC4096(void){
unsigned long long t, a=18782LL;
static unsigned long i=4095;
unsigned long x,r=0xfffffffe;
i=(i+1)&4095;
t=a*Q+c;
c=(t>>32); x=t+c; if(x<c){x++;c++;}
return(Q=r-x); }

In summary: If you're doing Monte Carlo simulations that sample from a
random variate hundreds of billions of times, don't use a LCG. If
you're writing a roguelike, feel free to use lrand48, or the system RNG
(which is probably lrand48 on most common systems, anyway.)

References:

[1] Knuth, _The Art of Computer Programming_, vol. 2 has discussion of
PRNGs.
[2] Nethack source (rnd.c, unixconf.h, and ntconf.h)
[3] http://groups-beta.google.com/group/sci.math/msg/9959175f66dd138f ,
a message by Dr. George Marsaglia, a well-known PRNG researcher, who
compares choosing the "best" PRNG to picking a "best" in the Miss
America contest. :D Also the source for the C source posted above.
[4] http://www.paulm.org/random.html . Additional discussion of
criteria for choosing PRNGs.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

neokosmos@gmail.com wrote:
[...]
> Let me think. When was the last time I played a game 2**31-1 times?
> How about... never?
> What if the PRNG did repeat on me? The significance of the value
[...]

The problem is correlation between values, not mere repetition: unless
one belongs to the minority who likes biased simulations, everything
should happen as often as the game rules say. Player expectations and
game balance depend on the RNG respecting the rules.
In Monte Carlo simulations correlation isn't usually a problem because
it averages out to a small error, but in a RL game there is no way to
compensate or average an orc here with a dragon there or the charges of
a wand with the type of a potion.

A good PRNG for RL games would have the property that, when all initial
states are selected with the same probability, given a huge number of
previous outputs all possible new outputs have the same probability.
>From a different point of view, there should be the same number of
states with each next output and each sequence of previous outputs.
Obviously no PRNG can be perfect from this point of view, and
approximate compliance requires a number of states exponential in the
number of independent consecutive outputs; in fact the PRNG could only
shuffle its truly random initialization without producing more bits.

What can we do?
- use truly random numbers, from "entropy pool" systems with various
sources like /dev/random on Linux.
- use less arbitrary random numbers and more deterministic rules, e.g.
level creation can take place from a simple seed (stairs and artifact
location) with rule-driven digging and placement instead of picking and
testing random squares.
- replace chaotic and unpredictable artifacts of the PRNG with
meaningful and/or visible and/or harmless dependencies, typically
suppressing extreme results.
For example monster treasures could contain item types from a
prioritized list (a fighter type monster could get first a weapon, then
armour, then a missile weapon, then an equal number of useful potions,
appropriate ammo and spare weapons until the target value is reached);
randomness would be very constrained.
Attack rolls could be based on a luck feedback loop instead of a PRNG:
with current luck score l and hit probability p, if l>0 you hit and l
is set to l+p-1 and if l<=0 you miss and l is set to l+p; l and p could
be visible to the player, maybe as indicators (e.g. monsters that would
hit the hero on their next move but not vice versa are in blinking
red).

Lorenzo Gatti
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

neokosmos@gmail.com wrote:

> Ray Dillinger wrote:
> > See the "what's wrong with the Random Number Generator that came
> > with my system?" part of the FAQ.
>
> I have two comments about the FAQ.
>
> 1. It took forever to find it searching Google groups, mostly due to a
> certain poster/Genrogue creator having the string "FAQ" in his .sig.
> At the very least, I'd suggest the author or current maintainer make a
> monthly posting so it shows up highly ranked on such a search.

A bit tangential I know, but if you search this group for "random number
generator FAQ" in google (without the inverted commas), it's the first
page of results on Google (the first result being the FAQ, but we
probably want the "updated and expanded with TOC" version a bit further
down).

> 2. The section on RNG's is pure hogwash.
>
> I don't think 1 will generate a lot of controversy, so I'll focus on 2.

[snip]

> Now, on directly to the FAQ entry.
>
> Let's say we have a particularly bad system PRNG with a period of
> 2**31-1 (and, thus, 32 bits of state). Essentially, what this means is
> that there are 2**31-1 possible games that your roguelike's code can
> produce, modulo user actions. (Obviously, for example, choosing to be
> one class versus being another class can significantly affect the
> outcome and unfolding of a game.)
>
> Let me think. When was the last time I played a game 2**31-1 times?
> How about... never?

[snip excellent summary of why you don't have to worry about the game
being cheatable by predicting the PRNG output]

That FAQ entry I've read doesn't mention that as a problem at all.
Just to check that we're reading the same FAQ, the current one is this
one (I think):
http://google.co.uk/groups?selm=6J_Md.5394%24m31.68565%40typhoon.sonic.net

The problem outlined in the FAQ is about how by using a small-state PRNG
you can inadvertently stop your game working as you intended. The
example given is that finding a Ring of Speed under a rock. This might
require several small-chance rolls in a row, so that assuming you *do*
find such a ring under a rock there were only, say five initial states
the PRNG could have been in to arrive in that situation. If you then
make a choice of ten bonuses from a lookup table you will not be able to
select some of them - five states, but ten choices. In other words, the
badness of the PRNG has led to your design and code not working
as expected, and in such a way you may not even notice, because it
doesn't come up often.

As you say in the snipped bit, you can code around problems by running
several "bad" PRNGs in parallel for different areas of the game, but I'd
expect (as someone who doesn't know enough about the subject to be
sure of anything much) this could have its own drawbacks. If someone
doesn't really know enough about PRNGs to anticipate all such problems
with their generator, isn't it better for them to not have to worry
about them because the randomness is sufficiently good already? Is this
one of those areas where if you don't understand it completely you
shouldn't be using it at all?
--
Antony Sidwell.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

neokosmos@gmail.com napisał(a):
[...]
>
> I'd also like to correct a mistaken assertion in my previous post.
> While this LCG does have a period of 2**31-1, it is *not* suitable for
> generating 32-bit pseudorandom numbers. The reason is that, since it
> has period 2**31-1 and the outputs range from 0..2**31-1, you can never
> get a repeating subsequence such as "1, 1", which is something you
> would want from a PRNG!

It is possible. You can put more than one LCG to one output and randomly
or sequentially choose which LCG will provide next random number.

Another way is instead of:

(lcg_out % n) + m

using:

round_down(lcg_out / max_lcg_out * n) + m.

[...]

--
Milesss
m i l e s s s @ i n t e r i a . p l
www.milesss.mylog.pl
"/0"
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Milesss a écrit :
> neokosmos@gmail.com napisał(a):
> [...]
>
>>
>> I'd also like to correct a mistaken assertion in my previous post.
>> While this LCG does have a period of 2**31-1, it is *not* suitable for
>> generating 32-bit pseudorandom numbers. The reason is that, since it
>> has period 2**31-1 and the outputs range from 0..2**31-1, you can never
>> get a repeating subsequence such as "1, 1", which is something you
>> would want from a PRNG!
>
>
> It is possible. You can put more than one LCG to one output and randomly
> or sequentially choose which LCG will provide next random number.

I don't know much about RNG theories but I think doing that has a chance
to give you a worse RNG than using a single one.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Ray Dillinger wrote:
> neokosmos@gmail.com wrote:


> This is false. Roguelikes use numbers in sequences; With a LCG,
> the sequence repeats too quickly. In practical terms, if you
> have a lot of "layered" probability rolls, then you will quickly
> "run out of numbers" and your probabilities will become skewed
> or, in the worst case, predetermined.
>
> Use the Mersenne Twister code, or even a lagged-fibonacci generator
> with a long period.

Well, I've got an approach to the issue of the proverbial "+6 rings of
speed under the boulder" in the random drops.
you could keep the relative distributions the same, while "randomly"
initializing the actual numbers which generate a certain item each time
the program is started.

for example, at start, initialize the RNG using the clock or whatever,
then instead of coding:
if RAND*100<10 then generate a ring
ELSE etc...

one could write something like:
criteria=RAND*90
generate=RAND*100
IF generate<criteria+10
AND gen>=crit, then generate a ring.

the predetermined patterns (like probabilistic themes) for the items
are still there, HOWEVER, there are DIFFERENT PATTERNS each time the
game is played or started

In effect, in one run, only +10 and +2 rings of speed are dropped, and
in another, only +4 and +6 rings of speed are dropped, but since these
patterns change randomly from game to game depending on where the RNG
is initialized , no one will care, as it's a rarer event in a single
run than across all of them.

Of course, this scheme must superimpose its own patterns, but hopefully
they won't be as glaringly obvious to players, as I think that to
notice these patterns would actually require the player to remember a
number of games appreciably close to the cycle of the RNG.

It occurs to me that I seem to run across themes in Crawl-levels where
needle traps are dropped especially frequently, or where books are
dropped especially often, but I seldom run into two in the same day.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

In article <1117044660.407055.82360@g43g2000cwa.googlegroups.com>,
jasonnorthrup@yahoo.com says...

> > This is false. Roguelikes use numbers in sequences; With a LCG,
> > the sequence repeats too quickly. In practical terms, if you
> > have a lot of "layered" probability rolls, then you will quickly
> > "run out of numbers" and your probabilities will become skewed
> > or, in the worst case, predetermined.
> >
> > Use the Mersenne Twister code, or even a lagged-fibonacci generator
> > with a long period.

If the original seed is a typical version of time(), i.e. milliseconds
since some base time, you will have only a restriced set of series
however long your RNG period.

To put it another way:
LOW ENTROPY IN = LOW ENTROPY OUT

- Gerry Quinn
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Gerry Quinn wrote:
> If the original seed is a typical version of time(), i.e. milliseconds
> since some base time, you will have only a restriced set of series
> however long your RNG period.

On Windows there isn't any superior source of seed entropy. Ditto Macs,
pre OS X anyway.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Twisted One wrote:
> Gerry Quinn wrote:
> > If the original seed is a typical version of time(), i.e. milliseconds
> > since some base time, you will have only a restriced set of series
> > however long your RNG period.
>
> On Windows there isn't any superior source of seed entropy. Ditto Macs,
> pre OS X anyway.

Hell, you could just save the last value the RNG generates for next
time it runs in a file right? The initialization wasn't really my
point though; it just was my understanding that many people use that
approach, as an example.

My point was in reference to the discussion (as mentinoed in the FAQ)
that roguelikes have problems not with the repetition in cycling in the
RNG, but with series of dependent calls to RNG.

to clarify:
>say you have an RNG with a cycle of only 1000, and you're dropping random >items; you have a rule that 1 in 50 spaces gets a randomly dropped item. >so you pull a random number out of the RNG. If it's like the RNG on the >TI-85, then you get a random float between 0 and 1.
> For a properly designed RNG, that means that there's no bias among its >range of output; This would generally mean that it will produce 0, 0.001, >0.002,... 0.999, 1.000, just not in a particularly obvious order, though >it is predictable if you know what number the RNG is seeded with.

>Each and every state (of the e.g. 1000) has exactly one output, and so the >next iteration has exactly one state as well.

>multiply that by 50, and you'll have a float between 0 and 50. so then, >you can say that if the number is less <=1, drop an item.
>That means that of the 1000 possible states of the RNG, only 20 will lead >to a dropped item. Still, not in any particularly obvious order though.

>But when, and only when, this happens, you decide to have your roguelike >to decide which items it will drop; again, at random, as you like variety >in your roguelike. If you have more than 20 possible varieties of items, >this is a problem, because only 20 possible states of the RNG will >generate any item, and the next state of the RNG will only be one of >another 20 states. Note that from this, I cannot predict which 20 >varieties will be dropped, but I can predict that only 20 varieties will >be dropped. experience playing would quickly reveal to a player which 20 >items he will find however. In reality, most RNG's have a much higher >cycle, but most roguelikes have more dependent calls in a row to the RNG.
>In implementation then, the only thing that makes roguelikes truly >unpredictable ( and hence replayable) at all is the initialization of the >RNG differently each time the game starts, and the resequencing of these >calls to the RNG by the player's choices of actions.



Now, rather than create a new RNG with a larger cycle (HARD WORK). you
can affect this situation somewhat (EASY WORKAROUND), by changing which
of the first 20 states generates an item; say, by choosing states whose
outcomes produce numbers between 49 and fifty instead, or between 27
and 28, instead, by determining this too, from a call to the RNG.
however, this would not be useful if the RNG were always initialized to
the same state before this step occurs.

This still leaves only 20 varieties of items to be randomly dropped,
but they would be 20 different varieties than those produced by the
algorithm I propose in the beginning of this post (not the thread)
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

In article <p7adnYaalZyaJwvfRVn-3Q@rogers.com>, twisted0n3
@gmail.invalid says...
> Gerry Quinn wrote:

> > If the original seed is a typical version of time(), i.e. milliseconds
> > since some base time, you will have only a restriced set of series
> > however long your RNG period.
>
> On Windows there isn't any superior source of seed entropy. Ditto Macs,
> pre OS X anyway.

One option is to ask for player input.

But anyway, my point is that unless you solve this problem, all the
stuff about how you will only get a +3 sword of torment, never a +2 or
+4, is just as true for the Mersenne Twister as for whatever version of
rand() your compiler gives you.

- Gerry Quinn
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Gerry Quinn <gerryq@deletethisindigo.ie> wrote:
> But anyway, my point is that unless you solve this problem, all the
> stuff about how you will only get a +3 sword of torment, never a +2 or
> +4, is just as true for the Mersenne Twister as for whatever version
> of rand() your compiler gives you.

Gerry, this isn't true. MT doesn't encounter this problem because it has
a much, much larger period (2^19927 as opposed to something around
2^1000). The small period of other algorithms is what causes the problem
you're describing above, and has nothing to do with entropy. Please let
me know if I've misunderstood.

Also, I just found a good C++ implementation of MT here
(http://www-personal.engin.umich.edu/~wagnerr/MersenneTwister.html)
which is something I've always been looking for.

--
Jim Strathmeyer
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Jim Strathmeyer wrote:
> Also, I just found a good C++ implementation of MT here
> (http://www-personal.engin.umich.edu/~wagnerr/MersenneTwister.html)
> which is something I've always been looking for.

Great link, thanks! I've been using a rather simplistic,
straightforward C implementation, derived straight from the original
source. This is much better, and OO. Very nice!


--
Read more about my three projects, SoulEaterRL,
Necropolis, and a little toy RL.

http://www.freewebs.com/timsrl/index.htm

--