Ctrl+F9 launches the map in the real engine, from the editor, with the map as
it currently stands. Not a preview and not a simulation of the engine: the same
code path a downloaded map takes, with your roster, your triggers and your data
overrides installed.
Come back to the editor and your tool, brush and selection are where you left them.
What to check first
A short list that catches most problems, in the order they are cheapest to find.
Does it boot? A map that ends instantly is almost always a one-seat map with standard victory still on. The validator catches it, but if you have turned validation warnings off in your head, this is the symptom.
Does every seat have a base? Missing town halls usually mean a player-owned building somewhere in the map has switched off the automatic bases. Set the rule explicitly instead of relying on the absence of buildings.
Can ground units get everywhere they need to? Walk a unit from each start to each expansion and to each opponent. Elevation problems that the validator classes as warnings rather than errors, like a one-wide terrace, only show up when something tries to walk on them.
Do the triggers fire? Give each wave, objective and cutscene a text message while you are testing and take them out afterwards. A trigger that does not fire and a trigger that fires and does nothing look identical without one.
Do the spawners produce what you expect? Watch a camp respawn at least once. A spawner with a squad entry that is not a real unit id is a publish error, but a spawner producing the wrong unit is a typo the validator cannot see.
Testing a specific situation
Two settings on the test launch make scenario testing faster: starting resources and fog. Give yourself ten thousand of everything and reveal the map while you are testing the second half of a scenario, then turn both back off.
Placed entities can be given build progress and health fractions, which is the fastest way to test a mid-match state without playing to it. A map fixture with a full base at 40% health and an army in the field tests the same triggers your players will hit twenty minutes in.
Testing multiplayer behaviour
Anything that involves more than one seat is worth testing with more than one seat, because a whole class of problem only exists there.
The one to watch for is any behaviour that differs between machines. The engine is lockstep: every client runs the whole match and compares hashes, so a difference is not a cosmetic glitch, it ends the match. The trigger set is built so that a map cannot cause this (every node is deterministic, every list is sorted, nothing reads the wall clock), but two authored things can:
- Time of day, which changes sight radii, is stored in the map and applied before the first tick on every machine. If you find yourself wanting to make it a graphics option, that is the bug.
- A modified map, where one player's copy differs from the host's. The map is hashed at match start and mismatches are reported, so this arrives as a clear message rather than a desync.
Playing your own map honestly
Two habits that are hard and worth it.
Play the map from a seat that is not seat 0. Authors test their own start position and rarely the mirrored one, and asymmetries in a supposedly symmetrical map turn up immediately from the other side.
Play it against the AI at a difficulty you would lose to. A map that is only balanced against an opponent that never attacks is not balanced.
Reading problems
The Validation module lists every issue with a severity and, where the problem has a location, a jump-to. Errors block saving, testing and publishing. Warnings never block anything.
A warning is not automatically wrong. "Seat 2 has no gold mine within reach" is a mistake on a normal competitive map and entirely correct on a map where seat 2 is a defending player with no economy. The validator does not have opinions about design; every error it reports is a failure you would not otherwise see.
Next: Publishing.