On the long drive home today, I got to thinking about randomization, as it has always interested me, and helped my car induced narcolepsy. Well, I stumbled across a realization for (more accurate) randomization of non binary numbers(2^x), like, a deck of cards.

So, there are 52 cards from which to pick, right? The lowest binary number we could get is 64. That's 12/64 cards that we DON'T want to be picked ever. Well, what if we double it? 104 and 128. Now we have 24/128. Same ratio, but if we double it a few more times, 416 and 512, we suddenly have 96/512, and 52 will subtract out of that 96, giving us 44/512, a much better ratio. Unfortunately, this never becomes zero, but at 2^14, it's 13312 and 16384, with a ratio of 4/16384. That means all the cards also have a range of 315 in the death counter, and 4 are "re-dos"

So 1/4096 is much better than, say, 3/16 chance of getting a redo, but I wonder if this might be improved more. I'll have to think on it some more.

Another problem with this is that it doesn't help solve the permutation problem inherent in a deck of cards. At first it's 52 cards, but then you only have 51, and 50, and so forth. Triggering such an event would require 52 sets of randomization triggers. In single situations, and with smaller numbers, this could be quite useful to make an equiprobable event occur more frequently.

And this would be simple to make with the Single Switch Randomization method, rather than using a crapload of switches.

What's wrong with re-do's? It's the same probability still...

The larger you make your population while your sample size remains proportionally unchanged, the smaller the delta between these two values will be proportionally to the population.


but as for all this talk about randomization... if i want to do a randomization of a non 2^x or in other words binary number of independent events, say 52 in your case, i pretty much ignore the 12 "unwanted" switch combinations when triggering, so meaning those 12 switches, when detected, will result in a redo. With hyper triggers and a generally smaller difference between the sample size and the closest 2^x value rounded up, the time it takes or number of "redo" loops needed to meet a satisfied condition should be kept to a minimum.

However if this randomization is a single occurrence situation such that "redos" are unacceptable, then to help minimize the chance of a "redo," set triggers for each of the 12 "redo" switch combinations so that they will randomize the switches (6 in this case) again. But you have to make sure that these 12 triggers come first before the 52 other "successful" events, otherwise it negates the fact the fact that you are trying to reduce the possibility of having to have to loop through your triggers again. If you do this twice for each of the 12 "redo" switch combos, it'll make your probability even smaller and so on. Eventually, if you do it enough times, it'll reach a probability so small that according to statistics we can declare that it's pretty much 0.

Speed. It's the same reason Kills to Cash perfect sucks. I imagine it would take a decent amount of time to get a 1/64 chance of pulling a card, even with hypers. Why should we settle for doing something in 5 seconds when we could do it in half a second, without compromising accuracy?

There should almost always be a way to have your randomization "prepared ahead of time." Like if at the end of a certain time or at a certain instant of time you want the randomization to occur. I actually used this in quite a few of my maps, particularly my minigame map.

In my map, I made it so that once a built-in timer in my map reaches a certain instant, it will pick a random mini-game (and it'll randomize only the ones that have not been played yet, thus making the population non binary.) I do the randomization like at the very beginning of this timer (at least 7 seconds ahead of the time I want the randomization to be detected). But if by mere chance that after 7 seconds my triggers still haven't detected a compatible switch combination, my built-in timer will pause but continue to let the map continue randomizing the switchs. Now unless the probability you are looking is like 1/1000, i highly doubt it'll take that long. 1/64 only takes like about 5-6 seconds at most.

Or, for many other cases, I have this randomization done during player interaction phases of the map. What I mean by that is like moments during the map which are not the funtion of time but rather the function of a player's success or actions. And once this phase is supposedly over but your randomization hasn't been established yet, you can still "pause" the map.


IMO, just about every scenario for any map can avoid "speed' issues if done correctly. The only exceptions to this are possibly killscores, etc which rely on trigger order. Even if the speed becomes so great of an issue where even having it prepared ahead of time will still cause delays, then you can use methods rockz or I have mentioned to eliminate pretty much all the delay time

What about using an extremely large value, and randomly giving some cards a negligibly higher chance of getting drawn?

If you simply copy the trigger 10 x, then the time is cut into 1/10 of the original. Now wasn't that simpler?

You would just put the ones not being used (so with 52 it would be the unused 12) and put them at the beginning of your randomization triggers so that if those aren't the right ones it will re-randomize in the same trigger cycle. Would take 2-3 cycles at most. You could simply do what madroc suggested to finish any that rolled two unused combinations and it would be done in 1 cycle.

My friend made a nice randomization algorithm (not SC) that goes through all the indeces and swaps them with a random entry. 52 cycles with HTs isn't that complicated.