← Back to the gamebug or idea?Terrapin Trail//Code BibleIIhow the game works, archive to van
Reel 03 · 6 min read

How the screens work

What 'state' means, and how the game decides which screen to draw and what your clicks do.

A game is always showing you some screen — the title, the parking lot, a road event, the finale. How does the program keep track of which one to show, and make your clicks do the right thing? Two simple ideas answer both questions.

Concept: "state". State is just "everything the program currently remembers." In this game that's your cash, your fuel, who's in your van, where you are on the tour — and, importantly, which screen you're looking at. All of it lives together in one place the code calls S (for "state").

Which screen? Just a word

The program keeps a single word that names the current screen — S.view. It might be "title", "lot", "event", and so on. To decide what to draw, the code looks at that word and picks the matching screen-builder:

●assets/game/game.js : 2328–2341trace ↗
2328  function viewHtml() {
2329    var v = S ? S.view : "title";
2330    switch (v) {
2331      case "title": return viewTitle();
2332      case "tours": return viewTours();
2333      case "campaign": return viewCampaign();
2334      case "role": return viewRole();
2335      case "crew": return viewCrew();
2336      case "builder": return viewBuilder();
2337      case "van": return viewVan();
2338      case "stash": return viewStash();
2339      case "library": return viewLibrary();
2340      case "peak": return viewPeak();
2341      case "lot": return viewLot();
A big 'which one is it?' list: look at the current screen name, and call the function that builds that screen.

Concept: a "switch". This is a switch — a tidy way to say "look at this one value, and depending on what it is, do the matching thing." Here: look at the screen name, run the builder for that screen. Add a new screen? Add a new line to the list.

Each builder just returns the screen as a block of text (HTML — the language web pages are written in). One function, render, takes that text and actually puts it on the page. Keeping "figure out the screen" separate from "put it on the page" is what lets the game also run with no page at all (remember the shape of the program).

Making your clicks do things

You might expect every button to have its own bit of code wired to it. Instead, the game uses one listener for the whole page:

●assets/game/game.js : 3431–3438trace ↗
3431  function onClick(e) {
3432    var t = e.target.closest("[data-action]");
3433    if (!t) return;
3434    // first gesture unlocks audio; a soft tick gives every button tactile feedback
3435    Sound.init(); Sound.resume(); Sound.tap();
3436    var a = t.getAttribute("data-action");
3437    handle(a);
3438  }
One click-catcher for the entire page: find what was clicked, then hand its label to the big 'do this action' function.

Concept: an "event listener". An event is something that happens — a click, a keypress. A listener is code that waits for one and reacts. Rather than give every button its own listener, this game gives each button a label (like pick-tour-1977) and has one listener read that label and act on it. Fewer moving parts, and new buttons work automatically.

So the whole interface is: a word decides the screen, a builder turns it into text, render paints it, and one listener turns your clicks into actions. That's genuinely most of it.

The ideas to keep
  • State is everything the program remembers, kept together in S; one word in it names the current screen.
  • A switch picks the right screen-builder from that word; render puts it on the page.
  • One listener handles every click by reading a label off the button — no per-button wiring.