This project was a study of the game Humans vs Zombies in order to design a solution to help increase immersion in the game environment and improve the overall experience for the players while they balance the game with their regular activities.
Duration: 5 months (August 2016 - December 2016)
Role: Research, Design, Software Prototyping
Geo Spatial games such as Pokemon Go and Ingress are all the rage these days. However before these became popular, there were games such as Humans vs Zombies played without the use of technology. We call these Mass Spatial Games. They are identified as games played outdoors with large numbers of people and involves people interacting with other people as well as people interacting with the 3D space.
"The fear I generally feel is small compared to the anxiety of being a HvZ human in an apocalyptic world."
Humans vs Zombies (HvZ) is a zombie apocalypse game played on campuses across the world. It is essentially a game of tag but played by very large groups of people in wide open spaces. The premise of the game is to live in a fantasy world where a virus has attacked the human population that is slowly spreading like an epidemic. Over time the game has involved to include technology into the game play to facilitate communication and to keep track of players. It is a free game under the creatve commons license that any person, group or organization can adapt and play on their campus. The Georgia Tech campus has been conducting this game every semester since 2012.
Step 1: Identifying User Characteristics
We identified active and passive participants focusing on traits relevant to the game such as physical characteristics: athleticity, age, access to technology and presence on campus. Some other social factors that could differentiate between user groups were also included time, membership in academic organizations/peer groups, experience, etc.
Step 2: Defining Research Questions
The purpose of identifying these research questions was to figure out what type of data we needed to collect and the methods we had to use to collect it. This could be user volunteered information through interviews, surveys or ethnographic data.
Step 3: Identifying Social and Technical Context
Social aspects of the environment and the community relate to the problem space in a game like HvZ where human interaction is a critical aspect to study. Technical context of the game is important to not just understand how the game is being played currently but also to understand what type of solutions can be implemented feasibly. These larger systems are important when designing for the users.
Step 4: Primary Data Collection
We reviewed games from previous semesters by looking at Facebook groups, websites and other social media outlets as well as reviewed the official HvZ pages. We interviewed the administrators of the game and a few former players. We studied the rules of the game and paid attention to specific details that were emphasised in the rules. We studied how the game and the rules have evolved over the years in this Pre-Game Research phase.
Step 5:Task Analysis
This analysis was a combination of 3 aspects:
- Characteristics of the tasks performed by the users
- Characteristics of the environment in which the task is performed
- A heirarchical analysis of the decision making process in the task
We followed this approach to identify and study how the user's current approach to the task and how this might influence our design eventually. Any existing systems that were in place had to be studied in order to understand if and how current solutions to problems work and perform a literature review of these systems.
Step 6:Initial Usability Criteria
We listed out principles that we would use eventually while evaluating our design. This formed a basic in/out list for our designs.
- Focus on the users and the tasks not the technology
- Match between system and real world
- Affordance, Recognition rather than recall
- Visibility of system status and feedback
Step 7:Secondary Research
We conducted this stage of research closer to the actual game of HvZ played on campus. We wanted to obtain more complete and detailed data that best reflects the user’s problems. We structured our research in order to understand the user’s experience before, during and after the game. Major portion of our research was conducted during the game itself. Two members of our team participated in the game while the other two observed from the outside. Most of our research data comprised of ethnographic data collected through interviews.
Pre-game SurveyParticipants: 80
Reach a large number of players and collect quantitative data. Collect data from both types of players: experienced and first time.
Diary StudyParticipants: 2
Unstructured information we might otherwise not have specifically asked about. Reach a large number of participants and provides detailed data about experiences.
Playing the game allowed us to observe the environment and player interaction first hand and get the "inside scoop" by being a part of the strategy conversations.
Understand gameplay in its natural state. It allows for understanding gameplay but viewing from an outside, unbiased, perspective and allows for movement between factions.
In-game interviewsParticipants: 10
Quick in-context interviews allowed us to capture player input as it was happening, giving us a rich account of experiences.
Post-game surveyParticipants: 80
Assess players’ feelings post game and compare it with their opinions pre-game. The survey allowed us to understand how the attitudes of the players changed over time.
We first decoded all the qualitative data from recordings, interviews, diary studies, etc and segmented them into affinity notes. We constructed an affinity map through the bottom up or deductive approach. We noticed some common ideas among different participants and hence we grouped these together into common areas. The affinity diagram allowed us to more easily see trends in issues across the people we interviewed. It was also a good way to get a feel of the players’ general thoughts about the game. We used the quantitative data collected from the surveys to confirm our findings from our affinity map. We had collected data such as player's preference to play as human/zombie, their knowledge about campus, etc. from a large group of people and therefore we were able to supplement our findings from the smaller sample set of interviewees using this more representative data.
Insights and Themes
1.Players enjoyed the immersive experience and taking on a role sometimes prefering one role: human or zombie
2.Players followed strategies to increase immersiveness as well as get around logistics of the game.
3.Stress was a big factor in the game. Some enjoyed it and some didn't but all players acknowledged it.
4.Players had tactics when dealing with tags and the process of being converted into a zombie.
5.New players were able to learn more about the campus as well as get to know other players.
6.There was an interesting group dynamic from the interactions in the game as well as when communicating through social media.
7.Some players like to practice suicide in order to turn into a Zombie early on in the game.
Problem - Increasing Immersion
- A large number of players would choose to turn into a Zombie on the first day in order to play the “more dominant” role. This disrupted the normal play of events that is similar to a zombie apocalypse.
- In order to log that a player has been converted into a zombie, players must obtain a Player ID from the newly converted human, sign into the Georgia tech HvZ website and enter this player ID. Many times this process can be time consuming and can remove the player from the experience of the game. This causes a delay in players entering this information which also forced the newly converted human to be removed from the game until his conversion was logged.
- If players didnt own smart phones or if their phones ran out of battery, this was delayed even further.
Billy: Human-Mole Person
"I've seen casualties. The texts never prepared us for that. War is hell."
Liz: Human-Average Player
“I can’t believe i’m still alive. I assume I am going to die.”
Not too experienced
“Anyone who tries to cross me will get a marshmallow in the face”
Prefers to play after tagged
Cameron “Braaains and” Braun: Zombie-Support
“Reporting not running”
Average risk taker
“Would you rather be the lion or the gazelle”
“I don’t have time for this” “I followed a group of people wearing yellow bandanas”
We began by splitting off and individually designing 20 divergent ideas and rapidly came up with more to solve that particular problem. We combined similar ideas that could work together in a single system to best solve the main problems identified in the affinity diagram. Through collaborative ideation and narrative development, acting out the story of how the concept is used, we honed in on our final design proposals. This allowed us to define features, address areas that might be problematic with the design as well us address issues with form factors and accessibility. We also focused on enhancing the player's experience in the game and increasing immersion and game feel and therefore refined our ideas keeping this in mind. We worked together as a group throughout the converging process so we could constantly build on each others’ ideas and eliminate them if we felt they did not address the problem well enough. Throughout the process we kept in mind the personas we had created since they best represented the people we observed through research. Particularly we wanted to keep in mind that we wanted to create an equally immersive experience for all the personas and did not want to skew the game towards one type of player.
Therefore, we kept all of these points in mind while narrowing down our ideas. The key method we used while doing so is by first dividing out 20 different ideas into groups based on the implementation. That is, we grouped designs based on form factor and device to human ratio. For example, designs that involved kiosks or screens around campus have a 1 to many ratio and are of a higher form factor as compared to wearable devices such as vests and watches. Once we grouped these designs together, we combined designs and eliminated redundant features. We then evaluated the smaller set of designs based on their usability, feasibility and of course how the increased the immersion of the game and how well they addressed the problems.
We had a peer evaluation session where we displayed each of our four solutions with story boards to depict how they would be used. Fellow HCI students, game players and faculty voted on the designs and gave feedback on each following which we evaluated the designs based on the following criteria
- Feasability vs Usefulness
- Form Factor - Inch vs Foot vs Yard
- Scale - 1:1 device vs many:1 device
After evaluating our designs and obtaining feedback on them we zeroed in on our solution: A foot sized device, a kiosk, that will be placed in various locations across the campus that players can interact with in order to perform various tasks. We realised that such a device would not just be more feasable compared to a wearable but also easy to maintain for the game admins. It also eliminates the need for using a mobile phone while playing which provides the most immersive experience compared to the other solutions. By making use of existing artifacts such as college IDs we would be able to make the device usable by everyone without having to put in effort for setting up. Our objective of creating a design like this was to keep its usage to the minimum. Players should be able to complete their tasks in the least amount of time and focus on the game.
Output - Prototyping
Our prototype was a stationary kiosk, a physical machine that would count coins that signify either human stuns or zombie kills. After a user swipes his or her buzzcard (or for the sake of the prototype taps a general purpose rfid card) the machine will recognize the user’s identity and will display the player’s in-game statistics. If the player is a human he can choose to log stuns by inserting coins taken from zombies. Similarly if the player is a zombie he can choose to log kills by tapping the coin received from tagging humans. The machine will count the number of stuns or kills that are inputted and display the player’s updated game statistics when finished. The machine will then send this data via wifi to the HVZ website. This will allow users to track stuns and kills while keeping the player immersed in the experience of the game.
Storyboard - Current Interactions
Storyboard - New Interactions
We focused on enhancing end-to-end experience right from being human until after they turn into zombies. Therefore, we added features to incentivize players to continue playing throughout as well as introduced risk to allow players to feel more adventurous. In addition we made calculated decisions to ensure players spent least amount of time interacting with the device and playing instead. We chose interactions that are quick and have low error rates: coin acceptor and RFID scanner as compared to entering a code on a touch screen.
Visual Design (Graphical interface)
We made decisions based on mental themes we discovered from the language players used as well as references they made to video games. We decided to create an apocalyptic theme for our visual design to be in-sync with the game feel. We had very little necessary information on each screen and focused information that was optional to smaller areas of the screen.
Visual Design (Hardware Interface)
We added visual effects using light to give feedback on the location of the kiosk and response to user input. We also stuck to the apocalyptic theme for the outer body of the kiosk.
We decided to use a Raspberry Pi with its 7-inch display in addition to an Arduino Uno to control the Input sensors and the LED lights. These are both fast prototyping kits that are easy to program in and are flexible in their usage. They are also small boards that are easy to fit in different form factors. We prototyped the outer shell of the kiosk using available raw materials: a camera tripod, laser cut cardboard and acrylic sheets and put them together using hot glue.
We used Python's standard GUI library TKinter and MySQL for the development. We used a "duct-tape and glue" method of prototyping in order to quickly simulate the end to end experience of using the kiosk. We creating a local database instead of hosting it on a server. We hard-coded authentication and authorization to simulate the RFID scanning. And we relied on illustrations for most of the data on the screen only focusing on developing the critical user journeys.
We conducted an initial stage of user testing with our peers at a presentation session where we got expert feedback about the usability of the device from fellow students and teachers in the field of HCI. We evaluated the prototype using the pre and post game survey to compare responses from the previous game as well as measure immersiveness using a survey by Jennetta et al . We measured basic values such as session time, errors, satisfaction, etc. to quantitatively evaluate the effectiveness of our prototype.
 Jennett, Charlene, et al. "Measuring and defining the experience of immersion in games." International journal of human-computer studies 66.9 (2008): 641-661.