Dirty Bomb — brayden law

Project Overview

In this project, my partner and I utilized our individual Raspberry Pi devices equipped with Sense HATs to develop an interactive game. The game was designed using the Python programming language, taking advantage of the capabilities provided by the Sense HAT, which includes sensors and an LED matrix for display. We began brainstorming concepts for the game and have decided to utilize the theme of teamwork and communications to engage our players through interactivity.

To facilitate the creation of the game, we splitted tasks based on our strengths. One focused on the user interface and visual design, while the other worked on the game logic and sensor integration of the game.

Through this project, we created multiple minimum variable prototypes (MVPs), conducted several rounds of user-testing to refine gameplay, adress bugs, and enhance the overall user experience. This project provided us to opportunity to understand the creation of game mechanics, creating MVPs and the understanding of using programming language to produce creative application.

Concept

This game requires two players, each utilizing a Raspberry Pi. Player A possesses all the information and instructions related to a bomb that Player B must defuse. Player A has access to a monitor, which displays detailed instructions and visuals related to the bomb's characteristics and potential defusal steps. In addition, Player A’s Raspberry Pi will display a digital timer using the Sense HAT LED display. The timer will provide real-time feedback during the gameplay, allowing Player A to keep track of elapsed time efficiently. This feature enhances the interactive experience and can be programmed to change colors or patterns as time progresses, further engaging the player.

Player B holds the second Raspberry Pi, which represents the bomb in the game. Their task is to follow Player A’s verbal instructions attentively to successfully defuse the bomb. Communication is crucial, as Player B cannot see the bomb's details and relies entirely on Player A for guidance.

If Player B completes the defusal tasks correctly as instructed, they will successfully disarm the bomb. However, if any of the tasks are performed incorrectly or if Player B fails to follow instructions, the bomb will detonate, resulting in the game ending prematurely. Effective collaboration and communication between the two players are essential for the game's success.

Timeline:

5 weeks

Roles & Responsibilities:

Python Coding, UX Research, Gamification, Game Development

Design & Development Tools:

Figma, Raspberry Pi, Google Sheet, Thonny, GitHub

PROGRESSION

FINAL VISION

In this game, the two players will turn their backs to one another. Player A possesses all the information required to defuse the bomb and will relay instructions to Player B. Meanwhile, Player B, who has the bomb, must carry out all essential steps to successfully defuse it.

PERSONA

SKETCHES

We created a userflow which clearly display the steps that players will experience and it outlines the process of losing and win each game.

This is an initial sketch of all the potential actions and display being shown on the sense hat for the “defuser” side of the game.

After roughly sketching all actions and displays, we used a spreadsheet to further refined and to have a clearer view of what it would like look on the sense hat. We used the colour blue to temporary replace the colour white on the spreadsheet for an easy view of the LED panel. Below we have also created a simplified code associated with the LED display.

MINIMUM VIABLE PROTOTYPE ONE

Given the nature of our game and how the users interact with the prototype, we figured that having MQTT implementation was not a priority in this MVP. That comes in the next MVP!

MVP ONE - USERTESTING ANALYSIS

Throughout our testing, we have found that most users would name what they see on LED displays differently. For example, for “Equal Sign” some would call out “Two Lines” instead. Because how each player would describe the display differently, it would cause confusion for the instructor due to the description of the display being named differently.
We had a player suggested that we could implement pictures on the instructor’s side to allow them to have a more clear vision of the display. However, we further explained that this would defeat the purpose of our game. Since we would like to focus on the communication aspect of the game, we want that sort of confusion and stress present. When diffuser names their findings differently would cause a sort of urgency for the instructor to find the correct step to complete the task.
As for things that went wrong, one user was having trouble whenever they tried to use the joystick. Whenever they move the joystick, it would move the typing position in the IDE. This would happen no matter how they ran the code. We tried debugging it by having them click the run button and nothing else but to no avail.
This proves to be a major problem as clicking the middle button is equal to the “enter” key of the keyboard. If the joystick is influencing movement in the IDE, it will mess up the code.
As for other things to note, while testing for other classmates’ games, we encountered a problem with one group’s project where we did not know the correct orientation on the SenseHat/Game. For me, I assumed that the HDMI port of the RPi faces towards me, with the test written on the SenseHat board upright. However, that was not the case for the group’s game. This causes some confusion during gameplay as there was tilting involved and we needed to tilt the SenseHat in a specific direction.
We brought this problem and applied it to our game. As our game involves correct movement of the joystick and SenseHat, it is very important that the user understands which orientation of the SenseHat is correct.
Lastly, at the beginning of testing, many users have not installed an additional application that is required for this game. Therefore it was causing them to not be able to access the GUI on the instructor side. We must provide clear instructions for them to install the necessary application in order to run more smoothly in the next round of user testing.
1. Open “Terminal”
2. Type “sudo pip3 install guizero”

