Description

P4 Report 1
Introduction 1
How to run 1
The Rationale Behind the Product 2
Design Decisions 2
Journey Map 3
Initial User Stories 3
Implementation 3
Implementation Challenges 4
Challenges when Implementing the Game 4
Challenges when handling Serial Communication 5
Challenges when fetching Highscores 5
Review of User Stories 5
Future Work 6

Introduction
Interaction between a user at home, and one in the exhibit should be fun. For this reason I have designed a game for the user at home which can be directly affected by the actions of the users in the museum. While the museum users have limited feedback, currently only able to see a player’s score when the game ends, I rely on people’s curiosity about mysterious buttons. In the Future Work section I suggest ways to address this limitation.
How to run
1. Navigate to: src/js_app
2. Run: npx expo start –web
a. If this fails, Run: npm install expo
b. Then retry step 2
3. Open the src/js_app folder in vscode
4. Install the vscode plugin ‘live server’
5. Start the live server
6. Navigate to src/js_app/p5/p5.serialserver-main
7. Run: node startserver.js
a. if this fails, Run: npm install serialport
b. Then retry step 7
8. In a browser go to: http://localhost:[OPEN PORT]/Highscores
a. e.g. http://localhost:19006/Highscores
The Rationale Behind the Product
I decided early on that I wanted the interaction to be fun in order to encourage people to see past the inherent complexity of hardware and software, and to consider what is possible.
Design Decisions
When designing the product I needed to consider the three components I had to work with: expo, p5, and the micro:bit, and the individual parts of the product itself. The product requires a game, a scoreboard and a way for the user to control the game. Expo was most suitable for implementing the scoreboard because it is good for quickly building aesthetic websites with efficient handling of database interactions. P5 is designed for making graphic and interactive experiences, and so I used it for the game. The micro:bit was used to control the game because it has a variety of useful inputs.
The method for users in the museum to trigger events needed to be considered carefully, because I wanted something that was likely to be triggered often, but required human interaction. For this reason I decided to use the buttons. In order to clearly mark these as part of the exhibit I recommend using big red buttons on pedestals which have a display of recent scores, and play a sound effect when triggered.
Journey Map

Initial User Stories
As a child visiting the museum, or at home
I want to find something interesting to play with So that I have fun
As a student visiting the museum, or at home
I want to find something engaging and informative about the principles used
So that I can learn more about the topic without becoming bored
As an adult visiting the museum, or at home
I want to find something interesting and novel
So that I can learn and be inspired
Implementation
Implementing the Highscores screen
The Highscores screen required fetching a list of all text inputs to groupId 20, filtering them to those matching the expected format, and extracting the useful information using Regular Expressions. Presenting the information was a very similar challenge to previous practicals, and so the same techniques were re-used. Because the design goal was to show the Highscores I decided to limit the scores shown to the top 10 users, considering only each user’s highest score in order to avoid a skilled individual occupying the entire set of Highscores.
Implementing the User Highscore and Game introduction screen
For the case when a user is not on the Highscores screen I decided to implement another screen to show the highest score corresponding to a username. Further I also used this screen to explain, and link to the Asteroids game. This required similar use of regular expressions as the Highscores screen, but in this instance also filtering for a name match using the text box. Linking to the game was difficult because I wanted to reuse one of Expo’s site navigation methods, such as Tabs. After some research I could not find any way to do this, so I use a link to the local URL that the game is hosted on instead.
Implementing the Game
The game required a number of falling asteroids which can be bounced, and a player character able to move around the screen and bounce them. Further, I needed to listen for new entries in Firebase during gameplay in order to choose when to introduce ‘bonus’ asteroids for the player. These interactions posed several challenges, as described in the Implementation Challenges section.
Coding the Micro:bit
The code for the Micro:bit was implemented very simply. It sends a string corresponding to each button press via serial for the Game to detect. This simplicity was deliberate because serial communication is unreliable and implementing a communication protocol can make it
noticeably slower, therefore I aimed for simplicity to minimise the risk of serial communication impacting the user’s experience.
Implementation Challenges
Challenges when Implementing the Game
Handling the influx of all historic messages when using the ‘onChildAdded’ listener. The onChildAdded listener was expected to only return new events. However, instead it returns all previous events for a given query up to the current moment and only then behaving as expected. To handle this I set a timer for 5 seconds which would allow all previous events to trigger the onChildAdded listener, after which the listener is able to trigger in-game events.
Implementing collision detection between the player and asteroids
Calculating object collision was difficult, and requires careful consideration of object geometries and positions in space. This motivated an early change from ovals to circles for the asteroids because the geometry is easier to handle. After some research I found and implemented a suitable procedure. At this point I aimed to permit asteroids colliding with each other, and had several more asteroids permitted on screen. This required an expensive procedure of calculating whether an asteroid collided with the player, or any other asteroid. As a result there was noticeable stuttering with several asteroids on screen. I decided that responsiveness was the most important factor, and removed the handling of asteroid-asteroid collisions, and reduced the number of asteroids permitted on screen. After this the performance improved to a satisfactory level.
Challenges when handling Serial Communication
Minimising the impact of data loss from serial communication
From previous practicals I have observed that serial communication is unreliable, and generally requires measures such as the use of checksums to check validity. I considered using such measures, but these can also slow down the communication, and therefore decrease the responsiveness of the game. To avoid this I decided to minimise the use of serial communication, and send single characters where necessary. This has significantly decreased the negative impact that serial communication can have on the game.
Challenges when fetching Highscores
Filtering all text messages to groupId 20 to only those relevant to the game The text messages on groupId 20 are shared by other users, and can be added to by the chatGPT based bunnies. I decided to still use this channel in order to display my messages (the most recent user scores) on the screen, and increase the interactivity between remote and in-person users. To filter out these other messages I use a specific format of string, then check if each string matches this template using a regex. This method was fast and convenient, and was also applied to extracting the content of the messages for the Highscores page.
Review of User Stories
The first user we consider is a child, either at the museum or at home. When interacting with the game at home this project is expected to entertain them, satisfying their needs. When interacting with the buttons in the museum the relationship between the scores on the screen and the buttons are not inherently engaging, and would be unlikely to satisfy the child for long.
The second user we consider is a student. When interacting with the game at home this project is expected to entertain them, but when they are in the museum and the interactivity between the buttons and remote user’s games is explained this will serve as a creative example of the Internet of Things (IoT), where physical interaction affects digital gameplay in a remote location.
User Story Analysis
The project is deliberately not targeted at any specific audience, instead aiming to entertain those who aren’t interested in the foundational principles, and serve as an interesting interactive example of the principles of IoT for those who are. The user stories reflect this, where groups other than children are less likely to find the game engaging, but more likely to appreciate the demonstration of real time interactions, while children are more likely to enjoy the game even if they aren’t interested in the principles.
Future Work
● Profanity filter for usernames
● Work on improving the engagement value of the game
○ Implement powerups for the player
○ Implement different types of asteroids, e.g. 3x size, but slow asteroids and tiny but fast asteroids.
○ Implement a scaling difficulty over time by modulating the speed of asteroids proportional to points scored.
● Design a website to broadcast the current top scorer’s gameplay to the museum
○ This should increase the value of the exhibit for demonstrating the interconnectedness inherent to the IoT, where they can watch their physical interactions affecting a human’s digital game.
● Change the design of the buttons to be more appealing.
○ large red buttons are likely to be more interesting to push, and users are less likely to believe they are mundane and not part of the exhibit. ● Include a plaque with the buttons explaining the exhibit