An asymmetrical strategy game about viruses and the immune system. Documentation available!
The final product:
Role: Systems Designer, UI Designer, Technical Designer
Tools: Unity, Visual Studio, C#, GIMP, Google Docs, Google Draw, Google Forms
Team Size: 4 people pre-Greenlight, 5 people post-Greenlight
For a Production II project, the people on my team wanted to keep the scale small, but still manage to create something interesting and innovative. Our artist was also interested in making something educational, which was an angle that really inspired the team. After suggesting ideas about chemistry and electronics, we came across the idea of a game based around viruses, which lead us to make Infection.
You can click here to read the finalized design doc for the game, though some of the diagrams there will be used below. Once the project is completed, I’ll write a postmortem about the whole experience. The rest of this page is going to highlight some of the obstacles faced each milestone, and what we learned from them.
Planning and Proposal:
From the beginning, we envisioned Infection to be a turn-based strategy game, with players moving units that were different types of viruses. Each virus would have its own special ability based off of the organism it was named after, and would have the ability to “incubate”, which would create a duplicate of the piece after a couple of turns. When a virus moved onto a red blood cell, the cell would become “infected” and change to the team’s color, adding a territory-capturing system. These mechanics are still in the game, and have remained fairly constant.
Fig 1: The Infection VDD as of Alpha
What did change, however, were the teams; initially, we had just envisioned two teams of viruses competing. When we proposed our game, however, one thing really bothered the professor, as well as the other teams: why are the viruses fighting each other? Where is the immune system? It certainly didn’t make sense since we were proposing this as educational. In order to get approved at Greenlight, we realized we had to change this. After some intense debate, we circled around to something similar to what we had. One player would play as the immune system, while the other would play as the viruses. We resolved to implement this by Greenlight.
The challenge with having these two different teams was differentiating playstyles. It certainly didn’t make sense to have the immune system infecting red blood cells. Instead, we decided to have white blood cells destroy the viruses, similar to taking pieces in chess. Once all the viruses were destroyed, the immune system would win. The viruses would still be able to incubate in order to replace lost pieces, and would need to infect a certain percentage of the board to win. With this asymmetric play designed, we prepared for Greenlight.
Fig 2: Gameplay loops for both teams
The first thing was coming up with pieces. Their abilities needed to be similar to what the actual organism behaves like, but still make sense in the context of the game and be fun. The immune system was easier, basing pieces on different types of white blood cells. Viruses were harder, however; since the game was taking place on a board of red blood cells, it made sense that all the pieces should be based on blood-borne illnesses. I had to branch out into researching other organisms, such as bacteria (which gave us the Tetanus piece), and fungi (which inspired the Aspergillus Fumigatus piece).
Presenting these changes at Greenlight, we got a positive experience, to the point where we got the most votes from our classmates to move on. Another team in the process got cut, and the members needed to be assigned to new projects. We decided that the design and art didn’t need much help, and that what we really wanted was to have networked multiplayer. We pulled the programmer from the cut team, who was fortunately familiar with Bolt, a networking codebase for Unity. Confident with the positive feedback and a new team member, we decided to push to get networking functional by Alpha.
Unfortunately, networking was something we hadn’t been coding around, as our new teammate quickly told us. A lot of the existing code had been written to be functional, as opposed to well-optimized. Re-factoring was something the initial programmer and I had mentioned doing at some point, but the reality of it was staring us in the face. Our networking programmer laid out an ultimatum that really bothered us; if we didn’t re-factor our code, we might have to scrap local multiplayer altogether.
We got to work rearranging whatever was needed to get both local and networking functional. We also had to keep certain things in mind while implementing new features; for example, while implementing all of the pieces, I needed to have their abilities override a base “PieceFunctions” class in order to keep things organized. A lot of the pieces and UI elements needed to be created in code as well, preventing errors from initializing objects that were already in the scene.
Fig 3: A screenshot of the game at Alpha.
Another thing that needed to be created was a tutorial that introduced the players to the different mechanics for each team. In order to accomplish this, a tutorial scene was made using something our programmers referred to as “slideshow programming”; the tutorial would feign interaction, but would only be able to progress if they clicked exactly what we wanted them to. In this way, the player wouldn’t be able to deviate from what we wanted to teach them.
By our “Pre-Alpha” presentation (our professor pulled a bait-and-switch about the Alpha date!), the networking was buggy, but operational to an exciting degree. All the pieces were in with their art assets, and a basic tutorial was already functional. Given that we would have another week to accomplish our Alpha goals, we were feeling confident with the amount of progress we had made.
After getting most of our features in, it seemed like a lot less work was needed in order to finish the game. Instead, a lot of refinement was necessary; I worked with our artist to get a lot of the UI functioning and easily readable, while the main focus programming-wise was bug fixing.
That lead to some troubles with a piece, however. Rubella had an ability to vanish from the board for several turns, then reappear on infected cells. The problem was that this created confusion with the players, could easily be exploited, and resulted in a number of bugs. I was asked to change the piece, though it was a bit late in the production process for comfort. I came up with the ability for the piece to swap positions with another virus piece, and got it implemented in the code quickly.
In the final stretch, the game seemed to be in a good place. Bug fixes, tweaks with UI, and added player feedback were all expanded upon.
Fig 4: A screenshot of our final build
While we had been doing playtesting before, it was all in the local mode. However, the networking mode was getting polished enough that we could start having playtesters on two different computers. A snag came up, though; the code for the server list didn’t seem to be working. In addition, the development server for Bolt, the networking framework we were using, didn’t seem to be operational. Instead, the programmers decided to have players enter each other IP addresses manually; it wasn’t an ideal solution, but it was functional and achievable in the time we had.
The networking playtests helped us expose a lot of bugs, but it was also really exciting to finally see it work so well. It was unfortunate that, during our presentation, we weren’t given a chance to demonstrate this, our time having been consumed by the tutorial instead. Still, our classmates seemed to really enjoy playing it, and the campus director said that she really liked the concept.
The one thing that the professor kept mentioning, and something that we had intended from the start, is that the scope of Infection was fairly small. This was largely so that we could have enough time for our other projects that semester. Despite that, we still had to cut some features out of the game, including a deck that pieces would be randomly selected from during the draft, and multi-round matches. A big feature that we had wanted early on was to get a version working on mobile and tablet devices, though we cut this in the interest of the programmers’ sanity. Our screen resolution stayed the same, though…
One thing that was very helpful was that we had implemented our core gameplay (movement on tiles, capturing pieces) very early on. This allowed us to playtest early and often, and focus on more emergent issues, such as what UI was needed. Getting in different piece abilities was simple as well, as our initial programmer set up a method for making new script components for each piece type.
As a designer, I hadn’t had a lot of experience making UI, and absolutely no experience designing around networking concerns. Both of these were largely absent from the design document I had written up, and I hadn’t considered that players would want a way to remember the stats of the pieces, or that they would need a visual element for movement increases and decreases. I’m now a lot more aware of what elements will be needed to indicate information to the player, as well as specifying what needs to be updated when for networked play.