Category: Physical Computing
Fall 2016
Taught by Tom Igoe
Controllers for Pong, Part 7: Pre-Final
So I made it to 7 controllers. Which is close to 24! (Sort of.)
Each controller is fabricated with a top plate and bottom plate, offset with metal standoffs. While I typically like to protype the physical fabrication parts for each project, these are the first go-around. A number of things are not ideal including the fit of the buttons, the pointy corners, and the awkward height. Fortunately some controllers aren’t necessarily meant to be held directly, but the overall dimensioning needs to be refined.
I was able to add an additional shared controller for adjusting ball speed and advancing between practice and game play screens. The ball speed adjustment is particularly helpful once players have learned their unique controller and are looking for a challenge. It also factors in a level of collaboration versus playful sabotage as both players can adjust the ball speed yet it requires them to temporarily abandon their own controller, leaving them vulnerable.
During user testing, the majority of controllers didn’t work nor was switching between them easy so I hope tomorrow’s presentation can be “user testing 2.0” and continues to inform the development of more controllers (on my journery to 100!) There’s a lot left to develop in this project; it might be interesting to develop a set of controllers based on each class next semester. How could geospatial mapping inform a controller for pong? Or take existing objects and convert them into controllers? I have no doubt this will continue to be another side project…
Controllers for Pong, Part 6: Systems Diagram
Controllers for Pong: Part 5, The Interface
Even though my five functional controllers are barely interesting in operation, I’ve put the more adventureous ones aside temporarily. Rather, I’ve focused on the initial sequencing of game and ensuring that the physical switching between controllers happens smoothly for the user.
Below is a screen capture of the game initialization. Additionally, the console of the Processing sketch on the right shows when a new controller is identified (~ at 1:08 into the video).
Rather than use a keyboard to advance to different modes, I’d like to have a shared controller with a button for triggering game play and a knob to control ball speed.
The handshaking code to get the name of the controller and then set its behaviour is as follows:
Controllers for Pong, Part 4: Post-Playtesting
“Same” Controllers
I see games as having two forms: the idea of the game and the practiced game. In the idea of the game, all rules and tools are the same and players are differentiated by their skills. By each side using the same tools, it is an attempt to equalize play. However, this is a falsehood as it this presumes that all bodies are the “same” and competition is determined by skill alone. In practice, we have different bodies with different capabilities. In the practiced game, players may use identical tools, or controllers, but the tools aren’t the equalizer their standardization suggestions. Controllers inherently cater to a type of body and type of capability.
Players and Controllers
The project is driven by an attempt to understand controllers:
- How can the same goal of hitting a ball be achieved by different interactions?
- How do different interactions change the relationship between the user and the game?
- Do different interactions make different games?
While these questions are interesting to me, through play testing it was evident that the players are not motivated by these same curiosities. They asked “How do I play and how do I win?” My assertion is that the answer to “How do I win?” varies between players. By offering a multitude of controllers, will players seek out the one that allows them to play their “best”?
“Different” Controllers
Players may decide to use the same controllers or different controllers. If two players choose different controllers, is it still the same game as when players are using the same controllers? That is, do the controllers themselves define the game?
Fundamentally, the behaviour for playing pong is to move a paddle to intercept a ball. When different controllers control the same paddle parameters—speed, direction, and/or position—but through different interactions, it is a question of how they are controlling them. By providing players the choice in how they control the paddle’s behaviour, the game rejects that a singular form of interaction is required to constitute a game.
Providing Different Levels of Control
Many users had difficulty using controllers which modified only one aspect of the paddle (i.e. its speed or direction) through a binary condition (i.e. fast versus slow or up versus down). They had to anticipate both the location of the paddle as it was constantly moving as well as the location of the ball.
In the context of play testing, they had very little time to learn and master these new controls. They quickly had to work against their expectations for how the paddle would behave. I wonder if played over a long period of time, once they could anticipate the behaviour of the paddle would it become boring as toggling between two binary states is a somewhat passive physical interaction? Additionally, how would adding a button that toggled between “in motion” versus “stationary” affect the game play?
Controller Orientation
For the controllers that moved the paddle to an absolute position on the game area, users implemented different orientations of these controls.
When using the multiple-button based controller, one user oriented the buttons horizontally and used multiple fingers to jump between locations. Alternatively, another user oriented the controller vertically—directly corresponding to the movement of the paddle on the screen—and used only a single finger to control the paddle’s position.
Next Steps in Testing
When play testing, I manually simulated the action of the paddle as the users interacted with cardboard controllers. When they controllers offered various parameters to adjust—speed, direction, position—I had a hard time accurately mapping their interaction to my manual adjustment of the paddle. In my next round of user testing, I plan on using a coded version. The controllers themselves will not be the final fabricated versions (enclosures versus breadboard), but they will use the actual sensors to directly control how the paddle behaves on screen. I also plan on coding a “debug” view for myself that visually shows the sensor output in order to map the user behaviour to what’s going on “behind the scenes”. This visualization will be particularly helpful when testing the tilt-based controllers where speed and direction are controlled along two different axes.