*******

TAG!

Introduction
Tag! is a game played via custom wireless consoles. The game logic is just like the children’s game. Here, however, each person is represented by a dot on screen, you are green and your enemies are red, and whoever is “it” is blinking.

The electronic components are very inexpensive. Of particular interest is the screen, which is a bi-color 5x7 LED matrix (normally used for alphanumeric display), which costs only a few dollars. This project started as an exploration of the interactive possibilities of these small screens. Currently we have allowed for three players, but the project could be scaled to more.

This game has many possible applications. In this version, we imagine the consoles being integrated into chairs in the waiting rooms of a children’s hospital. They would invite casual human-human interaction in a space where it might not otherwise exist.

Implementation

Ideally, the system would be entirely contained within the game consoles. However, for this version we have centralized the game logic on a PC running Processing. The Processing application sends commands to the clients via a PIC with a RF24G radio transceiver. The clients each consist of an identical radio transceiver, a PIC for controlling the transceiver, a 5x7 bi-color display, a PIC for controlling the display, and four buttons. The clients essentially display what the Processing app tells them to and relay the state of the buttons when Processing asks for it.

The Processing Application

The first version of the processing application can be found here. It allows for players to be controlled by AI, which provided an excellent platform to tweak the timing and look of the game before it was networked. The current version is almost exactly the same except for two changes: one, the locations of the players are broadcast to the clients; two, the states of the buttons are requested and their answers processed.

The Protocol

There are three types of transmissions, each consist of 4 bytes.

1.The display transition. This consists of a header byte followed by the position and state of the three players, each represented by a byte.

[display header] [(it/not it)(x pos)(y pos)] [(it/not it)(x pos)(y pos)] [(it/not it)(x pos)(y pos)]

2. Button state request. This consists of a button request header followed by the client id.

[Button request header] [client id] [not used] [not used]

3. Button state response. This consists of a header, client id, and the on/off states of the four directional buttons.

[Button response header] [client id] [button states] [not used]

Display

I’m quite proud of the logic I used to control our bi-color dot matrix display. It uses very few lines of code, and you can specify x and y coordinates. A useful test version of the code can be found here.

Pictures

This is one of our radio transceivers.

This is the first client we built. The breadboard on the left contains the radio transceiver and its pic. The board on the right contains the pic which drives the LED display. We've mounted the display and the buttons in some foamcore for testing. It works well.

This is a pic and transceiver that we have connected to the Processing application via serial.

The PC, server, and two clients.

Conclusions

While we have constructed all the components gotten them working, at the time of this writing, we have not built enclosures for the clients. Most importantly, the buttons are not yet mounted in a container. Therefore, we have not played the game to the full extent. However, using the console against the computer is quite fun.

By the time of ITP’s spring show (May 10 and 11, 2005), we will have constructed enclosures and the public will be testing our design. I’ll update this page afterwards.