In a large EUD map the frightening bug is not the one that crashes. It is the one that is quietly wrong: it compiles, the game runs, and one number disagrees with the design. Those are hard to find by playing and hard to find by reading.
The answer is a check script that runs before the build. It reads the source, reads the data in the compiled map, and confirms the things the design claims one at a time. If any of them is wrong it refuses the build. Refusing, not warning: warnings do not get read.
- Check invariants, not values. "the three weapons are within 15 percent of each other" is far stronger than "damage is 120".
- Where code depends on order, check the order. Which line comes first is the real condition, not whether the text is present.
- Check line counts on screens. An eleven line screen that becomes nine leaves the previous screen showing in the last two.
- Check the lists of things you must not touch: forbidden unit ids, unsupported addresses, anything the player owns.
- When you add a check, confirm it FAILS against the old code. A check that can only pass is not a check.
That last point matters most. Write a check, see it pass, and you may be holding a check that tests nothing. Always make a new check fail once against the code from before the fix.
Write the check messages as sentences for a person. On failure you want to know immediately what broke; on success the list reads like a design document. Several hundred lines of "ok" become the complete list of promises the map keeps.
Mind how the check script itself fails. If an outer script stops the build by looking for a word in the output, a check message containing that word will refuse a build that passed. That happens.