For our final project in this class Helen and I decided to continue bringing beloved childhood games out of the screen and into the real world. Our Chomp Monster was so incredibly successful that we wanted to see how far we could take this.
THE IDEA 💡
The idea was to make a multi-user pacman game that was combined with tag. The game was supposed to be interactive between different players. These would be communicated via a bluetooth network of microcontrollers that were going to be attached to their vests and then those same microcontrollers would communicate with the computer that would be the general controller of the game.
DESIGNING THE WEARABLE
I found that designing the wearable was by far one of the hardest projects I did at ITP. There are a lot of things to take into consideration like “will it work?” “Will it be comfortable?” “Are the components flexible enough but also durable?” But also variety, can many different people wear this thing and know how to use it? In general it made me appreciate much more the wearables that exist and we take for granted.
We decided to make vests because we needed to communicate specific things through LEDs and needed them to be highly visible. On top of that, in order to communicate the “tagging” portion of the game, we wanted to use hall-effect sensors on the back of each vest and the palm of each glove in the wearable. We also added bipolar magnets on the backs of the vests and the tips of the gloves. The idea was that each set of magnet would trigger the sensors once a player tagged another. That way we could tell the tagged player that the game was over and the other player that they won points. Combining hard and soft components was VERY tricky because we needed to keep in mind the things I mentioned earlier of how many people could use this easily and comfortably.
Adding the Neopixel LEDs to our vests.
Vest and glove.
We eventually learned that on top of adding LEDs to the vests we also needed a second set of LEDs on the gloves so that the wearer could more easily see their own state. We learned this towards the end of our tests so we hope that if we continue with the project we'll be able to do this.
Through our work process we took into consideration different components like reed switches, pressure sensors, piezoelectric sensors and conductive fabric.
Here are some images from our process of trying different things:
Testing sensors.
Testing piezoelectric sensors. Not as great as we expected but was considered as an option.
Testing pressure sensors. We thought these would be the easiest to trigger by players but with tests it became evident that the force needed to activate one of this size was too much and would result in players basically punching each other in the back. This made this sensor unusable in a wearable like this.
Test of hall effect sensors. These seemed to be the most reliable and fast of the bunch.
Testing conductive fabric. There was some delay here and we also couldn't figure out hw to trigger our second response for the player that wins points.
Many of these presented other issues like they were too fragile, too slow or needed extra components added in order to work which made it less practical so we went with the one that presented the best results in the end, the hall-effect.
Circuit made with Arduino Nano Iot 33
CREATION OF THE NETWORK
We decided to use a Bluetooth Network to connect our devices because we consulted with several teachers and were told this would be the most effective for what we wanted. We attempted to connect the BLE API to a P5 sketch that would go through the phases of the game and communicate these to our wearables. This would combine effectively our graphics with our code and sorting of our Game States.
P5 Sketch Screenshots:
Connection:
Up until this point the idea was a great one and successful, the vest and the interface were already figured out and in the end we only needed to build the network to make the communication between the two of them.
Originally we wanted our game to be played in a large area to make it more interesting and we had thought that WiFi would be best for that implementation until we consulted with our teachers and decided on the BLE and P5 combo because we strongly believe that this was a more simple and low consumption network.
As we can see in the graphic above, we set up a network that works in a Peripheral-Central configuration, working as a Slave-Master for BLE, which created the necessity to make a Mesh BLE Network with communication to a Web Browser. Later we discovered that the API created for P5 was not able to manage a Point-Multipoint network in just one device. This API was not designed for more than three characteristics in one device. Here is the link of the API employed.
One of the issues that we found in working in BLE networks in a large area was that in the ITP floor there is an average of 200 Bluetooth devices that even though they weren't connected to our small network, generated a kind of strange interference. After 7:00 P.M there were almost 100 students working on the floor and our network would stop working or become unstable. We discovered that this was going to be a major issue with our project due to the fact that nowadays each person carry their own PAN (Personal Area Network), thay always have Bluetooth headphones, mouse, smartwatches, etc. and with as many students as we have there would always be interference.
With this we learned a lesson that we first need to research our area of application before coming up with ideas to implement a platform.
FINAL DEVELOPMENT:
In the end we got as far as this test. Our sensors work but, ideally, we would like to have the delay be less than what we have and successfully connect our network to have a playable game. We might want to pick up this project later on as we still believe the idea is a good one.