6.5 Save and Load

Step 1 — Parse the call: storeItem(name, value) takes two arguments: a key name you choose and the value to save. Here the key is 'courtyardHighScore' and the value is the number 100.

Step 2 — Where the data goes: The value 100 is written to persistent storage — in a web browser, moSHion saves it to the browser's localStorage, a tiny built-in database that only your website can access. If you open the developer tools (F12) and look under Application > Local Storage, you would see an entry with key 'courtyardHighScore' and value 100.

Step 3 — Why it "persists": Unlike a regular variable, which disappears the moment the sketch stops running, this entry survives closing the tab and restarting the browser. It stays there until you overwrite it with another storeItem call on the same key, or delete it with removeItem('courtyardHighScore').

Answer: It saves the value 100 under the key 'courtyardHighScore' in the browser's localStorage (persistent storage), where it survives page reloads and browser restarts until it is overwritten or removed.

Step 1 — Recall what getItem promises: getItem(name) retrieves a previously stored value by key name. But that only makes sense when something has actually been saved — the question is what happens when the key is empty.

Step 2 — The empty case: Per Definition 6.5.2, if nothing has ever been saved under 'courtyardHighScore', there is no value to hand back, so the function returns undefined — JavaScript's way of saying "no value exists here."

Step 3 — Why this matters in practice: This is exactly why the standard loading pattern pairs getItem with || 0. Since undefined is falsy, the || fallback supplies a sensible default instead of leaving your variable holding undefined (see 6.5.4).

Answer: It returns undefined.

Step 1 — What removeItem does: removeItem(name) deletes the stored value under the given key. After calling removeItem('courtyardHighScore'), the entry that was in localStorage is gone entirely — it's not set to 0 or to an empty string; the key simply no longer exists.

Step 2 — What getItem returns afterwards: With the entry deleted, the key looks to getItem exactly as if nothing had ever been saved under it. So getItem('courtyardHighScore') returns undefined again — the same result you'd get on a brand-new browser that had never run the game.

Answer: It deletes the stored value for that key. Afterwards, getItem('courtyardHighScore') returns undefined until something is saved under that key again.

Step 1 — Read the left side: getItem('courtyardHighScore') returns either the previously saved high score (a number) or undefined if nothing has been saved yet — for example, on the very first run of the game on a new browser.

Step 2 — Understand the || operator: The expression a || b evaluates to a when a is truthy, and falls back to b when a is falsy. Values like undefined, 0, and null are falsy. So if the key has data, that saved number is used; if getItem returns undefined, the expression falls through to 0.

Step 3 — Why the default matters: Without || 0, highScore would be undefined on a first run, and then score > highScore (the new-record check from §6.5.3) would compare against undefined and never be true — a new high score could never be recorded. The || 0 guarantees highScore starts at a usable number.

Answer: It loads the saved high score from storage, and the || 0 part supplies a default of 0 when nothing has been saved yet (i.e., when getItem returns undefined), so highScore always ends up holding a usable number.

Step 1 — What "every frame" means: The draw function runs about 60 times per second. A storeItem call in draw's main body would therefore fire roughly 60 storage writes every second, whether or not anything actually changed.

Step 2 — Why that's wasteful: A write to browser storage is much slower than a plain variable assignment — it goes through the browser's localStorage database, not just memory. Almost all of those writes save the exact same value as the previous frame, so you pay the cost of persistence 60 times per second for essentially no benefit.

Step 3 — When you should save instead: Save once when something meaningful happens — at the moment the value changes in a way worth keeping. In the courtyard game that means inside the event callback (e.g., the coin overlaps handler), and specifically inside the if (score > highScore) branch so storage is only touched on a genuine new record, exactly as §6.5.3 does.

Answer: You should not call storeItem every frame because draw runs ~60 times per second and storage writes are far slower than variable assignments — you'd be rewriting unchanged data constantly. Call it only when something meaningful happens: once, at the moment the value actually changes in a way worth persisting (such as when a new high score is achieved).

Step 1 — Identify the bug: §6.5.2's version called storeItem('courtyardHighScore', score) inside both overlaps callbacks, on every coin and bomb pickup, with no check of whether the score was actually a record. That means the key held the latest score, not the best score.

