2025 COMSM0166 group 9
Click me! You Can Play The Game Here! 🎮🧪🌸
Click the image above to watch our gameplay video on YouTube!
- The Group
- Introduction
- Requirements
- Design
- Implementation
- Evaluation
- Process
- Sustainability
- Conclusion
- Contribution Statement
- References
| Name | Username | |
|---|---|---|
| Vera Babasa | ho24168@bristol.ac.uk | VeraB08 |
| Satvika Mallela | ig24071@bristol.ac.uk | satvikamal |
| Abdul-Hakeem Lamptey | qw19275@bristol.ac.uk | ahl-hx |
| Maram Abdulaziz Alhussain | ho24644@bristol.ac.uk | MaramAbdulaziz1 |
| Hadeel Ibrahim | po24432@bristol.ac.uk | hadeelibrahimn |
When designing our game, we set out to create a puzzle-platformer that encourages players to work together under time pressure. Inspired by Fireboy and Watergirl, we aimed to develop a game where each character has distinct roles and unique obstacles to overcome, making coordination essential.
Players take on the roles of two university students, a chemistry student and a botany student, who have accidentally infected themselves with a virus during a joint experiment. Trapped in an abandoned science building at the University of Bristol, they must work together to gather the necessary components to create a cure and escape.
The game is set within a multi-floor maze connected by a lift system. Each floor contains character-specific challenges and puzzles. To win, players must collect two ingredients (one per character) and a key to unlock the lab. Only certain characters can collect certain ingredients, requiring teamwork and strategic navigation.
There are two difficulty levels: easy and hard. Both feature different maze structures, but only the hard mode includes puzzles that must be solved to access ingredients. A countdown timer adds urgency to the gameplay - players must reach the lab with the ingredients and key before time runs out. If either player dies, the game restarts.
| Character | Description | Ingredient | Puzzle Description |
|---|---|---|---|
 Chemistry Student |
A student specialising in chemistry, responsible for collecting chemical compounds. |  Chemical Compound |
Identify the correct order of vials needed to complete the experiment. |
 Botany Student |
