At what point does a map begin to become "over-saturated" with constantly firing triggers, which can lead to high lag or latency for players?
This will depend on the CPU speed of the players, or more specifically the slowest CPU speed among the players.
When Starcraft goes through a trigger, once it hits a condition that it doesn't satisfy, does it continue to check the rest of the conditions in the trigger or does it simply skip and go to the next one?
Correct, trigger conditions are a logical and, which includes short-circuiting. (given a AND b, no need to look at b if a is false)
Best practice if you are worried about lag is order your conditions so the ones least likely to be met are at the top
This is not strictly true if the condition least likely to be true still takes a long time to evaluate. Mathematically speaking, optimal trigger condition ordering will minimize
average evaluation time, or expected value of evaluation time, which is the probability of the condition being false multiplied by the time it takes to evaluate the condition.
For example, if a Bring condition is 20% likely to be true but a Deaths condition is 90% likely to be true, you would still want the Deaths condition to be first if the Bring condition takes more than 8 times as long to evaluate versus the Deaths condition.
This is likely the case, since something like a Deaths condition is just doing some arithmetic to find a location and memory and look it up, whereas a Bring has to iterate over every unit and check its location boundaries, which is relatively speaking a lot more to do.
In practice, this is probably difficult to quantify given you need to know ratios of evaluation speeds of conditions to one another and have accurate estimates of the probability of your conditions being true.
Next best practice is avoid unnecessary use of Always condition and when possible group your Always condition's actions into single triggers.
While this certainly is a best practice, it's not for execution speed unless you have extraordinarily large numbers of always triggers. Assuming that that the always condition is implemented reasonably (and the optimization you described is not made under the hood for you), it should just be checking "if (true)". If your CPU gets bogged down evaluating "if (true)" a hundred times, then it's absolutely hopeless to loop over a thousand units to evaluate a bring condition. You should still do this, but for readability and more organized triggers.
Depending on how likely it is that the player has N units of a type, you could also do "commands at least 10 marines" followed by "commands/brings 10 marines at location"
This sounds like a dubious practice for similar reasons from my response to Oh_Man. You would need to know the ratio of evaluation speed of Bring to Commands. Which is the ratio of iterating over every unit and just checking what it is versus iterating over every unit, checking what it is and if it is a specific unit, checking its location coordinates. If the former is not fast enough compared to the latter, then the average evaluation time will be longer with this method.
This will also suffer in the worst case performance; that is, if the command condition is true, then the bring condition still has to be evaluated. Which means after looping over every unit to check what it is for the Command condition, now we have to loop over every unit again to check what it is (ie, information that has already been checked) and check its location boundaries for the Bring condition.
For this to be a good recommendation, you would need Command to be significantly faster than Bring and you would want that Command condition to be false most of the time. When the Commands condition is true, the conditions don't short-circuit and no evaluation time is saved, so you're in the worst performance case.
), I did some quick calculation and expect my map to probably hit somewhere between 75,000-100,000 lines of triggers in order to achieve a playable beta. Namely, I have around 150 provinces on my map, and the spawn triggers for each province alone are 400 lines apiece (I have to do this per-province because I use EUD's to detect the health of a specific unit in each province for calculations). And this is before I even get to "historical flavor" scripting.
