Recently, I have been in this Role Playing Hype. I remember playing dungeons and dragons with some friends a couple of years back, and remembered that dice were used to determine nearly everything. So I want to ask if dice roles would be good on starcraft? There could be a turn based battle. Attacker roles dice to determine atk. Well they do take out the concept of micro, but dice roles can be used for other ideas. Possibly an add-on to Role Playing maps. Feed Back Please.

By roll dice to decide attacks and such do you mean like in the classic RISK board game where defender and attack rolls dice depending on how many units they have on the battlefield kind of dice roll? If so I think that would be pretty cool depending on what kind of game/battle it is.

You dont HAVE to take out micro, You could give them certain units or conditions to fight with according to what they roll.

I believe this concept could be beneficial to successfully making board-game maps aswell. NOW LETS COME UP WITH THE BEST WAY TO DO THIS!

You guys are serious? All you do is randomize switches.

Sides | Switches
4 | 2
6 | 3 - 2 sides reroll
8 | 3
10 | 4 - 6 sides reroll
12 | 4 - 4 sides reroll
20 | 5 - 12 sides reroll
100 | 7 - 28 sides reroll

You could also only use 1 switch and use death triggers to add up 1 or 0 for the dice roll. Which could allow for more accurate results, merely have the switch loop randomization for as many sides as you want minus 1 (if you want a 6 sided, loop it 5 times). I'm currently high on hydrocodone after getting my wisdom teeth pulled out and figured that one out in 10 seconds. C'mon guys -_-.

Post has been edited 1 time(s), last time on Jan 7 2009, 9:23 pm by PridefulOne.

And yes, these are the only two ways to do it, unless you wanted to do something random and slow such as putting units on guard dog and having a timer countdown and then counting how many of them are on one side of the pool. Otherwise, these are the most efficient.

Post has been edited 1 time(s), last time on Jan 8 2009, 1:07 am by Mini Moose 2707. Reason: Flaming

Somewhat offtopic, but I have a set of D&D sourcebooks, so if you forget something, I can look it up for you. I'd also love to help with the D&D map.

(Assuming you are, in fact, doing a D&D map, which you seem to have implied your doing. If not, ask someone to delete this.)

This will work wrong because each roll of the dice have equal probablitiy to occure, but in your method numbers near to n/2 (where n is the number of sides) have more probablity to occur than numbers which are closer to 0 and n.

This is most obvoius but not the best solution for numbers which are not powers of two. For example 6. We cant make randomization with equal probablities for each of 6 sides without rerandomization (reroll), but we can decrease the probablitiy of rerandomization significantly making this event practically almost impossible and decreasing the mean time of randomization to one trigger cycle. For six, the idea is to randomize number r between 0 and 2^³¹-1 (overall 2^³¹ outcomes). 2^³¹ modulo 6 equals 2. This means that we will have the probability of rerandomization 2/(2^³¹)=1/2^³⁰. This is the least rerandomization probability we could achive using one death counter (DC). The problem of finding the least rerandomization probability for other values is not trivial and is of interest by itself. Let me designate q = 2^³¹ div 6. The resulting dice roll equals to r div q + 1.

The implementation of the method may vary. Let me give you one possible solution:

EDIT: Look an addition below in this topic.

Post has been edited 3 time(s), last time on Jan 9 2009, 5:39 pm by Wormer. Reason: linked an addition to the post

That actually might be useful in a D&D map. Rolling stats is a good example.

Also, what language is that in your quote? It doesn't look like valid trigger syntax.

Well, this could work, but one should understand that outcomes have different probabilities. And in general case of rolling dices this is not right.

Have you got problems understanding it? Everything should be obvious

EDIT:
Actually problems might be only with understanding FOR. The FOR-END block implies that you should subsequently copy it's body for each i from 30 downto 0 (decreasing i by one on each step) or for each s from 1 to 6 (increasing s by one on each step) depending what FOR are you looking.

EDIT2:
Also, different identifiers like sRollTheDice, sRandom, dcRandomNumber, dcRollOutcome, pGameMaster refer to different objects. Prefix of an identifier (s, dc, p) tells you the nature of the object: s is a switch, dc stands for death counter or in other words just a unit used in a role of DC, p is a player.

Post has been edited 4 time(s), last time on Jan 9 2009, 4:47 pm by Wormer.

I understand what you are saying... I've done programming before. I'm just afraid that other people wouldn't understand. (Also, it looked like it might have been a code for a trigger generator, and it would be useful if you knew of/had such a generator.)

Of course it is a code. Try looking recent topics in UMS Theory and Ideas and you will find out. If you're interested we could continue discussion about it there...

EDIT: I think all people out there know programming basics and feel comfortable with basic FOR-Loops.

EDIT2:
lol my bad, I should have figured that out by your signature

Post has been edited 4 time(s), last time on Jan 9 2009, 5:01 pm by Wormer.

An addition to the method I've posted above.

If one does not want to have rerandomization at all in cost of some dice roll inequality he may do the next thing. Lets designate the following code from my post as mTryRollTheDice():

