Simon Says (Emily Smith)

For making this Simon says game, I worked with Patrick and Bikel. Our goal in the beginning was to simply recreate simon says, and if we were to accomplish this, then maybe add to it. We started by making the box, however this wasn’t the best decision, because once all of the things were put together it was harder to move them if something wasn’t working.

Next we wrote the code, following along with Dr. Hamid. The next step was to test it and if it worked, to alter it into the real S says game. It failed miserably, and this is the result.

Whether this is a commentary on our intelligence or not I don’t know, but we thought it was a code problem, so we spent six hours tweaking the code. This had almost no effect, and the best we could get it to do was all light up, which encouraged our thought that switching states was to blame. Now a smarter person than I might have thought to take it apart sooner, however it worked with the test code that we tried it on, so that didn’t occur to us. For the life of us we couldn’t make it work. Tired and angry we went to sleep knowing that the next day we were supposed to present it in class, and hoping we would have time to finish it.

The next morning not long before class, Patrick and I made a discovery that when the ground wire for the button pins was tilted a certain way the game would start working, at least more than it had before, but we still didn’t know why. After presenting, I decided to just start pulling it apart, and this was why.


Somehow one of the wires had become un-soldered, and, because it was in a foam core case, enough pressure was on it to sometimes keep the sides pressed together. Whenever we began pressing buttons it fell apart messing up the entire thing.

In response to this we set up all of the components on the bread board, and took the original code that we used, which yielded much nicer results.

It actually did what it was supposed to do! Seeing as it was late, we did not put this into an enclosure. Really I was just glad that it was working.

So what did we learn from this?

  1. ALWAYS start on a breadboard. They are made for a reason, and can lead to catastrophic results when forgone.
  2. Always start far ahead of time. We procrastinated way to long and because of that we didn’t finish as much as we should have. If we had started earlier, it would have left more room for mistakes, and solving those mistakes.
  3. Be patient with each other, working in groups was stressful, especially when things didn’t go right. We need to work better at division of labor, and adopt the idea of double checking work like one group said they did in class.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s