Hi everyone,

I am learning about creating UMS maps in StarCraft 1 and noticed that as the number of triggers increases (especially in complex maps like RPG or Defense), the performance can drop significantly. This affects the player experience, especially in levels that require many events running in parallel.

I would like to open a discussion topic around the issue:
How to optimize triggers in SC1 UMS maps while maintaining the desired level of detail?

Some ideas that come to mind:

Combine conditions instead of splitting them—avoid writing multiple separate triggers for similar events.

Use “Death counters” to save variables and reduce the number of triggers needed.

Prioritize trigger order—put important triggers first to avoid conflicts.

Make good use of preserved triggers—but don’t overuse them to avoid heavy loops.

👉 I’d like to ask the community:

What are your “best practices” when working on complex maps?

Are there any support tools (other than SCMDraft) that you find useful for debugging and optimizing triggers?

In your experience, what is a reasonable limit on the number of triggers to keep the map running smoothly on most machines?

Looking forward to hearing experiences and sharing from seniors in the community.

Very nice topic, very good questions. While I personally can't really help with optimization of triggers (you already kinda mentioned all the best methods), I can help a bit with debugging and testing:

Currently, SCMDraft 2 is the most STABLE editor, but not the most POWERFUL one. You can use TheNitesWhoSay's CHKDraft for the best editing experience. It is prone to crashing, and some buttons don't work yet. However, it's scripts and trigger editing capabilities are very good.

For now I'll get a few obvious ones out of the way, and will add another post later.
manipulating/checking death counters (DCs) is one of the cheapest (perfomance-wise) actions/conditions. Try to exploit this by not checking 5x "player x brings 1 Marine to abc" but checking it once and then save that state in a dc and check that instead.
Also put those conditions first in the condition list.

And IMPORTANT: Avoid all waits. convert them to dc timers to avoid wait blocks. Wiki is down so I can't link what wait blocks are, but I can explain if necessary.
Transmissions are waits. Avoid them as well. You can emulate most of their effects through multiple actions.


Trigger order does not matter for performance (if you avoid waits), they will get checked all anyway irregardless of order.
Condition order matters. Cheap conditions like DCs and score before costly one's like brings.

During runtime trigger owner groups like forces or all players are copied to an instance for every present player (was in lobby, not defeated). So avoid them for general things like scoreboard and other globals stuff. Give these to a specific computer player. Make sure the computer doesn't get defeated, if necessary remove all their units instead.

Avoid an abundance of order actions. pathfinding is costly.

Death counters and wait removal is good advice.

Avoid using excessive triggers dealing with pathfinding as this is usually always the most resource intensive aspect of an RTS, and starcraft is no exception. Normally, you can have an obscene amount of triggers with no discernible impact on performance. However, actions like create, move, and order require a large amount of calculations because of pathfinding and collision checks. Your experience encountering lag within RPG and Defense maps would probably be caused by these.

Ordering/moving/creating a large amount of units will cause lag and it's exacerbated by frequency. This is the most common cause of lag in defense and massing maps. Solutions would be to reduce frequency of actions or stagger them so they aren't all executed at once. It may also help to space out the units with multiple locations instead of dumping them all in a single one.

Location grids, utilized in some RPGs will cause lag. It isn't very noticeable in most maps that utilize them but it does become apparent when multiple grids are active at once and near unplayable when they are run every trigger cycle.

Command is less expensive than bring although there are caveats to their behavior and variants. Although personally I haven't had an issue with bring causing lag but it may be noticeable if hundreds of triggers are used.

Practically if you keep these in mind you shouldn't really have an issue with lag although there's always room to improve optimization.