[Kde-games-devel] KsirK and Jabber

[Aaron J. Seigo]

On Tuesday 16 September 2008, Matthew Woehlke wrote:
> Aaron J. Seigo wrote:
> > On Tuesday 16 September 2008, Matthew Woehlke wrote:
> >> Hmm, good point. But what about using the seed distribution system
> >> again?
> >
> > assuming you can generate enough entropy between requests, that should
> > probably work.
>
> Well, you'd *better* be able to generate enough entropy :-). Otherwise,
> a central server is going to have the same predictability problem, no?

no, because you're not re-seeding the PRNG each time you go to get a result. 
if you don't get enough entropy between re-seeds, e.g. the see is the same, 
then you end up with a predictable result. SO... one client could simply 
request random numbers constantly from the clients and "peek ahead" that way 
too if the entropy is too low.

> > note that you can only have as many players as there are bits in the seed
> > before it starts to break down (on disconnect you could re-choose seed
> > contributors; or rotate between players). i doubt that will be an issue
> > for most games though =)
>
> I think that would depend on how you feed the bits into the PRNG, i.e.
> you could probably use a bitstream-based PRNG that can accept any number
> of input bits. But as you say, how many games have that many players? ;-)

yeah, it's not like we're making WoW

still ... central server is way more straightforward for this... 

if *i* was writing the code (i'm not, btw ;) then i'd create a PRNG interface 
with three implementations: all-local (use the local PRNG only for local only 
games), sync'd-seed, central server.

the library with the PRNG access in it would use local PRNG if it's not a 
network game, and try the central server if it was and failing that fall back 
to the sync'd seed mechanism which may be less reliable but at least let you 
play =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech