akaylyn / simon

Simon v2 Overview

The general relationship between the four micro-controllers is:

Light <= Console <=> Tower, Music

That is, Console has a unidirectional relationship with Light (I/O pins), and bidirectional relationships with Tower (radio) and Music (serial).

Microcontrollers

• Light

  • Arduino Pro Mini controlling WS2812 RGB pixel strips to light rim and buttons on the console.
  • Has 4x GPIO pin connection via Console(Light).

• Tower

  • JeeNode controlling tower lights and fire.
  • Has RFB12b connection for two-way communication via Console(Tower).

• Music

  • Arduino Pro Mini controlling VS1053 music breakout.
  • Has Serial connection for two-way communication via Console(Sound).

• Console

  • Arduino Mega controlling the Simon implementation.
  • Arranged around submodules mirroring the outboard micro-controllers and internal functions:
  • Button: Responsible for hard buttons on a PCB. Used for debugging purposes.
  • Extern: Responsible for interfacing with other projects via RFM12b (currently: Clouds, Giles).
  • Gameplay: Responsible for Simon implementation as a Finite State Machine.
  • Touch: Responsible for UX input via MPR121 capsense breakout.
  • Light: Responsible for UX (light) output local to the console. Coordinates outboard Light.
  • Tower: Responsible for UX (light/fire) output to Towers. Coordinates outboard Tower.
  • Music: Responsible for UX (sound) output. Coordinates outboard Music.

simon's Issues

Light, sound and fire: Playing

While the game is playing, we don't want the light, sound and fire going to be (very) distracting from game play. Maybe kick off a quiet "score"/"soundtrack"/"jam" in the background. Maybe kick out a little fire when a player reaches each "skill level" threshold?

System configuration on-the-fly

At some point, we'll identify system tuning parameters that we'd like to adjust while the system is running, without requiring that we recompile and upload code. Let's use this Issue to track what parameters we want to expose, as we learn them.

Light, sound and fire: Game Start

Game start should be punctuated with a short production of light, sound and fire, giving the player the sense that "it's on like Donkey Kong".

Light, sound and fire: Game Ends

At the end of the game, we should have a pretty elaborate light, sound and fire production. Presumably, in proportion to how well the player did (see Skill Level Issue).

Difficulty levels

The original Simon game features 4 play levels which increased the sequence length required to "win". When you "won", the game would just beep. Additionally, the game required that you set the difficulty level before game start, which is kind of fiddly in-real-life. I think we can do better than that!

When the game concludes, check the correct sequence length (int currentLength) and compare to a table. Produce sound, light and fire proportional to achievement level.

Target: Console / Gamplay.cpp / idleState() and playerFanfare()

Cards:

• https://trello.com/c/3wdnI1h8/1-win-animations-with-fire-and-sound
• https://trello.com/c/6j75196y/4-difficulty-levels

Light, sound and fire: System Idle

After some interval of nobody playing, the project should kick out a light, sound and fire production that's designed to entertain folks standing around, and to draw people in that are in line-of-sight. "Kiosk mode" or "attractant mode".

touch sensors stick

During gameplay and bongo mode, the touch sensors have started registering a button press without a release.