Train of Thought

What if we had a tool that was relatively easy to use, lightweight, and powerful that could give us all the information we need to make our maps more efficient and less cluttered?

I was considering the principle of minimum chance conditioning (hereafter MCC), which is essentially ordering the conditions in your trigger so that the one(s) least likely to be true is(are) checked first, thus preventing the trigger from checking the list further than it has to. This saves computing time and therefore reduces lag, especially in maps with thousands of triggers.

MCC is all well and good, but how does one determine which condition is least likely to be true? And how do you order them in order of least to most likely with complete accuracy? Based on intuition, it's not likely that a human would be able to arrive at the right order to fit each particular trigger. But if you had more information... What then?

Idea

Invent a trigger system to check the probability that any given condition is true. It's a lot simpler than I first thought, I'll admit, although its simplicity depends on circumstances. Also, changes in the map to trigger code would in some cases require a recheck, to ensure that the probabilities haven't been messed up. The ideal scenario would be to save one or two deathcounts for diagnostics once your map was finished, run the probability check(s), then reorder conditions according to the results.

Essentially, such a check could be more or less complex based on what you wanted for results. For some trigger systems, a simple trigger that adds one to a diagnostic death count whenever the condition you want to check is true will suffice. For other systems, you may want a more complex system that checks probabilities while some combinations of conditions are true, or at specific points in the game.

It's also possible that this is all useless bullshit given that the majority of maps will never need MCC. But I liked the idea of a system like that - maybe even one that could be imported into maps straight from a text file found on these forums, or something (SCMD ). Anywho, anyone got thoughts on this?

I tried doing that as often as I could remember, but I don't recall my data about how well it worked. Since I do know that most of the condition lag comes from certain types of conditions, another optimization is to "cache" the results of a given expensive condition (such as setting a switch when a 'brings' condition passes, then replacing all subsequent instances of that condition with a check for that switch). You have to be able to rely on being able to use this for large numbers of conditions, though (and you'll definitely want to take care when using it).

Worrying about any of this is already in the realm of over-optimization, of course.

Post has been edited 1 time(s), last time on Nov 27 2011, 6:54 am by Tuxedo-Templar.

I recently started organizing my triggers kind of the way tux was talkin bout. Each system starts with a trigger that checks for shared conditions within that system, if the conditions are true it sets a switch. All of the triggers under the system have the switch condition at the top of the condition list. So the map is pretty much only checking laggy conditions in the trigger at the beginning of a system, all others are just a switch, which is probably the least laggy condition to check. Another great thing about this is that if you want to change a condition you only have to edit the system's initial trigger, instead of having to edit every single trigger in the system.

I don't know how many people do this, but whatever. It's worked really well so far for my map.

What you're asking for, an algorithm to determine MCC flawlessly, unfortunately doesn't exist.

Imagine a scenario where for 1 minute of gameplay out of an average 50 minute game, a DC was set to a certain value. Imagine that for 35 minutes out of the average 50 minute game (some of which may overlap with the first 1 minute DC), some other DC was set to a different value. Which DC should you list first?

If you want the trigger to only fire during the first 1 minute, then obviously you put the 1 minute DC first. But if you want the trigger to fire every time except for the 1st minute, then putting that DC first will be redundant because 49 minutes out of 50 it will be true and so checking it first may be a wasted operation, so you'd have been better off putting he 35 minute DC before that. Now it would be possible to computationally solve this by creating a model of all the other triggers and how they interact with each other - under what conditions they set each DC and to what value. Ok, so that's fine.

But then you are presented with triggers where the expected execution time as a proportion of total game time is a lot more difficult to discern, or in fact impossible because it depends on player actions: the player may equally choose to go down one path or the other, and if you optimize for path A you'll harm path B processing, and vice versa.

Essentially it means that there exist maps where no one, including a human, is going to be able to always optimize the triggers for best-possible execution, but a human will be able to take their knowledge of the map and the players to say "well actually 80% of the time this trigger path will be followed before that trigger path, so I can optimize my triggers to cope with that and just accept that 20% of the time they will lead to redundant processing overhead". In essence, optimizing trigger conditions requires creativity, something that computers aren't really capable of.

Now, it might be possible to take triggers and create a mark-up language so that a human can input this sort of above information alongside their triggers so that a tool can read it and optimize the triggers themselves. But this isn't really practical because any human that was sufficiently motivated to enter mark up could just optimize the triggers themselves, probably in less time than the markup (and if the human doesn't know what they're doing, then the mark up is likely to be wrong anyway).

Nice idea, but any tool is likely to be quite crude and give sub-optimum results in many maps.

True optimization is a pipedream, but a program that helps the user approach MCC is highly plausable (this is, of course, assuming you could roughly rank condition weight with respect to circumstances (ex: location size))


Assuming we have the equations (which i gather, the program would depend on), we could have the program do some basic calculus and arrive at the optimal (for our given info) result immediately



Cumulative real-game stats would give the expected times players do x and expected time players do y per game; this of course may change as stratagies change over time, but you could develop a high effeciency system for your map at the time its efficency is updated



Assuming the mapmaker did an acceptable number of real-game trials, the map knoledge and creativity wouldn't be wholly required as increasing numbers of trials cause the experimental results to approach acctual probabilities of the condition checks occuring, thus giving sufficient information to the program to figure the high-efficiency organization.



Scores are ranked least to greatest and their respective triggers put in that order.