2025 COMSM0166 group 3
| Name | Github | Role | |
|---|---|---|---|
| Shuyin Deng | ta24493@bristol.ac.uk | @Ruby-sy | Project Manager |
| Jiaxin Fan | sg24148@bristol.ac.uk | @paidaxin760 | Technical Writer |
| Peixuan Li | ra24381@bristol.ac.uk | @pluvo070 | Developer |
| Yibu Ma | sd24536@bristol.ac.uk | @Grooveofmimosa | Developer |
| Yu Qiu | kp24679@bristol.ac.uk | @PekkaLnx | Developer |
| Jiahao Liu | qi24477@bristol.ac.uk | @TYHD759 | Test Engineer |
- Introduction
- Requirements
- Design
- Implementation
- Evaluation
- Process
- Sustainability, Ethics and Accessibility
- Conclusion
- Individual Contributions
Capoo is a 2D puzzle-platformer that combines lighthearted gameplay with thoughtful level design. Players control Capoo, a quirky blue cat-bug hybrid, as they navigate a series of levels featuring interactive environments, platforming challenges, and environmental puzzles.
The game draws inspiration from the visual charm of Capoo Pals and the whimsical absurdity of Cato, aiming to deliver a humorous yet polished experience that balances casual accessibility with cognitive engagement.
Capoo introduces two unique mechanics:
The ability to separate Capoo from the can using key inputs, enabling the player to control each component independently. This will allow for diverse platforming strategies, increasing gameplay variety and encouraging creative problem-solving.
The game is structured across multiple levels, each of which presents increasing puzzle complexity and map decryption difficulty. This will gradually raise the cognitive challenge, ensuring players remain mentally engaged as they progress through the game.
Its appeal lies in its distinctive art style, playful animations, and inventive gameplay. The development process followed agile methodologies and user-centered design, incorporating feedback from playtesting and usability evaluations.
This report documents the game's development, including requirement analysis, design, implementation, evaluation, team workflow, and sustainability aspects, highlighting key decisions, challenges, and insights gained throughout the project.
Our team's original idea was based on Stardew Valley, As the ideation process progresses, our team proposed two new game directions based on existing titles. One was inspired by the charming character design of Capoo Pals, using its playful style to create a two-player adventure with lighthearted storytelling, interactive environments, and humorous boss fights.The other was based on Cato, featuring physics-based platforming puzzles and humorous mechanics involving a cat and a can.
We created simple paper prototypes to evaluate the original idea during class. For the Stardew Valley-inspired concept, we mapped out character movement, basic dialogue trees, and interaction zones. For the Cato-style game, we sketched out how the two controllable characters (Capoo and the can) could move independently, interact with physics objects, and solve platforming puzzles cooperatively.
Paper Prototype of Stardew Valley
Week.3.-.Paper.Prototype.01.mp4
Paper Prototype of Cato
output.mp4
During discussion, we compared the scope, technical difficulty, and uniqueness of both ideas. The Stardew Valley concept was rich in narrative potential but required a large amount of content creation, scripting, and world-building, which exceeded the time and resource constraints of our project. In contrast, the Cato-like game offered a clear mechanical focus, allowed for creative level design within a manageable scope, and aligned well with our team's strengths in puzzle and physics-based gameplay design.
As a result, we unanimously chose to develop a game inspired by Cato, aiming to replicate its humorous tone and distinctive mechanics while introducing our own puzzle challenges and platforming dynamics through the characters Capoo and the can.In addition,we were also attracted by the cute characters in Capoo Pals and introduced them into the game,adding visual beauty and fun.
The main stakeholders for Capoo were:
- Players: End-users who play the game and provide feedback.
- Developers: Team members implementing game logic and features.
- Designers: Responsible for crafting puzzles, UI, and character behaviors.
- Artists: Create visual assets, animations, and icons.
- Test Engineers: Validate usability, performance, and stability.
- Publishers: Potential distributors or promoters of the final game.
Each stakeholder’s expectations were captured using epics and user stories.
- As a casual gamer, I want Capoo’s controls to be simple and intuitive so that I can jump into the game and start having fun without needing a tutorial.
- As a puzzle lover, I want the levels in Capoo to offer clever environmental challenges, so I feel rewarded when I figure them out.
- As a curious player, I want a lighthearted story or backstory for Capoo, so I can feel more connected to the game world.
- As a player interested in customization, I want to choose the difficulty level at the start, so the game fits my skill level and mood.
- As a new player, I want to be guided by brief tutorials or examples that explain unique mechanics , so I don't feel confused.
- As a visually impaired player, I want color-coded elements to also include shape or pattern-based distinctions, so I can still solve puzzles if I can't distinguish certain colors.
As a member of the development team, I want to implement a first-in-class app/game that pushes me to learn new skills.
The team broke down user stories into implementable tasks. For example, the "core movement" story led to:
- Movement System: Implement character locomotion with keyboard/controller.
- Jumping Mechanic: Design jump arc, gravity, and mid-air control.
- Interaction System: Detect interactable objects (e.g., switches, NPCs).
- Animation Integration: Connect animations to movement states.
- Playtesting and Feedback: Gather usability feedback to adjust control responsiveness.
| Easy Level | Difficult Level | |
|---|---|---|
| Description | An introductory level where Capoo does not need to separate from the can, controlled via keyboard (WASD). | A more advanced level where Capoo can separate from the can to perform more complex actions, including tougher puzzles and platforming, controlled via keyboard (WASD). |
| Basic Flow | Goal: Learn basic operations, complete simple platforming and puzzle interactions, and finish the level without failing. | Goal: Use learned mechanics to solve more complex puzzles, avoid hazards, and reach the finish flag. |
| Step One | Player controls Capoo using the keyboard. Pressing S allows Capoo to separate or merge with the can. | Player controls Capoo using the keyboard. Pressing S allows Capoo to separate or merge with the can. |
| Step Two | Find the key to open the gate. | Find the key to open the gate. |
| Alternative Flow | Challenge: Capoo falls off platforms, fails to trigger mechanisms, or cannot solve the puzzle. | Challenge: Capoo falls off platforms, fails to trigger mechanisms, or cannot solve the puzzle. |
| Step One | Capoo touches water, traps, or mistimes a jump, and gets reset to the start point. | Capoo touches water, traps, or mistimes a jump, and gets reset to the start point. |
| Step Two | Player can press H to bring up a tutorial. |
No tutorial available; puzzle elements must be figured out, and mechanisms will not activate if solved incorrectly. |
The Capoo project adopts an object-oriented approach to structure gameplay logic, data flow, and visual presentation. To facilitate collaborative development and modularity, we designed our architecture around clear abstractions and used UML diagrams to model our system’s behavior and structure. In particular, we utilised a Class Diagram to represent core entities and their relationships, and a Sequence Diagram to model runtime interactions, especially in puzzle-related events such as switch activation and character interaction.
Our class diagram provides a structural overview of Capoo’s object-oriented architecture. At its core, the system is driven by a GameModel, which holds references to key game objects such as platforms, interactable elements, and the player character.
- GameModel: Serves as the central container for game state and level data. It stores all terrain, interactive elements (e.g.,
Switches,Keys,ElevatingWalls), and references to theCapoocharacter. - Capoo: Inherits from
AbstractCharacter, encapsulating properties such as position, speed, and state (e.g.,facingRight,isGrounded). It is the player-controlled entity responsible for interacting with puzzles and moving across terrain. - Terrain & Environment: Classes such as
Ground,Trap,Spring,Water, andClimbinherit fromAbstractTerrain. These are used to render the static environment and define different gameplay zones with unique physical effects. - Interactables:
Switches: Can be triggered by the player or other entities. Linked to actions such as activatingElevatingWalls.Keystem: Represents collectible or logic-triggering items that influence puzzle conditions.Flag: Represents level goals or checkpoints.Potion,Wizard: Dynamic game objects that can be interacted with or triggered conditionally.
- GameController: Controls the game loop logic including player input, game reset, and interactions. Interfaces directly with the
GameModeland processes collision and event updates. - MapLoader: Responsible for loading and parsing level data into structured game objects.
- UI and Rendering:
GameView: Renders the visual interface by referencingGameModel.RenderLogic,SplineLayer, andCloud: Manage background animations and UI transitions, powered by the THREE.js rendering engine.
This modular structure allows for flexible development and easy modification of individual game systems.
To represent dynamic gameplay interaction, we created a sequence diagram that models a typical scenario where the player activates a switch that raises a wall and unlocks a key mechanism.
- Player initiates movement using key inputs processed by
GameController. Capooupdates its position and interacts with terrain using gravity and collision checks (e.g.,canClimb(),isNearPix()).- A collision with a
PotionorSwitchesobject is detected:- For
Potion: updates Capoo’s velocity and position. - For
Switch: triggers wall movement (ElevatingWalls) viasetTarget()andupdateWallPosition().
- For
- The game logic updates the visual state (
GameView.drawGameScreen()), and the camera updates its position viaRenderLogic. - Additional UI feedback is managed via the
Messageclass andUtils.showPotion()method.
The sequence clearly demonstrates the flow of control from player input to game logic and rendering, emphasizing how interactions cascade through the system.
We created a state diagram for Capoo to map the lifecycle of key game components like GameModel, Capoo, Potion, and others. The diagram illustrates state transitions—such as Capoo moving from Idle to Walking, or the GameModel transitioning to GameOver—which helped clarify the conditions for state changes during development.
For instance, the Potion transitions from Inactive to Active upon pickup, and ElevatingWalls move from Static to Moving based on triggers. This visual representation helped identify edge cases, ensure synchronized game logic, and streamline development, ultimately reducing debugging time.
The Communication Diagram for the Capoo Game illustrates the interactions between key components. The Player sends inputs to the GameController, which processes them and updates the GameModel. This triggers changes in entities like Capoo, Potion, KeyItem, Flag, and ElevatingWalls. These updates are rendered by RenderLogic and displayed in the GameView.
The MapLoader initializes game levels and parses entity data for the GameModel. Capoo interacts with objects, triggering events that are reflected in the game state. SpineLayer manages character animations, ensuring smooth visuals. Error handling in GameController ensures stability during gameplay.
This structure maintains synchronized game states, smooth animations, and consistent feedback to the player.
During design and implementation, we faced several technical challenges that led to important design decisions:
- Modularity vs. Integration: While we abstracted base classes such as
AbstractEntity,AbstractTerrain, andAbstractItemto promote reusability, we needed to balance this with the tight integration required for real-time gameplay response. - Rendering Separation: By offloading animation and background logic into
RenderLogicandSplineLayer, we ensured a separation of concerns between game logic and rendering, improving maintainability and scalability. - Puzzle System Scalability: Elements like
SwitchesandElevatingWallswere designed to be easily extendable by assigning ID-based triggers, supporting more complex puzzles in future levels.
Consistent with agile methodology, our class and sequence diagrams evolved over time. For example, earlier prototypes had more monolithic controller logic, but we later separated GameController and MapLoader to improve maintainability and testing. Additionally, classes such as Capoo, Potion, and ElevatingWalls saw expanded responsibilities as gameplay mechanics became clearer through playtesting.
The UML models we developed played a crucial role in organizing our design and facilitating communication within the team. By combining a strong object-oriented foundation with agile iteration, we built a flexible and scalable game architecture that can accommodate future features such as multi-character control or extended puzzle mechanics.
During the implementation of Capoo, we encountered several technical and architectural challenges that significantly influenced how we structured our codebase and implemented gameplay mechanics. These challenges not only tested our ability to adapt existing libraries but also reinforced the importance of good software engineering practices such as object-oriented design, modularization, and debugging of physics simulations.
We summarize our major challenges below:
One of our key design goals was to bring the personality of Capoo to life through expressive animation. To achieve this, we used the Spine animation model from Capoo Pals. However, p5.js, our main framework for game logic, does not natively support Spine.
To solve this, we adopted a hybrid rendering solution:
- We integrated Three.js specifically to render the Spine character model.
- The game logic, UI, and gameplay rendering remained within the p5.js environment.
This introduced complexity in synchronising game state between the two rendering contexts. For example, the Capoo model's facing direction, animation state, and position had to be manually updated based on logic handled by GameModel and Capoo classes in p5.js. Despite the complexity, this approach allowed us to maintain p5.js’s simplicity while leveraging Three.js’s flexibility for skeletal animation.
Key Takeaway: This integration allowed us to retain the charming animation style of Capoo, but required careful coordination between libraries and update loops to ensure smooth rendering.
Our initial prototype was built in a script-style format, where all logic was spread across multiple JavaScript files attached directly to the HTML. This led to tight coupling, poor reusability, and difficulties in managing the growing complexity of the game logic.
To improve code structure and maintainability, we undertook a full refactor using OOP principles:
- We created clear class hierarchies (
AbstractEntity,AbstractTerrain,Capoo,Switch,Potion, etc.). - We used encapsulation to hide internal state and expose only necessary interfaces (e.g.,
update(),collide(),move()). - We applied inheritance to create polymorphic behaviors (e.g., all terrain elements inherit from
AbstractTerrain). - We transitioned to ES6 modules, enabling better file separation and dependency management.
This refactor took nearly a full sprint but paid off by enabling cleaner logic separation, reusable systems, and better collaboration across the team.
Key Takeaway: Refactoring for OOP was essential for scalability, especially with multiple types of interactive elements and physics objects sharing behavior.
Implementing reliable physics interactions and collision detection was another significant hurdle. Early in development, we encountered several issues:
- Capoo would clip through terrain or platforms, especially at corners.
- The character could get stuck to walls, due to overlapping bounding boxes and imprecise collision checks.
- Inconsistent jump mechanics, caused by timing issues with
isGroundeddetection and terrain state updates.
To address this, we implemented:
- A more precise tile-based collision system, where each entity checks collisions using adjusted hitboxes relative to its position and sprite dimensions.
- Logical state flags (e.g.,
onGround,canJump) to control character state transitions and avoid unintended behaviors. - Frame-wise correction in
update()methods to prevent multi-frame glitches caused by high speed or overlapping collisions.
After multiple rounds of debugging and playtesting, we were able to achieve consistent and stable interactions, with Capoo responding correctly to terrain, jump inputs, and puzzle objects like Switches and Potion.
Key Takeaway: Stable and responsive physics is critical in a puzzle-platformer. Careful tuning of hitboxes and state logic was necessary to ensure playability and fairness.
Each challenge forced us to adapt and improve our technical approach. From animation system integration, to architecture refactoring, to gameplay responsiveness, these implementation problems guided the evolution of Capoo and shaped its final experience. Despite early difficulties, they ultimately contributed to a more stable, engaging, and maintainable game.
| Interface | Issue | Heuristic(s) | Frequency (0–4) | Impact (0–4) | Persistence (0–4) | Severity = (F + I + P) / 3 |
|---|---|---|---|---|---|---|
| Game UI | The color contrast is not distinct, making it difficult for players to see clearly. | Aesthetic and minimalist design | 3 | 2 | 3 | (3 + 2 + 3) / 3 = 2.67 |
| Game Rules | Players think they can step on monsters and do not understand the function of the mushroom, making the game rules unclear. | Help and documentation | 4 | 3 | 4 | (4 + 3 + 4) / 3 = 3.67 |
| Controls | Using the space key for jumping does not align with user habits and is not easy to operate. | Flexibility and efficiency of use | 3 | 2 | 3 | (3 + 2 + 3) / 3 = 2.67 |
| Game Objects | Players believe that brown is a toxic color and touching it will cause them to lose health. | Consistency and standards | 2 | 2 | 3 | (2 + 2 + 3) / 3 = 2.33 |
| Exit Option | There is no clear exit option. | User control and freedom | 3 | 3 | 4 | (3 + 3 + 4) / 3 = 3.33 |
This report aims to evaluate the user experience of the platformer puzzle game "Capoo" at low difficulty (L1) and high difficulty (L2) using quantitative methods, comparing workload and usability differences.
NASA TLX is a tool for measuring subjective workload across six dimensions (Hart & Staveland, 1988). SUS is a reliable usability assessment tool (Brooke, 1986). This study combines both methods to analyze the impact of Capoo’s difficulty on player experience.
- Quantify the workload (NASA TLX) and usability (SUS) of Capoo at L1 and L2.
- Use statistical tests to determine the significance of differences.
- Number: 10 volunteers.
- Characteristics: Classmates with no specific gaming experience requirements.
- Selection Method: Random recruitment.
- Difficulty Levels: Capoo includes L1 (low difficulty) and L2 (high difficulty).
- Testing Order:
- 5 users played L1 first, then L2.
- 5 users played L2 first, then L1.
- This minimizes learning effects.
- Tools:
- NASA TLX: 6 dimensions (raw scores).
- SUS: 10-question survey.
- Procedure: Each user played one difficulty level and then filled out the NASA TLX and SUS forms, resulting in four scores per participant.
- NASA TLX: Dimension score = (Rating - 1) × 25, Total score = (∑ Dimension scores) / 6.
- SUS: Odd-numbered questions = Rating - 1, Even-numbered questions = 5 - Rating, Total score = (∑ Score contributions) × 2.5.
- Tool: Wilcoxon signed-rank test.
- Online Calculator: Statology Wilcoxon Test Calculator
- Significance Level: α = 0.05.
| User ID | L1 NASA TLX | L2 NASA TLX | L1 SUS | L2 SUS |
|---|---|---|---|---|
| V1 | 12.5 | 16.67 | 55 | 50 |
| V2 | 20.83 | 20.83 | 45 | 35 |
| V3 | 29.17 | 33.33 | 55 | 55 |
| V4 | 20.83 | 25 | 45 | 42.5 |
| V5 | 29.17 | 29.17 | 52.5 | 50 |
| V6 | 37.5 | 41.67 | 37.5 | 40 |
| V7 | 33.33 | 37.5 | 42.5 | 45 |
| V8 | 8.33 | 16.67 | 37.5 | 40 |
| V9 | 37.5 | 45.83 | 35 | 35 |
| V10 | 16.67 | 20.83 | 55 | 42.5 |
- Averages:
- L1 NASA TLX: 24.58, L2 NASA TLX: 28.75.
- L1 SUS: 45.5, L2 SUS: 43.5.
- NASA TLX:
- Wilcoxon test result: W = 36 (n=8, excluding zero values).
- Critical value (n=8, α=0.05): 3.
- Conclusion: W > 3, no significant difference.
- SUS:
- Wilcoxon test result: W = 24 (n=8, excluding zero values).
- Critical value (n=8, α=0.05): 3.
- Conclusion: W > 3, no significant difference.
- Workload: L2 NASA TLX (28.75) is slightly higher than L1 (24.58), mainly due to increased physical demands (e.g., jumping) and mental effort (e.g., puzzle complexity), but the difference is not significant.
- Usability: L1 SUS (45.5) is slightly higher than L2 (43.5), suggesting that the increased difficulty of L2 slightly reduced perceived usability, but not significantly.
- It was expected that L2 would have a higher workload and lower usability. The observed trend aligns with expectations but does not reach statistical significance, possibly due to insufficient difficulty differences.
- Increase the difficulty of L2 by making jumps and puzzles more challenging to amplify workload differences.
- Optimize L2’s control smoothness (SUS Q1 and Q6 had lower scores) to reduce inconsistencies.
- Small sample size (10 participants) limits statistical power.
- The difficulty difference between L1 and L2 may not be significant enough to fully reflect puzzle and platforming challenges.
Capoo’s L2 workload is slightly higher than L1 (28.75 vs 24.58), and its SUS score is lower than L1 (43.5 vs 45.5), but neither difference is statistically significant (NASA TLX W = 36, SUS W = 24, p > 0.05). It is recommended to enhance L2’s difficulty and optimize control experience to improve player immersion.
- Enhance L2 Jumping Difficulty: Increase platform height and introduce moving obstacles to heighten physical demand.
- Optimize Puzzle Consistency: Standardize puzzle hint styles to improve SUS Q4 (consistency) scores.
- Implement Dynamic Difficulty Adjustment: Adjust jumping and puzzle complexity based on player performance.
We used black-box testing with equivalence partitioning to validate the game. Test cases were designed based on input types and game states, without looking at the internal code. We focused on transitions (e.g. main menu to level select), controls (e.g. movement, jumping), and interactions (e.g. keys, traps, water). Each feature was tested using representative inputs from different equivalence classes to ensure correct behavior.
| ID | Description | Precondition | Test Steps | Expected Result |
|---|---|---|---|---|
| TC-01 | Game Launch and Main Menu Test | Launch the game | 1. Start the game2. Observe the main menu | - Game resources load correctly- "Capoo" title appears on the main menu- "Press ENTER To Start" prompt is shown- Background and cloud animation display properly |
| TC-02 | Transition from Main to Level Menu | Game is at the main menu | 1. Press ENTER on the main menu | - Game state changes from START to LEVEL_SELECT- Level selection screen displays correctly- "Use LEFT/RIGHT To Choose Press SPACE To Start" prompt appears- All level options are visible, with the current one highlighted |
| TC-03 | Level Selection Functionality | Game is at level selection screen | 1. Press LEFT arrow key2. Press RIGHT arrow key3. Observe changes | - LEFT arrow decreases selected level index (unless at first level)- RIGHT arrow increases selected level index (unless at last level)- Selected level is highlighted |
| TC-04 | Level Loading Function | At level selection, one level selected | 1. Press SPACE | - Game state changes from LEVEL_SELECT to PLAYING- Selected level loads and displays correctly- Character appears at initial position- Level background, terrain, and items are displayed correctly |
| ID | Description | Precondition | Test Steps | Expected Result |
|---|---|---|---|---|
| TC-05 | Basic Character Movement | Game is in PLAYING state, character on ground | 1. Press LEFT2. Release LEFT3. Press RIGHT4. Release RIGHT | - Character moves left and faces left when LEFT key is pressed- Character moves right and faces right when RIGHT key is pressed- Character stops moving when key is released |
| TC-06 | Flying When Merged with Potion | Game is in PLAYING state, character merged with potion | 1. Press SPACE2. Hold SPACE3. Release SPACE | - Character flies upward when SPACE is pressed- Keeps flying while SPACE is held- Falls when SPACE is released |
| TC-07 | Separation from Potion | Game is in PLAYING state, character merged with potion | 1. Press S | - Character separates from potion- Potion pops upward- Merge wall disappears (merge layer invisible) |
| TC-08 | Potion Ejection After Separation | Game is in PLAYING state, potion and character separated | 1. Ensure potion is landed or stuck to wall2. Press A to test left ejection3. Press D for right | - Potion can be ejected from ground/wall- A triggers left-upward ejection- D triggers right-upward ejection- Potion has proper initial velocity and gravity scaling |
| TC-09 | Climbing Feature | Game is in PLAYING state, near climbable wall | 1. Move character near wall2. Press UP3. Press DOWN | - Wall is detected as climbable- UP moves character upward- DOWN moves character downward- Gravity doesn't apply while climbing |
| TC-10 | Automatic Remerge with Potion | Game is in PLAYING state, potion and character separated | 1. Move character close to potion | - Potion automatically merges when close- Potion appears on back- Merge wall becomes visible again |
| ID | Description | Precondition | Test Steps | Expected Result |
|---|---|---|---|---|
| TC-11 | Spring Mechanism | Game is in PLAYING state, level contains spring bed | 1. Move character onto spring bed | - Character gains upward speed- Bounce height exceeds regular jump- Spring sound plays |
| TC-12 | Collecting Keys | Game is in PLAYING state, level contains visible key | 1. Move character to contact key | - Key disappears on contact- Key count increases- UI updates- Key collection sound plays |
| TC-13 | Level Completion | Game is in PLAYING state, all keys collected | 1. Move character to touch the flag | - State changes to LEVEL_COMPLETE- Completion screen shows- "Level Complete!" and continuation options appear- Completion sound plays |
| TC-14 | Switch and Mechanism Wall Interaction | Game is in PLAYING state, level contains switch and wall | 1. Touch switch2. Observe wall3. Touch switch again | - Switch changes state- Wall moves to target- Pressing again returns wall to original- Switch sound plays |
| TC-15 | Water Hazard | Game is in PLAYING state, level contains water area | 1. Lead character into water | - Character dies- Message "Cats dissolve easily in water!" shown- Respawn at starting point- Death sound plays |
| TC-16 | Trap Hazard | Game is in PLAYING state, level contains traps | 1. Lead character into trap | - Character dies- Message "You are trapped!" shown- Respawn at starting point- Death sound plays |
| TC-17 | Potion Falling into Water | Game is in PLAYING state, potion and character separated, level has water | 1. Make potion fall into water | - Game resets- Message "No water with my pot!" shown- Character and potion respawn and remerge- Death sound plays |
| TC-18 | Ice Surface Limitation | Game is in PLAYING state, level contains ice surface | 1. Move character onto ice2. Attempt to jump | - Jumping is disabled- Message "Ice! You can't jump!" shown |
| ID | Description | Precondition | Test Steps | Expected Result |
|---|---|---|---|---|
| TC-19 | Help Interface | Game is in PLAYING state | 1. Press H to show help2. Press any key to close | - H key shows help overlay with game controls- Any key hides help and returns to game |
| TC-20 | Level Reset | Game is in PLAYING state | 1. Press R | - Character resets to start- All keys reset- Switches and walls reset- Message "Restarting level..." shown- Death sound plays |
| TC-21 | Return to Level Selection | Game is in PLAYING state | 1. Press ESC | - State changes to LEVEL_SELECT- Character and level state saved- Level selection screen shown |
| TC-22 | Post-Level Completion Options | Game is in LEVEL_COMPLETE state | 1. Press any key (except ESC) to continue2. Press ESC after completion | - If not last level, any key starts next level- If last level, any key returns to selection- ESC returns to selection in all cases |
The evaluation process confirmed that Capoo is easy to use and cognitively manageable for casual players, even as difficulty increases. While workload and usability metrics did not show significant shifts, qualitative feedback provided actionable insights for polishing level design and improving onboarding. Heuristic evaluation revealed critical UI flaws that were successfully addressed. Ongoing testing ensured stability, performance, and a better user experience across devices.
The development of Capoo adopted an agile methodology, allowing us to iterate quickly, validate ideas early, and adjust to challenges throughout the project. As a six-member team with diverse skillsets, we collaborated effectively using well-defined roles, flexible planning, and regular communication. This section outlines our workflow, tools, collaboration strategies, and reflections on key outcomes.
At the start, our requirements were still evolving. Agile’s incremental development cycle suited our needs perfectly, allowing us to break the project into small, manageable units. Each sprint focused on delivering working features—such as camera movement, physics logic, or puzzle modules—that were tested and refined immediately.
We followed core Agile practices:
- Weekly sprint planning to define scope and distribute tasks.
- Asynchronous stand-ups on Microsoft Teams to check progress.
- Sprint reviews with playable builds shared for feedback.
- Retrospectives every Friday to reflect on pain points and improvements.
Rather than striving for perfection upfront, we emphasized continuous improvement. Working code was prioritized in each sprint, enabling us to gather regular feedback from teammates and testers. This helped identify issues like unclear UI or imbalanced difficulty early, which we could adjust in subsequent iterations.
We used a focused set of tools to streamline collaboration:
- GitHub Kanban Board: Task tracking with columns for “To Do,” “In Progress,” “In Review,” and “Done.” This visual workflow kept everyone aligned and made progress transparent.
- P5.js: The core development engine, used for implementing physics, UI, and gameplay.
- Git + GitHub: Version control with feature branches, pull requests, and code reviews.
- Visual Studio Code: Shared development environment across the team.
- Microsoft Teams: Central platform for discussion, stand-ups, and file sharing.
- Google Forms + Excel: Evaluation data collection and analysis (NASA TLX, SUS).
- Miro: Used during early ideation for wireframes and stakeholder modeling.
During development, we maintained stable code by enforcing pull request reviews and consistent branch naming. Members created feature branches, submitted pull requests after testing, and waited for peer review before merging. This process reduced bugs and ensured everyone stayed aware of changes.
Each member took on a primary role while remaining flexible to support other tasks as needed:
| Name | Role | Responsibilities |
|---|---|---|
| Shuyin Deng | Project Manager | Report / Tracking project progress / Task allocation |
| Jiaxin Fan | Technical Writer | Documentation/Evaluations/video |
| Peixuan Li | Developer | Early stage prototype / Physics and collision / Main logic implementation |
| Yibu Ma | Developer | OOP refactor / Spine model integration / Documentation website |
| Yu Qiu | Developer | Player Interaction / Performance Optimization / Main logic implementation |
| Jiahao Liu | Test Engineer | UI design / Map design / Testing |
Cross-role contributions were encouraged—for example, developers helped with writing and testing, while testers participated in prototype evaluations and level design discussions.
-
Fast Feedback Loops: In-editor playtests and quick builds allowed us to validate gameplay ideas within hours. This significantly improved iteration speed and creativity.
-
Test-Driven Debugging: Having a dedicated test engineer helped identify issues early, improving overall build stability.
-
Asynchronous Coordination: By relying on GitHub comments and Kanban updates, we avoided bottlenecks despite having different schedules.
-
Merge Conflicts & Overlaps: Early on, lack of communication led to Git merge conflicts. We solved this by increasing pull request discipline and documenting changes clearly.
-
Task Estimation Challenges: Some complex systems (e.g., modular puzzle logic) required more time than expected. We learned to plan buffer time and refine story-point estimation.
The agile workflow enabled us to adapt quickly as we learned more about the game’s needs. We found that maintaining working features at all times, writing clean and commented code, and using a consistent branching model allowed for a sustainable and efficient development pace.
Although Capoo is a lightweight 2D game, we made conscious decisions to minimize its environmental footprint. We optimized asset sizes, limited unnecessary visual effects, and avoided resource-heavy rendering techniques. By choosing p5.js—a browser-based and lightweight JavaScript library—we ensured that the game runs efficiently on low-spec hardware, reducing the energy cost required to render and interact with the game.
The game is hosted on GitHub Pages, a static hosting platform that reduces server overhead compared to dynamically hosted environments. While we did not measure energy use directly, our decisions were informed by a preference for minimalist design and efficient execution.
Reflection: Future iterations could further reduce environmental impact by compressing image assets, optimizing animations, and exploring green hosting options for game deployment.
Capoo was designed to be accessible and enjoyable for a broad range of casual players. The game's humorous tone, simple controls, and low cognitive demands make it approachable for players with varying levels of experience. Difficulty levels (L1 and L2) are included to cater to different preferences and skill levels.
The visual theme—centered around a whimsical character solving puzzles in a non-violent world—was deliberately chosen to promote positive, non-aggressive play. No enemies or combat mechanics are involved, and puzzle solutions are based on logic, timing, and creative thinking, aligning with ethical principles of inclusive and peaceful gameplay.
The development process also followed ethical software practices, including:
- Original asset use or fair-use adaptation.
- Respect for contributors’ time and fair role distribution.
- Transparent task tracking via GitHub for accountability.
Reflection: While the game promotes positive interaction, more diverse character options and narrative depth could better represent varied social backgrounds in future expansions.
We made several design choices to improve accessibility:
- Color-independent puzzle elements: Visual indicators such as shape and motion complement color cues to aid colorblind players.
- Simple controls: All game mechanics are operated through standard keyboard inputs with minimal complexity.
- Tutorial and difficulty settings: An optional tutorial and adjustable difficulty settings help new or casual players ease into the game.
- Responsiveness across platforms: As a browser game, Capoo is accessible across Windows, macOS, and mobile browsers without installation.
Reflection: While the game accommodates casual play and basic visual limitations, it lacks full accessibility features such as screen reader support. In future versions, we aim to add audio cues to improve inclusiveness.
Our project team used the Sustainability Awareness Framework (SusAF) to guide decisions across environmental, social, and technical dimensions. The following are sample user stories reflecting our sustainability mindset:
Environmental Requirements
- As a developer, I want to reduce asset size and rendering load so that the game uses less GPU power.
- As a maintainer, I want to reuse code components to minimize redundancy and improve efficiency.
Social Requirements
- As a new player, I want an easy mode with guided controls so that I can learn the game comfortably.
- As a colorblind user, I want non-color-based cues to help me navigate puzzles.
Technical Requirements
- As a developer, I want modular systems for puzzle logic so that I can extend levels without major code rewrites.
- As a tester, I want the game to run in a browser so it can be tested on different devices easily.
This section concludes our discussion on how Capoo was built with sustainability and accessibility in mind, while acknowledging future improvements that can be made in hosting efficiency, inclusive design, and social representation.
The development of Capoo was a rewarding yet technically demanding experience that significantly strengthened our software engineering and collaboration skills. Building a physics-based puzzle-platformer with charming visuals and modular design required us to navigate a range of challenges—from integrating Spine animations with p5.js to implementing precise, bug-free collision mechanics.
One of the defining features of our development journey was the decision to refactor our early procedural code into a fully object-oriented system. While time-consuming, this refactor paid off by making our codebase more scalable and maintainable, which proved essential as new gameplay elements like potions, switches, and modular puzzles were introduced. The class and sequence diagrams helped the entire team—regardless of their background—understand system structure and dependencies, enabling more efficient implementation and debugging.
Agile methodology also played a critical role in the success of this project. Through regular sprint planning, retrospectives, and asynchronous updates, we maintained a clear development pace while remaining flexible enough to respond to technical hurdles and player feedback. For example, early usability testing revealed that tutorial screens were confusing and some levels lacked clear feedback cues. By integrating heuristic evaluations and SUS/NASA TLX assessments into our workflow, we systematically addressed these issues, improving both clarity and user engagement.
Despite our progress, there are areas we could have improved. Early integration between Three.js and p5.js lacked a clearly defined communication layer, which caused synchronization issues in animations and input feedback. Additionally, adopting more rigorous unit testing earlier in the project—especially for collision detection and interaction systems—could have saved time debugging later. We also encountered minor setbacks with Git merge conflicts, which highlighted the importance of consistent communication and clearer task allocation.
Looking ahead, we see multiple opportunities to extend Capoo. These include designing additional levels with dynamic puzzle mechanics, implementing audio cues for accessibility, and eventually creating a mobile-optimized version. The game’s architecture already supports modularity, which will make future expansion feasible without major rewrites.
Above all, this project gave us our first taste of end-to-end game development in a team setting. Each member brought their strengths—whether in coding, design, testing, or coordination—and learned to adapt to new responsibilities. Capoo is not just a game, but the culmination of our collaborative problem-solving, technical growth, and commitment to delivering a creative and enjoyable experience.
| Name | Role | Contributions |
|---|---|---|
| Shuyin Deng | Project Manager | 1 |
| Jiaxin Fan | Technical Writer | 1 |
| Peixuan Li | Developer | 1 |
| Yibu Ma | Developer | 1 |
| Yu Qiu | Developer | 1 |
| Jiahao Liu | Test Engineer | 1 |