Fighter-vs-fighter randomness

[Guest]

Archived from groups: alt.games.vgaplanets4 (More info?)

I was testing simulations of pure fighter wings versus other wings in
one-on-one duels, and I was struck by how the only combat option which
made any difference was "Close to point blank". If a sim started with
say 250 fighters versus 300, it would always end with eg 119 vs 83. The
code must be highly deterministic (no randomness), but most options
(even adding HG) made no difference to the outcome.
--
Paul Honigmann

 

[Guest]

Archived from groups: alt.games.vgaplanets4 (More info?)

> If a sim started with
> say 250 fighters versus 300, it would always end with eg 119 vs 83.
The
> code must be highly deterministic (no randomness), but most options
> (even adding HG) made no difference to the outcome.

I think this is strictly a Diplomat feature. Fightercombats in Diplomat
will always give the same result - scripting or real games will get
various results. Don't ask me why, you're the pro .

 

[nameless]

Archived from groups: alt.games.vgaplanets4 (More info?)

KlingonKommand wrote:
> I was testing simulations of pure fighter wings versus other wings in

> one-on-one duels, and I was struck by how the only combat option
which
> made any difference was "Close to point blank". If a sim started with

> say 250 fighters versus 300, it would always end with eg 119 vs 83.
The
> code must be highly deterministic (no randomness), but most options
> (even adding HG) made no difference to the outcome.
> --
> Paul Honigmann

Part of the problem is probably that in the diplomat, even with calling
the vcr routine, the numbers are not randomized (no call of the
function randomize anywhere in the code) - that problem does not arise
when the normal host is called, since anywhere at the beginning of the
code execution the function randomize is called, but it is not called
anywhere within the vcr code...
Of course that is just a guess, since I do not have the code to check.

 

[Guest]

Archived from groups: alt.games.vgaplanets4 (More info?)

It's standard practices dealing with RNGs to:

1. Minimize the complete reseeding of it. (Because the reseed itself is
highly determinstic, it's based on the remainder you get when you
divide the time of day in milliseconds by a number that's a power of
two.)

2. In inital development and when debugging, artificatlly seed it to
some constant, so that the code will execute identicaly for a few
times. Remembering to replace the arificital seed with the standard
call to get a "random" seed based on time of day as above.

Because of this, it is not surprizing that fast host mode skips seeding
the RNG entirely, and apprently in the language and set of utilites Tim
is using, has the same effect of the seed being "0".

Now all Tim needs to do is find the appoartive place in code for fast
mode to seed the RNG where it wouldn't reset it under normal host mode.

 

[Guest]

Archived from groups: alt.games.vgaplanets4 (More info?)

In America, the standard achronynum is RNG and not PRNG. For exactly
the reason you described. Since all random number generators are
puedso, the word is redundant, and the letter fell out of the
anchonyum.)

#1 close enough for a general audience. Applications programmer has no
control of the constants chosen anyway. All he states is he wants a
number between [0 .. 1) or else an int or long between [0 ..
MAX_DESIRED_VALUE - 1]

#2 Language dependent. Using random numbers in C-64 without a call to
randomize first would result in same order executeion.

#3. Visual Basic is what Tim used for the Client. He's using a
different form of basic for the host [one that actually works in a
Linux enviroment like Drew's site unlike VB]. The fast host mode was an
afterthought, only added after Diplomat came out and people wanted the
sim to come out faster.