MINIMUM VIABLE PROTOTYPE TWO

Since MVP in addition to implementing MQTT, we have added a timer to increase the sense of urgency we want in our bomb-defusing game. As of now, there are a few issues we still need to tackle but it works nonetheless.

Here, in this chunk of code, we are using the time function time() to set a start variable. This variable holds the time since the epoch (Jan 1, 1970) in seconds. Then the variable “t” holds the time since the first time that time() was called (the variable “start). With the difference of the current epoch time and the starting epoch time, we are able to implement various if statements depending on how many seconds have passed since to set pixels on the top of the LED array to visualize a timer. 8 if statements for each LED pixel. Once the timer (the variable “t”) hits a specified second (as of testing the code internally, 24 seconds), It ends the game.

For the instructor side, we added extra screens to also let the instructor know whether they lost or won. These screens will be triggered by the diffuser side via MQTT.

One problem we encountered, although not game-breaking, is that when the players lose when the instructor tries to click “back to the main menu” on the Lose Screen, they would have to press that button multiple times before actually getting back to the main menu.

MVP 2 OVERALL CHANGELOG

MQTT IMPLEMENTATION

TIMER IMPLEMENTATION

WIN & LOSE SCREEN

MVP TWO - USERTESTING ANALYSIS

In the second user testing, we had done it through ZOOM with both players’ video cameras on. This was something that I noticed during our testing that players would provide a few non-verbal cues that might have affected the overall experience. Players might not notice their facial expressions or even hand gestures could provide a minimal clue to the other player. Not being able to see each other adds another level of complexity to the game. As of right now, we would like to keep the gameplay mainly focused on verbal communication. However, allowing players to see each other could be a viable option as an alternative experience to the gameplay in the future.
Throughout the testing of our second MVP, we noticed that adding a timer to the gameplay drastically changed the way both players communicate with each other. In the first round of testing, we can tell that players were sort of taking their time with explanations and spent a little more time finding the correct answers and movements. As for this round, both players have a little more pressure for them to clear each task. They seems a little more rush and vague with their findings and were easily mistaken in the steps to complete the tasks.
In addition, on the GUI, we have also changed the way each page was flipped through. Players were only able to flip through one way and is not able to go back to previous pages. They would need to cycle through to find the correct steps again.
A couple of testers had mentioned we did fairly well on implementing joystick movement and other actions involving accelerometer into our good. They expressed that they enjoy that they get to perform different actions to complete a task and it further enhances the overall gameplay experience.
However, another testing group had experienced a few difficulties regarding actions such as tilt and flip upside down not being detected properly. This is a problem that we should fix immediately to allow players to have a smooth experience. When players are facing these issues, it causes them to feel frustrated and annoyed at the experience itself. This could lead to a negative impression in the future.
In terms of LED display, in the first MVP and user testing, testers mentioned the colour “yellow” and “orange” had look extremely similar causing them to have a hard time to differentiate between the two.
We made a small adjustment changing orange to light blue. Yet, the same problem had occurred once again. We realized afterwards that light blue and white looked very similar which causes the same issue as well. We will need to find other alternative colours which help players differentiate a colour from others.
A user came up with the idea of using different colour shapes on each of them. This could be a viable option for us to further improve the gameplay. This opens a lot more options and possibilities for a style of LED display. This is something that we would consider implementing in the future for this game.