I don't know if this has been done before but it's probably been thought of before. I just felt like sharing this with everyone else here at SEN.
Usually when randomizing something, you will need a certain number of switches, and then a trigger for every single possibility. Now to change the pecentages, you would need to make an entirely new set of triggers for the new percentages. Now this is quite inefficient if you think about it.
So if you wanted 25%, you would randomize 4 switches and have a trigger only acting upon 1 possibility. Now if you wanted to change that to a 75%, you would need to randomize 4 switches, then have a trigger acting upon 3 possibilities.
Instead of having it do that, I assigned a number for every possibility for the switches. Then I made another death counter be the "percentage control" which would control how much % would have an action occur. Now we can easily change the percentage of action by just changing a death counter.
I used this in combination with
ABS (Accuracy Bullet System) and I got rewarding results. Now many degrees of accuracy without so many triggers. And if you wanted, you could make it randomize accuracy for every single unit you wanted to shoot.
In the example map, I only randomize for the entire large location. I made a Marine so you could test the possibility changes. Of course a direct hit will always kill the Marine
Enjoy!
Trigger |
Conditions: |
¤ Player X suffers at least 1 death of unit
|
¤ Switch A is set
|
¤ Switch B is set |
Actions: |
¤ 25% |
Trigger |
Conditions: |
¤ Player X suffers at least 2 death of unit
|
¤ Switch A is set
|
¤ Switch B is clear |
Actions: |
¤ 50% |
Trigger |
Conditions: |
¤ Player X suffers at least 3 death of unit
|
¤ Switch A is clear
|
¤ Switch B is set |
Actions: |
¤ 75% |
What about something like this?
Then when you randomize it . . .
Trigger |
Conditions: |
¤ Whatever |
Actions: |
¤ Display Text "You have a 50% chance"
|
¤ Set deaths of unit to 2
|
¤ Randomize Switch A
|
¤ Randomize Switch B |
Sorry i didn't look at your triggersSame effect but more efficient on making the triggers, I like how you have modified my ABS.
Only one suggestion, I'd be better if the Marine was moving so that the ABS would be used to it's full potential, but thats just for gameplay issues.
My suggestion for implementing this into Tank Command would be to make the Big Location bigger and use it with a Disruption Web so that it won't interfere with any ground units.
Bolt:
Don't you mean "at most" in your triggers?
That could work the same way but I did it a more different way
BeeR:
You know I could've made huge factors into the accuracy and such but this is just a concept map
Good idea about TC. Now we just need to tear down the current system
QUOTE
Good idea about TC. Now we just need to tear down the current system
If it'll make TC a better map then let's do it.
QUOTE(LegacyWeapon @ Jun 20 2005, 03:02 PM)
Bolt:
Don't you mean "at most" in your triggers?
That could work the same way but I did it a more different way
[right][snapback]239511[/snapback][/right]
No i ment at least. If you had only 1 death then only one of the triggers could fire making it a 25%.
Although it would work the same using at most except your numbers would be reversed.
with at least, 1 death would satisify only 1 of them for 25%
with at most, 1 death would satisify all of them for 75%
You're right, I was thinking about it differently.
I just thought of a new way to do randomization with Very Fine Granularity and One Switch. Doubling granularity requires only 1 additional trigger.
High level overview:
Maintain 2 death counters - one for the current bit and one for the result. Iterate from bit = 0 to n-1 (where n is the number of bits you want). On each bit, randomize a switch (use the same switch each time). When the switch is set for a given bit, add 2^bit to the result counter. When you are done, you will have a random number with uniform distribution from 0 to 2^n.
Example:
Suppose you want 1/64th (1.5%) granularity on your probabilities. You need n=6 bits to do this because 2^6 = 64. You will need 7 or so triggers to do the randomization. Suppose you want an event to happen with 37/64 probability: all you need to do is set a condition if the result counter is less than 37.
Implementation:
For i = 0 to n-1:
{
Trigger |
Conditions: |
¤ Deaths of 'Current Bit' is exactly i
|
¤ Switch 'Random Bit' is set |
Actions: |
¤ Add 2^i deaths of 'result'
|
¤ Preserve Trigger |
}
Trigger |
Conditions: |
¤ Deaths of 'Current Bit' is at most n-1 |
Actions: |
¤ Randomize 'Random Bit'
|
¤ Add 1 deaths of 'Current Bit'
|
¤ Preserve Trigger |
To begin the randomization, set deaths of 'Current Bit' to 0. When it equals n, the randomization is complete.
Holy crap this is absolutely awesome
Good job Heimdal.
I think i get what your saying heimdal but your programing lingo confuses me.
Heimdal is doing two cool things:
- He is reusing the one switch for doing all the randomisation, generating a random binary string of 0's and 1's.
- He converts these random 'bits' into a number in a death counter through a 'binary countoff' type system after each randomisation of that switch.
The death counter will then read a random number which will have a maximum value dependent on the the number of repetitions used. The probability of getting any number is the same as that of getting any other number (up to the maximum value, of course).
An excellent idea, I say.
*claps*
lolz... 1's and 0's.
im going to say awsome in computer lingo.
0111111111111010100010101000101111111111111101001010010001010101011111011001001010000001111010101000000011010. (lol, not literally of course)
The only problem is you need to wait longer if you want the top to be big (like 128). And this definately needs hypers
Althought judging by the people who have posted here this is out of reach of typical mappers. (I understand it though, as does biskit, I'm not sure about illusion though) However for people doing heavy randomization for their shooter type maps (an better accuracy system for RUSH?) or attempting very true Chrono Trigger style RPGs this would be incredibly useful.
Oh, and can you belive i never looked at your ABS system up until now? I don't know why? I regret not looking at it earlier, it's really interesting.
This would be a great way of doing a true accuracy system without tons of triggers. You could have nested locations, the smallest one would use 100% and the biggest one could use 12%. That way, you have a chance of killing it if you hit really far away, but as you aim closer, the chance increases.
i understand what hes doing. im not stupid. im in advanced math!
I just didn't have anyway of verifying it becuase your post was a bit spammy.
Actually 90% of the people on SEN could get this easily if the tutorial was written right.
Also, legacy, do you think you could write a tutorial on how TT's
gunner system works?
QUOTE(LegacyWeapon @ Jun 24 2005, 10:05 AM)
The only problem is you need to wait longer if you want the top to be big (like 128). And this definately needs hypers
[right][snapback]243066[/snapback][/right]
I would just make copies of the triggers (like 7 copies for 128)
QUOTE(m.r.bob(MM) @ Jun 24 2005, 01:21 PM)
Also, legacy, do you think you could write a tutorial on how TT's
gunner system works?
[right][snapback]243169[/snapback][/right]
3 steps yet not many ever understands it:
1) Calculate the slope of the line created by the Defiler and the Dark Swarm.
2) Find the closest mobile grid design that will fit the line.
3) Use the mobile grid to fire until collision.
OK, I've put my randomization system to the test in this proof-of-concept map. I've used multiple triggers instead of running a loop, so it'll go a bit faster but you have some redundant triggers in there.
I rigged the map so that whenever the probability "hits," it increases your minerals by one. On every "trial," it increases your gas by one. Therefore, at any given time, your minerals / gas should be the probability that I programmed into it. In practice, however, the mineral count seems a bit high. Is it a problem with blizzard's randomization technique? Are the hyper triggers interfering? I dunno. In any case, if you use this, be aware that the actual result may be a bit higher than you expect. Increasing the number of bits in your random number should help make it more accurate.
This map generates a random number from 0 to 31 and fires the trigger when it is less than or equal to 22. This should correspond to a probability of 23 / 32, or 0.71875. The actual result was 2427 / 3200, or 0.7584375.
[attachmentid=10864]
If anyone has undestood what Haeimdal has said...he may have just revolutionized Randomization.. Thats just awsome.
I did some tests with that map and a modified version. For the most part the further you get away from the 50/50 value (switch is on or off and adds to count) the more the result will fluctuate. So with your example I noticed it went from 70 to 75. And with a 50/50 test it went from 49 to 51.
I also did some testing and found blizzard's randomisation to be pretty good: out of 500 randomisations, 245 came up with 'set' - a 49% probability, which is as close to 50% as you can expect.
To be more precise, I made a map to randomise a switch 50 times, and played it ten times. The number of 'set' results ranged from 18 to 31 out of 50, and the average was as said above, 24.5. The standard deviation was 4.3, which is fairly significant; it means that you probably shouldn't be very surprised if there is a large amount of fluctuation in your results, especially for the low number of randomisations that will occur in most maps.
If you want even results, you could 'weigh' the randomizations in two counters, and when one gets noticably higher than the other (like if its 'set' more often), use two randomizations and take the one that is cleared of the two (if any... a 75% chance) and keep randomizing like that until the statistics even out.
It would be a bit of extra work, but if you really needed a balanced randomizer, that could be one way to do it.
EDIT- Like this...
Arguably, that's not really much of a 'randomisation' any more, if you're rigging it such that it's more likely to be even... not that that mightn't be desirable though...
That's what he said he was doing.