Hasbro's Simon reconstructed with MSP430s and multiplayer capability
Simon the interactive children’s game is a timeless memory challenge for all ages. The game consists of a randomly generated pattern that increases by one each turn. In the original game the ever-increasing pattern would be played back to the player by flashing lights and corresponding sounds. Then the player would attempt to play back the pattern by pressing button, which would light up a corresponding LED and play the respective sound as well. The goal of our project was to not only create this game using MSP430s, but also to add another game mode on top of the pre-existing game. The mode added would implement a multiplayer mode. The goal of multiplayer mode was to have two separate individuals both creating their own color patterns in which the other person would have to try their best to memorize and playback. Now this classic game would have a functioning single player mode as well as a functioning more competitive multiplayer mode.
Next, let’s talk about how we did it. Single player mode requires less hardware than multiplayer mode, so we can introduce that first. For the fully functioning game we needed to procure a MSP430, a XBEE, and a custom made PCB board. The MSP430 is the microcontroller that we can use to load the program or functionality of the game onto. The design of this game would use up pretty much every pin found on the board. The only pins left unused on the board were the XIN and XOUT pins. The P1 pins were utilizes for status LEDs, UART, and game mode buttons. The P2 pins were used for the buttons that correspond with the colored LEDs. With some clever circuitry we were able to allow these four pins to control the 4 color buttons along with the 4 different colored LEDs. The main source of power we used was power from a local computer via USB, which would supply a steady flow of ~3.5 Volts. We attempted to make the main source of power just a battery source but we ran into some difficulties with the time we had allotted ourselves at the end of the project. We assume that the battery packs were simply just not supplying enough power because when measured it was only outputting about 3V, which may have fallen a little short of the necessary voltage.
The next piece of hardware that added a nice touch to the appearance of the game was the PCB board. The PCB board would act as a shield to the MSP430 and could be used to implement a circuit that would otherwise look quite messy and convoluted in a simple and understandable way. Deciding that we were going to implement a PCB board meant we were going to have to start early and were very likely going to have to do a lot of debugging in the last few days before the due date. Knowing this, the PCB board was designed and ordered as soon as it could possibly be done, however we couldn’t be too hasty with the PCB design because a flaw in the design could prove to be a fatal error come the final assembly of the project.
Multiplayer mode would implement the last piece of hardware that could be found on our design. This last piece of hardware is the XBEE. We used this for wireless communication via Bluetooth. The mode of transfer that we used on the MSP430 was UART. Unlike previous times we had used UART the XBEEs believe it or not actually made things a little easier when it came to transferring over data. For example, normally when using UART one has to cross the RX and TX lines to ensure that the transfer line of one MSP430 would be going to the receive port of the other MSP430, however the XBEE does this for you with its built in DIN and DOUT pins (Data out and Data in).
Multiplayer mode was much like single player mode in reference to the state machine developed to control the game. To enter multiplayer mode you simply have both controllers press the multiplayer button and then one of the microcontrollers is specifically the starter while the other will go second. The microcontroller that goes first simply just presses one of the colored buttons and the game is now underway. Now the opposing player should receive that signal and have to play it back. If the aforementioned step is done correctly that player will now get their chance to create the start of their pattern. This will continue until one of the two players inadvertently makes a mistake, in which case the game will alarm both player that the game is over and can then be reset for the next game whether it be a single or a multiplayer game.
The code itself for the MSP430 one can find to be fairly readable and easy to follow. The program starts by setting pins to specific buttons, leds, etc. Next, is the main function that is used to set up all the settings of the game. For example, one can find initialization functions for P1 ports, P2 ports, and UART. The Watchdog is also set up as well as a random array of 40 values for one player mode. The portion of the code where all the “magic” happens is located pretty much all within the WDT interrupt. The idea was to set up a state machine for the game and have the WDT set interrupts for very fast intervals to create seamless gameplay. Based on the current state that would be stored in a global variable the program could continue within a state or move on to the next. In general the order of the states would go from gameplay mode to pattern playback to pattern polling and verification; this would loop back to pattern playback or to the end game state if someone made a mistake. A diagram of our state machine can be found below for easier understanding.
Additionally, it might be a good idea to implement more modes, which we could implement by pressing two buttons at once: reverse mode (player has to repeat the pattern in reverse) and reverse multiplayer mode (same principle but in multiplayer). We may be able to do this by changing the state in which we poll for button presses. If “reverse” flag is set, the player must traverse the array backwards.