Raghar:
Yeah, I was assuming that we''d all see % and think percent. I mean, it only stands to reason that the symbol for percent is acceptable to use when it means percent.

Anyways, never mind that. About Dice chugging, okay, 10.5, not 10. But, it is a tendancy because of the addition of the die faces. Assuming none of the dice are weighted, you have 3 even chances of rolling between 1 and 6. Because you add them, this makes only 1 combination in... 216?... only 1 combination would yield the value 3.

On the subject of linear pseudorandom number generators, they can scale just fine given appropriate math. If rand() returns a value between 0 and 4294967295, it would scale perfectly if you cast it to a double-precision floating point and divide it by 4294967295. The result is a random number between 0.0 and 1.0. Multiply that by whatever you want and cast it back to an integer, and rand() scaled without a change in even distribution. What you''re thinking of, the loss of scale and distribution, is when you use modular mathmatics, which is that damn % sign again, isn''t it.

Now, as to produce an artificially weigted system, theres always just rolling rand() 3 times and scaling it like I''ve said each time, but then theres also the array method I''ve stated with the values in there in multiples. Theres probably other good ways as well, but thats besides the point. What is the point is that the chances of rolling any given number on a set of dice added up is on a logarythmic scale, not a linear scale. Most people think in terms on linear, so its totally up to the designer to determine what he wants. A chance in hundred is most easily represented with linear even distribution. A logarythmic chance placed around a central trend is hard to think of until you give that central trend a number. 1d3, 10. (10.5) Of course, once you toss the concept of 6 sided dice, you could easily change the central number and reweight the system to your liking.

quote:

---

On the subject of linear pseudorandom number generators, they can scale just fine given appropriate math. If rand() returns a value between 0 and 4294967295, it would scale perfectly if you cast it to a double-precision floating point and divide it by 4294967295. The result is a random number between 0.0 and 1.0. Multiply that by whatever you want and cast it back to an integer, and rand() scaled without a change in even distribution. What you''re thinking of, the loss of scale and distribution, is when you use modular mathmatics, which is that damn % sign again, isn''t it.

---

Not true. Casting to int truncates, not rounds, to the whole number. So the only time you would get the top number is when you got an exact 1.0, any fraction less than 1.0 would put it at the next lower number. That also means that there would most likely be more zeros than any other number.

To get nit picky.....
- You also have the problem that rand() does not have equal chance of returning any specific number from 0 to 4294967295. Do a search on cryptography and pseudorandom number generators if you want specifics.
- Some numbers just can''t be represented accurately on a computer. I.e. 1/3 would actually be an infinite repeating .33333333...., PI, etc.

Kars...

At first I was going to address each issue you raised and discuss how to overcome them... but we're programmers! At least whoever is trying to code this system is. And a truncation rather than rounding error isn't really that hard to deal with.

As for the rand function not returning every single number equally, unless it is extremely skewed I don't think it will make a difference. I doubt the player will notice if 36502 occurs twice as many times as 36501.

---------------------------------------------------
There are two things he who seeks wisdom must understand...
Love... and Wudan!

[edited by - thelurch on January 15, 2004 2:38:31 PM]

I was only trying to point out some pit falls.

I tried using rand() in one program and the results were skewed enough that people did noticed. I have also successfully used rand() in other programs where it worked fine.

On the issue of truncation, its actually easy to deal with that, you round the number off before casting it to int, and thats easily done by just adding 0.5 to the number and then chopping off the decimal. (5.499 + 0.5 = 5.999, floor(5.999)=5.0 )

(int)((((double)(rand())/RAND_MAX)*high)+0.5)

As for rand, I was actually discussing that today with some people. The easiest answer is to not use rand(). The implementation of it on windows based systems is actually quite horrid. Heres two links to place with better rand functions, as well as some other stuff:
http://remus.rutgers.edu/~rhoads/Code/code.html
http://www.math.keio.ac.jp/matumoto/emt.html

Or if you run off of a linux based system, read in a number from /dev/random

I would love to see a game that didn''t necessarily use the Cyberpunk 2020 system (interlock was it?), but took place in the same type of world. Cyberpunk 2020 is my favourite P&P RPG, but unfortunately I don''t know anyone else interested in it.

---------------------
Ryan Bujnowicz
[ vangelis ]

Hi Vangelis,

Yeah, I''m a big fan of cyberpunk as well. Here''s my plan to bring that vision to life

I''ve got a very basic graphics engine that is based on Jim Adam''s Prgramming Roleplaying Games with DirectX.

My current step is to develop the "game" engine that handles all the characters actions such as moving and shooting. I''ve got the basic tactics done but there is a lot of polishing left. I''m hoping that this can be used in both modern and old world settings.

I''m going to then go back and polish the graphics and then work on easy to use tools that people can use to build a campaign.

I want to see cyberpunk come to life!

---
Today, is a good day to code.

Modulo isn''t written as %. It is written as
7 + 5 = 3 (mod 9)

"I don''t quite understand those three sentences."

1/6 is better. It''s more readable, and shows more information. compare 1/36, 2/36 with 2.7% 5.5%. First number shows it''s done in one case from 36, second shows that probability is twice as much. When you are designing system that depends on random generator, you frequently need to have a possibility to know precise numbers. That two other numbers didn''t correlated as nice.

Instant Kill system. The system where you would be hit hard by pure random shoot.
Reasonable system. The system that suits the Game needs better. For example an extensionable system, or system that is fast. In that sentence it ment something like not as accidental as the instant kill system.

We should have some kind of a game dictionary. These terms were used pretty long time ago.

As a sidenote SR system is dependant on a roll of multiple dices. DON''T use C rand() for this. You''d end with really screwed up results.
You might like to use that link on Mersene twister. Or you might look at documentation at java.util.Random for slightly faster, but less effective random generator. (Actually it''s twice as fast, but it''s just a linear c generator.)

It could be useless to check bouding box with intended target, you already know if it was hit or not. You just need to compute and show? trajectory of bulet. Around right side of head of first alien, left side of second, ricoshet from the wall, third alien lowered it''s head just in time, and looks anoyed, ricoshed from another wall with direction back to soldiers. With comment of second soldier "Drop that boomerang NOW.". And strange missed shoot in direction of first soldier.
It depends on what level of AI you would like to attempt.
Just be carefull with Kenedy like miracle bulets. ~_^