I don't understand why this is at all a difficult concept that requires so much discussion, it's simple death counters.

Always
- Add 1 to deaths of Terran Barracks.
- Preserve trigger.

Current player has suffered x deaths of Terran Barracks (x being the number of sides on the die wanted)
- Set deaths of Terran Barracks to 1.
- Preserve trigger.

Current player brings exactly 1 Terran Civilian to Location "Roll the dice!"
- Move all Terran Civilian owned by current player to Location "Waiting to Roll."
- Set "Rolled."
- Preserve trigger.

Rolled is set.
Current player has suffered exactly 1 deaths of Terran Barracks.
- Do whatever for rolling a 1.
- Clear "Rolled."
- Preserve trigger.

Rolled is set.
Current player has suffered exactly 2 deaths of Terran Barracks.
- Do whatever for rolling a 2.
- Clear "Rolled."
- Preserve trigger.

etc, up until x sides for a die.

The randomization is easy, the hard part is comparing the dice values if you're having combative rolling as in Risk.

Post has been edited 1 time(s), last time on Jan 13 2009, 12:48 am by FaZ-.

That's basically what I was saying. I was just putting more detail into the subtleties.

I wouldn't think comparing would be to[o hard either, if you just subtract a defense die and attack die at the same time until one reaches 0. But that's if you actually want to put time into something like Risk =P.

Well, I've got a map that does something very similar to this (it has attack rolls, dodging rolls, damage rolls, and raw stats that influence them all, spells, abilities, a death counter system that limits your movement to a set speed regardless of unit, etc.) so if anyone wants to take a look at the systems I'd be happy to send out a few of them, though it is my next years contest entry in the works so I'd rather it not get awy from me, even if it is in super pre alpha format.

They key is to use death counters for absolutely everything, and to make them as modular as possible. You'd need to make extensive use of temporary death counters and subtraction, and for a dnd style map, multiplication and division by two, which is quite time consuming with triggers. What I did was go in to MSword with a generic, if death is n, then subtract x dc from y dc, and then copy paste the entire code for subtracting and resetting, to eventually return the difference as z while leaving x and y unchanged. Then I simply copy-pasted this over and over, and used another trigger to set the condition.

Also, for the record, these maps are quite possible, I'm running well over 12 thousand triggers per second without any glitches due to game issues.

JaBoK, that all is nice.

I dont understand how death counter system could limit your movement.

Actually multiplication and division by any constant could be easily done within one trigger loop. Problems arise with multiplieing and divideing DCs by DCs.

Consider looking at MacroTriggers development tool supporting duplication and other usefull things. That could be extremely usefull to you as you're extensively working with DCs.

I dont quite understand you. Do you run 12 thousand triggers per second or per trigger loop? Do you have hyper triggers? Are those triggers executed mostly for one computer player or DC computations are repeated for each player? I am asking because I have a map where I am using DCs for computations as well with about 15 thousand triggers, which are executed for each of 5 players and it lags like hell I am declined to put the lag down to big number of triggers (conditions) being checked each loop, but I may be wrong.

Well, Wormer, you're talking about using 226 triggers to simulate something that took me 9, so I can see where you may overcomplicate things.

Honestly for a dice rolling system where the user selects when the dice is rolled, a DC that cycles from 1 to 6 is more than enough for this application. I mean one can appreciate the switch system for its complexity, but there's no point in even bothering when it can be done much more simply. Less triggers means easier to implement and less possibility for error in the future.

There's no real merit for opting to use anything but a DC cycling for this particular scenario and I don't advocate using a more complex system just for the sake of using a complex system.

There are 226 with 3 copies, I've came to conclusion that one copy will be enough which is only 76. Frankly speaking number of triggers do not bother me at all.

I agree with you, for dice rolling that might be an overdo. But aren't we pushing maps to limits? I've just nocitced a good way to make randomizations with equiprobable outcomes almost without rerandomization in case of the number which is not an exact power of two and decided to share the concept with you, isnt it fun? That might be usefull in other applications.

Yeah it's good for when you need an immediate result in a periodic fashion which might see repeats with DC cycling. That's about it. Anything without a fixed time interval between rolls is good for DC. And yeah forget re-rolling with your concept... just make one or two outcomes or whatnot be duplicated, and make them evenly spread over the total possibilities, like if rolling 1-6 with 8 actual outcomes, make '2' and '5' the #7 and #8 kind of thing. I say just because the fact that it can all be done in one trigger cycle is basically all it has going for it, so don't bother with a concept that ruins that.

Haven't I heard you speak of this concept in one of the two major randomization threads I've read though? DC cycling goes to falkoner, btw, as a side note.

[typo, 3 and 4 are evenly spread, or 2 and 5.]

Dont remember, probably I was speaking about this somewhere earlier. With 8 outcomes 2 takes a significant part of 8, the idea was to increase number of outcomes to make the reminder neglecting.

See Spaceship combat.

Uhm... wormer, I was simply describing a method to use dice-based systems in maps

Anyways, if you make a random number between one and 8192, you can probably divide that in to enough sub-intervals to make multi-sided dice work. Your remainder for a d20 would be 12, which translates to 8 numbers having a 1/8192 disadvantage. I really don't see what the question is, we're never going to be able to randomize factors of 3 or 5, end of story.

No, there doesn't need to be any disadvantage. You have the remainder just rerandomize again. The concept Wormer described is that you randomize a number from such a large range that the proportion of rerandomize coming up is extremely small compared to all the other numbers that will correspond to actual outcomes.

For example for a 20 sided die if you took a random number from 1 to 32 you would have a remainder of 12. Those 12 would call for another number to be picked. However, because you're only selecting from a range of 32 numbers the probably that it will rerandomize at least once is high, 12/32. However, using 8192 the chance of rerandomizing would be 12/8192.

Yes, and my point was only a simple example. Obviously, I'm not saying to use 8 for 6 sides. That was simply the concept of what one should do with the remaining values for when you make the outcomes something huge like 8192. If you're dealing with numbers and not widely varying effects (like 1 = heal, 2 = kill enemy, etc) then having some evenly spread repeating numbers with only a tiny bit more chance of showing up would be perfectly acceptable, and still only happen within one trigger cycle, which is the only good thing about the large system.