Icebreaker — HCI Spring 2022 Final Project
By Vishal Tak, Debbie Wong, Francis Tran, Daniel Killough
Imagine attending a group party or social event where you only know one or two people, or perhaps none at all. You’re hoping to get to know new people, but you’re not sure how! Popular icebreaker activities don’t focus on connecting users by making them acquainted with each other, and apps like Jackbox and Kahoot are oriented to showcase the user’s skills rather than introducing people’s stories. Icebreaker solves this issue by making it compelling for users to get to know each other through sharing personal answers.
Icebreaker breaks the ice by connecting users to a central server (shown on a large display) where each player is asked questions from a pool of categories they pick. Categories can be anything from food, animals, travel, and more. The players take time to answer their questions and wait for the server to start the game. Some sample questions the player could be asked are “What animal scares you the most? Why?”, “What is the most useless tool in the kitchen?”, and “Which is better? A picnic in the park or a meal in a restaurant? Why?” Once the person who is running the server starts the game, players are shown the question and answer pairs and have to guess the person who wrote the shown answer. The person who wrote the answer to the question being displayed will be tasked with pretending that they’re diligently guessing like the other players. Players are scored based on the number of correct guesses and a winner is crowned at the end of the game. By the time the game finishes, all players will have had their assigned question and answer shown to everyone, and everyone will have learned something new about the other people in the group.
Design Process
Ideation
While we originally started with many different app ideas including an aim trainer or an AI playlist generator, we narrowed down our ideas to an application meant to enhance social interactions with other players you haven’t met. Our initial idea of an icebreaker game was inspired by existing social games like Kahoot and Jackbox, where players participate in the game on their phones while prompted with tasks from a large screen display. Our team aimed to gear our design after these apps while combining some aspects like the waiting screens from Jackbox and scoreboard display from Kahoot. We meshed these initial ideas with our own in the sketches to create a friendly user interface. We wanted the feel of the game and UI to be welcoming so that players are more likely to answer questions that invite laughter and plenty of ice breaking. Originally we planned to time the players by typing their answers and guessing who the right player was, similar to many Jackbox games. However, we felt that it went against the spirit of our game; Icebreaker is about making jokes and getting to know new people, not a challenge to get the most correct guesses.
Interviews
We conducted a total of seven interviews, consisting of people of different backgrounds, as well as varying experiences of games like Kahoot and Jackbox. The formula that these applications and games follow involves a game on the screen that the user interacts with using a simple UI on their phone. Our interviewees shared the sentiment that an environment that is relaxed yet comical, combined with learning about the backgrounds and interests of the people is essential for “breaking the ice,” hence the name of our game: Icebreaker. We wanted our game to be simple and easy to pick up so that the emphasis is placed on getting to know the people around you; join a lobby, enter a funny nickname, choose a topic and answer some questions, and guess who gave what answer. The guessing part of the game is where the “Icebreaking occurs” because the players will discuss amongst themselves, using the limited knowledge they have of each other. The questions that users answer should reveal some unique information about them, as to expose a funny story, or provoke an insightful discussion.
We understand that people are usually more inclined to play games with people that they already know, so part of the challenge of the game is to make players comfortable to play the game but also have them feel like they can share parts of their life. Another insight from our interviews was that people’s social nature becomes accentuated in a party setting, so it might be hard to get people that are shy to have the same, fun experience. However, we believe with the right questions, anyone can come out of their shell.
Persona
Nick is a 22-year-old who likes to attend parties. He attends a party where he doesn’t know many people. The party host decides to start a game of Icebreaker on the TV, where the lobby is shown on the screen and party-goers can join the game from their phone. After everyone joins the game, Nick answers questions on his phone about his interests and preferences, and then afterward everyone takes turns guessing who wrote each answer. By the time the game ends, Nick feels that he learned more about the other partiers there and feels more comfortable talking to others later that night.
Prototyping
In our initial prototype of the game, we wanted to set a timer on how long a player gets to guess who answered a question, we removed this to encourage discussion among players. In turn, our game ended up much more enjoyable since it was fun having players talk and theorize why a specific player would be the one to write an answer that’s displayed on the big screen. When coming up with how the app should look and feel, we wanted the app to be extremely accessible so that anyone would be able to understand the base mechanics of the game; there should be as little barrier to entry as possible to encourage all players to join. In turn, all the screens on the phone have at most one option to do: join a lobby, choose a topic, answer the question, and guess who wrote the question. These options present themselves via a large text box or large buttons to press. We believe that this produces a streamlined experience for the players.
Although we ended up altering the color scheme slightly on our implementation, the idea remained the same. We initially created a mood board to capture the essence of a group game and social setting. Games like Kahoot that have a very distinct color palette for their UI elements inspired our color palette to have that kind of contrast, but a bit more laid back and less vibrant to make it easier on the eyes. There’s no pressure to win in our game, so we wanted the UI color palette to be calming.
Implementation
Backend
We chose to use Django for our backend implementation as that was what we were recommended. For our models, we designed a Player model to store information about the player including the Question assigned to them, their nickname, the topic they chose, and their specific hashed ID. The nickname is the name the player chooses for themselves upon filling out the form on the player page of the app, and the hashed ID is the randomly generated string of letters and numbers assigned by the web socket server when a new player joins the server. We use this hashed ID to identify the player so we can avoid issues with multiple users choosing the same nickname. Upon creating a new Player object in the backend, we also fetch a Question from the already existing pool of questions that fits the topic they requested, and assign that question to the Player. The Question model consists of a text field containing the actual question and a boolean flag representing if the question has been used. Once assigned to a Player object, the Question is marked as used so no two players will get the same question to answer when the game starts. While the Players database is populated as each user joins the game, the Questions database is populated once when the server page is launched and is not altered as the players play the game outside of marking it as used. The entire backend is flushed if the user chooses to press the “Play Again” button upon completing the game so new players can start a new session of the game.
We use an expanded version of a web socket template to facilitate the server/client interactions. This web socket server acts as the mediator between the player and the host. For example, the player sends a message to the web socket that has their name and a flag which indicates that the message is a nickname. The web socket parses the nickname and sends a message to the host containing the name of the player. The web socket server requires that the host is the first connection to be established as the host (a server) needs to be set up before players can connect to it. This allows us to differentiate between the host and player connections (everyone that connected after the host is assumed to be a player) and send messages accordingly. Some information such as question and answer pairs are known to the server only and are only made known to the players when necessary.
Frontend
Users can visit one of three pages: landing, host, or player. All users are first directed to the landing page. From there, players will click the “Join Game” button to visit the player page. The host page is accessed by clicking “Host Game” and is designed to be shown on a large display such as a desktop monitor or TV screen. We want to engage the audience and stimulate conversations about their responses and guesses, and the host is displayed on a larger screen facilitating player interactions more smoothly.
The host page monitors the state of the game. It sends the name of players to the backend as well as receives the questions that each player will be answering. The questions exist in our backend that is received via an HTTP request. Once the game has started, the host page randomly selects players to display the question they received along with what they answered. Once the question and answer are displayed, the host waits for responses from all players before displaying the updated scoreboard. If all players have finished guessing, we use jQuery to hide the contents of the screen and display a scoreboard using data from the list of players to keep track of the score of each player.
Upon changes in the state of the game loop, we use jQuery operations to add, hide, and show different elements that correspond to the state of the game. For example, after a player decides to join a lobby, all the elements on the screen are hidden and buttons with topic choices are revealed. Similarly, after receiving a message from our web socket that everyone has answered a question, the page again hides all the contents of the screen and will either show buttons that correspond to a “guess” of a player or text that tells you to act like you are guessing.
Game Loop
Throughout the game, the host and player pages will communicate with each other to retrieve user information. The player page will send a message to the host page after selecting their desired topic, and the host page will talk to the backend to fetch a question with that topic. Upon the success of the question retrieval, the host sends the player the question, and the player page will update the contents of the page to show that question. The host will send messages to the players during the game to request their guesses, and the player page will reply with their selected guess. This communication between the host and player pages continues until the game loop ends (we have shown each player and their question once) we show the scoreboard once more and terminate the game.
Evaluation
Our second round of need-finding consisted of a practical user focus group. The group was composed of five college students aged 19–21. Three of the five students knew each other prior to the experiment, having attended high school together. Furthermore, only two of the students attended the same institution (Clemson). Students were recruited in-person and via Discord servers by the conductor of the study and did not receive compensation for their participation. All students were friends with the conductor of the study. All participants except one, a fellow UT student, have already completed their spring semesters.
Participants were added to a group direct message on Discord. Participants were assured that the study would take 15 minutes to play the game and 15 minutes to answer questions. All students gave verbal agreement to take part in the study. Participants were instructed to take out their mobile phones and navigate to the following link: https://group-final-project-with-p4-starter-code-uthci-1.uthci.repl.co/. Meanwhile, the conductor navigated to the same link on their computer, clicked “Host Game”, and began screen sharing the window. Unfortunately, some players were unable to join the game because of connection issues to Repl. As the only known solution to this problem was to restart the client, the host and players repeatedly cleared out the backend and restarted the game until users were able to start. One prominent bug discovered during this time was that having spaces in a player name will cause a 404 error when trying to POST to the endpoint, effectively breaking the flow of the game and forcing a restart, flushing the player from the backend.
Once even the conductor of the study was receiving Secure Connection Failed errors, we decided to completely clone the repository into another project.
Doing so appeared to solve the problem, however, now the administrator panel to clear previous players was unable to be accessed, even after running the create admin command. Since participants had been on the phone for over an hour up to this point, we decided to run the game anyways with what we had until we could no longer continue.
Players typed in unique names on their phones, selected a topic, and answered a question. They were then greeted with the appropriate answer screen on the main display, a screen shared on Discord, as well as the list of players on their mobile devices. Friendly banter and discussion ensued, with interesting pieces of information shared like “oh, this person’s parents own a restaurant, so they probably wrote this answer.”
Once everyone guessed an option, the host page automatically progressed to an updated leaderboard with everyone’s scores. For each correct guess, the player’s score incremented, and the conductor advanced to the next question.
Unfortunately, due to the fact that we could not clear old players from the database, we were unable to complete the full game as it hung on players who were no longer connected to the server. The study ended thereafter.
General feedback from the study included:
- Players would be apt to play the game with acquaintances in a similar age range
– If questions were more “chaotic” or intimate, then close friends as well.
– If questions were more professional, then coworkers or those meeting for the first time as well. - Some introduction between players is necessary or every guess becomes completely blind. Better with individuals most people know.
- The game is effective in getting to know others at a surface level, but discussion should be emphasized further to enhance the intent of the game.
- The UI is effective but bland. Would benefit from color palette or themes; color-coding players/question categories; character limit on names; include question above names on mobile; two-column layout of names on mobile.
- The game may benefit from user-generated questions, additional questions and categories, and special point opportunities
- Keeping the game on mobile web as opposed to a downloadable app helps user retention due to storage concerns and lack of use sentiment.
Reflection
Looking back on our project, the largest obstacle by far was Repl itself. There were numerous occasions where we could not test anything we wrote in code because Repl had “unexpectedly closed the connection”.
Despite the official Repl status page saying that “all systems were up and running” when we searched for the cause of this issue, the general consensus was that Repl was having issues on their end, and the only cure was to wait it out, which is exactly what we did. The waiting time ranged from the low end of 20 minutes to half of a day gone by before Repl was up and running again. We are confident that this issue is not on our code, as the website would load and could run the entire game with no problems in one second, then without changing any of the code, it would crash. Other times there would be the issue of the website somewhat loading, where it would say “Run the Repl to see the output”, but upon inspecting there would be a 404 error.
There was even one instance where the entirety of Repl was down and we had to check the status page to see when the service would be back up.
Overall, using Repl was a very bad experience for all of us on our team when trying to work, especially since we all had different schedules so having the website load with no issues during our scheduled meeting times was very important. We would work odd hours into the night according to the schedule Repl set for when it would decide to load. If we could do this project again, we would absolutely not use Repl to build our project and instead opt for a React web application with a Mongo backend hosted on Amazon Web Services.
There are a couple of improvements we could make to the game if we had more time. The most obvious one from our planned out UI is the use of lobby codes, where we could have multiple games up and running at the same time, and upon hosting a new game, a lobby code would be generated that the host could share with their group to use to join. At the present moment, the lobby code section of the player page is just a proof of concept with no real functionality. Secondly, each player only receives one question to answer upon choosing a topic. This means the game can be rather short if only you’re playing with a small group of people. In the future, we could allow the user to choose multiple questions to provide answers to so the people playing can get to know each other more outside of the one question they’ve been assigned to answer. On that note, having more topics and questions, in general, would be nice to have outside of the ones we currently have. We could also implement sound effects when pressing on buttons and background music to match our game, along with animations and transitions to make our game more entertaining. Lastly, we could make it a stand-alone game available on multiple platforms, not just web-based.
Links
- Interview Audios: Interview Audios
- Final Video: https://youtu.be/N10AEo31QwY
- GitHub: https://github.com/debbiew27/Group-Final-Project
- Slides: Pitch Presentation
- Poster: Icebreaker.pdf
