arduino & interaction

Continuing from the previous post, I will be exploring the first method of input for the Aplysia game project. Explorations with Arduino microcontrollers, open license C++ code and an array of components led to the first, very primitive prototype of the game controller. The advantage of using only electronics versus a game engine and outsourced camera controllers (Kinect or webcam) was the simplicity in the approach – no plugins or assets were needed to construct a playable demo.

Arduino with activating button, buzzer that plays melody and LED to signal button interaction.

An ultrasonic sensor was centric to the creation of the first method prototype, and additionally a piezoelectric buzzer, LED and button for relaying information and allowing starting and stopping game sessions. It felt necessary to start with the most rudimentary components and work upwards to a more complex system, with the first being an LED blinker activated via button press. Lionel suggested searching through the Arduino references for code I could use. With my limited knowledge of C++, I adapted the Blink and Button example code into one to achieve this small test. Afterwards, I researched into including the piezo buzzer to emit a single tone or music, which was made possible with the Melody code being included in the existing Arduino code.

And, of course, I recreated the melody of Megalovania.

Initial struggles with having multiple functions run in parallel to one another caused concern that some game logic, for instance having an LED blink as a sensor checks for motion, might not be possible. This was the first hurdle to get over in the project, to allow for the inclusion of any more complex logic. Thankfully, using a while() loop in the code would allow for functions to only happen when specified criteria was fulfilled. An ultrasonic sensor was attached to the Arduino; resources that explain exactly how to attach and implement the component helped greatly here. The issue with game logic was solved. An ultrasonic sensor was given to me by Lionel during an earlier discussion for the project. I consider this to be the most viable form of input for motion detection due to being able to read a distance value from the component, allowing for more interesting input applications (simulating petting a dog using hand gestures from the component, creating a piezo theremin, a stepper LED that blinks in intervals based on distance).

A while() loop was used to light the LED on the breadboard once the ultrasonic sensor detected an object in its range.

With a rudimentary system built, a scoring system was implemented to the code. A ‘GAMESCORE’ integer is incremented by one for each swipe within 20cm of the sensor component. Later, this will be expanded to include decrementing the score variable if a secondary LED lights instead, if not using an inverse-parallel LED with a reversed current to provide a different light color. This may be the most cost-effective angle when producing multiple iterations of the same system to create the finalized prototype. Green/red inverse-parallel LEDs are conveniently the most common type and therefore the cheapest to purchase from electronics retailers. Three rings of LEDs will be placed within each other to make up one disc’s phases (spawning phase, middle phase and exiting phase).

Each finalized disc system will include:

• Connections to the Arduino Uno microcontroller
• A ring of LED (two varying colors together or a singular inverse-parallel diode)
• Resistors for these LEDs
• An ultrasonic sensor to detect swiping motion from a set range
• A switch or button to trigger the start of a game session
• Piezo buzzer for debugging and relaying information such as having the player lose a ‘life’ during play

Arduino Uno with sensor and LED to signal sensor interaction.

Arduino Uno with activating button, sensor and LED to signal sensor interaction.

Going forward, this system will be completed and repeated to create a 2m tall 9:16 gameboard for the first prototype method. The importance of components used in electronics is vital to the quality of the game experience and must be considered when working with microcontrollers versus game engines, in which much more room is allowed for interpretation of gameplay concepts through either pre-existing scripts or complex but easy to implement game logic.

The next post will explore and discuss the process in creating this final prototype and the beginnings of the game engine method using Unity.