Project Summary
Qualified Immunity is a 2D detective/mystery game set in the dystopian Colander City. The player operates as Colander City Police Department’s newest probationary officer, Sal Troppo, and follows his investigations around the city, uncovering the secret cult that runs deep underground across a series of missions. Each mission tasks the player with identifying clues and suspects, and success is determined by the player’s ability to correctly find the culprit of each crime by combining clues and testimony.
This game was developed by team Last Braincell, a 5-member team consisting of me, writers Alex Kohl and Catherine Kim, artist Ashli Black, and coder Victor Do. More credits can be found on the Itch.io page for the game, linked above.
Work and Credits
Qualified Immunity was developed by Last Braincell, a small 5-member project development team. The team’s members and their responsibilities were:
- Alex Kong (Me) – Designer & Coder
- Alex Kohl – Writer & Audio
- Ashli Black – Artist
- Catherine Kim – Writer & UI/UX
- Victor Do – Designer & Coder
Reflections and Development Process
Towards the last few semesters of university, I began working on projects that had me step out of my comfort zone or pushed me to expand my skillset to tackle new obstacles. Qualified Immunity was one of these projects. As part of UT’s AET program, final-year undergraduate students were tasked with forming teams and pitching and producing an interactive project of their choice. Each team was assigned a professor as their executive producer, and would meet with them on a regular basis to deliver progress updates and discuss production issues.
The five of us formed our team very early on into the semester. Most of us were either friends or were familiar with each other beforehand, so we quickly built up a rapport that would help us maintain good coordination and cooperation as the project unfolded.
Inspiration
The concept of creating a detective/mystery game set in a dystopian world sprung from Catherine’s idea of creating a game centered around identifying and preventing relationship abuse. After much discussion, we decided to take the idea a step further and focus on the abuse of power as a core part of the game’s story. To enshrine this narrative component, we chose to go with the name Qualified Immunity for the game. Qualified immunity is a type of legal defense that, in short, shields government officials from being sued. Broad interpretation of this principle, however, can allow law enforcement and other officials to act unconstitutionally with little to no punishment. This is reflected by many parts of the game’s story, as the player will uncover a pattern of corruption that runs deep within Colander City’s police force, and even within the city’s government itself.
We also wanted to avoid creating “just another dystopian game.” To give the game’s narrative and aesthetics a twist, we wanted to combine the otherwise darker tones of the game’s core narrative aspects with lighter overtures – pasta, in particular. Alex had the brilliant idea to tastefully scatter pasta-related puns throughout the game. Many names of places and people (e.g. Colander City, Police Chief Rotini) were also inspired by pasta. The question is, why pasta? During our research and brainstorming phase, we learned of Pastafarianism, or the “Church of the Flying Spaghetti Monster”. A parody religion, we felt that it spoke very closely to the “light overtures” we wanted to employ in our storytelling and visuals, so we chose to infuse the game with a healthy serving of pasta moving forward.
The Core Gameplay Loop
We sought to keep the basic gameplay straightforward, and settled on the loop below.
Each mission would be relatively open for the player to explore. Upon entering a mission, the player could seek clues by interacting with objects and NPCs scattered around the level. Clues would be “collected” in a journal of sorts the player could access with a keypress. Once the player was satisfied with the clues they gathered, they would interact with the accompanying Officer NPC to enter the suspect identification phase. In order to complete the mission, the player would need to accuse a suspect of committing the crime, then support the charge with proper evidence using their gathered clues. The Officer would determine whether the accusation and evidence makes sense, and if the player is unsuccessful, they would be able to make another accusation attempt. Upon a successful accusation, or too many unsuccessful attempts, the mission would end, bringing the player back to the Police Station lobby area.
The Development Process
From the start, we wanted to ensure that the pipeline for implementing content from our artists and writers into the game would be as streamlined as possible. We wanted our non-coders to be able to focus on working on their content without worrying about messing around with too many elements of the engine, so the coding team developed a series of systems that would allow for easy drag-and-drop or copy-and-paste functionality. While my counterpart adapted the dialogue system to enable the writers to build quick and easy dialogue sequences, I worked on developing a modular mission structure to enable quick mission creation and management, and a map system that would work in tandem with this mission structure to determine how missions were unlocked and accessed.
Within missions, we also worked on a robust clue collection system that allowed us to tag various items and dialogue options as clues that would be collected in the player’s journal. This and the accompanying suspect identification system took a significant chunk of time to build and polish, but it enabled us to add flavor to game mechanics that the player would interact the most heavily with, alongside the dialogue system.
Another important aspect of Qualified Immunity’s design is the isometric perspective the game is built in. One challenge we faced was producing this isometric gameplay perspective while purely using 2-dimensional artwork. While it may have been easier to work in an isometric perspective with 3-dimensional assets, our team in general was more comfortable with working in 2D, and we wanted to make use of everyone’s best skills. We spent a few days playing around with different solutions, initially using a 3D environment with 2D sprites. Eventually, we settled on a system that would mathematically determine the rendering order of different objects based on those objects’ collider bounds, and the player’s y-position in comparison with those objects’. This worked surprisingly well, mainly because we only needed to worry about player movement; all other objects in the different game scenes are static. Furthermore, because this system was wrapped in a single script, we simply needed to add the script to any object in a scene that a player might be able to move around, and code would do the rest. My task for a few weeks was fine-tuning this Isometric Object Sorter to clear different edge cases that we caught during playtesting; some objects, for example, had unusual collider borders that the script wouldn’t play nice with, so the script needed to be adjusted to allow for these cases.
Issues and Development Difficulties
Our biggest enemy during development was, naturally, time. Milestone deadlines we needed to meet meant that along the way, we inevitably needed to cut planned features and trim existing ones. These periods of content triage occurred primarily during the first and last months of development.
The first content triage period focused on cutting content that was too ambitious for the agreed-upon scope of the project – content that would require far more time than we could afford investing, or content that would expand the project scope beyond what we could manage. One example was the map and mission system; originally, we wanted the game to have both a line of main story missions, and a set of side missions that would appear randomly as the player progressed through the game. These side missions would have been procedurally generated, drawing from a list of components – mission objective, mission NPCs, rewards, and so on – and would give the game replayability even once the main storyline had been completed. Unfortunately, the sheer number of factors that would have been introduced (e.g. character and environment art, dialogue lines, and more) with such a system would have put too much strain on our team, and we canned this idea early in development.
Another feature that was cut early was a day-night time cycle. Originally, the player would have a “time bank” of sorts – each mission would take a certain amount of time to complete, and that time would be deducted from the player’s time bank. Once the player ran out of time in the day, the day would end, and the next day might introduce new missions and old ones might disappear. This system would have accompanied the procedural mission system, and when that feature was cut, this one went with it.
Final Thoughts
Qualified Immunity ranks among my favorite projects, not least because of the extensive codework the game required. Qualified Immunity was also the first game I developed as part of a team of more than three people, and first and foremost amongst the lessons I learned from this project was the importance of cohesive teamwork. While, as mentioned before, all of us were somewhat familiar with each other in some capacity prior to this project, we had not yet worked together as a team. The early stages of development involved us understanding the strengths and weaknesses of each team member’s skillset, so we could set reasonable goals and better conceptualize how to blend our various talents together. This learning was not restricted to early development, however, and as work on Qualified Immunity progressed, we continued to adapt as needed to cover each other’s backs as needed (e.g. working on tasks that normally would have been assigned to a particular team member if existing responsibilities or limited time left that individual indisposed).
Part of maintaining cohesive teamwork was ensuring a standard of amicability amongst the team throughout the length of this project. Each of us sought to ensure that everyone felt comfortable within the team, and this understanding led to quick resolutions on any challenges or obstacles we encountered. We trusted each other’s expertise in the areas we specialized in, and generally deferred to this expertise if needed during production discussions. Differing visions for parts of Qualified Immunity often led to thoughtful debate, rather than conflicted arguments or unnecessary friction.
Another important lesson learned was the importance of content triage, and knowing when to cut your losses. Many of the game’s planned features were cut during various stages of development due to time constraints, and the final product differed quite significantly from the team’s original vision. We were in several cases forced to cut some of these features almost last-minute, which often led to “uh-oh” moments where we needed to scramble to develop new solutions.
Good time management and planning went hand-in-hand with content triage. During early project planning, we envisioned several ambitious features that needed to be trimmed as development pressed on and we better understood the time that our individual tasks would take. I certainly fell culprit to this, and while we were ultimately satisfied to some degree with the final state of the game upon release, I sometimes wonder what the game could have been like under different circumstances. Underestimating the magnitude of the project was a tough lesson that we all took to heart, and will doubtlessly remember for all of our future works.