After focusing on paired activities last week, we turned to queuing for this week's assignment. Maria and I teamed up with James and Kai, and since all of us created partner-based painting/drawing apps last week, we found inspiration in the drawing adaptation of the surrealists' game, Exquisite Corpse. Also known as Picture Consequences, players take turns drawing a portion of a person or a fantastic creature on the same piece of paper without the other participants seeing each other's sections until the full drawing is revealed at the very end. We looked to these paper-based examples online here and here, as well as Xavier Barrade's awesome online version, as additional models.
First, the four of us played in a traditional analog way (with a regular 8.5" by 11" piece of paper), folding the page into four sections--one for the head, then the torso, next the waist to knees, and finally, the knees to feet. I'm kicking myself for not documenting this version because seeing our composite creature at the very end was well worth the wait! We had fun, and it motivated us to pursue a digital rendering of the game which we called Creature Consequences.
Using a classroom's whiteboard walls, we sketched out what the screen might look like and outlined the code behavior for each person's turn. We envisioned a screen divided into four even rectangles, each the width of the window, from top to bottom. For each player's turn, their rectangle would temporarily disappear to expose the canvas beneath and onto which they could draw their assigned piece of the figure. Their marks would be constrained to that portion of the canvas only. Pressing the Return key ends their turn and advances the next section of the drawing to the next player in the queue. The canvas is only activated for players with active turns; other participants may not leave marks on the screen while they wait. When the last player completes the feet area, pressing Return hides all rectangles to display the full image to everyone on their own screens.
We adapted and built on top of Mimi's human auto-complete example for the server-side queuing, and methodically worked through each item in our list (mentioned above), play testing as we went to clarify functionality and root out any bugs. To start we figured out how to draw rectangles as HTML elements over our P5 canvas. Then, we figured out how to link their visibility to the queue position of each player. Next we implemented the drawing feature, being sure to send that information to the server to broadcast to all input screens (normalizing the location of the marks by dividing by device width on the emit and also multiplying the incoming data by device width). After solving how to constrain players to their specific sections of the screen, we played another round and after creating a completely misaligned character, decided to extend that range into the next player's portion so each person would know exactly where to continue the drawing.
Here are a few screenshots from our initial meeting, as well as some hastily-drawn characters from our play testing:
In our opening conversation as a group, we reviewed our experiences of waiting during our in-class games. Either we were engaged on how the game was playing out (or anxious that our turn was approaching in Zip! Zap! Zoop!) or completely tuned out. Kai suggested that in our online game we include the option for waiting participants to interfere with the drawing player's "pen," such as change the hue, stroke, and opacity (alpha) values. A bit of a last-minute addition, all the slider values are emitted and broadcast from the server in one bundle. So all three waiting players are not only blindly submitting values for the visual output, but they are also entangled with one another for control of their own slider position. Needless to say, at this stage in the project's development, the sliders are a bit jumpy.
Play and remix on Glitch