We can subsequently copy this code few times to make the rerandomization event even more improbable and then just add this last outcome to one of the roll dices (for example for the first one):
This of course will make the dice sides a little not equal but this inequality will not be relevant in most applications. I might calculate later how many tests one should carry out to notice this effect, but that should be really large number.

EDIT: this will take up overall 226 triggers

EDIT2: The estimation of how nocieable the effect might be on practice could be found below.

Post has been edited 7 time(s), last time on Jan 10 2009, 11:07 am by Wormer. Reason: added link to prob estimation

Alternatively you could have lurkers burrow and unburrow randomly using switches for a few seconds to add to suspense and make it look cool. I mean for a six sided die. Sorry I didn't explain that very well at ALL i mean it would actually look like a six sided die, with the unburrowed lurkers being the dots on the die.

Yeah i know what your saying, madroc. What you could do is randomly go through 1-6 unburrowed lurkers really fast and the player moves to a beacon to stop it from changing.

I've estimated the size of the probalbility value from the above.

As we know the probability of rerandomization using one copy of mTryRollTheDice() is 2^^-30. If we're using 3 copies of these triggers then we have probability 2^^-3*30=2^^-90~10^^-27. How real might be this probability on practice? Let me give you comparative example from life. The emperical probability with which an airplane crashes is 10^^-7. Our probability is 20 degrees lesser! This is a *great* difference. Of course everything depends on number of experiments held. For airplains there are hundreeds of experiments (flights) are held each day. I dont know how many SC games are held in the world each day, but that might be little bigger value (not much though, I assume it might be no more than 2 degrees bigger ~10^⁵). I know that to make the effect as noticeable (with the reliable confidence interval) as the airplans crashing is noticeable today (which everyone of you can feel on your own) we need about 2 degrees more experiments that the 1/probability. For our example that gives us 10^²⁹ games! To make you feel such a big number I can tell that the Big Bang took place 2*10^¹¹ years ago.

The conclusion is the following. Though the method gives you events with slightly different probability in theory this will not be ever noticeable on practice, which means that on practice the probabilities could be considered equal. Also, after I calculated these values and compared I realized that 3 copies of triggers is an overdo. You can use only one copy with 10^^-9 with a rerandomization which never happens on practice. That should be sufficient.

Post has been edited 1 time(s), last time on Jan 10 2009, 11:11 am by Wormer.

... I still don't see exactly what you're talking about for my system being faulty O.o.

The only reason that problem exists when using multiple real dice is because the number 1-6 are on them (greater amount of possibilities for 7 to occur (the middle)), these are a 50/50 chance so it's exactly equal for any outcome to come out.

Please, say clearer what are you implying =) I couldn't get it.

The method you've posted with rerandomization will work fine, The only thing I was trying to improove is to minimize the rerandomization probability as much as possible.

The method with using a switch and then randomizeing it 6 times in a row, adding one for each outcome where it was set to imitate the 6-sided dice wont work exactly like using 6-sided dice itself, because probabilities of having 3 and 4 would be greater than having other values. The latter probably what are you talking about in the post, but in particular case of two 6-sided dices... if I understand you right.

After rolling, you could randomize a switch, and toggle all the dice switches if it is Set. That would make the chances exactly equal.

Look, there are two basically perfect methods.

1. use switches but you must have total outcomes be a power of 2 (unless you don't mind the chance of waiting a long time for when it hits a "wrong" number and tries again). Computer randomization is what it is and you trust it. I don't know the method blizzard uses but if it has anything to do with using the internal clock as a seed, then i'm sure it's as good as it can get (i don't know enough about standards =P).

2. cycle a DC from 1-6 (if a die, for instance) every trigger cycle, once per cycle, and determine when to stop by the randomness of the player stopping it ("rolling the die"). You also need to make sure that before hand you have a bit of randomized timer to prep the DC... so that if a player rushed for it, it wouldn't be the same thing every time. Yes, because of the nature of using the 1st method as a timer, this would make it more likely to start on a certain number, but unless you have a player with not only clairvoyant and superhuman timing but also the ability to recognize the higher likeliness of him getting certain numbers when he hits it at exactly the same time each roll time... Yeah it won't happen. Humans are the random factor here, and the randomness gets lower with a higher amount of sides on the die.

I say that because they can then begin to at least estimate a low number timing, even if not a particular number, unless you do that randomization before each roll, either via switch randomization, or by having non-timed intervals between rolls (like if a roll per battle, if the battle was over when only 1 is left standing with micro, then it's indeterminable). You can also prevent the predicting a low or high number by incrementing by a number the doesn't not divide evenly into the max number. But keep in mind 5 goes into 6 in such a way it's basically just subtracting 1. So this is easier for larger numbers and odd numbers. (Just round down or up from the halfway... like 2 or 3 into 5. It'll basically just switch between a low/high and a medium, which is nice.) I recommend against changing the sign of the number you increment by, as it will probably have the effect of making it hang around the current number, unless that's an effect you'd like. /ramble

So in the end, the best randomizer for higher numbers is a combination of switch randomizing, incrementing by an indivisible number about halfway down maybe, and indeterminable (to 1/12's of a second with hyper trigs) lengths of time (as in, human controlled).