Unimodal Interaction with Arduino
This was one of the most difficult challenges to overcome during development. The project brief called for using only one type of interaction with the audience, whether it was a camera, accelerometer, or a single type of sensor. I wanted something that was both tangible and responsive, so I decided to create my interaction type using potentiometers connected to an Arduino that passed their data over serial communication.
The game can be played entirely with only those inputs, which led to an interesting challenge. How could I let the player start/restart the game? Most games ask the player to “Press Start” to play, but given that my player would only have access to the two dials, I needed to have a way for the player to start.
To do so, I created a square button in the center of the title screen in-game that says “Start” and indicate via text to the player that they need to match the shape to play. To match the shape, the player will need to learn that they can move their “player” using the left dial to the center of the screen, and also change the shape to a square by adjusting the right dial.
Although it is unlikely that the dials will be left in this exact position during play, a failsafe was also implemented in the form of a countdown to start the game, so as to ensure that the player doesn’t just start the game accidentally without realizing how they did it.
Serial Communication
When I originally started development, I didn’t have an idea for how exactly players would interact with the game. I knew that I would need to send data over serial between the game and the Arduino, although I needed to decide how I was going to do that.
My original prototypes were for a wireless controller (rather than an arcade cabinet). I had two ideas, one that could “stretch” to allow players to grow or shrink shapes, and the other was to use volume dials to make a Sony Walkman type controller (also very 1980s). Both would communicate wirelessly using serial over bluetooth. I used an HC-06 Bluetooth module for Arduino to perform my initial tests. And while they worked, they did not work very well. There appeared to be enough lag while using bluetooth 2.0 that it was making the game less fun than when communicating over USB. Both methods both suffered from occasional bad data (where the shape would jump around the screen or randomly change its number of sides)
The lag issue was solved when I decided to make the arcade cabinet, and therefore communicate over USB (because the cable would be connected for power as well). However, I still needed to solve the unstable data issue as well.
By inspecting the console, I found that while I was only sending two numbers (one for the player position and one for the number of sides), they would occasionally flip. This appears to occur when only one of the messages makes it through the serial communication process and the other byte is lost. To fix this, I did two things: I utilized a smoothing function (where the averages of sensor data are compared to remove any outliers) and I implemented a check byte. What this means is that when I sent over information from the Arduino, the first byte of every complete package was meant to be 255 (a value that the potentiometer readings were mapped to ensure they would never reach). Shape Arcade would then check to make sure that the first number of every sequence of messages from the Arduino was, in fact, 255. If it was, it indicated that the data was okay, and if not it would break and read the next set. With how fast the data is being sent by default over serial, this fixed the issue while remaining responsive during play.
Matthew Deline 