Whether you’re just getting started or building a massive serious adventure, these saveSystems I’ve created are equipped to handle it. Each varies in complexity, flexibility, storage capacity, and security. Each namespace has user-friendly comments, so, plug in your variables, and you’re good to go! They’re also designed to be scalable, you can upgrade/downgrade the amount of data you want to save. Here is a quick comparison table between the three systems:
==========================================================================
Basic Save System:
Type: blockSettings
Shareable: No
Encryption: None
Encryption Strength: 0/10
Browser Capacity: ~150-200 Variables (numerical) [16KB]
Hardware Capacity: ~8-10 Variables (numerical) [1KB]
Read/Write Time: Instant (<1ms)
Ideal for: Beginners, local scores
Unsuitable for: Large or secure data
PasswordSaveSystem
Type: Password String
Shareable: Yes
Encryption: XOR + Checksum
Encryption Strength: 4/10
Browser & Hardware Capacity: ~6-10 Variables (numerical) per 10-char password
Read/Write Time: Fast (<5ms)
Ideal for: Shareable saves, minimal data
Unsuitable for: Long saves, brute-force resistance
SaveSystem
Type: blockSettings
Shareable: No
Encryption: Bit-packing + Base64
Encryption Strength: 8/10
Browser Capacity: ~10,920 Variables (numerical) [16KB]
Hardware Capacity: ~681 Variables (numerical) [1KB]
Read/Write Time: Mostly Fast (<50ms)
Ideal for: Full-fledged games with multiple stats for each level
Overkill for: Tiny games, human input (Encryption is non-readable)
==========================================================================
Each system targets different usage cases, you should pick the one that is best suited for your game as choosing the wrong system could lead to unexpected behavior when approaching save-data limits, or unnecessary operations dealing with base64 & binary encoding for simple write/read operations.
If you’re going for a retro-style game, the Password system is the best of both worlds, encryption that isn’t insanely hard, but not so easy where anyone can easily input a cheat code to max out their stats, and many games in the retro-era used passwords instead of SRAM.
BasicSaveSystem is the most popular and easy-to-use one, good for small games that never approach the save limits of 16KB for browsers or 1KB for hardware.
SaveSystem I would only recommend for full-fledged platformer games that include lots of levels and there are stats for each, as doing this conventionally would lead to hitting the 16/1KB limit FAST, this system is by far the most complicated and your game code must be formatted to handle the 2D-array arguments/returns properly.
==========================================================================
For those wondering how I calculated the storage limits for each system, here is the underlying math:
Definitions
- 1KB = 1024 bytes = 8192 bits
- 16KB = 16,384 bytes = 131,072 bits
BasicSaveSystem
Let:
- v = number of values (each 4 bytes)
- s = storage limit in bytes
Formula:
v ≤ s/4
Storage Limits:
Hardware: (1024/4) = 256 values (v)
Browser: (16384/4) = 4096 values (v)
SaveSystem
Let:
- l = number of levels
- t = combined levelStat bit sizes
- b = base64 bytes per level = t
- s = storage limit in bytes
- v = number of values
Substitue t for 6 since: 12 bits (time) + 11 bits (score) + 10 (extra) = 36 bits = 4.5 bytes * 1.33 for base64 overhead, roundup from ~5.98 to 6
Formula:
l ≤ (s/b) => v = 3 * l
Storage Limits:
Hardware: (1024/6) = 170 max Levels (l), (170*3) = 510 values (v)
Browser: (16834/6) = 2730 max Levels (l), (2730 * 3) = 8190 values (v)
==========================================================================
With all that out of the way, here’s the project link containing all three Systems (Nothing happens on the sim just pure code without any visuals):
Hope it helps you out! Report any issues or questions, please!