A student specialising in Botany, responsible for collecting rare plants. |  Rare Plant |
Guess the name of the flower. |
Requirements Engineering is a thorough process to create and develop the requirements of a software system while managing the needs and expectations of the stakeholders. The requirements fall into two categories - functional and non-functional. Requirements engineering is vital as it tells every team member what to do. This leads to an optimised development process. (Irum Inayat et al., 2014)
Our team pitched two games each to serve as inspiration for our final idea in our group chat. Each game pitch comprised of our proposed idea for a ’twist’, ways to adapt the game, and a pros and cons list. Along with this, we expressed any challenges our team may face during the implementation of each game. The top two ideas to base our game on were Space Invaders and Fireboy and Watergirl.
Our initial idea involved fighter jets shooting out ‘enemy/alien’ ships while adapting to weather conditions, returning fire, changes in altitude, and birds. To make the game more challenging, we introduced a time limit and bullet restrictions. When presented to players, our team applied the twists to the existing games. The feedback from test sessions informed us that the game was easy to understand and play. However, Dr Bennett suggested that it was too similar to Space Invaders, so we changed course.
Potential game ideas and voting
During the same testing sessions, our team presented a game based on Fireboy and Watergirl. Players were more enthusiastic and willing to play the game multiple times. Hadeel, a team member, created a digital prototype to help us visualise the new idea.
Our initial idea was to develop moving platforms for the game and allow players to start and stop them. Additionally, a magic door feature, enabling players to swap their positions in the game. To represent the idea, we created a paper prototype video:
Initial Prototype Video: https://youtu.be/2q2cDIboFrI?si=yGbFsBmup3uEhzl5
Building on this foundational idea, we developed several concepts to make the gameplay more engaging and challenging. This included the introduction of cooperative puzzles and an expanded narrative structure. We created a digital prototype video, which later served as a key inspiration for our final game concept, "Race for the Cure".
Inspiration Prototype Video: https://youtube.com/shorts/O2Wved8YsHU?si=evTJdVszApQ8bumC
The team developed a final interactive prototype to showcase the core concept of the game. The prototype reflects the finalized vision: a CoopPuzzleGame that emphasizes cooperation, exploration, and problem-solving between two distinct characters. This video demonstration serves as a visual summary of the gameplay mechanics, level design, and user interface elements we have worked collaboratively to build.
Final Prototype Video: https://youtube.com/shorts/r6emoXvEDbI
Digital prototype
Stakeholder Onion Model
1. Product: Race for the Cure
2. The System: Development Team, Normal and Maintenance Operators
- Group 9
3. The Containing System:
- Casual Gamers
- Competitive Gamers
- Gamers with Disabilities
- Young Gamers
- Elderly Gamers
- Platform Hosting the Game
- Assessors
4. The Wider Environment:
- University of Bristol
- Parents of Young Gamers
1. Gameplay & Mechanics
Ensuring smooth, enjoyable, and challenging gameplay
- As a new player, I want a tutorial mode that explains the game mechanics and rules, so I can learn how to play efficiently.
- As a casual player, I want the game to be intuitive and easy to learn, so I can start playing with minimal effort.
- As a competitive player, I want a challenging difficulty level and a ranking system, so I can compare my performance with others.
- As a player, I want smooth and responsive gameplay, so I can play for extended periods without fatigue.
- As a player, I want minimal lag between audio and visuals, so the game feels synchronized and immersive.
- As a player, I want sound effects when characters move or interact with the environment, so the game feels more engaging and responsive.
- As a competitive player, I want level completion times to be recorded and displayed, so I can compete against others based on speed.
- As a competitive player who frequently replays the game, I want an option to skip non-gameplay animations and introductions, so I can focus on gameplay.
2. Accessibility & Inclusivity
Ensuring the game is playable for all users, including those with disabilities or specific needs
- As an elderly player with limited vision, I want an option to adjust text size, so I can read in-game text comfortably.
- As a color-blind player, I want customizable color schemes, so I can distinguish game elements easily.
- As an impressionable young player, I want the game to avoid excessive violence, so the content remains appropriate for my age group.
- As the University of Bristol, I want the game to avoid insensitive or discriminatory depictions, so it remains inclusive and respectful to all players.
3. Narrative & Aesthetics
Ensuring the game has an engaging story and a visually cohesive design
- As a player, I want an engaging introductory sequence that explains the game's lore, so I can be immersed in the story.
- As a player, I want a consistent art style, so the game remains visually appealing and cohesive.
4. Technical & Development Considerations
Ensuring efficient, scalable, and maintainable development
- As a developer, I want the game to follow a modular design, so features can be added or removed easily.
- As a platform hosting the game, I want the game’s file size to be optimized, so it does not consume excessive server space.
- As an assessor, I want the game to feature a unique twist on a classic concept or an advanced implementation challenge, so the game demonstrates originality and technical depth.
Before settling on classes we first mapped the high level behaviour of the game with use case diagrams. A use case diagram captures the game from an actor's point of view. Visualising the system from the actor's perspective, in this case the player, helped us identify key interactions early, and helped define clear boundaries between gameplay and menu logic. Aspects of this high level view remained stable even when lower level class and sequence diagrams changed, giving us a constant reference during sprint planning and reviews.
.jpg?raw=true)
Preliminary use case diagram showing system interactions.
Brief Description
The Player navigates either the Botany Student or the Chemistry Student through a level, solves puzzles, collects objects, and reaches the exit portal to complete the level.
Primary Actor
- Player
Preconditions
- A game session is active and a level is loaded.
- Accessibility settings (colour filter, font size) are configured.
Postconditions
- Success: Level is marked complete; next level loads or Win Game screen appears.
- Failure: Lose Game subflow (Game Over) is invoked.
- System displays controls and HUD:
- Botany Student: W/A/S/D to move & jump
- Chemistry Student: directional keys to move & Space to jump
- Player moves and jumps around the environment, avoiding obstacles.
- Upon reaching a puzzle portal, System launches the Play Puzzle Game subflow.
- Player solves the puzzle.
- System returns to the main level map.
- Player collects any available object via the Collect Object subflow.
- Player proceeds to the exit portal.
- System marks the level complete and either loads the next level or displays the Win Game screen.
-
1a. Pause & In-Game Menu
At any time, Player presses Esc → System pauses and displays the In-Game Menu subflow (Replay Tutorial, Quit Game, Restart Level). Resume returns to step 1. -
2a. Time Out
If Player runs out of time during movement/jumping → System invokes the Lose Game subflow. -
2b. Stepped on Obstacle
If Player steps on a lethal obstacle → System invokes the Lose Game subflow. -
3a. Puzzle Failure
Player fails the puzzle → System respawns them at the portal entry to retry the Play Puzzle Game subflow.
Subflows & Includes
- Play Puzzle Game
- Collect Object
- In-Game Menu
- Lose Game
- Win Game
Before undertaking the coding stage, our team first drafted a class diagram to act as a structured framework for our game. A class diagram is a core component of Object-Oriented Design (OOD). It visually represents the classes in a system, their attributes, methods, and the relationships between them (e.g., inheritance, associations, and dependencies). It was important for us to create a class diagram early on, because it would help us understand the system’s structure at a high level before diving into implementation. It also ensured that key design principles such as encapsulation, modularity, and reusability were considered. Therefore, allowing us to plan how objects would interact, identify potential design flaws, and improve collaboration within the team by providing a shared understanding of the system architecture.
Class Diagram
The GameManager class is the game's main controller, monitoring overall progress, managing state transitions among the game states, and making sure players reach win or fail conditions. It controls the GameController directly, which manages individual game logic like monitoring the cure components that have been collected, monitoring the players' status, and managing the countdown timer.
The Player class, that extends from GameElement, is utilized to define the two game characters: the Chemistry student and the Botany student. The characters possess certain skills and interact with various game elements such as Floor, Lift, Puzzles, Obstacles, and CureComponents. The Floor class, extending GameElement, is utilized to define the multi level game structure in which puzzles, obstacles, and significant items are placed. It contains methods for creating the layout and placing interactive objects such as walls, lifts, and pathways.
The Lift class offers a way for players to move between floors, responding dynamically to player input. Players also face Puzzles, which need to be solved in order to enter specific areas or unlock cure parts. Every puzzle has a type, a timer, and rewards when solved successfully. The Obstacles class adds obstacles that block player movement or need careful actions to disable. Barriers can be immobile (e.g., walls) or mobile (e.g., moving obstacles), and they damage player health or progress.
The CureComponents class is the main ingredients that must be collected in order to create the cure. The component is assigned to a specific player depending on their specialty (Chemistry or Botany), and coordination is required to complete the task. The GameController checks if all the cure components have been obtained, and upon completion, it signals the GameManager to begin the final challenge to beat the clock in reaching the lab before the virus can fully mature.
Trying our best to stick to Agile Development principles, we endeavored to be flexible with our initial designs. After each play‑test we compared the behaviour we observed on screen with the structure we had drawn, refined the code to address any discrepancies, and only then revised the diagram. This cycle—code, test, adjust, document—kept the model lightweight, ensured performance remained acceptable, and allowed new requirements to slot in without large‑scale rewrites.
Early play‑testing highlighted several performance and maintenance issues in the original design. The first concerned the Floor class: modelling every platform as an object created a large number of allocations and slowed collision detection. We replaced the class with a single platforms[] array of axis‑aligned rectangles and used a dedicated utility function to perform the collision calculations.
The player hierarchy was simplified for similar reasons. Both student characters share identical movement and physics behaviour, so maintaining two full subclasses duplicated logic. We retained a common Player base, while each role‑specific subclass (Chemistry, Botany) overrides an update() method tuned to its own key bindings (arrow keys for Chemistry, WASD for Botany) and implements an updateImages() helper that refreshes its left‑ and right‑facing sprites whenever the active colour‑vision set changes; the puzzle classes read a simple role flag to adjust interactions.
Additional functional requirements surfaced as the prototype matured, prompting two focused utility classes. The ImagePreloader builds three complete image sets—default, protanopia, and deuteranopia—during application start‑up, and its loadSet(filter) method swaps every texture at runtime, enabling colour‑vision accessibility without code duplication. For audio, each effect is wrapped in its own SoundManager, a thin layer on top of p5.Sound that standardises play/loop behaviour and maintains independent volume levels, preventing overlap artefacts and centralising sound configuration.
Each change followed an implement‑test‑refine cycle; the diagram was updated after stabilisation so that documentation remained aligned with the code. We eventually ended up with the following final Class Diagram.
Final Class Diagram
Final Class Inventory
| Class | Responsibility |
|---|---|
| GameManager | Central state machine; moves the application between home, difficulty‑selection, gameplay, win, and game‑over states, and triggers the corresponding music and sound effects. |
| GameController | Maintains ingredient counters and puzzle completion flags, monitors both players, and signals GameManager when win or loss conditions are met. |
| GameLoop | Executes once per frame; processes input, updates physics, puzzles, lift, timer, and UI, and performs collision checks. |
| UIManager | Renders menus, pop‑ups, HUD, and settings; routes mouse and keyboard events to the correct UI element. |
| TimeManager | Maintains the global countdown timer; supports reset and pause; provides a formatted “MM:SS” string to the HUD. |
| ImagePreloader | Loads three colour‑vision asset sets (default, protanopia, deuteranopia) at start‑up and swaps active textures at runtime. |
| SoundManager | Lightweight wrapper around p5.Sound; standardises play/loop/stop and independent volume control for each effect. |
| Player (base) | Implements shared physics, movement, and sprite handling; stores a role flag consumed by puzzles. |
| Chemistry (subclass) | Uses arrow‑key input; overrides update() for its control scheme; role flag set to “chemistry”. |
| Botany (subclass) | Uses WASD input; overrides update() for its control scheme; role flag set to “botany”. |
| Lift | Controls elevator motion between floors and synchronises any player standing on the platform. |
| ChemistryPuzzle | Manages the book‑and‑vial question sequence and awards the vial ingredient when answered correctly. |
| BotanyPuzzle | Manages the note‑and‑flower identification sequence and awards the flower ingredient on success. |
A sequence diagram complements the class diagram by showing the order in which objects exchange messages. We used it to confirm that, in every frame, physics, puzzle logic, timer updates, and win/loss checks occur in the intended order. The following diagram illustrates the core flows of our game—from the launch sequence through the gameplay loop that repeats throughout play.
Simplified Core Sequence Diagram
The lift’s movement changes based on the level of the game. In the easy level, the lift operates in two modes: ground floor to first and first floor to second. The change in movement is triggered by a character standing by the lever and pressing the letter “S”. In the hard level, it travels from the ground floor to the second floor in one motion. The challenge with this is altering the minimum and maximum positions of the lift.
Easy Level Lift
floorOne and floorTwo are already defined in sketch.js. Therefore, the most efficient way to precisely implement the two modes is to assign the values in these attributes to nextMinFloor and nextMaxFloor within the Lift class. To ensure that the transition between floors is seamless, Boolean logic is used with the attribute inTransition. This is set to true when the lift has not yet reached the value in targetFloor; it contains the same value as nextMaxFloor.
Since most of our team are not gamers, we wanted to make sure our game appealed to both gamers and non-gamers. Our objective was to create a game that was simple yet engaging. One of the first steps we took to achieve this was to create a user-friendly interface.
Race For The Cure had several iterations. The finalised layout and colour scheme were driven by the feedback received during the Think Aloud and Heuristic evaluations. Initially, we had one instruction page detailing a backstory, how to play, the controls, and what to collect. Our team also wanted to lean further into the pixelated aesthetic. However, we felt that it was too much information to present to the player at one time. Coupled with the aesthetic, the instructions were difficult to read.
Early version of the Instruction Page
Our solution - present bitsize information that is pertinent to gameplay throughout three cards.
How to Play pages
The feedback from the qualitative evaluations suggested that some more clarification at certain points in the game would benefit the user experience. So to further improve user interface, we created popups to indicate when an ingredient has been collected or to provide in-the-moment instructions and error messages.
The evaluations pose another question: What if the player solves the puzzles and obtains both the vial and the flower using a single character? To promote the use of both characters, we designed them to be able to acquire ingredients that are exclusive to their speciality, such as the Botany student can only retrieve the flower. The chemistry student can only retrieve the vial. In the hard level, only students of the science can solve the puzzle to collect the vial or the flower.
Character Specific Interaction
Protanopia and Deuteranopia are the most common forms of colour blindness. Those with Protanopia are likely to perceive some shades of blue with red, purple or dark pink and green with orange. Those with Deuteranopes are likely to perceive red with green or brown, bright green with yellow, and light blue with lilac. The colours listed here are the ones that would directly affect colour blind users when playing our game.
For example, all of the pages are various shades of blue, and one of the puzzles implemented in the hard level requires the identification of the colours red, green, yellow and purple.
Original
To ensure that colour blind players are offered the same experience while playing as those who aren’t colour blind, all of the images are processed through a colour filter and called upon in the ImagePreloader.js class. Depending on the accommodation a player chooses, images with the suffix RBP will be called for Protanopia and GBD for Deuteranopia. When preloadImages is called, it takes the root image name and combines it with the respective suffix. Then all relevant images are loaded into setImgs.
Accomodated version of the Chemistry question and Easy level map for Protanopia
Accomodated version of the Chemistry question and Easy level map for Deuteranopia
Window is used to maintain consistency with variables in sketch.js. This allows for the images to be preloaded, therefore, at runtime the change from the original images to the accommodated images will be seamless.
During the development process, it was important to ensure the usability and effectiveness of our game's design and core mechanics. To this end, we used a mixed-methods approach, combining qualitative and quantitative evaluations. The qualitative evaluation was interested in gathering rich user feedback for the sake of revealing usability issues early, while the quantitative evaluation was interested in measuring player performance and satisfaction through statistical analysis.
In Week 7's lab, we used two qualitative data collection methods: Heuristic Evaluation and Think Aloud. Heuristic Evaluation was conducted by three peers from other teams, each independently assessing the game based on Nielsen’s usability principles. They identified a range of issues related to visual design, user control, and system feedback. These insights helped highlight critical usability problems at an early stage, allowing us to address them systematically. A full breakdown of the Heuristic Evaluation findings is provided in the attached HCV table.
Heuristic Evaluation Table.
The Think Aloud test, conducted on our digital prototype, provided us with additional feedback on the real user experience. Three users were recruited from outside our development group. Each user was instructed to make their way through the multi-floor maze, collect ingredients specific to their character, solve puzzles while against the clock, and reach the lab before the time expired. Throughout gameplay, players were prompted to think aloud, sharing their thoughts, feelings, and confusion, which enabled us to gather in-depth qualitative feedback.
Throughout the sessions, a number of common themes appeared. Players often complained of being confused over movement controls and having trouble finding objectives, pointing to a lack of clear onboarding and tutorial instruction. Visual issues were common; testers often struggled to distinguish between characters and weren't sure what various in-game icons meant. Platforming mechanics also received uniform feedback, namely the speed and responsiveness of the jump action. Text presentation was also pointed out as needing improvement, with font sizes being too small and pop-up instructions containing too much text.
A mind map of Think Aloud findings and thematic categorisation is presented below to graphically show the results of the evaluation.
Think Aloud evaluation feedback.
-
Shortened and summarised instructional text.
-
Increased font sizes for better readability.
-
Refined jumping mechanics for smoother and more consistent platforming.
-
Increased visual cues to differentiate between two characters and draw attention to collectible items.
In order to evaluate different aspects of user experience in our game, we conducted two quantitative tests: the System Usability Scale (SUS), which focuses on system usability, and the NASA Task Load Index (NASA-TLX), which measures perceived workload. For this part, we're looking at the SUS method, as it provided more observations about users working with our interface. The full results of both tests are shown below in the tables.
 SUS scores for both difficulty levels |
 NASA-TLX scores for both difficulty levels |
