We all (hopefully) know that we use Switches to do clean and clear Randomizations...

however, I've been using 1 switch with 2 outcomes... and, even tho I might just be paranoid, I keep finding the switch favoring the "set" option.

I remember this being discussed somewr, but I'm too lazy to find out.. Is it true that randomized switches prefer set/clear? ...

If it's doing ONLY the "Set" option and you have never even seen the "clear" option, then you may have a bug in the triggers.

If Not, then I beleive you are just paranoid, because I think switches are quite unbiased when it comes to their two options.

I don't really know how the SC randomization code works, but maybe if the switch is being randomized at exactly the same time every game, and if the code depends on the in-game clock, perhaps it might not be random. If the trigger is something like
Always
Randomize Switch 1

then it happens at the same time every game so, just a theory.

Just use deather counters, DC= bomb in every situation, Ok what you do is have 1 death counter cycle through 1-2 if you just want to random switches, so when it hits 3- tell the game to set back to 0. Now the deather counter is going back and forth between 1 and 2. Now when you want the random part to happen have it switch another deather counter to 1. So now if player so and so, has 1 + 1 dc then do this, 1+2 death counters then do that.

I agree with you Ashamed, I use hyper triggers and Death counters to randomize stuff in my map and it works perfect, I have no reason to change them.

1. copy your triggers into notepad++ (or other programs like that).
2. search for
# = the number of the switch you are using (if you didn't rename it).
3. check your triggers

I've noticed that some games are a bit biased towards some switches or their combinations, while other games are fine. In my The Thing map, you get one of 8 random messages when you step on a corpse. If you set your unit to patrol on and off the corpse, you notice that it tends to repeat the same message a lot, sometimes even up to 4 times.

I personally consider the randomization engine in SC to be total crap.
This is wrong. If it were true, the same player would be 'the thing' or 'the phantom' every time in such maps.

This gets into the topic of how computers (and computer programmers, for that matter) randomize things.
There are a couple of methods in which they do something like this: (These are not all of them, mind you)
-They take a very highly complicated formula (By complicated, I mean lots of different operatives are used) and use a small number of variables that are very prone to change with the game, so that the results of the formula are extremely exaggerated, even with the littlest changes to that variable. Vrael was thinking of this when he said the randomization may depend on an "in-game" clock. This would be similar to most of the "DCs" we have in our maps today. (Without the formula in most cases, anyways)n
-They also may take a series of variables that are very highly prone to change, and then use either a very complicated formula or a not complicated formula to change these results.

The variables in these randomization engines may account for the "Biased" feeling that people get towards switches. Since we often run similar courses of action while testing/playing our maps who run quite similar each game (especially in the early game), we often keep these variables quite constant (or close to constant) and then see more of a "constant" feel to our Switch randomizations.

How big is your sample size? You may think there's a bias but that's only because you're looking at a small sample. I think this is a pretty pointless topic questioning the randomness of switches especially when you don't have any evidence and it's just based on your hunch.

Obviously it was just a random test, and one outcome was more abundant than the other...

Anyways, I simply wanted to see if there is a mechanism in Starcraft that'd create a bias.
Pyro's answer is very enlightening... but also raises more questions than it answers... Though I don't really care, I'll just stick with what I have.

.. Oh, Devilesk... If you really want, I don't remember for sure, but if out of 10, about 7 was the switch being "set"...
So in that case, the probability of getting that is...

10C7 (0.5)^7 (0.5)^3 + 10C8 (0.5)^8 (0.5)^2 + 10C9 (0.5)^9 (0.5)^1 + 10C10 (0.5)^10 (0.5)^0
= 0.1719 > 0.05
therefore we would fail to reject the null hypothesis... which would've been that the switches favor being "set"

If you want, you can create a larger experiment to test the bias with the Chi-square test.

Even if you do attain a reasonably large sample (over 30, which is considered the 'minimum' for most industrial problems by most analysts), it is still you who has to pick the critical value. Thus it is again based on what you think if a 'good randomization'. Say we make 1000 randomizations and get 570/430. Some may say that's a fair switch/coin, while others will disagree.

Just stick to your personal opinion about switches and that's it. If you hate them so much that you don't even want to use them, you can use JYD or unit death updating (50/50 with hypers). If the trigger cycles in which you will need the random number are random themselves in a way, go ahead and use a looped deathcounter.

i personally have ran 8 switches 80k times each. 8k times at a crack to see there variance. although i wasn't specifically looking for preference to set vs clear every time a different color won out and the color was not more than 100 ahead of the others. i would say this is fairly random. the % diffence between all tests was 2.3% i believe.

You're coming here after only doing 10 trials? Lol.


Of course there will be interpretation that we will have to debate, but I was just asking the question to see what we were currently working with. And as seen by Unholy's post we are dealing with his laughable 10 runs.

After considering this information, combined with this:

...I am tempted to think that some bias in randomization follows a sinusoid through time (note: not game time). Although there is no statistical method to prove that short-term randomization is biased, because it's hard to get a large-enough sample. Although my experience says there is something fishy about it: testing the zombie spawns in CotD seems to support this idea.

yes that could be tru jaff. i certainly wouldn't argue against it from what i have seen. I too have played the thing maps and have seen time after time someone constantly being selected.

as for ashamed's method i think it seems flawed but maybe i'm misunderstanding cycling through.

if your going to truely randomize the cycle should not happen. It should be something like 1,1,2,1,2,1,2,2,2,1,1,2,1,2,1,2
if your cycling n + 1 and if n=3 then n=0 well then you are forcing it to go back and forth between 2 and 1 therefore you can never have two or more ones in a row or two or more twos in a row.

Nothing can ever be perfectly randomized.

UU, you're being paranoid. If you're that worried about it, randomize more than one switch.

But its not suppose to be random, Its just supose to be a system and what ever is showed in DC when you do the trigger that is what reacts. There is the same amount of 1 and 2 DC's because the second it gets to 3 it starts over back at 1. So then it goes 1 and 2. Then starts over again. This lets it be almost always on 1 and 2. Then it will change the output when the trigger is activated.

Post has been edited 1 time(s), last time on Aug 5 2009, 8:24 pm by Ashamed.

If you need the random variable at the same trigger loops, this method stops working. Picking the thing or the phantom in the first trigger loop with this method will always result in 0 or 1, depending on how you set it up.

Its always worked for me, i have random battles set up on my game 1-4, and it looks like it really is random, but its a bit differnt the way i use it.

Such a system is only 'random' because the players and in-game events bring randomness into it. If the battle begins when, say, all the players bring their heroes to a town, it can be considered 'random', because the players don't know what trigger loop did the trigger fire in.