Artists’ Statement
Through LOVEBUG, we hope to represent the system of an email virus spreading from person to person through the actions of a malicious hacker. The hacker poses as a real user, slowly infecting their semi-oblivious friends through emails carrying a bug that then turns their friends into carriers. We also are looking to represent how friendships and connections are made online, specifically through email and particularly in the early Internet (1990s-2000s). Through asymmetric gameplay, hidden information, and the conflicting interests of not being infected but making as many friends as possible in conjunction with a cohesive Windows 98-style visual design, we hope to fully immerse players in the roles of users making connections and friends while being wary of hackers.
In designing this system, our team wanted to emphasize the importance of loops and arcs through asymmetric gameplay. The player creates a mental model based on their identity (User or Hacker), the current board state, and their goal cards as well as current friendship levels, infected status, and suspicion of who is the Hacker. Players then decide which long-term goal to pursue through their short-term actions such as sending email, placing and establishing connections, opening and deleting emails, and spending (or denying access to) cybersecurity tokens. The board then updates based on these actions through changing of friendship and infection status, updating the player’s mental model and informing their next decision.
As those that playtested with us can attest, the ILOVEYOU virus was an incredibly difficult system to abstract. Originally we were considering a digital game with hidden information, then an analog game with hidden information behind screens, but finally settled on a hidden information social deduction game. We abstracted quite a bit of information from our system to streamline gameplay, namely:
- Randomizing NPC email sending. We really wanted to allow the Hacker to be Gamemaster and send NPC emails, but we valued the hidden information, impersonation aspect of the Hacker’s identity more than having NPCs send emails more purposefully. The impersonation mechanic improved the competition aesthetic we wanted to engender through gameplay.
- How friendships form and are maintained. Friendships, especially online, take much more than a singular email to send, and degrade over time if not maintained. This element is not present in our game in order to streamline gameplay and encourage more diverse strategies, one of our values and a staple of good system games.
- Methods of defending oneself from attacks. Although the ILOVEYOU virus spread like wildfire, people with a stronger cybersecurity intuition would generally avoid emails from senders they don’t recognize with suspicious attachments. We considered adding subject lines and even body text to the email cards, but we abstracted them to expedite gameplay and iteration.
Overview
Welcome to LOVEBUG! Make connections, send email, build friendships… but be careful! A devious HACKER is among you. The Hacker looks like you, acts like you, makes friends like you – but their mail contains a dastardly virus that steals your personal information! As they send emails to you and your friends, their virus will slowly spread through your network, so watch out!
In this thrilling 4-player social deduction systems game, you will relive the chaos of the infamous ILOVEYOU hacking outbreak—one of the most widespread cyberattacks of its time. As innocent users, you are racing to build out your email network, forging new friendships and connections to achieve your personal goals… but lurking in your midst is a secret hacker, spreading infected emails disguised as harmless messages. Every email you open could be your downfall!
It is May 4th, 2000, and you’re caught in the chaos of the LOVEBUG hacking oubreak—one of the most widespread cyberattacks of its time. In this 4-player social deduction systems game, innocent users race to build email networks and forge friendships to achieve their personal goals… but lurking in your midst is a secret hacker, spreading infected emails disguised as harmless messages.
Every email presents an agonizing choice: open it and strengthen your friendships, expand your network, and complete your goals, or delete it and stay safe? Build paths across the graph, deduce who’s spreading the hack, and race to reach six goal points before everyone gets infected. Meanwhile the hacker will secretly and silently spread the infection through your network, hoping to evade detection and infect everyone.
Can you expand your network and keep yourself safe? Trust no one. Open carefully. Don’t catch the LOVEBUG!
Final Concept Map
Iteration History
Initial Brainstorm
The world is full of systems… and we considered a lot of them before settling on LOVEBUG. Our initial brainstorming saw consideration of mining systems and their impact on the environment, mass surveillance systems, and social media addiction and the refining of algorithms to increase engagement. We finally settled on the spread of internet scams as a middle ground for all of the ideas that excited us in the other options: media literacy, asymmetric information, and spread through a network.
Coming out of our initial brainstorming sessions (Nov 3 and 4), we intended to design a game targeted at young adults with the goal of increasing tech literacy by expanding their understanding of the spread of computer viruses across digital social networks. This was motivated by an understanding that scamming is becoming an increasingly big issue, with historically less vulnerable populations (i.e. those with higher tech literacy, like young adults) being put at risk by new methods of scamming (i.e. voice fakes). This initial goal shifted when we specifically focused on the Love Bug virus (see more information on the real life hack here!) which took place in May, 2000, requiring us to focus our intention onto modeling the spread of the scam rather than the scamming mechanisms themselves.
We were strongly inspired by Pandemic, which two of our group members (Ryan and Brydie) played for the Working with Systems Dynamics Read and Play (link to Brydie’s write-up), and its use of compounding components within its system (where infected cities spread the virus locally and infection level compounds between rounds). This inspired our design of the spread mechanic in our own game (Fig. 1).
We waffled early-on between an analog versus a digital implementation of the game. While our group had unanimously expressed interest in developing a digital game, encouragement from the teaching team swayed us towards analog, given the short time frame and limited game development experience in our team. However, given the asymmetric information component of our system, we didn’t completely bar the possibility of switching back to digital to allow for more hidden information.
Version 0
Our first tiny playable prototype was called ILOVEYOU and asked players to navigate a shared network while trying to identify the hacker and contain the spread of the virus. Each player was given a copy of the central network graph (Fig. 2) with their starting connections, which were initialized with a friendship level of three. The game then played out in loops of two engaged phases—sending mail and opening mail—and two maintenance phases—refilling your hand and adjusting friendship levels. The game was won by the last player to avoid infection.
More technically, the original mechanics included sending emails (bugged or clean), opening or deleting responses, and tracking friendships levels. The intended dynamics were suspicion of other players and risk assessment (balancing friendship levels with risk of infection); the intended aesthetics were paranoia and deduction; and the outcomes were the spread of the Love Bug hack.
Playtest 1 (Nov 5, in class)
Our first playtest took place in class with Angela, Evelyn, Leyth, and Christina. Angela, Evelyn, and Leyth, who are all young adults studying computer science, which fits into our target demographic (stated originally as young adults who show interest broadly in computer science and enjoy systems games). From this playtest, the main takeaway was that we had ultimately made a digital game and tried to cram it onto an analog format. Many of the current feedback loops were broken because too much information was public, meaning that the balance was severely upset to favor users over the hacker. Angela—who was the hacker—expressed frustration over not being able to deceive others (hackers could originally only send bugged emails), confusion over the win condition (hackers couldn’t win because the “last man standing” always won), and stated that the hacker role felt “inevitable” since the firewall tokens would eventually burn out and players would simply be forced to open her mail (Playtest 1, 16:55).
Moving into version 1, the primary feedback that we took was to make more information private, add more randomness and create a sense of adjacency through the use of a randomized board (hexagons), and allow players to switch back and forth between “teams” through scrubbing (allowing you to discard your infected status).
Version 1 (Nov 7)
In the next iteration of our game, we were sent back to the drawing board (literally, to our massive white board [Fig. 3]) to reconsider many of the core mechanics of our game. Specifically, we were struggling to draw the correct lines between asymmetric information levels and balancing the hacker and users’ likelihood to win. Thus, the main change we focused on in this iteration was information privacy—we basically heaped all of the information in the game behind player screens (see the photos above distinguishing between private and public information… one is not like the other). We changed the win condition in response to feedback from our first playtest so that users win by reaching a given point value, while the hacker wins by infecting all players. We also increased the size of the graph by adding NPCs who could also get infected through gameplay and made the graphs modular by adding hex tiles instead of pre-drawing the nodes. This was motivated by a desire to increase the replayability of the game and introduce more randomness and add a sense of adjacency between nodes to model social networks.
Another key change was allowing players to get rid of their infected status by scrubbing, which helped to more clearly define the win condition for all identities and distinguish the game as competitive rather than cooperative. We also added goal cards and a hacking phase where the hacker could infect NPCs. Finally, everyone was given a mix of bugged and clean emails, and the hacker could only infect someone when they draw a bugged email from their deck.
The addition of goal cards and hex tiles were the beginnings of the major tradeoff in the game: building connections vs. risking infection. While this mechanic was intended to be the motivating factor in Version 0 as well, this is the first version where the tradeoff impacted the gameplay loop significantly since players were now required to maintain connections in order to win via the goal cards.
Playtest 2 (Nov 10, in class)
Play testers: Sebastian, Ngoc, Christina, and Butch
Demographics: Sebastian, Ngoc, and Butch are all young adults, computer science students, and have designed and played systems games. Christina is a pro at all things games but doesn’t enjoy overly-complex systems.
In general, players found the theme of the game cute and were intrigued by the idea of mixing social deduction with a systems game. However, our game still had some fundamental issues with its core mechanics. Specifically, since players could directly connect to any NPC without building intermediary connections, the graph structure didn’t have any impact on gameplay (Fig. 3). This essentially undermined all of the strategies we had ideated, meaning that the emergent gameplay turned into more of a puzzle than a system. We also continued to run into issues with analog play—players were able to identify one another’s emails, and the hacker couldn’t interact with cards on the main board without physically disturbing the table and giving themselves away. Players also noted that goal cards were too easy, which further undermined strategy. Finally, the players felt isolated keeping such a large amount of information behind their screens and were hopeful that future iterations would have more player-to-player interaction.
Following this playtest, we spent many many hours crashing out in office hours trying to fix our system (Fig. 5). Butch knows. We even tried to learn Godot. It didn’t go well.
In this ideation session, we were mostly workshopping the graph itself—the main component that was breaking our system. We played around with hex tiles, trying to make a stagnant graph where players weren’t too close to one another to negatively impact the system. We also tried to reduce the surplus of information that was currently hidden behind player screens—even considering moving the game to a digital couch co-op format. By the end of office hours, we were banging our heads against the wall—we knew exactly what was broken but couldn’t fit together the puzzle of fixing it. We decided to put a pin in the conversation and reconvene the next morning.
Our brainstorm the next day (Fig. 6) was much more productive! With fresh eyes, and inspiration from Watergate’s graph structure (off of Butch’s recommendation), we decided to change the graph to a set of nodes with target NPCs positioned in the center (see the updated graph below). The graph is now publicly visible to all players, which reduces the amount of hidden information, sets a common ground for player objectives, and helps players understand how other peoples’ actions might impact them. Having predetermined nodes and NPC placement also means that players will need to invest in building connections across multiple actions to reach an NPC. This encourages long term strategizing and tradeoffs between when to build connections versus send an email.
We also made the entire game state public, removing player screens and displaying graph connections on the central board. This required drastically reducing the number of hidden components and simplifying the social deduction system by establishing a common and visible goal—connecting to NPCs (Fig. 7). This allowed players to strategize and deduce information based off of other’s actions. We also located real tokens (borrowed from Catan) to better immerse players in the game and remove confusion from the use of dice as trackers.
Playtest 3 (Nov 11)
Demographics: The developers of LOVEBUG (internal playtest)
The third playtest was more of a brainstorming session than a playtest, but we were able to ideate a ton about how the actual mechanics would work and make an actual game. Since we were playtesting the game with ourselves, we were hyperfocused on asking questions and iterating while we tested. We were excited to see that the game felt fully playable now! The onboarding was simplified, the hacker felt as though their hidden identity was protected, and each player felt as though they could strategize around the placement of their connections. However, we still ran into some fundamental issues
Feedback during playtesting was:
- The game is finally playable now (yay!).
- The game is a lot more simple to onboard to and understand
- Players were strategizing around how they place connections so they can block other players from achieving their goals
- Hacker wins faster than players gain points with NPC friends
- The Hacker might need some threat from the player
Changes that needed to be made:
- It was hard to keep track of who sent email to who, especially when the NPCs are also sending and receive mails
- The hacker would need to have more pressure from the players or the game to make it harder for them. As of now, the hacker infects faster than the players gaining points with NPC friends.
- Goal cards aren’t diverse enough and don’t require encourage a lot of strategies. It also does not enable player agency.
Playtest 4 (Nov 12, in class)
Demographics: Playtesters in CS377G, designers with an understanding of systems games
After intensive restructuring for Version 3, we finally were able to bring a fully functional game to playtest in class. Feedback was focused on asking players about 1. If the game was comfortable to play, 2. If the goal cards were achievable, 3. If players felt they had enough agency and interaction with the game, and 4. If players felt they were able to strategize.
Players enjoyed the aesthetics and premise – values we emphasized during brainstorming and development – but struggled to find the system in our systems game. Players didn’t feel their actions led to unexpected consequences, goals felt too easy and not diverse enough, and all players spent their entire first turns taking the same action (placing three connections). Finally, the Hacker didn’t realize they were the hacker until we had ended the game and revealed the other players’ roles.
Of course we wanted players to engage with the system in our systems game, but we were concerned about the goals feedback. The goals and points system was meant to create a competitive type of fun within players, and the lack of engaging goals did not make players feel this way.
The issue of the Hacker not knowing their role was directly addressed by writing the word Hacker on their identity card, and we spent a lot of time brainstorming new goal cards for Version 4.
Playtest 5 (Nov 16)
Players: Martin, Zoe, Gabe, Christelle
Demographics: 22-year-old STEM students; all players are familiar with systems games
Throughout our playtest, people seemed genuinely interested in the game, thought the system we were modeling was intriguing, and pitched really cute design ideas for our cards and board! This iteration was also much more playable than previous versions — the larger graph and increased number of NPCs added more complexity and dynamism to the game (Fig. 8). However, from this playtest, we learned that despite the scaling of our board, we needed to make it even larger. This state was still too small and crowded. As a result, the goal cards were much too easy. Furthermore, there was not enough risk embedded in the game, thus undermining the intended social deduction aspect of the system.
As a result, we plan to make the board bigger, space players out, and rework our goal cards to add more of a challenge and risk. With reworked goal cards and more competing interests, this should also reintroduce the social deduction aspect to the game. Before play testing again the next day in class, we adjusted the graph to be symmetrical and rewrote some of the goal cards to increase balance, ensuring that all players had equally difficult goals.
Playtests 6/7 (Nov 17, in class)
For our final in-class playtest, we were able to test three play throughs with two groups. Playtest link here!
Group 1: Angela, Evelyn, Marielle, and Leyth
Demographics: All young adults within our target age range
Up to this point, this was by far our best playtest with a new graph seen in Figure 9. Players were able to successfully complete multiple rounds before reaching a viable win condition and there were relatively few broken mechanics throughout the play through. The main comments that players had at the end were all balance related—increasing the consistency of wording on goal cards (5:00, 17:25, 39:09, 45:36), adjusting the difficulty of goals and the number of points required to win (36:40, 37:38, 37:50, 42:04, 43:14), and increasing the size of the graph.
Group 2: Luna, Sebastian, Aalaap, and Marielle
Demographics: All young-adults in our target age range
The play-throughs with the second group were much shorter, with Sebastian winning within the first ten minutes both times. This reflected the importance of balancing our goal cards and increasing the difficulty of the win condition for users. Between the play-throughs, the game was adjusted by ensuring that everyone had the same number of Easy/Medium/Hard goals in their hand and reducing the connection action to placing a single token rather than two. However, both playtests had the same end result of a quick win by a player with a “User” identity.
The feedback from these playtests was invaluable in making the final changes to balance our game. We use the Rule of Two’s to balance our graph and win conditions, doubling the graph size and required points to win (Fig. 10). We also increased the number of NPCs by three.
Version 5 (Nov 17)
This was our nearly-finished version! Major changes from the previous included increasing the size of the board to 81 nodes from 37 nodes (Fig. 11), increasing the number of NPCs from 6 to 9, and upping the required score for a user to win from four to eight. We also updated the goal cards in response to feedback from the in-class playtest by adjusting the wording and increasing size requirements to better fit the new board. We also decreased the physical size of emails significantly so they would fit on the nodes themselves. Finally, we added bugged emails on 3/9 of the NPCs to balance the game back towards the hacker. This abstracted a bit from the real-world system, but was based on the assumption that the NPCs might have gotten hacked via their external network and represented the intrinsic risk of connecting with someone new online.
Playtest 8 (Nov 18)
As our final polishing step, we playtested once as a team with our almost-finished version (Fig. 12). We verified that the changes to the board state made sense and that each of us felt as though the game was “winnable” from our role. We ultimately ended up adjusting the board size to 64 nodes (almost the exact double of our in-class size—the rule of 2s is magic!) and the point value to 6 points in order to win (Fig. 12). We also made a few more balancing changes to the goals, adjusting those that felt too easy or too hard, and removed the dynamic of allowing players to send mail directly to one another. Finally, we added edges along the outside of the board graph to make players equidistant from three NPCs to start so there were multiple viable strategies for the starting path and increased the number of starting bugged emails to 4/9. Changes and feedback from this version were:
- Adding in diagrams to rulesheet to clarify how to place connections (5:36, 9:39)
- 6:49: Added more background about what the Love Bug actually was to give context to game dynamics – this group skimmed the rules and relied on play testers to supplement knowledge and lead to random actions (like sending to an NPC that they weren’t connected to) Adding context guards against this in the future
- 8:30: “This is a cool concept”
- 13:40: “What happens if you have two of the same goal?”
- 17:16: “Wait, Asimov isn’t Powder’s father?” (joke)
- 18:56/21:29: “I wanted to go that way” – evidence of successful competition aesthetic!!
Playtest 9 (Nov 21) and Final Version
Linked here!
Play testers: Julia K.S., Julia F., Anthony
Demographics: 22-year-old master’s students who enjoy social deduction games and have a medium amount of experience in systems games
Our final play-through went well! It was fun to see all of the components printed out (Fig. 13), and after the play test, our friends pointed out which characters were their favorite (DoubleBubble was the fav). Players also noted that they enjoyed the concept and design of the game (8:30, 17:16). Some last-minute changes we made to the design in response to the play test included adding diagrams to the rulesheet to clarify how to place connections (5:36, 9:39) and adding more background about what the Love Bug actually was to give context to the game dynamics. This play testing group wanted to jump into play, so they skimmed the rulesheet and relied somewhat on us as play testers to explain the intricacies. This led to some confusion about fundamental game dynamics that I think would have been more intuitive if the players were more grounded in the game’s background (6:49).
It was great to see some emergent strategies and competition coming out in this play test (18:56, 21:29)! Players were focused on route building, sending emails, and avoiding connections with others. They noted that the game might be even more fun if it was scaled up further to include more players and longer paths.
The main point of confusion in the game was still around goal cards, including what happens if a player gets two of the same card (13:40). Otherwise, there were relatively few mechanics questions, and most of the clarifications we made were just rephrasing the rulebook directly.