The SUS questionnaire was presented to ten subjects after they had played both levels of difficulty for our game. We purposely randomized the order of play to reduce the learning effect, some subjects began with the easy level, and others began with the hard level. This gave us more balanced feedback and avoided biased results due to familiarity.
Each SUS score was calculated as per the standard method: adjusting responses by question type, summing, and multiplying by 2.5 to get a score out of 100. A score above 68 is generally "above average" usability. Our results, however, were that both levels were below this.
The ratings were almost identical in both modes, with only two users rating differently. This was confirmed by a Wilcoxon Signed-Rank Test, where the test statistic W = 0 with only 2 non-tied pairs — a statistically significant difference, but one based on very little variation.
SUS score comparison between easy and hard modes.
Both levels' SUS score average was still under the 68 threshold. This reflected the need to improve some aspects of the system's usability, which we successfully addressed in the final version. We incorporated numerous interface enhancements, including more descriptive instructions, stronger visual cues, simplified and easier navigation and controls, and less overall complexity to improve the intuitiveness and user-friendliness of the gameplay.
Throughout our game development process, we maintained user interface (UI) and and functionality testing as a priority to ensure a consistent, and engaging player experience. We wanted to maintain usability levels that were consistent with our design specifications, particularly after receiving feedback from qualitative and quantitative evaluations.
User Interface Testing
We performed UI testing at different stages, from the readibilty of layout to feedback pop-ups during gameplay. Specific improvements included adjusting font sizes for better readability, refining instruction clarity to minimise player confusion and enhancing the visibility and responsiveness of interactive elements such as buttons and puzzle pop-ups. We also ensured that visual cues for important events (e.g., collecting an ingredient, triggering a puzzle, or collecting the key) were clear.
In addition, we conducted accessibility checks to verify that color schemes provided sufficient contrast for visually impaired users and that key game information was communicated through both text and visual indicators. This made the game experience more inclusive and intuitive for all players.
Functionality and Mechanics Testing
On the functionality side, we carried out continuous testing of core game mechanics, including:
-
Puzzle Triggers and Logic Flows: Verified that puzzles activated correctly and provided appropriate feedback on both success and failure. This included ensuring that puzzles couldn’t be accidentally retriggered or bypassed.
-
Ingredient and Key Collection: Tested collection logic extensively to confirm that ingredients and keys were properly registered in the game state and that collection animations and sounds played reliably.
-
Lift System: Special attention was given to the lift mechanics, ensuring it responded accurately to player interaction, moved smoothly between floors, and behaved correctly across both difficulty levels. We also checked for edge cases such as players trying to access the lift before completing prerequisite tasks.
-
Collision Detection: Tested character, item, and obstacle interactions to ensure that collision detection was precise and prevented unintended overlaps or clipping through objects.
Win and Lose State Testing
We performed comprehensive scenario testing for both win and lose conditions. This included verifying that:
- The win state only triggers when all required ingredients and the key are collected, and both characters successfully reach the lab before the timer expires.
- The game correctly resets after player death or when the timer runs out, including proper state resets for ingredients, keys, puzzles, and timers.
Additional Testing Areas
Boundary and Edge Case Testing: Explored extreme or unlikely scenarios to ensure the game handled them gracefully. Examples include attempting to collect ingredients before completing necessary puzzles, trying to access restricted areas, or performing multiple rapid interactions that could potentially break the game logic.
Audio Feedback Testing: Ensured that background music, sound effects, and event-based audio cues (such as puzzle completions or item collections) played correctly and didn’t overlap or cut off unexpectedly.
In Week 10, our group analyzed Race for the Cure through five sustainability dimensions individual, social, technical, economic, and environmental to ensure the game is engaging, accessible, and responsibly designed.
Sustainability dimensions.
We also explored how it supports sustainability through its design. We analyzed each dimension and mapped out the chain of effects to show how our choices impact player well-being, environmental efficiency, technical performance, social value, and economic accessibility.
Chains of effects across sustainability dimensions.
From an ethical perspective, our game avoids violence, discrimination, and exploitative mechanics. The narrative centers on a single player controlling two university students who work together to fix a problem they unintentionally caused promoting accountability, empathy, and learning.
- The game does not collect or store personal data, aligning with privacy first principles.
- Character roles (botany and chemistry) are not restricted by gender or cultural stereotypes, supporting inclusive representation for all players.
We designed to be accessible to a broad range of players, including those with diverse abilities:
- Colour Accessibility: Important visual information is conveyed through icons and shapes, not color alone.
- Clear UI and Fonts: The interface is clean, using readable fonts and minimizing distractions.
- Input Simplicity: The game can be played fully with a keyboard, without requiring special equipment or high end devices.
- Cognitive Accessibility: Puzzles are structured to be challenging yet fair. The time limit introduces light tension without overwhelming the player, encouraging thoughtful coordination between the two characters.
| Plan to Add to Game | Relevant Pattern | Link | Task Description |
|---|---|---|---|
| Convert PNGs to WebP and use sprite sheets to reduce file size and energy use. | Minify Web Assets | Minify Web Assets | Removed backgrounds from image assets and used PNG format for sprites and UI elements to reduce file size. This partially follows the Minify Web Assets pattern. |
| Replace GIFs with CSS/SVG animations | Deprecate GIFs for Animated Content | Deprecate GIFs | Replace GIF based animations (e.g. lift and collectable items) with efficient alternatives. |
To ensure Race for the Cure meets sustainability goals, we turned our main design priorities into user stories. These stories are supported by acceptance criteria to help guide development and measure success.
Sustainability Requirements as User Stories.
We worked closely and communicated effectively throughout the entire development process. We met regularly during weekly lab sessions and often stayed behind or arranged extra meetings afterward. As the project progressed, we began scheduling frequent check-ins over WhatsApp and Microsoft Teams, particularly during key stages such as the design and final implementation phases.
From the beginning, we assigned tasks based on individual strengths. For instance, design-related tasks were mainly handled by Maram and Hadeel, while coding responsibilities were led by Vera, Satvika, and Hakeem. This division ensured that each team member could focus on what they felt most confident in, while also learning from others in collaborative settings.
Our meetings typically followed a structure where we’d begin by updating each other on what we had completed that week, and then decide on what we wanted to achieve in the week ahead. We would then split tasks into smaller groups or pairs. We found this structure to be far more efficient, especially after initially trying to do tasks with all five members at once which often slowed things down and led to duplication of effort.
In the early stages, we used the WhatsApp poll feature to shortlist and vote on our top two game ideas. We then held an in-person meeting to discuss the pros and cons of each, eventually deciding on a concept we all felt enthusiastic about. This helped everyone have a say, and we were able to quickly agree on a game idea that we all liked.
When making other decisions about the game, such as design choices and feature implementations, we often used the poll feature or held quick votes during meetings. This ensured that everyone’s opinions were considered throughout the development process and that decisions reflected the whole team’s input.
A major strength of our collaboration was our use of pair programming, a technique supported by Cockburn and Williams (2001), who highlight its effectiveness in improving code quality and reducing defects through continuous code review. Working in pairs allowed us to support one another in real time, troubleshoot more effectively, and share different perspectives, which ultimately improved the quality and readability of our code. An example of when we used pair programming was during the development stage, when we were working on the player class. One person would focus on writing the code while the other helped with debugging or suggesting improvements. This made the process faster and helped us catch issues early on.
We incorporated various tools and techniques throughout the development process, many of which were inspired by lectures and labs on Agile software development (Week 2) and Project Management (Week 5).
Meeting Notes:
To document our progress, we kept detailed meeting notes on the repository, outlining what was discussed, what was completed, and the upcoming tasks for the next week. These notes helped ensure that no one lost track of our goals, even if they missed a session.
Left - folders for each week used to store files and notes; Right - Week 4 meeting notes example with goals, stakeholders, and user stories
Kanban Board (GitHub Projects):
We used a Kanban board to effectively visualize and manage our workflow. Tasks were categorised into "To Do," "In Progress," and "Done." We would often move cards during meetings and use labels to indicate coding, design, or report-writing tasks. This was particularly useful during busy periods and ensured that everyone could see the project’s overall progress at a glance.
Our Kanban board used to track coding, report writing, and task progress across the team
Google Docs:
Our shared Google Docs was used for collaboratively writing the final report. We also created a mini to-do lists for each section within the doc so that everyone was reminded of the specific requirements. This made it easier to divide writing tasks and collaborate on edits in real time.
Sections of our shared Google Doc - Left: built-in to-do list for tracking progress; Right: main report document used for collaborative writing
Planning Poker:
When estimating the effort required for larger tasks (like implementing animations or writing evaluation sections), we used planning poker during team discussions. This helped us set realistic expectations and distribute the workload fairly. These estimates also helped us plan our sprints, break the work into smaller, manageable chunks, and keep things moving smoothly throughout the project.
Sprints:
We structured our workflow around sprints to help maintain steady progress. Each sprint represented a focused period, typically one to two weeks, during which we planned, assigned, and worked on specific tasks. At the start of each sprint, we held short meetings to discuss priorities, estimate effort using techniques like Planning Poker, and allocate tasks based on availability and skillsets. We also made use of our GoogleDocs Notes and a Kanban board to plan and manage each sprint.
At the end of each sprint, we reviewed our progress, discussed any challenges faced, and planned adjustments for the next sprint. This iterative cycle kept the team aligned, ensured continuous progress, and allowed us to adapt quickly to any changes or new ideas that emerged during development.
Communication Platforms:
We mainly used our WhatsApp group chat to stay in touch and ask quick questions throughout the week. For longer discussions or updates, we had regular meetings on Microsoft Teams, especially when we needed to talk through bigger decisions or check in on overall progress
While our collaboration became strong over time, we did struggle initially. In the early weeks, there were miscommunications around game design and gameplay ideas. Some team members had different understandings of what we had agreed on, especially when it came to how mechanics should work. These bumps helped us realise the importance of clarity after each meeting. We made a group effort to clearly define weekly goals and individual tasks before wrapping up any discussion. If anyone was confused, we’d follow up on the WhatsApp group chat, which became a central hub for clarification.
Having a clearly maintained Kanban board and a detailed to-do list in the Google Doc helped us massively. It meant everyone could double-check responsibilities, even outside of meetings. We also realised that large group efforts on small tasks weren’t effective. During the first few weeks, all five of us would try to work on the same small feature or decision, which led to confusion and slow progress. Once we switched to working in smaller groups or pairs, we noticed a significant improvement in efficiency. We were able to tackle multiple things at once and make better use of our individual strengths.
Another learning curve came with our meetings. Initially, we didn’t set clear objectives, and as a result, some of our early meetings felt unfocused. Recognising this, we made it a habit to set a clear agenda for each meeting and identify what outcome we wanted. This small change made our sessions much more productive.
Overall, once we got into a good routine, things went a lot more smoothly. We stayed in touch, used the right tools, and worked well together.
Race For The Cure is a cooperative game set in an abandoned science building at the Universoty of Bristol. The students dodge obstacles and solve puzzles. The player must dash around three floors to obtain the required ingredients to survive. Developing this game has been a rewarding way to experience the software engineering process. It allowed each team member to apply their creativity and technical skills while also providing opportunities to learn and develop new competencies.
During the early stages of development, our team struggled with miscommunication. Using the agile methodology to its full extent has subsided most of it. Having a clear goal and description of each task, staying in regular communication, whether it be through the use of WhatsApp, Microsoft Teams, or talking to each other in person, had an exponential impact on efficiency. The use of Pair Programming sessions proved vital for code integration. Managing game mechanics, level layouts, and making adjustments where possible to increase convenience for the player became an integral part of our meeting.
At the forefront of our development was user feedback. The Think Aloud evaluations conducted on the digital prototype highlighted the issues we had with our user interface the most. Players wanted a simpler design as they found it difficult to keep track of all of the information presented to them. Subsequently, our team redesigned the layout of both levels and created succinct instructions, including popups throughout the game, to promote user experience. Due to the feedback being largely about the user interface, we prioritised UI testing throughout the later stages of development. This yielded a final game which resembles our final game concept and fulfilled our requirements analysis.
Early testing showed maintenance and performance issues with the original system architecture. As development progressed, it became more important that the revised architecture could keep up efficiently. To cater to players with Protanopia and Deuteranopia, the most common forms of colour blindness, two dedicated utility classes had to be created.
In the future, we aim to make it more accessible for players with disabilities. Focusing on motion tracking for players with physical disabilities and implementing a mute button for those with Hyperacusis, noise sensitivity. Another feature we would implement is adapting the code to fit touch screen devices. This would allow users to play on the go using smartphones, tablets, etc., while also providing another accommodation for those with reduced mobility. We plan to introduce new levels and themes, such as jungle and space, adjusting components of the game to better suit the new location. Another of our goals is to lean further into our aesthetic and create more animated sprites to enhance gameplay for an arcade feel.
To summarise, Race For The Cure has been an invaluable experience for our entire team. As a team, we had a chance to experience every aspect of building a software product and put our knowledge into practice. Since this is the first team project completed in this discipline, it has become a solid foundation for us to continue improving our skills in future projects.
A table to show team member contributions for Race For The Cure
| Name | Contribution |
|---|---|
| Vera Babasa | 20 |
| Satvika Mallela | 20 |
| Abdul-Hakeem Lamptey | 20 |
| Maram Abdulaziz Alhussain | 20 |
| Hadeel Ibrahim | 20 |
Irum Inayat, Salim, S.S., Marczak, S., Daneva, M. and Shahaboddin Shamshirband (2014). A systematic literature review on agile requirements engineering practices and challenges. Computers in Human Behavior, [online] 51, pp.915–929. doi:https://doi.org/10.1016/j.chb.2014.10.046.
Laplante, P.A. and Kassab, M.H. (2022). Requirements Engineering for Software and Systems. [online] doi:https://doi.org/10.1201/9781003129509.
Nielsen, J. (1995). Ten Usability Heuristics for User Interface Design. Nielsen Norman Group. Available at: https://www.nngroup.com/articles/ten-usability-heuristics/.
Nielsen, J. (1994). How to Conduct a Heuristic Evaluation. Nielsen Norman Group. Available at: https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/.
Sustainability Design. (n.d.). Sustainability Design and Software: The Karlskrona Manifesto. Available at: https://sustainabilitydesign.org/.
Cockburn, A., & Williams, L. (2001). The Costs and Benefits of Pair Programming. In: G. Succi and M. Marchesi (eds.), Extreme Programming Examined. Boston: Addison-Wesley, pp. 223–243.