“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?”1 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.
