This is a post about the final updates to our ball game and the 2017 ITP Winter Show. For more about the project’s conception and prototyping, look here, and for our planning process, look here, and for some on our fabrication, look here, and again here.
Final User Testing
Our in-class discussion and feedback for our final project presentation focussed on opportunities for increasing subtlety and complexity in how we presented information. April and I aspired to create a game which didn’t require any instructions — one in which the game’s interface afforded exactly what the users could and should do. In practice, the game required a single instruction:
- shoot for your own goals (rather than your opponent’s goals)
This could have perhaps been solved with a painted playing area (one half being red and one half blue), or some other related design choice, but in the time we had left, it was solved with an on-screen instruction.
Additionally, we would have liked to have the game’s reset and (planned) menu options (for choosing between planned single and 2-player modes, difficulty levels, high scores, etc.) to all be accessible through the game’s goal interface (i.e. menu options could be chosen by shooting for specific goals), but we again did not have time to fully implement this.
After presenting our final in class, we had one last opportunity to user test at this year’s ITP Winter Show. We updated our project based on our in-class feedback, focussing on making our serial Arduino to P5.js interface and physical game more robust to hold up to the several hundred visitors for the show. While debugging, we simplified the serial protocol so that the “hello” portion of the handshake reset the game on the p5.js side. This allowed the arduino to be reset directly (using a big red arcade pushbutton attached between its reset pin and ground), rather than through a p5.js interface. In practice, this meant our code was simpler on both the Arduino side:
and on the P5.js side, which recognized this “hello” function as a cue to reset the game:
Of course, using this method, rather than use the much more complex protocol we had previously used, in which our p5.js sketch had control over all of the Arduino’s goal-states (which control the LEDs as well as the scoring) was a decision driven by need rather than desire. Our previous serial communication protocol was buggy and this work-around seemed best suited to fix it. If I were to continue with this project, however, I would re-implement p5.js control over the arduino, such that all of the game logic was contained in one place and could be more easily connected, changed, and iterated upon.
Additionally, if I were planning the project’s next phase, I would work on:
- increasing interactivity with respect to goal-state changes and scoring: I could imagine a number of modes in which the goals responded actively to scoring to benefit either the first or second place player. For instance, goals switching colors after every score would benefit the second place player while having scores turn off an opponent’s goal would benefit the player in first place.
- managing chaos: while the bouncing ping pong balls were fun in class and at the Winter Show, that particular aspect of the game didn’t lend themselves to any sense of containment or order. Without a dedicated game space, or a net setup like I put up at the Winter Show, chaos rules. Perhaps this game is not meant to be portable, and should be used with a net, but I would be interested in cheap (in terms of less complexity while building, not just cost) solutions to this problem. I can foresee using less bouncy balls and/ or creating angles on the faceplate and goals which redirected incoming balls downward.
- dialing in the interactions: ideally, this game wouldn’t require a screen, or at least wouldn’t require anything resembling a sentence on screen. I can imagine this working if we added more visual and aural cues for the player in terms of blinking goals after a score, more sound cues, spoken countdown and game over cues, etc. and would increase the overall smoothness of the game experience.
All of that said, the reaction at the Winter Show was very positive! Our setup was packed the first day with children (who often played three or four games in a row) and — after some brief repairs — was packed again on the second day! It held together remarkably well through several hours of sustained use, and was reliable in its score-keeping, serial communication and p5.js sketch. For whatever reason, we sometimes needed to reset the Arduino several times before the p5.js sketch reset, but it worked reliably enough that I never quite tracked down this bug’s source… Anyway, here are some photos from the show: