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.

Debugging FireFly Output

We wanted to see the output of the FireFly's GPIO pins which transmit the player's actions. Here, the pins are hooked up to LED's so we can see what is being transmitted. We fixed the bugs and now the FireFly can send the correct data through the pins.

Inverters added

The 3-to-8 decoders (74F138) invert the outputs, which works for the bottom low bits (0:2) going to each Monome board, since we want all high and one low to power a specific row.

However, the higher bits(3:5) going to each Monome needs to have noninverted inputs, so inverters need to be attached to the output of the decoders going to the high bits.

Hence, we will be using the SN74LS02 NOR gates to invert the output of the decoders.

Hardware Configuration

Here is an example map we will be using on our Monomes:




Here is the general hardware setup we will be using:

Project Overview: Bomberman x Monomes

Motivation:

To create an interactive game using accelerometer and wireless communication with a simple display

Goal:

For this project, we propose the creation of a wireless, multi-player clone of Bomberman using 4 8x8 monome boards.

Methodology:

The LEDs for our monome are only a single color, so different objects will be represented by different shapes.

Unlit = Empty path

Solid Units = Wall/block/player

Input:

Movement = tilting the box, direction based on accelerometer data

Bombing = press any of the buttons of the monome

Networking:

There will be one “Master” box and 2-4 “Player” boxes. The “Master” box will be the box running the game and will be the one to which all the “Player” boxes synchronize to. The “Master” box will continually broadcast the state of the game while the “Player” boxes will report back to the “Master” on what each player’s actions are.

An alternative approach would be to have the first box also be the “Master” for the game and all other boxes communicate with that box. This, however, will lead to more complicated logic and the issue of the “Master” box also being a “Player” box.

Game logic:

Players will start off at opposing corners of the board. They destroy blocks by dropping bombs that explode after a set number of seconds (e.g. 3 seconds). As blocks are destroyed, players can move over the blocks. The objective of the game is to eventually make way to other players and strategically time and place bombs such that these bombs will explode with the other player in the explosion path.

Additional logic:

Walls: Some of the blocks will be non-destructive walls. In the basic level of Bomberman, these walls make up a grid pattern. This will probably be used here.

Power ups: In Bomberman, powerups may drop from blocks. The bomb powerup allows you to drop more bombs, each with independent countdown timers. The firepower powerup increases the explosion path of the bomb.

Project Components:

Monome: The monome will be the game’s main display interface.

HCS12: The monomes will be controlled and powered by a Freescale HCS12 microcontroller.


Firefly: The FireFly nodes will be used as controllers for their accelerometer sensor

and wireless antenna.


Enclosure: Holds all the components, probably cardboard or possibly acrylic


Testing and Evaluation:

Playability – Does the game work as intended and expected.

Responsiveness – Does the game run fast enough and is it real-time.

Deliverables:

Bomberman game implemented with 2.

Extra Credit:

Bomberman game with 4 controllers, which would have slower response time.

Overall Timeline: (in weeks) Approximately 4 weeks, to be completely by December 12, 2011