Creating an Interactive Number-Guessing Game With HTML, CSS and JavaScript (Part 1)

Less than two weeks ago I claimed on the homepage of this very Web site to have made a promise to myself to keep this blog up-to-date with weekly posts. As I didn’t get around to posting anything last week, it transpires it took me only a few days to break this promise. For this appalling inconstancy, you may rest assured that I’m not letting myself off lightly: Much to my chagrin I’ve been giving myself the silent treatment all week.

The only defense I can offer in my, uh, defense, is that I’ve been as busy as the proverbial bee. To continue the apicultural metaphor, you might even say my home office has been a hive of activity. Bad punning aside, what I’ve mainly been up to for the last several days is working on a coding test for a potential employer. Since I’ve been off work for a couple of months it was nice to get my teeth into a coding project again, so nice in fact that I’ve decided to make it the subject of this very post! In recompense for last week’s lapse, I promise to make it doubly good!

So what was this coding test all about? Well, it involved writing a program for an interactive game that gives the player 10 attempts to guess a “secret” number between 1 and 100. (If you’d prefer to play the game than read about its development, the fruits of my labor can be found on jsFiddle.) The specific requirements for the game were as follows:

• The secret number should be known only to the program.
• If the player succeeds in guessing the secret number before they’ve used up their attempts, they should be informed that they’ve won the game.
• If the player fails in guessing the secret number before they’ve used up their attempts, they should be inform that they’ve lost the game.
• The player should be informed of whether a specific guess is higher or lower than the secret number.
• The player should be given the option of customizing the number of guesses they’re allowed.
• At game’s end, the player should be given the option of replaying the game.
• The programmer should make some attempt at styling the program’s user interface.

The language in which the program would be written was left to the programmer to decide. As such I had little hesitation in choosing JavaScript as the language I would use. I’ve been doing a lot of work with JS over the last year or two, and it’s the language I know best. I’ve also been doing a lot of work with JS libraries such as jQuery and jQuery Tools, and I was confident they would come in handy for the client-side scripting and UI components the program would require.

With this linguistic decision made, I turned my attention to the user interface. I wasn’t particularly concerned with the exact look-and-feel of the UI at this stage, but I thought it wise to devote some attention to the UI screens the requirements of the program would necessitate. I eventually determined that five separate screens would be required:

1. A screen for the actual game interface.
2. A “splash” screen from which the player could choose to either play the game or adjust its settings, i.e., the number of guesses the player is allowed.
3. The settings screen itself. This screen would list the specific options for the number of guesses the player is allowed and would allow the player to confirm or cancel their selection.
4. A screen that would appear upon the player’s winning the game. From this screen the player could choose to either replay the game (with the same settings) or return to the splash screen.
5. A screen that would appear upon the player’s losing the game. This screen would give the player the same set of options as screen no. 4.

The following diagram depicts these five screens. Note that the hash-mark-prefixed names correspond to the IDs of the HTML elements I would go on to create for each screen, while the inner rectangles correspond to the buttons with which the player would need to interact in order to exit a particular screen. The screen’s window type (modal or main) is indicated in parentheses. Basically I decided that screen nos. 2 thru 5 should be represented by modal dialogs and that screen no. 1—the actual game interface—should occupy the main window.

With this broad overview of the UI in mind, my next step was to form an idea of the actual game screen. I initially thought a drop-down menu would be a nice way of presenting the hundred different number choices to the player. However the multiple clicks that this would require of the player finally struck me as being awkward. I eventually decided that a tabular, or tiled, format would make for a more usable arrangement. Recall that the program requirements also called for a means of indicating to the player whether a specific guess was lower or higher than the secret number. I decided it would be convenient to place this information, along with some other data I deemed might be useful to the player, in a series of “gauges” that would appear above the numbered tiles. The following diagram depicts the layout I decided on:

The content for the other screens was a simpler matter. I decided that the splash screen would list the game’s features; the settings screen would list the options for the number of guesses the player was allowed to take; and the win and lose screens would output the secret number along with a message informing the player of whether they had won or lost the game.

With these high-level concerns addressed, I was now free to set about writing the application logic: a fitting subject, methinks, for my next blog post.