Metal Race Game: Motion and Motors

A recent Friday talk by Frank Lantz from the NYU Game Center about the rise of mobile and casual gaming made me suddenly unearth a memory of middle school I’d almost completely lost: the culture of writing and playing games on graphing calculators.

These games seemed to emerge suddenly a few weeks after acquiring our TI-83s in 7th grade. Though they seemed to come from nowhere, they were probably written by the class geeks. They spread amongst the students like a virulent disease. Soon, everybody had them.

The two most popular games were Drugwars — a text-based simulator for the life of a dealer — and RACE.

Demoed in the animated GIF at the top of this post (courtesy of ticalc.com’s terrific archive), RACE was a high speed game where you controlled a letter V representing a car as it hurdled down the screen between square brackets. If you failed to move left or right to stay between the brackets, you died in a cloud of asterisks.

Listening to Lantz and remembering these games, I was possessed by a strong desire to build their physical analog — to bring the simple ‘lo-bit’ aesthetic into a real world interactive game.

After some early attempts to conceptualize the logistics of a more complicated maze, I settled on doing a one-dimensional scrolling game based on RACE: your “car” would stay fixed in place along one access while the “route” scrolled by at a constant rate from right to left. You’d be able to move your car up and down to follow the various twists and turns of the route. The route and your car would both be made of metal and so if they came into contact, they would close a switch which would trigger a buzzer and other indicators of failure.

So, I had two things to learn: 1) controlling motors so that they could move in two directions as necessary; 2) transforming the rotational motion of a motor into linear motion along each access to control both the long travel of the route and the vertical range of the car.

After talking to Shahar and some other students, I decided to poke around the junk shelf. I soon found a discarded CD-ROM drive, which contained a nearly perfect motor and gear mechanism for creating the short run linear motion of the car. I followed the H-Bridge tutorial to figure out how to move this CD-ROM motor in multiple directions via the Arduino and soon I had it up and running. Here’s the motor alternating between moving up and down every 500ms:

Now, I just had to figure out how to create the longer run of horizontal motion. Back at the junk shelf, I found a printer that had a long plastic band stretched between a free-floating round pulley and a motor. After some hard and dirty labor with a screwdriver, I extracted those and set to work hooking them up to a DC motor I had handy.

With some advice from Michael I put together this very basic physical setup for connecting the motor to the band and the pulley. The pulley is just on a simple metal rod that’s hot-glued into the board. The motor is similarly jankily attached to the screwed-on pieces of wood that give it enough height off the board for its wires to run free.

Here are a couple of detailed pictures to give you a better sense of the fragility and hand-rolled aspect of the system. Here’s the motor mounted in place

a close-up of the pulley with the screw-on shaft-connectors I’m using to hold it in place

and finally an overhead view to show how poorly aligned the two sides are.

However, even with all the messiness, the system worked! Once I plugged in the motor and attached a small bit of paper to the band so its direction would become visible, you could see that the setup was mostly working as intended:

The motion is somewhat erratic despite the regularity of the sketch controlling this example (code below) because of all the slippage happening between the band and the motor/pulley. The flexibility of the hot-glued mounting of the pulley means that there’s never quite enough tension on the band, but trying to pull it away from the motor too far can increase the tension so high that the motor fails to actually have enough torque to spin the band at all. I’m sure these issues will pose difficulties going forward.

Having gotten the actual new part (the motors and their motion) working, I’m now somewhat behind on building the part I thought would be easy: the route itself (early maze-style prototype). I should have that in place in the next day or so and then will be able to start working out all of the details of how to get the route in the right place so that the car can pass smoothly through it, not to mention additional difficult details like how to get the car back to the beginning after the failed or successful completion of a run.

I’m going to be working on these problems as I continue this project into next week. In the meantime, here’s the code, as promised. It will likely get much more complicated by the time the game is playable.