Lessons from Pattycake

For our first Costume assignment, we were asked to create a game with the Flora and conductive fabric (made of copper). My teammate, Abhishek, and I decided to make a pattycake game with gloves as controllers. (It turns out a lot of other people in the class also made glove controllers. It figures, since we are most familiar with using our hands to interact with and control our environment.)

We connected each pair of hands as a switch that would produce digital inputs into the Flora, so we can differentiate between one switch on (one pair of hands in contact) or both switches are on (both pairs of hands in contact). The inputs are categorized as three states: no contact (1), one switch on (2), and both switches on (3). Then this information is fed into Processing through port communication to match with instruction patterns we created.

Sketch of different contacts.  Schematic of the two switches with help from Benedetta.

Sketch of different contacts. Schematic with help from Benedetta.

Gloves are switches.

Gloves are switches.

For the screen interface, we designed five patterns based on the five different types of contact. They alternate between each other randomly on screen to instruct the player which hands should contact, similar to how arrows work in Dance Dance Revolution.

Five patterns for the different types of contacts.

Five patterns for the different types of contacts.

Playing pattycake (fast forwarded)

Playing pattycake (fast forwarded)

Takeaways:

  • It’s really hard for more than one players to take instructions, even just a little bit complicated, on the screen and coordinate physically with each other based on those instructions. DDR works because arrows are very simple signals and the player is only interacting with another player through coordinated instructions on the screen: each player is really only focused on his/her task instead of having to physically coordinate with another player.
  • It would be more appropriate for a multiplayer game, where each player need to collaborate physically, to either have the instructions embedded in the wearable controllers or provide on screen visual feedback instead of instructions that the players would have to follow.
  • Audio (sound effects) and costumes can add more to the experience of a game.

Technical issues:

  • We had a really hard time getting data from Flora to transfer over to Processing. We got it to work in the end by changing strings to integers and 0s to 1s in the Adafruit Arduino IDE, but the solutions still seem very arbitrary to me.
  • We had originally wanted to differentiate between different types of one switch on (meaning one pair of hands in contact). For example, a player’s own hands touching would be different from the right hand of each of the players touching. This was impossible to accomplish with the two switches connection we created, because since one hand of each player is connected to the ground the signal would come from the same pin when a third hand touches either ground. We haven’t figured out an alternative circuitry.

 

 

 

 

 

 

 

Paint by Pong

**UPDATE** I updated the program so the loading time is not as long.
Move your mouse to control the paddles. Click to alter the paint’s path.


For my second ICM assignment, I was paired with Hugo to make an animated sketch. We started with implementing the classic Pong.

With Pong, the challenge for us was figuring out at what distance the ball should bounce from the paddles. We calculated the longest possible distance from the center of the ball to the center of the paddle if the ball should bounce from it, and used that value to determine whether the ball was close enough to the paddle. The issue then was to make sure that the ball actually touches the paddle when it bounces. Since the paddle is always on the same x-axis, the ball’s axis is always the same when it’s touching the paddle. So we added a check for that on top of the check for longest distance.

Calculating longest distance and shortest distance between the paddle and the ball.

Our Pong!

Our Pong!

Then Hugo and I split up to create separate versions of the Pong game. I decided to turn the ball into a paint brush and create abstract strokes with the game. My inspiration was Rafael Rozendaal’s interactive gradience shapes.

new move.com

new move.com

To draw a gradience with the ball, I saved color values into a 2D array. Then drew an ellipse with the stored color value every time the ball moved. The ellipses connected into a stoke. Below are some variations of the strokes I made with the game.

drawings

Takeaways:

  • When designing an interactive program I should really think about where and how it would be displayed and how would the participant encounter it. In this instance, I made the window way too long for the WP blog display. Also the game starts immediately after it loads, without giving the player a prompt.
  • For animated or interactive visual display type of work, it’s not very interesting when element values (e.g. the colors) are hard coded in. It would be better if the value is changing or has some randomness to it.
  • Coding for over 5 hours without a break is a very bad idea.
  • Don’t draw any elaborate elements in setup(), or the program will take forever to load.
  • If the program takes forever to load, distract the participant with something.

Questions:

  • The programs takes some time to load. How to make it faster?
  • How can I draw an ellipse over the trail of another ellipse? (how can I still show the ball in a different color over the stroke?)