Superpong

SUPERPONG, by Lucas Werthein

POSTED OCTOBER 29TH by LUCAS in ARDUINO, FABRICATION, INTERACTIVITY, PHYSICAL COMPUTING, SUPERUBER,OPENFRAMEWORKS

About a month and a half ago i was approached by SuperUber – a Brazilian based interactive design collective – to remake one of their most exciting and successful pieces: SuperPong. The installation consists of a game that mixes elements from foosball and Pong. Up to eight participants can play by walking up to the table and taking control of custom knobs that move the players. The game is simple, elegant, and minimalist and demonstrates that high resolution graphics and complex shapes are not necessary to make people laugh, cheer, high-five or hug total strangers after a match.

SOFTWARE
Initially, SuperPong was developed in 2006 on Lingo, using custom electronics and boards that at the time were not as popular as arduino. Do to that fact, the installation needed an update and SuperUber decided that it would be interesting to modernize it with a language and electronics that were up to date. The new software was written in c++ using openFrameworks. Writing the software was a pretty arduous process, although it was a simple game. When writing code for a game many variables and possibilities have to be taken into account. User experience has to be flawless or people can get frustrated with the game dynamics pretty quickly. The main challenge was finding the right electronics and making them talk to openFramewoks without any issues. This took a lot of researching and experimentation.

ROTARY ENCODERSThese babies are absolutely amazing. However, you do pay the price for having butter smooth sensors to control your players. We used Bournes’ N encoders and each one cost us 90 dollars. The encoder spits out a number which we can interpret if the value is either positive or negative. This is some great code from the Arduino guys that can help understand the process.

BUTTONSAfter i had the code for the encoders, i plugged in the buttons and was sending a buffer of 12 bytes into openFrameworks. Each byte represented a sensor. I had 4 buttons (2 reset buttons, 2 buttons to start the game) and 8 sensors (1 for each row of players: 4 on each side of the table).
DESIGN, BUILD, ELECTRONICSI have to say that this was the most stressful part of the project. The project got a little rushed because we were invited to display it at Creators Project NYC. Therefore, time i thought i had for research and design ended up not happening, which led to one of my biggest mistakes. Since i did not plan the design of the PCB board, i ended up soldering direct connections and doing things not as clean as i hoped for. If i had an extra day to only research about clean and simple design i would have had less problems in the electronics side of things. Specifically, i could have used better connectors, ribbon cables, and other sub-pins to secure better, cleaner, and more elegant connections. I had to build three boxes/ brains for the project and ended up doing it a little bit better and different each time. This is something extremely negative because you don’t want to be debugging different problems each time you build a new set. The objective is to build the first one, solve all your problems and replicate it. This avoids headaches that come from new connections, lack of security and just new problems in general. Electronics design ALWAYS has problems. Therefore, you can’t expect to make something different and not have issues. Replication is the key to success in this case. The housing for the electronics was designed in illustrator and printed on a laser cutter. Here’s a template for a box if you ever need one:

HELPI could not have done this project without Nien Lam and Shahar Zaks. Both helped me with a lot of issues i had with the code and electronics. Nian and I were stuck one night because making Arduino talk to OF is not as simple as making Arduino talk to processing. It is extremely important to remember that the only way they work together is through the handshake method. In a nutshell, OF has to be sending a byte to Arduino constantly and vice-versa for them to operate without timing issues.
Shahar on the other hand, gave me great insight on how to make my encoders run smoothly in OF. Through simple logic and 1 or 2 lines of code, he helped my encoders work like butter. This guy is a genius!
I was also able to teach my girlfriend a lot about soldering and electronics and she helped me more than anyone and probably learned more than i did during my first semester when i was a student at ITP
PHOTOGRAPHS BY: Calli Higgins
VIDEO BY: The Creator’s Project
EDITING BY: myself