MP1: 2048 Controller

by Rotem Katzir and Phil Dasler

2048 Controller code on GitHub

Overview





2048_full.png
In this assignment, we created an input device for controlling the popular game 2048 without the use of keyboard. As we both wanted the ‘main’ component of the device to be something that neither of us had used in IA2, we decided to use tilt sensors, enabling us to play the game in an intuitive way. Given that the basic movements in the game cause the tiles to all slide as if pulled by gravity, we felt that a tilting controller would give the player some sense of physical connection to the game in a way that pressing keys on a keyboard could not. Additionally, we wanted to package our controller in a more thematic way rather than as bare wires and circuitry or a plain project enclosure. Being Computer Scientists and seeing as how the game is based on numbers and calculation, we chose to build our controller into a calculator.

The controller uses a pair of tilt switches mounted at a right angle to each other. These switches detect a tilt in two directions along a single axis. If tilted more than 45 degrees, the switch is closed between the middle pin and the pin of the respective direction (the switches have three pins in all). The center pins are both tied to 5v and the outer pins are each tied to ground via a 10k Ohm pull-down resistor and to a digital input pin on the Arduino.

The Arduino reads the values of the tilt switches and then makes a state-based determination as to what output to provide. It cannot simply output moves directly correlated to the sensor values because, for one, this could lead to nonsensical moves such as simultaneously pressing UP and LEFT (these values are read by different tilt switches and could be read concurrently). Second, mechanically switches generally suffer from bounce issues. Bounce occurs when the contacts in a mechanical switch literally bounce off of each other as the switch is being closed. This happens in an extremely short time period, but the Arduino runs quickly enough to detect it and would read the input as though the switch were being opened and closed several times in quick succession. Directly outputing this would lead to making multiple moves in the chosen direction when the intention is to only make one.
2015-02-11 23.15.00.jpg
The solution, then, is to implement debounce measures in the software to filter out these spurious readings. First, a counter is kept for each direction, tracking the number of consecutive cycles in which the associated input is HIGH. After some target value is reached, the system state changes to being in that direction and a single keyboard command is sent. A tunable constant is used to determine how many consecutive readings are necessary in order to change states as finding the correct amount is a bit of an art. Too low of a value and the debounce measures are not very effective. Too high of a value leads to a noticeable delay between when the user tilts the controller and when the move is transmitted to the game.

Our original concept for debounce was a buffer that kept track of some number of sensor values. The size of the buffer was tunable just as the counters above. When prototyping with a single tilt switch, we discovered that a size of 800 data points was reasonable. Unfortunately, adding the second tilt switch (and thus a second buffer) caused the Pro Micro to "brick". While its indicator lights were still on, computers no longer recognized it when plugged into a USB port and it was impossible to program. Luckily, it's possible to reset the Pro Micro by shorting its reset pin to ground twice (there is no reset button) and quickly connect to it while the boot loader is running (you only have 8 seconds to do this!).

After further testing, it seems that adding the second buffer caused some sort of memory issue. By reducing the buffer size to 400 we could program the Pro Micro without fear of bricking it again. Unfortunately, this was too small of a value to effectively debounce the inputs, hence our move to the counter based solution.

Other Uses:
While our controller was designed with ‘2048’ in mind, it can of-course be used for other purposes as well. Other games that use the arrow keys such as tetris or rhythm games (e.g. Flash Flash Revolution) are a natural use, but with only minor changes to the programming any system that requires only four different keys to control can be controlled with the calculator.

Materials and Parts

Part
Describe the Part's Role In Your Project
Count
Cost
Total Cost
Pro Micro
The main brains of our project that interfaces the sensors with our computer and performs some simple onboard signal processing.
1
$19.95
$19.95
Micro USB cable
Used to communicate from the controller to the computer.
1
$4.79
$4.79
Tilt Switch
Used to sense tilting of controller.
2
$1.25
$3
Calculator
Gutted and used as a case for the project.
1
$8.99
$8.99
10k Ohm Resistor
Used as pull-down resistors for the tilt switch inputs
4
$1.19
$4.76
Perfboard
Soldered tilt switches to as a breadboard would not have fit in the calculator
0.5
~$2
$1
Hookup wires


~$3
$3



Total
Cost:
$45.49

2048_parts.png


Schematic
Due to some missing parts in Fritzing (the tool used to generate this schematic), the diagram below is not 100% accurate. While different parts are used as proxies, the wiring and conceptual design are accurate. The SparkFun Pro Micro has been replaced by an Arduino Micro and the tilt switches are represented by simple sliding switches. See above for complete (and accurate!) part list.

2048 Controller.png

Challenges

2015-02-11 23.26.57.jpg
Our first difficulty was, of-course, in coming up with idea that we both liked and thought was innovative and cool. Our ideas included, among others, a musical instrument concept by Rotem and an ASL interpreting glove by Philip. Concerns were had regarding how innovative or achievable our various ideas were and we finally settled on the idea described above. The original concept, however, had a little more to it.

First, it seemed much more compelling to have the calculator be a stand alone device rather than having it tethered to the laptop via a USB cable. Despite many great tutorials, forums, etc., we were unable to get a BlueSMiRF Bluetooth board to actually connect to anything.

We also tried to use an XBee module and RedBearLab's Blend Micro, a combination Arduino-compatible board and Bluetooth. Given the space constraints of our calculator, however, neither of these actually fit into our case.

Future Work Ideas

We had hoped to actually use the calculator's original display to show the player's score. In addition to being neat, we felt that this would help solidify the connection between the device and the game in the player's mind. This, however, would require that we leave much of the calculators internal circuitry intact, and there simply wasn't enough room to do that as well as put our custom electronics in. A bigger calculator may have fixed this, but at that size one would likely need a graphing calculator, which has a more a complicated screen and is significantly more expensive.