Multi-screen party game

Introduction

In this case study, we will discuss the development of a multi-screen party game that allows users in a single room to play together through prompts via a centralized screen that everyone can see and submit answers with their phones. The game has its own allocated room, so many users globally can play at a time. The project was built using Node, React, Socket.io, MongoDB, and Giphy API.


Planning and Research

During the planning and research phase, I focused on finding the best way to architect the application to work with live-time data for closed groups in game rooms, despite having a limited schedule. I conducted extensive research to determine the optimal information architecture and layout for the required screens, while also taking into account the needs of the target audience. The resulting design was intuitive and user-friendly, enabling users to easily navigate the application and engage with the game in a seamless manner.


Implementation

I needed question prompts for users to submit GIFs to and they had to be humorous. I was able to generate 688 of the type questions.

Next, I implemented Socket.io to facilitate communication between users and the central screen. Once this was working, I added the Giphy Search API to enable users to search for a GIF to submit to the game round's question. The API was user-friendly and rendered 25 GIFs per request, with many options for sizing and media type. I was pleased that the API credited its sources per each GIF.

I also needed to track who was submitting which GIFs, which was easy through the socket.id. However, I realized that if a user disconnected and then reconnected, their socket.id would change. To address this, I stored the socket.id in the user's localStorage and used that as verification to reestablish a connection upon an "accidental" disconnect.

Once the above was completed, I set up a MongoDB database table to capture each GIF submission to calculate winners/round stats. The database table was cleared when all users disconnected from the room, making it cost-effective


Testing

I tested multi-user sessions and core game features using Selenium. I to test multi-user I spawned 3 screen contexts for each user. The tests were written in an E2E fashion where both client and the server were required to be running locally. This assisted in a 5x development speed over manually testing the application as features were added


Go-live

I used the free tier of Heroku to host the dockerized version of the app. It was fun while it lasted, but unfortunately Herkou has put an end to free tiers