Building a save system and wiring it in

Everything you save is a death counter - level, money, class, upgrades. You pick the counters your triggers already use.

For each one you set a range and a precision, and those two decide the length. Levels 1-100 cost almost nothing; money up to 300 million stored to the exact unit costs a lot. Store money in steps of 10,000 and it collapses.

The player types this code by hand, so shorter is better. Giving up a little precision to save two or three characters is usually the right trade.

If you do not want to give up the precision, split one figure across two fields: the big part in coarse steps, the leftover in a small one, and add them back on load. Money up to 100,000,000 in steps of 100 plus a 0-99 remainder costs what the coarse field costs and loses nothing of the actual amount.

// 저장할 때 / on save
SetDeaths(cp, SetTo, (gold / 100) * 100, "GoldBase");   // 100단위 / coarse
SetDeaths(cp, SetTo, gold % 100, "GoldRem");            // 0~99

// 불러올 때 / on load
const gold = v_base + v_rem;

The map and the site must agree on which field is which. One RPG stored gold and experience in each other's fields and the codes still worked perfectly - both restored losslessly, so nothing failed in game and only the leaderboard printed one figure under the other's heading. The names on the configuration screen are the specification.

Changing the set of stored values later invalidates every code already issued - that includes adding a field or widening a range. Leave yourself headroom at the start.

The code uses only 32 characters - 0, 1, I and O are left out, because StarCraft's font renders those pairs closely enough that copying a code off the screen produces typos. That costs a character or two of length in exchange for a code that can actually be transcribed correctly.

That is the design. The rest is generating it and wiring it in.

You can design a save code yourself, but format design, bit packing, checksums and forgery resistance add up. And a code with fixed positions is broken the moment a player saves twice and compares.

1. 1Post your map as a project on SCRMaps. The generator lives inside the project.
2. 2Enter the counters you want stored, with each one's range and precision.
3. 3Turn on the idle guard and minimum-player requirement if you want them.
4. 4Take the generated EPScript and key table.

The generator writes the binary-search read for every value you store - the pattern you saw in the EPScript module.

You will almost certainly edit the script you receive: an adapter between your map's variables and the death counters, sounds, a save condition that matches your map's rules. Regenerate it from the dashboard and every one of those edits is gone - the generator knows what is in the configuration and nothing about what you added by hand.

Nothing fails, which is the trap. The new script builds cleanly, the map runs, and what went missing is reported by a player weeks later. One map lost its game-over panel options in a regeneration and shipped three builds that way before anyone noticed the level and best round had stopped printing beside the code.

1. 1Keep the pristine generated file beside your edited one. Diffing the two gives you the list of things to re-apply.
2. 2Keep your map-side logic in a separate adapter file. That shrinks what a regeneration can touch.
3. 3After regenerating, check with a diff rather than a build. A build says nothing about a feature that is simply gone.

// ==========================================================================
//  Save / Load system for: <projectName>
//  Generated by scrmaps.com - paste into EUD Editor 3 (epscript).
//
//  Code length: 14 characters.
//  This project’s salt is 1284739201 - it makes these codes valid ONLY in
//  this map. A code from another map, or another map’s copy of this system,
//  will not decode here, and cracking another map does not weaken this one.

Putting what you receive into the map is two pastes and two triggers.

What you get is two blocks. The EPScript goes in EUD Editor 3's TE section and the key table in the Plugin section. Without the key table saving still works but nobody can type a code in to load.

1. 1In ScmDraft, create the three counter unit names: one for save, one for load, one for key input.
2. 2Paste the EPScript into TE and the key table into Plugin.
3. 3Add a trigger that sets the save counter to 1 when the player stands on a save pad.
4. 4Do the same for the load counter.
5. 5Compile and actually save in game.

Trigger {
	players = {Force1},
	conditions = {
		Bring(CurrentPlayer, AtLeast, 1, "Men", "Save Pad");
	},
	actions = {
		SetDeaths(CurrentPlayer, SetTo, 1, "SaveTrigger");
		PreserveTrigger();
	},
}