SIMON 0
In this project, we kick off the development of our Simon-like pattern matching game by writing the pseudo-code for our game.
Having issues? Check out the Troubleshooting Guide.

Over the next eight projects, we're going to use buttons, LEDs and a good bit of code to build and program a pattern-matching game much like the popular toy Simon.  

If you're not familiar with Simon, let me describe how our pattern-matching game will work.  The game will start by flashing one of four LEDs at random (and will play a tone speciific to that LED).  You (the player) will then have a short amount of time to press the button associated with the LED that flashed.  If you do that successfully, the game will repeat the first LED flash and then add a second LED flash at random.  Again, you'll need to remember the pattern and press the correct buttons to replicate the pattern.  Each time you successfully enter the correct sequence, the game will replay the previous pattern and add a random new LED flash at the end.  This will continue until you incorrectly repeat the sequence -- of if you take too long between button presses -- at which point the game ends and the entire sequence is repeated back to you one last time.

Since this is a bit longer and more complex project than we've done so far, it's important to spend some time planning what the code will do and in what order.  In fact, before undertaking a big programming project, most programmers will create an "outline" for the code they are planning to write.  Just like an outline helps keep you organized when writing an essay or a paper, writing an outline for your program will help keep you organized and allow you to create a logical flow for your program before you start coding.

The way we're going to create an outline for Simon -- and the way most programmers create their outlines -- is through a common programming technique called pseudo-code.  Here's a quick overview of what pseudo-code is and how it works...


Pseudo-Code

It's common for software developers (people who program and write code) to plan to use something called "pseudo-code" when they are preparing to write their software.  Writing pseudo-code before you write software is similar to writing an outline before you write a paper or an article.  Basically, you create an outline for your code using a combination of regular English mixed with some bits of programming code.  This allows you (or others) to read the order of the code and determine if what you're getting ready to write is logical and will accomplish what you expect your code to accomplish.

Let's look at an example of pseudo-code...

Imagine you are planning to write some code that will add two numbers together.  Here is what our pseudo-code might look like:

    Ask the user to enter the first number and store that number in a variable

    Ask the user to enter the second number and store that number in a variable

    Add the two numbers together and store the result in a variable

    Display the result on the screen for the user to see

    Ask the user if they want to run the program again

    If they want to run the program again:

        Run the program again

    else:

        Stop running the program and exit

You notice that each line is easily readable as English -- with some code formatting for the if/else statement -- and overall, you now have a detailed outline that you can use as a template for your new code.  

Now, in reality, you probably wouldn't need this much detail to write a simple program like adding two numbers together.  But, for more complex software, writing the pseudo-code before you start writing the actual code can make the entire process much easier.


Now that you hopefully have a general idea of how pseudo-code works, let's talk about what the pseudo-code for our Simon game will look like.  We've found that the best way to outline a programming project is to start with big ideas and then break those ideas down into smaller and smaller pieces, until the pieces are small enough that we're comfortable starting to write our code.

For example, this is what the very high level outline for our Simon game would look like:


Import Modules and Initialize Game

Add another random LED to sequence

Play LED sequence 

Allow player to repeat sequence one button at a time 

Get the user's button press

If user enters incorrect button, end game

If user enters correct button, flash LED and play tone

If the user enters the entire sequence, go back to top and add another LED to the sequence

If the user enters the wrong sequence, play an error sequence


That's basically all our Simon game needs to do.  But, now it's time to start thinking about how this outline would actually look when written with code. You'll notice that the last two lines indicate that -- for as long as the user does something correctly -- we go back to the top of the code.  Does this sound like a concept we've already discussed?  A while: loop, perhaps?

Also, you'll notice that in the middle of the code, we're checking for the sequence of button presses from the user -- one-by-one.  This sequence of getting input and checking it would likely be a loop as well -- in this case, probably a for loop.

Let's rewrite our psedu-code above, but this time, let's add in a couple loops to make it more clear how the code will work:


Import Modules and Initialize Game

while (user enters the sequence correctly):

    Add another random LED to sequence

    Play LED sequence 

    for (each of the buttons in the sequence): 

        Get the user's button press

        If user enters incorrect button, end game

        If user enters correct button, flash LED and play tone

    If the user enters the entire sequence, go back to top and add another LED to the sequence


If the user enters the wrong sequence, play an error sequence


The pseudo-code above is still very simple to follow, but by adding in the two loops, we start to see the format for our program.

We could drill down into each piece of the pseudo-code further -- and in some future projects we'll be much more detailed -- but for our Simon-like game, we think this is enough detail to get started.  As we build up the code over the next many projects, we'll use the outline above to organize and ensure that we're doing everything that needs to be done to get the game working properly.

prev| next