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:
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();
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:
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 }
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.
- 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;
renderputs it on the page. - One listener handles every click by reading a label off the button — no per-button wiring.