The Simon Game. An iconic piece of 1970s and 1980s pop culture. I remember growing up in the 80s and seeing the commercial for one of these hand held devices, though my parents never actually bought me one. The Simon Game is simply a memorization game where a player follows a sequence of lights and sounds.
The rules are simple: The device plays a sequence and you repeat it by tapping the colored buttons. If you fail to repeat the sequence, the game would replay the sequence and give you another chance.
There’s also a “strict” mode where the player has just one chance to match the sequence. If the player fails to repeat the sequence, the game will restart back at level 1.
The game has 20 total moves, progressing faster as you advance through the sequences.
Where to start?
I won’t get into any details about the HTML or CSS behind the game. All the images, colors, animations and design is entirely done in CSS.
If you’re curious about how I structured some of my HTML or CSS, you can check out my code here.
The game’s primary functions will require:
- 20 random moves for the computer’s sequence.
- A way to track the player’s moves.
- Some sort of check to see if the player’s sequence matches the computer’s sequence.
- Create a “strict” mode to restart at level 1 when the player fails to match on the first attempt.
The game will begin with a “new game” configuration. All the configurations are assigned to individual variables, including the sound bites, speed of the game, level and with the game powered off.
Empty arrays are used to track the sequences for the computer and the player. In this game, I chose to have two arrays for the computer and one for the player. The first computer array will have a set of 20 random moves generated at the start of the game. The second computer array will receive one move at a time, allowing the game to advance across 20 levels while being able to track and check the sequences against the player’s sequences.
Note: You could also use objects in place of the variables to organize the different game settings as well. All the game settings can be defined using JSON dot or bracket notation.
To make this game more modular, I decided to create multiple, smaller functions that would interact with each other through out the game.
While the functions aren’t the exact textbook definition of functional programming, I think it’s close enough to my needs to make the game’s code accessible and easy to edit.
By creating smaller function modules, I can organize each function to address one set of tasks to complete as you play through the game.
I can also call on only the functions I need during the game play, only when I need them. Having smaller, modular code is a lot easier to debug in my opinion. If something’s broken, or doesn’t behave as predicted, I can trace back the issue and locate it among a small function rather than search the entire file of code.
Just keep in mind that sometimes your projects can span hundreds, or thousands of lines of code. Make your life easy by planning and organizing your code ahead of time.
Here’s an example of creating some individual, smaller functions for tracking the sequence’s speed:
The counter keeps track as to what level the player is currently on. Based on the level, if it’s above level 4, level 8 or level 12, the corresponding speed of the lights and sounds will increase. A setTimeout is being used here to “turn on” and “turn off” the lights on the colored buttons, via a CSS class styling.
Tracking the sequence…
To track the sequence for both the computer and the player, I chose to generate numbers between 1 and 4. Each number would correspond with a particular color and sound.
The player’s sequence is also generating a number between 1 and 4. This allows easy comparison between the computer’s sequence and the player’s sequence because the values are the same type and values.
Once all these smaller functions and variables have been set up, I was ready to tie the game up into one large function.
In my project, I chose to organize the variables and functions in order of declared first, then called later. I figure this would be great practice so I wouldn’t get sloppy when working with similar logic in other programming languages.
The Hardest Problem to Solve…
While completing the game’s final logic, I was stumped with a pretty vital piece of the game’s flow. I could not seem to figure out the best way to check the player’s sequence against the computer’s sequence.
What do I mean?
Well, if a player were to input their sequence, how would I be able to check if the user is done inputting their sequence before the game can check it?
At first I thought I could use a timer to allow a timeout of some sort. While this is technically feasible, I could multiply the length of time allowed for a player to input their sequence as the levels advance.
I then realize this is a silly method because it would slow the game play and experience down if the player were to input sequences faster than the allowed time.
I won’t lie that I did struggle with this piece of logic for a day or so.
It wasn’t until I was sitting at a red light with my girlfriend that I stumbled on the solution!
The solution wasn’t necessarily simpler in any way. It was just different from how I initially interpreted a possible solution.
In order to check the sequence, all I had to do was check each move based on its indices. If each move in the player’s array and each move in the computer’s array was the same, then there was a second check to run.
The second check would simply check to see if length of the player’s moves array was the same length as the computer’s moves array.
In other words, if the computer played 12 moves, did the player complete 12 moves too?
If the player did not, then the sequence would not progress forward. It would simply wait until the number of moves is matched.
Once that logic was completed, the rest of the game’s logic was easy to complete. Just simply advance each level, speed up the game’s lights and sounds as the player advances and then check for a win or lose scenario once 20 levels are up!
This project is one that I am really proud of completing. I went about building this game from start to finish in just 5 days of non-stop coding and tinkering. Initially, I was doubtful if this was something I was capable of completing as it seemed really complex. I decided to challenge myself by planning and structuring out my game and it’s logic on paper and building the necessary components (or functions!) to make this game work. Anything I couldn’t figure out immediately, I chose to experiment various ideas on it until it worked.
In the end, having a fully working Simon game allowed me to achieve two things: 1) I finally have my own Simon game to play with after 20+ years. 2) I manage to tie up a slew of front end web technologies together to build something using algorithms and some fancy CSS styling.