Lesson 3 teaches the Deal Game using JavaScript DOM

Published October 24, 2026

What happens before a browser game shows its first button? In this lesson, the answer is simple: JavaScript prepares the game data, CSS builds the stage, and the DOM connects the two.

The Deal Game is a small setup with a familiar hook. Values sit in a list. Offers appear in another list. A player will later choose between a deal and no deal. For now, the work is getting the numbers in order and making the page ready for play.

That may sound plain. It is also the part that keeps old browser games from becoming a pile of buttons with opinions.

Start with the game data

The game begins with a list of values:

const vals = [100, 2, 3, 4, 5, 6, 7, 8, 10, 15, 20, 40, 50, 75, 1, 200];

vals.sort((a, b) => a - b);

The list has 16 numbers. JavaScript’s default sort can treat numbers like text, so the comparison function matters. The expression a - b tells JavaScript to place smaller numbers first.

The result is:

[1, 2, 3, 4, 5, 6, 7, 8, 10, 15, 20, 40, 50, 75, 100, 200]

That small function does useful housekeeping. It gives the game a clean order before the page needs to display anything.

Next comes the offer list:

game.offers = [100, 14, 4, 12, 2, 1]
.filter(x => x < vals.length);

game.offers.sort((a, b) => b - a);

Here, vals.length is 16. The filter keeps every offer smaller than 16. That removes 100, but keeps 14, 4, 12, 2, and 1.

The second sort uses b - a. That reverses the order and puts the largest remaining offer first:

[14, 12, 4, 2, 1]

This example shows two common JavaScript moves. filter() removes items that fail a condition. sort() changes the order of the items that remain. Together, they turn rough setup data into a usable game list.

Let the page announce itself

The next piece wraps the setup in an app object:

app = function () {
 const page = {};
 const game = {};

 app.init = function () {
 console.log(vals);
 console.log(game.offers);
 };

 return { init: app.init };
}();

document.addEventListener('DOMContentLoaded', app.init);

The game object gives the game its own space. The page object is ready for page elements later. At this stage, the setup function only logs the two lists.

The final line waits for DOMContentLoaded. This event fires after the HTML has been parsed, so the script does not rush ahead of the page it needs to work with. It is a small pause with a sensible job.

When the page is ready, app.init runs. The browser console then shows the sorted values and the prepared offers. Nothing flashy happens yet. That is fine. A game does not need fireworks to prove that its numbers are behaving.

Build the first button

The start button needs a clear visual role. Its class is start, and its first style gives it a gray background, white text, centered text, padding, and a slightly larger font.

The button uses:

• position: absolute
• left: 35%
• width: 30%
• margin: auto
• cursor: pointer
• A visible z-index

The width and left position work together. A button that takes 30 percent of the page, beginning 35 percent from the left, sits in the middle. No float is needed.

The pointer cursor gives a simple message: this thing can be clicked. On hover, the background changes to red, the text stays white, and a box shadow adds a stronger edge. The hover effect is a little old-school, which suits a browser game built from boxes and bold decisions.

The exact shadow setting may use a value described as “three.” The useful idea is the visual change. The button should feel active before JavaScript gives it a job.

Make room for the game

The game area uses the class game area. Its width is 60 percent, and its margin is set to auto. That centers the area on the page.

During development, a border helps show where the area begins and ends. Borders are often removed later. Early on, they are less like decoration and more like honest witnesses.

The columns use a minimum width of 100 pixels. The lesson material calls these values “picks,” but the CSS unit is pixels. Each column has a light border and no extra padding at first.

The columns float left. This places them beside one another instead of stacking them down the page. It is an older layout method, but it makes the lesson’s structure easy to see.

The main game area has a height of 100 viewport-height units, or 100vh. It also has a minimum width of 800 pixels and a centered margin. The visible border stays useful during layout work. A background color can help too.

The page is allowed to look unfinished for a while. That is part of the process. Clear boxes beat mysterious spacing.

Cover the screen with a modal

The Deal Game uses two modals. A modal is a panel that sits above the main page. One can show an opening message. Another can show the deal choice.

Both begin with:

display: none;

That keeps them out of sight until JavaScript shows them. During development, one modal may be left visible so its layout can be checked. The second stays hidden.

Each modal covers the screen with:

position: fixed;
width: 100%;
height: 100%;
left: 0;

Fixed positioning places the element against the viewport rather than the normal page flow. A high z-index brings it above the game area. The background can be black or a transparent black such as rgba(0, 0, 0, 0.4). The result is a darkened page behind the modal.

Inside sits the modal body. It can use a light gray background, a minimum height of 30 pixels, 30 pixels of padding, and rounded corners. The content then feels like a panel instead of a sheet of raw HTML.

Old web games loved this trick. Dark screen, pale box, one urgent question. Suddenly the page has drama.

Give the player a choice

The offer buttons share the class offers. One button uses a green background for Deal. The other uses red for No Deal.

Each button is 50 pixels wide. The text is large, white, and centered. Padding gives the words room. A margin of 3 percent separates the buttons, and display: inline-block lets them sit side by side.

The hover state can soften the text color and adjust the font weight. The pointer cursor returns here too. These small changes help the buttons read as choices, not labels.

A close button belongs near the right side of the modal. It uses a large font, often 3em, and bold text. Its color changes on hover, ending in red. The text decoration is removed, and the cursor signals that the symbol can be clicked.

The close control does not need a long explanation. A large X has been doing this job since the web was young.

A clean order saves time

The styling order matters because each layer supports the next:

1. Style the start button.
2. Center the game area.
3. Add borders and float the columns.
4. Set the main area size.
5. Build the modal background and content.
6. Style Deal and No Deal.
7. Finish the close button.

Visible borders and backgrounds make layout errors easy to spot. Percentage widths help with centering. z-index keeps the modal above the game. Hidden displays keep unfinished panels from appearing at the wrong time.

Later, JavaScript can show a modal, fill its body, and respond to clicks. The first lesson is smaller, but it reaches the important point: game logic and page structure can meet through the DOM.

You can now sort the Deal Game’s values, prepare its offers, wait for the page to load, and build the screen that holds its first choice. The game has not made a deal yet. It has something better for now: a clear place to begin.

That is the kind of small browser discovery The Continue Screen is made for, where a simple choice, a bright button, and a slightly odd old layout still have room to surprise.