Step 2 — See the consequence: A run that peaked at 12 coins and then lost 15 points to bombs would end with 'courtyardHighScore' storing a value lower than the true high point the player reached — so the "high score" wasn't high at all. It also wrote to storage on every single pickup whether or not that was needed, which is the wasteful behavior from 6.5.5.

Step 3 — How §6.5.3 fixed it: Two changes. First, setup loads the real saved best with highScore = getItem('courtyardHighScore') || 0. Second, the save now happens only inside the coin callback's if (score > highScore) branch, which updates the in-memory highScore and calls storeItem only when the current score genuinely beats the stored one. Bombs no longer touch storage at all — they can only lower score, never raise the record.

Answer: §6.5.2 saved the current score on every pickup, so 'courtyardHighScore' ended up holding the latest score rather than the best score (and wrote to storage far more often than necessary). §6.5.3 loaded the true high score in setup with getItem(...) || 0 and saved only inside if (score > highScore), so storage is updated solely when a genuine new record occurs.

Step 1 — Notice both calls use the same key: storeItem saves a value under a key name, and per the Insight Note in §6.5.2, saving again under the same key overwrites the previous value. One key holds one value — there is no history of past saves.

Step 2 — Trace the sequence: The first call writes 50 under 'courtyardHighScore'. The second call then replaces that entry with 30. Nothing remembers the 50; it's gone from storage.

Answer: The second call overwrites the first, so the value 30 is stored under 'courtyardHighScore'.

Step 1 — Plan the logic: The count must (a) be loaded from storage in setup with the || 0 default pattern so it survives a refresh, (b) increment only when a jump actually happens — that's the existing jump condition kb.presses(' ') && player.colliding(ground) — and (c) be saved right there, at the meaningful moment, following §6.5.5's "don't save every frame" rule. Give it its own key name, 'courtyardJumpCount'.

Step 2 — Write the sketch:

▶ Press Run to see the output…

Step 3 — Check that it survives a refresh: Every real jump (space pressed while grounded) immediately increments jumpCount and writes the new total to storage — one save per jump, never per frame. On reload, setup runs getItem('courtyardJumpCount') || 0, restoring the previous total; the || 0 covers the first-ever run when the key doesn't exist yet.

Answer: The sketch above: it loads jumpCount in setup with getItem('courtyardJumpCount') || 0, increments it inside the jump condition, and saves it with storeItem right there, so the jump total persists across page refreshes.

Step 1 — Count the moving parts in each approach: With two separate keys, saving means two storeItem calls and loading means two getItem calls (each with its own || default). Every additional related field would add yet another key and another load/save pair to juggle. With one object, it's one storeItem('courtyardStats', stats) to save everything and one getItem('courtyardStats') || { highScore: 0, totalCoins: 0 } to load it all.

Step 2 — Consistency: The two numbers are related — they describe the same player's history — so they belong together. Saving one object means both fields are written in a single operation and restored together. With two separate keys, a forgotten save (or an interruption between the two writes) can leave them out of sync: for example, a freshly saved high score paired with a stale coin total.

Step 3 — Simplicity and the structured-data bonus: One key name to remember instead of two (or more), and per the Structured Save Data definition, getItem hands back the whole object directly — moSHion serializes and deserializes it for you, so stats.highScore works immediately with no parsing.

Answer: One object under one key takes a single save and a single load no matter how many related fields it holds, guarantees the fields stay consistent with each other (saved and restored together), and keeps the code simpler — versus maintaining a separate key plus getItem/storeItem pair and default for every individual number.

Step 1 — Recall the Structured Save Data definition: An object passed to storeItem is returned by getItem as an equivalent object, not as a string. moSHion's storage layer serializes the object when saving and deserializes it when loading, so you never parse it yourself.

Step 2 — Apply it to this case: After the refresh, getItem('courtyardStats') returns the object { highScore: 12, totalCoins: 40 } — a real object with working properties. Code like stats.highScore or stats.totalCoins += 1 works immediately, which is exactly why §6.5.6's setup line can feed the result straight into stats.

Answer: It returns the object itself — { highScore: 12, totalCoins: 40 } — not a string needing parsing, because moSHion's storage layer serializes and deserializes structured save data automatically.