If hours of progress vanish when the game ends, nobody plays a second time. For a map like that, saving is not a feature - it is the condition the map exists under.
It is also hard to add later, because what you save shapes how your counters are designed. Bolting it on at the end usually means rebuilding the counter layout first.
That is why this module sits here rather than next to publishing. From the moment you lay out your triggers, ask of each value whether it is one that has to survive.
| Maps that need one | RPG progression, defence prestige, an arena with a leaderboard - anything where something is meant to outlast one match. |
|---|---|
| Maps that do not | A self-contained arena, a single-round versus map - there is simply nothing to carry forward. |
There are three ways to do it and they give up different things. This module teaches the third, but it is worth seeing all three before choosing.
| A save code that stays inside the map | The map prints a code, the player writes it down and types it back. No launcher and no server, so it works for everyone - but it only holds as much as a person will type, and with nothing to check it against it is weak to forgery. |
|---|---|
| Launcher storage (SCDB and the like) | A launcher stores death counters and the units inside nominated locations on the local machine. No typing, players are identified by their StarCraft nickname, and multiplayer does not desync - but everyone has to run that launcher and the data lives only on their own computer. Maps sharing a serial number share the data. |
| A script running inside the launcher (SCAScript) | An extension of the second. The SCArchive launcher runs Lua, which does save and load but also draws real windows and buttons over the screen, plays sound with proper fades, and reads and writes local files. Everything StarCraft itself cannot do - at the same price, that everyone has to run the launcher. |
| A code a server mints and verifies | A site mints the code and validates what is submitted. The leaderboard becomes trustworthy and forgery is detectable, at the cost of the player having to visit a site. This is the approach the module teaches. |
It is worth seeing how the first approach was built before EUD, because it makes clear why people generate a codec now. The whole of the old method was one srand.
- 1Hash the player's nickname into a number.
- 2Call srand with it. That pins the random sequence to the nickname, so the same person gets the same numbers in the same order every game.
- 3Call rand 256 times to fill an array A[0..255].
- 4The code for progress value x is A[x].
- 5To load, search A[0..255] for the typed code: the index that matches is x.
Step 2 is the good idea: one srand buys a per-player salt with no cryptography at all. The same progress prints a different code for every nickname, so codes cannot be traded between players.
The ceiling is step 5. Decoding is a search of the table, so the state it carries is exactly one table's worth - one byte, 0 to 255. Carrying more means inverting the function rather than searching for it, and that is the point at which you want a generated codec. Note that the one-byte limit belongs to this construction and not to StarCraft: what actually binds is typing, because the chat window has no paste.