Lesson 5 teaches Deal Game JavaScript DOM manipulation

Published October 25, 2026

What makes a browser game feel alive instead of frozen on the page? The answer is usually the DOM. That is the part of the page JavaScript can see, select, and change at run time.

In this lesson, the work is less about flashy game rules and more about setting up the stage. The code is teaching how to find page parts, store them, and react when a player clicks. That is the first real step from static HTML to an interactive game.

The shape of the lesson is simple. First, the page is prepared. Then the start button is wired. Then the game state is reset. After that, the game can begin.

The lesson starts with a small pool of case values. They are put into an array and sorted in ascending order. That gives the game a known set of values to work from, even before any board is built.

A second array holds possible offer values. Those offers are filtered so only numbers smaller than the number of cases stay in play. Since there are 16 case values, every offer in the sample list passes that check. The offers are then sorted from largest to smallest, which makes later deal logic easier to manage.

That may sound dry. It is actually tidy. A browser game often needs this kind of housekeeping before it can feel fun. No one sees the sorting, but the game depends on it.

The main idea here is DOM selection. The code uses document.querySelector() to grab pieces of the page and save them in a page object. That object ends up holding references to things like modal windows, the start button, the game area, and the left and right sides of the board.

This is a smart move. Instead of hunting through the page again and again, the game keeps those references ready to use. It is like putting tools on a workbench instead of leaving them in a drawer across the room.

The lesson also shows a common event pattern. When the document is ready, the app runs its init() method. That means the code waits until the page is loaded before it starts looking for elements. In plain terms, it avoids trying to grab buttons that have not appeared yet. That is the sort of bug that makes a beginner stare at the screen and feel personally insulted.

Inside init(), the start button gets an event listener. When the player clicks it, the game runs startGame(). That is the first real bridge between the page and the game.

startGame() does a few important things at once. It logs a message, hides the start button, calls a board-building function, resets the game state, and shows an instruction pop-up. None of that is visual magic yet. It is wiring. But wiring is where browser games begin to breathe.

There is a good lesson hidden in the game object too. It stores simple flags like inPlay, lastOffer, and offerMade. These values tell the game what state it is in.

That matters because a game is not one long blur of clicks. It changes state. At one moment, the game is waiting. Then it starts. Then it accepts a case pick. Then it might show an offer. Then it may end. The game object is the memory that keeps those steps from getting tangled.

One small concrete example makes this clearer. Imagine the player clicks Start. The code hides the Start button, sets game.inPlay to true, and shows a message that says to choose a case. If the button were not hidden, the player could click it again and restart the setup by mistake. If game.inPlay were not tracked, the code would have no clean way to know whether the round had begun.

That is the real job of DOM manipulation in a game like this. It is not only about changing text or styles. It is about making the page respond in a controlled way. A click should mean something. The screen should react. The game state should match what the player just did.

The pop-up system in this lesson is also worth noticing, even if it is still plain. The message function only logs text for now. The modal elements are found and stored, but the actual pop-up UI is saved for later. That split is practical. It lets the lesson focus on structure before decoration.

There is a kind of old-web honesty in that. Build the bones first. Add the shine later. Too many games do the reverse and end up with glitter on a broken machine.

The placeholder board builder matters for the same reason. The lesson names the job without fully doing it yet. A complete board would randomize the cases and place them on screen. Here, the function is only a promise. That is fine. It teaches where the missing piece belongs.

This is also where beginners often learn a useful truth. A game can be designed in stages. You do not need the full experience at once. You need a page, a few stored elements, a click handler, and a clean way to remember state. After that, the rest becomes much easier to place.

The offer logic hints at the next part of the game loop. Once the player chooses a case, the game can draw offers from the sorted list and stop when lastOffer turns true. That gives the design a sense of rhythm. Pick a case. See an offer. Keep going or end the round. Nice and simple. Very browser game. Very “one more click” in the best possible way.

What this lesson teaches, in plain terms, is how JavaScript reaches into a page and makes it behave like a game board instead of a poster. It shows how to find elements, react to clicks, reset state, and prepare later game logic without trying to do everything at once. That is a useful skill on its own, and it is the kind of foundation that keeps a simple web game from falling apart the second a player touches it.

The Continue Screen would enjoy this one for the same reason it enjoys a lot of old browser curiosities: the odd charm of seeing a game wake up one tiny DOM change at a time.