Demo video!

src code: http://beatsportable.com/static/bombernome/

Latest revision is r19 at the time of this post.

Update: Startup Screen

Startup Screen:



:)

Update: B-Mac, Buzzers

B-Mac is faster than RT-Link. Since speed and responsiveness is important for our game, we switched from the RT-Link protocol to the B-Mac protocol.

Also, we attached buzzers to the FireFly player controllers so that they buzz when bombs are placed.

What we got working:
- Bombs
- Buzzers

Task to be completed:
- Whatever embellishments we feel like

Status Update

Map/Grid display working:



THE BOMBERMAN:



What we got working:
- Monome display
- Player movement
- Buzzer
- Exterior

Tasks to be completed:
- Bombs
- Use buttons instead of light sensor as bomb trigger
- Buzzer to player controllers

Project Status

Currently, two of the Monomes are hooked up to display the map with the players correctly. The FireFly is able to communicate movement to the HC12. However, there is some software issues with controlling the direction of the players.

Task 1: Get the movement directionality correct in game logic. (Philip)
Task 2: Complete wiring and possibly implement sound on HC12. (Monica)
Task 3: Output to GPIO on controllers for vibration, maybe. (Faqin)

Rewiring

We rewired the circuitry from one protoboard to two protoboards. This allows the circuits to be cleaner, more robust, and more debuggable.

Before:



After:

Multiplexer

After conversing with someone who was working with lots of LED circuits, they suggested a demultiplexer circuit using latches to remember the state of the LED's so that less ports are needed and ports inputs can be changed quickly. The reference used was:

http://www.instructables.com/id/Led-Cube-8x8x8/step8/IO-port-expansion-more-multiplexing/

However, the circuit in the HC12 triggered an Illegal BP every iteration and occasionally would not even run and gave an HI-WAVE MCU clock not detected error. We discussed among ourselves and decided that the latches would not help us anyway, since we want the LED's to be lit for the same duration, and having the earlier lit LEDs stay on until the last LED is lit and the system starts over would be bad, unless we specifically programmed in software for each latch to clear after a certain duration, which would make the software more complicated.

Hence, we decided to stay with our original circuit, due to time constraints, and have the more complicated multiplexer circuit as future possible expansion.