🎮☝️PLAY TAKE AIM👆🎮
Take Aim is hosted as a static site on GitHub Pages - no install needed!
- Open your browser (chrome for best experience) and go to:
https://uob-comsm0166.github.io/2025-group-23/ - The game will load instantly.
- Click One Player or Two Player on the main screen to begin character selection.
Why GitHub Pages?
- Zero setup: Your browswer downloads only HTML/CSS/JS assets.
- HTTPS by default: Secure connection for loading audio, font, and sprites.
- Instant updates: New commits to (
main) go live immediately.
If you'd rather test or tweak the code, serve it locally:
- Clone the repo:
git clone https://https://github.com/UoB-COMSM0166/2025-group-23.git cd 2025-group-23/docs npx http-server -c-1 -p 8000 # initiate local server
- Open your browser (chrome for best experience).
- Navigate to
http://localhost:8000/and Play!
Game won't load / blank screen?
- Make sure you're on
https://or running alocalserver(asfile://routes often get blocked). - Check your browser's console for missing-file errors.
Audio not playing?
- Some browsers require a user gesture before unlocking sound. Click once inside the canvas before playing.
TAKE AIM!
FIGHT!
🎮 PLAY! 👈
- 1. Development Team
- 2. Introduction
- 3. Requirements
- 4. Design
- 5. Implementation
- 6. Evaluation
- 7. Process
- 8. Sustainability, Ethics and Accessibility
- 9. Conclusion
- 10. References
Team Photo Week 1 and Team Roles
Team member roles, from Left to Right in Figure 1
| MEMBER | NAME | ROLE | |
|---|---|---|---|
| 1 | Ching-Yueh Lin | xs24198@bristol.ac.uk | Frontend Developer |
| 2 | Yu-Hsin Chang | mh24718@bristol.ac.uk | Frontend Developer |
| 3 | Gioven Posa | kw24347@bristol.ac.uk | Backend Developer |
| 4 | Tzu Wei Lee | jj24506@bristol.ac.uk | Frontend Developer |
| 5 | Kotzamanidis Nikos | yy24148@bristol.ac.uk | Product Owner/Frontend Developer |
| 6 | Shabarish Menon | xh24681@bristol.ac.uk | Scrum Master/Backend Developer |
Welcome to the development documentation for Take Aim, an innovative 2D action shooter designed to reinvent platform arena-style combat with a blend of fast-paced gameplay and intelligent AI opponents. This documentation serves as a comprehensive guide through the entire development and design process of the game, serving as a resource for developers, evaluators, and game enthusiasts interested in the intricaies of modern game development, while highlighting key elements such as team roles, requirements and use cases, implementation challenges, evaluations testing, and sustainability considerations.
Based on contemporary gaming trends and bolstered by the felxibility of p5.js, Take Aim features both single-player and multiplayer modes with two difficulty settings - each affecting the behaviour and resilience of the computer-controlled adversary. The easy mode pits you against an AI that takes standard damage, while the hard mode introduces a tougher opponent which is designed to require even more precise timing and strategy. Key aspects that set Take Aim apart include: responsive and immersive UI, advanced AI mechanics, diverse and thematic game environments - like desert, underground, sky, - and innovative gameplay mechanics such as health tracking, power-ups and dynamic weapon-drops.
The project is driven by a collaborative team, with each member contributing unique skills across clear distribution of responsibilities ensuring an efficient workflow and robust software design. The documentation details the requirements that shaped Take Aim, specifically outlining key use cases which focus on different player interactions, ensuring that both single-player and multiplayer experiences are engaging and intuitive. Additionally, this documentation discusses some challenges we faced during the development process and how these challenges were addressed through iterative prototyping, rigorous testing, and performance evaluations. Detailed quantitvate and qualitative performance evaluations have been integral to the project, and such evaluations are documented to provide insight into how the game meets its design goals. Lastly, this document intends to share how our team recognisesd the importance of long-term maintainability and scalability - emphasising clean, modular code, comprehensive documentation, and a sustainable development process.
Requirements Engineering (RE) serves as a structured communication framework to capture and prioritize client requirements during the initial phases of the Software Development Life Cycle (SDLC) (Rasheed et al., 2021, pp. 1–2). This process is especially critical in game development: a postmortem review by Petrillo (2009, pp. 18–20) reveals that 75% of examined game projects suffered primarily from ambiguous or overly ambitious project scopes and unchecked feature expansion.
At the start of our ideation phase, we initially began with 12 different games. Our goal was to create a game that called back to classic games in the past but bringing another level of fun, freshness and challenges. Therefore, before finalising a game to develop, it was important for each member in the group to bring together 2 already existing games each, with their added twist to them. In our meeting, we discussed potential development challenges we, as developers, could face during production for each games that we liked. Some of the games we considered include Doodle Jump, Cat vs Dog, Bounce, and Flappy Bird. A summary of our game ideas with their brief description from Week1 are documented using google docs.
Moving into Week2, we have chosen two games to further expand on: Cat vs Dog, and Bounce. Communication between the team became more transparent as we decided to have three members working on each game, to go deeper on the specific in-game dynamics, mechanics, rules, and challenges. This was especially helpful to understand the scope of the entire development process.
Week3 allowed us to showcase these ideas by creating Paper Prototypes of our initial game ideas. Unfortunately, from the feedback we have recieved from the testers, it was clear to us that both our ideas did not fully satisfy us in-terms of our shared goal of creating a game that is 'classic-throwback', fun, fresh and challenging. We decided to combine the features we loved from Cat vs Dog, and Bounce to create an entire new game concept. We took the face-to-face battle throwing concept of Cat vs Dog, combined with the manuevering of the classic platform game in Bounce, and we have a game that combines tactical game-play and strategic combat. A GIF of our first Take Aim Paper Protoype is shown in Figure 2.
Take Aim Paper Prototype GIF
As some members in our team have had previous game development experience before, we decided to create a playable prototype where we were able to perform initial user testing for collision checking, map tile initialisation and player key handling. This was extremely useful as it boosted the backend team's confidence in overcoming the initial developmental challenges we highlighted at the start (collision behaviours and map creation). The initial version of the platformers and the map tiles is shown below (in Figure 3).
Screenshot of Game Prototype During Early Development
For frontend design, our group shared a common interest in the style of "Crossy Road" for the character look and in-game theme. We love the idea of players being able to choose their characters, as well as varying maps and environments where the game is set similar to "Crossy Road", while manipulating the platform style genre similar to "Mario".
It was important to us that we are develop a game that incorporates varying playing styles and tactical game-play, so we experimented with the game mechanics such as developing different types of weapons, the interval between weapon drop, auto-aiming, black hole mechanics, and AI algorithm (for One Player Mode).
Onion Model of Take Aim Game
- The Product or Service: Take Aim Game
- Development Team: Frontend, Backend, Quality Assurance, Product Owner, Scrum Master
- Game Testers: Testers, Professors, Experts (assessors)
- Users: "Retro Game/Arcade Game Lovers", Casual Gamers, Competitive Gamers, Interactive Gamers, Gamers with Disability
As we finalised our chosen game, it was clear to us that identifying and understanding key stakeholders is essential to ensuring a well-rounded, engaing, and accesible gaming experience (Alexander, 2004, p. 227). As shown in Figure 4, our stakeholders include end-users, such as retro game entusiast, both casual and competitive gamers, interactive players, and gamers with disabilities. Each group bring unique expectations and preferences, guiding us with developing the mechanics that cater to various playstyles and accesibility needs.
The development team, consisting of frontend and backend developers, quality assurance testers, a Product Owner, and a Scrum Master, is responsible for turning our ideas into a functional and immersive game. The team will also determine the technical feasibility, ensure performance optimisation, and maintain smooth development workflows. Additionally, game testers play a crucial role in validating our concepts, ensuring gameplay balance, and identifying potential issues before launch.
By actively involving these stakeholders in our ideation process, we can create a game that not only meets industry standards but also resonates with our taget audience. This approcah allows us to refine our vision early on, reducing development risks and fostering a more innovative and player-centric experience. Committing to this stakeholder-driven approach ensures that Take Aim will be both technically sound and highly engaing for its intended audience.
In order to have a better scope of what features we should prioritise, we gathered user-stories from our key stakeholders. These user stories were categorised by their Epics, a wider scope, high level requirement so that we can break our development process into independent, testable and valuable peices to implement (summarized in table 2).
User Stories for Take Aim
| Stakeholder | Epic | User Story | Acceptance Criteria |
|---|---|---|---|
| User: Retro/Arcade Lovers | Fullfill Player Enjoyment | "As a retro/arcade game lover, I want to play a classic game where I can customise the look of the players and display so that I can relive my favorite gaming experiences in a way that suits my preferences and enhances my enjoyment." | Given I am on the main menu, when I start game, then I should be able to change the player’s look to something like Pacman. |
| User: Casual Gamers | Implement Tutorial for Game Instructions + Pause Function | "As a casual gamer, I want the game instructions/rules to be very clear, and the visual design should be straight-forward. Also, I need to pause the game whenever I want." | Before the game starts, add a short interactive tutorial, then I can fully understand the game. Also, I should see a pause button function. |
| User: Competitive Gamers | Implement Multiplayer Mode | "As a gamer that is extremely competitive, I want to play against my friends so that I have bragging rights when I win” | "On the main menu page, when I navigate to the game mode page, then I should see an option for multiplayer game. |
| User: Interactive Gamers | Implement Fast-paced in Game Activity | “As an interactive gamer, I want to be able to have different features, like weapons, available in-game so that the game feels different every time." | During the game I need new weapons to be spawned every few seconds and previous weapons to be discarded after a certain amount of time. |
| User: Gamers with Disability | Enhance Visual Accesibility | “As a user with low visibility, I want to be able to see my player and in game activity to be interactive” “As a user with low visibility, I want to be able to resize the text of the main menu” |
Given during gameplay, when a player is being hit, then I want to be able to clearly see this with bright and big colors or hear this action. Given during the main menu page, when I navigate to the setting page, then I should see an option for resizing text. |
| Developers: Frontend | Improve UX in Game | "As a player, I want the graphical interface to be visually appealing and less straining on my eyes, so that I can play for longer periods without discomfort." | The UI should use less saturated colors to reduce eye strain. Implement sound and visual effects for player actions (e.g., button clicks, attacks, game events). Ensure that all game menus and interfaces are easy to navigate. Transitions and animations should be smooth and visually engaging. |
| Developers: Backend | Improve UX in Game | "As a player, I want the game to respond smoothly to my actions so that I can enjoy a seamless gaming experience." | Optimize server response time to reduce lag and delays. Ensure that real-time player actions (e.g., shooting, movement, interactions) are processed instantly. Implement efficient database queries to speed up data retrieval and updates. Expand game content by adding more map designs and increasing the variety of available weapons. |
| Developers: Quality Testers | Prototype Quality Assurance | "As a tester, I want to check the movement mechanics of the playable character so that the character moves as it is desired." | Movement Controls: The character can move forward, backward, left, and right using the designated input controls (e.g., keyboard). The character's movement speed and responsiveness are consistent. Jump Mechanics: The character can jump to a specified height and distance. Collision Detection: The character does not pass through obstacles or walls. Collision with objects is accurately detected, and appropriate reactions (e.g., stopping) are triggered. Environmental Interaction: The character can interact with the environment (e.g., climb on top of the platform) as specified. Performance: The character's movement does not cause any crashes or major bugs in the game. |
| Developers: Product owner | Ensure Game is Operating Smoothly | "As a product owner, I want to implement scalable and automated monitoring and logging solutions, so that I can ensure the system is consistently accessible and performing well for all users, including those with disabilities." | Given I am monitoring the system, when I observe the logs and alerts, then I should be able to quickly identify and resolve any accessibility or performance issues, ensuring the best experience for all users, including those with disabilities. |
| Developers: Scrum Master | Initiating Game Development Planning and Finalisation | "As a Scrum Master, I must decide the roles of each Team Member so that I can assign tasks accordingly." | Role Clarification: Each team member understands their role and responsibilities. Task Assignment: Tasks are assigned to team members based on their roles and expertise. Each task has a clear description, due date, and expected outcome. Task Tracking: The progress of each task is regularly updated by the assigned team member. Communication: Regular communication is maintained among team members to discuss task progress and resolve any issues. Sprint Planning: Sprint planning meetings are conducted to review and assign tasks for each sprint. The Scrum Master ensures that the team's workload is balanced and achievable within the sprint. Review and Feedback: Regular review meetings are conducted to assess task completion and gather feedback. The team is encouraged to provide constructive feedback to improve future task assignments. Documentation: All assigned tasks, roles, and responsibilities are documented and accessible to the team. Updates to roles and tasks are documented and communicated promptly. |
| Game Testers | Ensure Feedback is More Categorized to Improve Game Design | "As a game trial player, I want to know what's the difference between this game and others, make it simple to understand and play with, so I can provide feedback on its enjoyment and playability." | Before the game, I need a prototype video to understand the whole game. Also, after the game, provide me with a form of feedback categorized with usability, enjoyment and difficulty so you can clearly know how I feel about the game. |
| Developers (Frontend and Backend) | Ensure Game Runs Smoothly on Various Devices and Browsers | "As a developer, I want the game to run efficiently in the browser without requiring high-end hardware, so that it is accessible and eco-friendly for users with different devices." | The game loads within 3 seconds on standard home internet and devices. No more than 50MB of assets are loaded during gameplay to reduce memory usage. Performance optimisations are applied to rendering and animation to keep gameplay at 60 FPS on mainstream browsers. Idle state logic is implemented (e.g., pause menu, no background rendering) to reduce energy usage when game is not actively played. |
| Gamers with Disabilities | Enhance Accessibility and Visual/Audio Feedback | "As a player with visual or hearing challenges, I want the game to clearly show and/or play sound when important events happen, so I can react in time." | When a player is hit, bright flashing colours and large text animations appear. When weapons drop or a player is eliminated, clear sound effects are played. The settings menu allows players to toggle or amplify visual/sound feedback. Text and HUD elements are large and contrast-friendly for easy readability. |
| Interactive Gamers & Solo Players | Provide Flexible Game Modes to Support All Player Types | "As a player, I want to choose between multiplayer and single-player modes so that I can enjoy the game whether I want to play socially or alone." | The main menu includes Single Player and Multiplayer game mode options. Single Player mode offers AI opponents for casual or solo play. Multiplayer mode allows players to compete locally or online. The game tracks performance separately for both modes to encourage participation in either play style. |
As our user stories includes a wider range of users such as both casual gamers and competitive players, it was vital for us to convert our user-stories into use case diagrams. This way, we can better conceptualise our development processes and mitigate the difficulties when making a game for a large group of costumers. By transforming our user stories into use case diagrams, we are able to visualise the interactions between the end-user, our development team and the game system itself, ensuring a well-organised and efficient development proccess.
Each user story represent a real-world scenario that our end-user might experience when playing Take Aim. For example, a competitive gamer suggested that: "As a competitive gamer, I want to play against my friends so that I have bragging rights when I win."
From this story, we extract key interactions and translate them into a use case diagram (shown in Figure 5), where the competitive gamer (actor) interacts with the game system through use cases like "Start Game" (shown in Figure 7).
By mapping these interactions, we have identitifed primary actors, clarify dependencies between different game functions, and ensure that all user needs are accounted for. This process also assisted our development team by providing a clear structure for implementing features in a user-focused manner.
Use Case Diagram 1: Main Menu Navigation
Figure 6.
Use Case Diagram 2: Gameplay System
This document provides a detailed description of the use cases represented in the "Main Menu Navigation" and "Gameplay System" diagrams. Each use case highlights the interaction between the player(s), AI and the game system. Our Use Case Specification is completed using Eraser.io and a link to the full documentatiion is attached below.
Screenshot of Use Case 1: Start Game (used as an example above)
Figure 8.
Screenshot of Use Case 3: Player Shoot
[📑 Link to the full Take Aim Use Case Documentiation] https://app.eraser.io/workspace/2WadpJ57Y5SRLlBTODcR?origin=share
After reviewing our potential stakeholders and analysing a diverse range of User Stories, we now have a clear understanding of our objectives and requirements which means we identified the key features to integrate into our game design. The use of our Use-Case Documentation/Specification has made our development process much easier to structure, notably providing clear guides for developing the accessibility features and accommodated our fast-paced agile approach.
We considered the following factors during the design process:
- Teck Stack: As our game is a web-based game, we decided to use a JavaScript library called P5.js to build our Take Aim game. P5.js is a well known library for building creative animations therefore it is a perfect tool to develop a dynamic and fluid shooting game.
- Data Storage & Collection: As a team, we discussed if there was a need for our game to store essential data. To match the requirements, the players have the option to input a nickname to be displayed during the game. However, due to Take Aim being a web-based game, users wont need to install the game as the browser automatically downloads the necessary content from the game's website (GitHub Page). This means that users information will not be collected and game state's will not be saved.
- System Architecture: Before we began implementing code, it was important for us to touch on Take Aim system architecture design in order to visually represnt a blueprint for the game's system and components. So we created Class and Behavioural Diagrams to meet this.
A Class Diagram provided a systematic view of Take Aim as a System (Figure 9). This allowed us to structurally plan ahead the relationship between objects and help with visually identify where certain functions and variables should be located/implemented, which would contribute to good Object-Oriented Design (OOD) principles within our code. Each class has attributes and methods appropriate to their function within the game. For example, GameController directly communicates with Player and AIPlayer to control game progression, while MapManager provides the environment in which players interact.
- Setup: Initialises the whole game, loading neccessary resources like sprites, sounds, and setting up the game canvas.
- Game Controller: Manages game states such as starting, pausing, and ending the game. It interacts with Player, AIPlayer, and manages game rounds.
- Player: Represents both human and AI players, handling actions like moving, jumping, and shooting. Player is extended by AIPlayer.
- AIPlayer: Inherits from Player, adding AI behaviours such as finding weapons, hiding, and pathfinding to power-ups and weapons.
- Items: Manages in-game huds like health icons, weapons icons. It is responsible for displaying and updating these items.
- Power-Ups: Handles power-ups within the game, including their effects and updates during the game.
- Sound Manager: Manages all sound effects and music, controlling their playback based on game events.
- Sprite Manager: Loads and manages all sprites used in the game, providing sprites based on player index and direction.
- Map Manager: Manages the game maps, including their creation, rendering, and animation based on predefined tiles and background imges.
Class Diagram Generated Week 10
Following the Class Diagram, we wanted to effectively visualise the behaviour of Take Aim as a whole program so we formed a Sequence Diagram (Figure 10). This offered a clear visual representation of how various game components interacted over time, which we found was a powerful tool for both our team's planning and communication. By mapping out player actions, AI logic, and system responses, our team were able to quickly identify design flaws which improved collaboration.
In order to meet the requirement specification, we ensured to develop a system architecture that starts with a user-interface menu. Take Aim begins with the Setup component initiating the game mode setup via the Game Controller, which further initialises the maps, generates the player(s), weapons, and power-ups through respective components such as Map Manager, Player, Weapon, and Power-Ups.
The core gameplay loop involves continuous player updates (movements and interactions), weapon pickups, bullet generation and usage, player damage handling, and power-up consumption. An AI player is also generated in single-player mode, and continuously updates its movement behaviour depending on the player and game states. Sprite Manager serves images upon request, supporting visual elements of the game.
Sequence Diagram of Take Aim
We incorporated agile methods when designing Take Aim which required fequent updates to our system architecture. So by having an updated class and sequence diagrams to show during sprints cycles, our developers, testers, designers, and stakeholders maintained a unified understanding of the system, a key Agile value.
However, due to rapid iteration cycles, some diagrams quickly became outdated which required extra workload to update and hindered our teams agility efficiency on a few occasions. One way we overcame this issue is by creating multiple different github branches of our game repository that handles the implementation of predefined features, as well as a currentWorkingBranch where we implemented final versions of features into one working program.
Overall, agile's iterative nature required constant testing, debugging, and refactoring. Our behavioural diagrams simplified these processes by quickly identifying where interactions broke down or misalign with expected behaviour, improving responsiveness to change.
After reviewing our development process, we have encountered a number of interesting and pivotal challenges. The challenges focuses around: the game UI/UX design demands, the auto-aim feature, and the data structure algorithm for AI (hard-mode) pathfinder. Including other minor prerequisite implementations that took multiple iterations and rigorous testing to complete, such as the map-collision handler and player controls.
Prior to implementing any of the challenges, it was a prerequisite to create two basic platformers representing: Player 1 and Player 2. Although not one of our main developmental challenges, we found that programming the players movement was initially difficult. For example, our initial approach to applying gravity to the player's ability to jump would cause both of the platformers to move infinitly upwards and outside the canvas. To overcome this, we realised that each players will need two sets of different keys, so passing the respected key buttons (shoot, left, right, and jump) in the parameters is the best way to instantiate the players and their respected controls. Next, in order for these platformers to have an environment they can interfact with, we created a 2D array of tiles with a predefined size and populated the canvas with it. Initially, we expected to include the map collision check as one of our main challenges however, this turned out to be a quick implementation due to previous project experience in this concept. Our approach used the predefined width and height of the tiles with conditional checks such as isOnPlatform method.
1. Auto-Aim Feature
One of the most technically nuanced features we developed was the auto-aim shooting mechanic, implemented inside the Player.shoot() method. The purpose of this mechanic was to simplify player input by automatically targeting the opponent whenever the shoot key is pressed, simulating a form of assisted targeting as shown in Figure 11. Although this may sound straightforward in theory, implementing this functionality presented several unexpected challenges.
Auto-Aim GIF of Two-Player Mode
Our initial difficulty stemmed from determining the most accurate and fair way to calculate the direction a bullet should travel. We knew the shooting player would need to "auto-aim" towards the opponent, but due to dynamic positions, gravity, jumping states, and horizontal movement, achieving consistent targeting without unfair advantage was tricky. Early iterations would cause bullets to fire in unnatural directions - especially when players were close together or overlapping vertically - resulting in missed shots or self-inflicted misfires.
To resolve this, we implememented a solution that calculates the center of both the shooting player and the target player using x/y positions and sprite dimensions. We then used the atan2() function to determine the exact angle between them, which was used to rotate the weapon sprite and to calculate the bullet velocity vector using basic trigonometry (dx / distance, dy / distance). Normalising the direction vector by dividing by the computed distance ensured bullets always traveled consistently at the desired speed regardless of the distance between players.
2. AI Pathfinder(Hard Mode)
A particularly complex implementation during our development was designing the AI player's pathfinding system, especially in hard mode. This challenge involved creating a non-trivial decision-making process for navigating a dynamic platformer map while selecting weapons, avoiding bullets, and positioning for tactical attacks. In contrast to this, the first iteration of AI player involved a hard coded reactive behaviour that allows the AI to behave in a pre-defined way based on the other player which we felt could be the easy version of the game.
The central issue was building a robust AI that understands the environment and reacts to both static platforms and dynamic game elements like power-ups and bullets. Our early versions of this AI would either get stuck in infinite loops when navigating vertically or behave unrealistically - either walking off edges or trying to jump at walls. Since the game is a 2D platformer, vertical navigation added additional complexity.
To tackle this, we created a graph-based node system representing the top of platforms in NodeNetwork.js (as shown in Figure 12). Nodes are connected horizontally and vertically (with safety checks to prevent excessive vertical chaining, using a max chain constrait in A*). This map graph is initialised each round using buildPlatformNetwork(), allowing the AI to perform A* pathfinding based on valid movement constrainst.
AI Pathfinder Nodes
We extended the AIPlayer class from the base Player class and gave it states like seekingWeapon, shooting, and seekingPowerUp. Each AI update checks for nearby bullets (to dodge), finds the nearest desirable item (weapon or power-up), and navigates to it using a custom A* implementation that avoids paths with excessive vertical climbs.
One of the hardest bugs we fixed was the AI getting stuck vertically. It turned out that nodes were being linked without accounting for unreachable vertical chains. We added a "vertical chain constraint" that limited consecutive vertical transitions to five, which stabilised movement logic dramatically.
- Prioritised shortest paths with the fewest jumps.
- Bullet detection with dodging behaviour and cooldown.
- Fallback strategies if pathfinding failed or AI was blocked.
The result is a challenging reactive AI that feels organic to play against - especially when combined with its decision to engage players only when it has a clear line of sight or access to power-ups.
3. Game Graphic Design
Perhaps the most time-consuming and visually demanding part of the development for the frontend team was creating the 3D character models and integrating them into fully interactive Character Selection Page. The goal was to have a seamless and polished selection experience where players could preview rotating 3D versions of character like Lion, Parrot, Dog, Crab, Penguin and Chicken - each built entirely using p5.js's WEBGL system.
One of the most persistent challenges was ensuring that each character was accurately constructed and visually distinct while still maintaining a consistent design language. Each model required dozens of individual 3D primitives (box, speheres, etc) layers and transformed in 3D space as seen in Figure 13. We had to iterate through several poses, proportions, and rotations to make sure characters looked engaging from all angles.
An additional layer of complexity came from having to convert standalone sketches (each character was developed separately for testing) into a unified, working UI component within the CharacterPage. Managing canvas rendering, viewports, and interactively in a multi-character, multi-player selection interface pushed the limits of p5.js's DOM integration.
Crab and Pengiun p5.js Sketches
We modularised each character sketch into its own function (eg. parrotSketch, lionSketch, etc.) and registered them inside a preview map structure. This allowed the CharacterPage.js to dynamically generate and attach p5.js instances to designated HTML containers based on player input. We also used p.ortho() and transparent backgrounds to make sure each 3D canvas blended with the UI.
To ensure consistency and usability:
- All characters were scaled appropriately and centered in the canvas.
- Angle rotation (rotateY) was implemented per frame for a smooth preview.
- Each player preview was isolated to prevent DOM collisions.
- UI elements were styled with a consistent pixel font and layout to match the game's retro tone.
Although initially frustrating, the final result offered a professional, responsive character selection experience - essential to setting the tone before the gameplay begins.
This week, we invited other team members to try out the newly released version of our game (Figure 14). We received a lot of positive feedback, along with some valuable suggestions and ideas. To collect comprehensive insights, we conducted several evaluation methods, including Think Aloud Evaluation, Heuristic Evaluation, NASA-TLX for workload assessment, and the System Usability Scale (SUS).
Observers playing/evaluating our game
1. Think Aloud Evaluation:
Summary of Think Aloud Evaluation
We conducted a qualitite Think Aloud (TA) evalation as it has been shown to be effective in areas of Human Computer Interaction (Nielsen et al., 2002; Joe et al., 2015). Participants were encouraged to think aloud as they played, expressing their thoughts and reactions in real-time. Using audio recording, we recorded their feedback and identified a series of underlying themes utilising techniques found in Thematic Analysis (Braun & Clarke, 2006), paying special attention to moments of confusion and engagement. From these observations, we identified several key themes and categorized the feedback (in table 3) as follows:
Cetagorising Think Aloud Results
| Category | Issue | Solution |
|---|---|---|
| Player Control | 1. It's difficult to distinguish player identity when selecting the same character. 2. Health visibility is unclear during gameplay. |
1. Display the player's name above their character. 2. Add a health percentage indicator both above the character and at the bottom of the game panel. |
| Game Instructions | The game lacks an instruction page, making it difficult for players to understand controls, weapons, black hole mechanics, etc. | - Implement an instruction page accessible by pressing "Esc". - Preload the instructions during loading and require players to read them. |
| Difficulty | The AI opponents feel overly challenging for some players. | Introduce difficulty settings. Players can choose a preferred difficulty level (Easy, Hard) before starting the game. |
This feedback gave us a clearer understanding of where players encountered friction or confusion. Based on this, we’ve already started implementing targeted improvements to enhance both usability and gameplay experience.
2. Heuristic Evaluation:
To ensure our game delivered a smooth and engaging player experience, we conducted a heuristic evaluation based on Nielsen’s usability principles. We invited seven observers and experts to assess the main game interface, whose insights helped us identify key usability issues, such as unclear health displays and confusing controls. This process guided our team to implement targeted improvements, significantly enhancing gameplay and player satisfaction.
Scores from Heuristic Evaluation
| Interface | Issue | Heuristic(s) | Freq (0-4) | Impact (0-4) | Persist (0-4) | Severity |
|---|---|---|---|---|---|---|
| Main Game | Unclear keyboard controls for character operation | Help and documentation | 3 | 4 | 0 | 2.3 |
| Main Game | Player health display is unclear or hard to see | Visibility of status | 4 | 3 | 4 | 3.6 |
| Main Game | Different weapons deal the same damage, confusing players | Match system & world | 3 | 2 | 2 | 2.3 |
| Main Game | Too many powerups make the game too easy | Match system & world | 2 | 1 | 2 | 1.6 |
The heuristic evaluation of the game (as scored in table 4) highlights some usability issues with different levels of impact.
- Unclear health display (Severity 3.6): Players can’t clearly see their remaining health, a frequent issue that disrupts gameplay and persists, violating the "Visibility of system status" heuristic.
- Unclear keyboard controls (Severity 2.3): Unclear controls for character operation frustrate players often, tied to the "Help and documentation" heuristic.
- Confusing weapon damage (Severity 2.3): Different weapons dealing the same damage confuses players frequently, linked to the "Match between system and the real world" heuristic.
- Excessive powerups (Severity 1.6): Too many powerups make the game too easy, a less common but persistent issue, also tied to "Match between system and the real world" heuristic.
Fixing the health display and adding better instructions should be top priorities to level up the player experience and gameplay.
Improvements Implemented
To enhance the game’s usability, we made the following improvements:
- Fixed the unclear health display: Added a clear health bar at the bottom of the game screen with high-contrast colours, making it easy for players to track their status (Figure 17).
- Clarified keyboard controls: Introduced a clear instruction page, shown during the pre-game loading screen, ensuring players knew how to operate characters without confusion (Figure 16).
- Resolved weapon confusion: Differentiated weapon damage and added varied weapon types to meet player expectations and eliminate confusion (Figure 16).
- Balanced powerups: Reduced powerup frequency to keep the game challenging and engaging.
Implemented instruction page in both pre-loading and in-game
 |
 |
Improved health bar display before and after
 |
 |
By prioritizing the health bar and control instructions, we’ve significantly improved the player experience and gameplay flow.
3. NASA TLX :
To assess the perceived workload our users have when playing our game, we conducted a NASA-TLX (Task Load Index) survey with ten participants after they experienced both the easy and difficult game modes, as NASA-TLX has been shown to be highly reliable in many areas of Human Computer Interaction (HCI) including video game difficulty assessment (Hart & Staveland, 1988; Ramkumar et al., 2016; Seyderhelm & Blackmore, 2023). According to research the NASA TLX has helped improved validity, easy to administer, and measures six dimensions of workload: mental demand, physical demand, temporal demand, performance, effort, and frustration (Said et al., 2020; Virtanen et al., 2021). Table 5 and 6 results showed a consistent increase in workload for every user across all dimensions in the difficult mode, with the most notable rises in mental demand and frustration. These insights helped us validate the intended challenge progression and informed subtle adjustments to balance difficulty, ensuring a more engaging but manageable player experience.
Table 5.
Average TLX Scores per Dimension
| Category | Easy Level | Difficult Level |
|---|---|---|
| Mental Demand | 35 | 65 |
| Physical Demand | 10 | 15 |
| Temporal Demand | 22.5 | 38.5 |
| Performance | 17.5 | 28.5 |
| Effort | 45 | 63.75 |
| Frustration | 35 | 63.75 |
Table 6.
Total TLX Scores (Per User)
| User ID | Easy Level | Difficult Level | Difference |
|---|---|---|---|
| 1 | 20 | 44 | |
| 2 | 27 | 36 | |
| 3 | 19 | 53 | |
| 4 | 33 | 39 | |
| 5 | 26 | 55 | |
| 6 | 33 | 53 | |
| 7 | 32 | 48 | |
| 8 | 19 | 38 | |
| 9 | 19 | 47 | |
| 10 | 47 | 44 | |
| Average | 27.5 | 45.75 | 18.25 |
Comparison of results for NASA TLX Evaluation
| Average rating of each subscale | Total TLX Scores per user |
|
|
4. System Usability Survey (SUS) :
To evaluate the overall usability of our game, we conducted the System Usability Scale (SUS) with ten participants after gameplay. Users rated both the easy and difficult modes, producing average SUS scores of 74.5 and 64.35 respectively (Table 7). These results indicate that the easy mode falls within the range of good usability, while the difficult mode revealed usability challenges likely tied to increased game difficulty. This feedback helped us spot moments where players were struggling against the AI and led to tweaks to the AI’s responsiveness and challenge curve to create a fairer and more engaging 1v1 experience. Below is the table which represents the total score for both levels and shows the average difference between the collected data.
SUS Scores per user
| User ID | Easy Level | Difficult Level | Difference |
|---|---|---|---|
| 1 | 87.5 | 75.0 | |
| 2 | 55.5 | 50.0 | |
| 3 | 77.5 | 62.5 | |
| 4 | 82.5 | 67.5 | |
| 5 | 75.0 | 55.0 | |
| 6 | 72.5 | 67.5 | |
| 7 | 80.0 | 72.5 | |
| 8 | 85.0 | 80.5 | |
| 9 | 50.0 | 40.5 | |
| 10 | 80.0 | 72.5 | |
| Average | 74.5 | 64.35 | 10.15 |
Figure 19.
Comparison of SUS scores by level
Statistical Insight (Wilcoxon Signed-Rank Test)
To assess whether the differences in workload and usability between the easy and difficult game modes were statistically meaningful, we referred to the Wilcoxon Signed-Rank test.
With a sample size of ( n = 10 ) and a significance level of ( α = 0.05 ), the critical value for detecting significance is 8 (as illustrated in Figure 20).
Critical Value Scale for Wilcoxon Signed-Rank Test
The observed average difference in NASA-TLX scores was 18.25, while the average difference in SUS scores was 10.15—both well above the critical threshold. This result suggests that users consistently experienced greater workload and reduced usability in the difficult mode compared to the easy one. The statistical evidence supports our design assumption: increased challenge in the difficult mode leads to a noticeably different user experience, validating the effectiveness of our difficulty scaling.
Throughout the Take Aim project, the team relied exclusively on manual testing and fuzz testing of inputs by actively playing the game to verify each new feature. After implementing a feature – whether it was basic movement controls, the shooting mechanism, the health system, or enemy AI – developers would immediately test it in‑game to ensure it behaved as intended. This informal approach meant that most team members were continuously involved in quality assurance during and after their implementations. Each developer would not only test their own code but also join others in play sessions, ensuring a second pair of eyes on new features. This iterative “play as you develop” process was built into every sprint, aligning with our agile workflow by catching issues early in the same sprint they arose. As a result, testing was a constant, ongoing activity rather than a one‑time phase, growing in scope alongside the game’s functionality.
Throughout our game development, we adopted a structured yet flexible approach guided by Agile principles. By integrating collaborative techniques such as face to face meetings (as seen in Figure 21), we ensured smooth and efficient teamwork. We were enthusiastic about immersing ourselves in the development process, embracing diverse ideas and solutions. Through structured planning and adaptive collaboration, we leveraged each team member’s unique strengths to support our game's success. We followed Scrum to guide iterative development, fostering a responsive, self-organising team and continuous improvement through regular feedback.
Team meeting
We followed Agile values: frequent communication, iterative planning, and collective decision-making. Operating under a flat team structure, every member had equal opportunities to contribute, which helped us with a range of ideas and abilities.
At the beginning of the project, each member proposed two game ideas. We selected our final concept through majority voting (as seen in Figure 22), ensuring it aligned with our shared interests and project goals. Weekly in-person meetings on Tuesday helped us to track progress, delegate tasks, and resolve issues. A Game Jam during reading week boosted development, creativity, and team bonding. Once the course ended, we shifted to remote collaboration using Microsoft Teams and WhatsApp to accommodate members living further apart.
Idea selection meeting
WhatsApp supported daily communication, updates, and file sharing. Major decisions—such as AI implementation and visual design choices—were made through consensus during team meetings. To prioritise user stories, we used planning poker, helping us balance project goals and workload. A shared Microsoft Word document was used for brainstorming and documentation sharing.
While scheduling conflicts occasionally delayed decisions, we set clear deadlines and used asynchronous updates to stay on track. Agile’s iterative sprints and retrospectives helped us refine our process, maintain steady progress, and adapt to new challenges.
Monitor game development progress using Jira Gantt
To support Agile’s focus on communication, transparency, and iteration, we used a suite of collaboration and development tools:
Communication & Collaboration:
-
Microsoft Teams: Hosted remote meetings.
-
WhatsApp: Enabled real-time communication and file sharing.
-
Microsoft Word: Used for collaborative documentation and brainstorming.
-
Microsoft PowerPoint: Created and presented visual concepts.
-
Jira: Managed tasks and visualised progress using a Kanban board.
Development:
-
Geny.lovo: Generated AI voiceovers for our project video.
-
Logic Pro: Assisted in sound design and audio editing.
-
Figma: Initially used for mockups and UI/character design.
-
Eraser.io: Helped create class diagrams and UMLs.
-
CraftPix.net: Provided inspiration and assets for visuals.
-
Pixel Studio & MediBang: Used for pixel art and other graphic assets.
Initially, we experimented with Figma for UI and character design but found it challenging for some team members. We pivoted to PowerPoint, which was more accessible and familiar. This flexibility reflected Agile’s adaptability—choosing tools that best suited our team’s needs. Jira’s Kanban board was particularly valuable for maintaining task visibility and accountability.
Group online meeting
To maximise efficiency, we assigned team roles based on individual skills, experiences, and interests, established early through team discussions.
-
Backend Developer: Focused on game logic and AI systems, including map collision, player controls, and implementing two AI modes.
-
Frontend Developer: Developed 3D character models and custom visuals using P5.js, designed the user interface, and added smooth animations for an enhanced user experience.
-
Scrum Master: Facilitated sprint planning and kept the team aligned by writing clear user stories.
-
Product Owner: Prioritised tasks and ensured the development stayed consistent with our vision.
Although roles were defined, our team remained flexible and collaborative. For example, when we introduced a new AI feature, one member supported from scrum master to backend to develop implementation. This adaptability improved collaboration and knowledge-sharing.
During the Game Jam, we used pair programming to streamline development, promote real-time code review, and share skills. This Agile-aligned practice fostered shared ownership of the codebase and enhanced team cohesion.
Our teamwork experience was highly effective, supported by Agile practices. Regular meetings and tools like Jira and WhatsApp kept us aligned and accountable. A flat team structure and shared decision-making empowered us to work collectively, supported by techniques such as planning poker and regular feedback further supported efficient collaboration.
We created an inclusive and communicative team culture that encouraged idea-sharing and continuous feedback. Agile’s focus on flexibility and iteration helped us adapt to change and minimise unnecessary work. These practices improved our problem-solving and communication skills—preparing us for real-world software development environments.
This project demonstrated how Agile’s focus on collaboration, flexibility, and iterative feedback cycles can lead to effective and satisfying teamwork.
By applying Agile principles, we were able to build a functional and engaging game. Using tools such as Jira, Microsoft Teams, WhatsApp, and PowerPoint, assigning tailored roles, and embracing Scrum’s structure, we overcame challenges and met our objectives. This experience reinforced the importance of iterative planning, proactive communication, and collaborative problem-solving in software development.
Sustainability is now central to software engineering and game development. Following the framework introduced in our sustainability lectures, sustainability can be understood across several dimensions, including environmental, social, technical, individual, and economic aspects. Throughout the design and implementation of Take Aim, our team actively embedded sustainability concerns, particularly focusing on environmental, social, and technical dimensions to ensure ethical and accessible gameplay experiences.
Environmental Sustainability
Although video games are less resource-intensive than other ICT products, they still contribute to global energy usage, particularly through hosting infrastructure, network transmission, and client-side processing. In response, Take Aim was deliberately designed as a lightweight web-based game using P5.js. This decision enabled the delivery of rich gameplay experiences through minimal resource consumption on the client side. By optimising rendering processes and avoiding heavy graphical or computational demands, we reduced the energy footprint on end-user devices.
Furthermore, our deployment strategy reflects careful consideration of sustainability. Hosting the game via GitHub Pages leverages existing infrastructure, eliminating the need for bespoke server solutions that would otherwise increase electricity and cooling demands. This aligns with the principles of substitution and optimisation highlighted in sustainability design — replacing resource-heavy approaches with lightweight alternatives and optimising system operation to minimise energy use.
Social and Ethical Sustainability
Social sustainability emphasises inclusiveness, diversity, and ethical responsibilities towards users. In Take Aim, we implemented several features to address these areas. Firstly, we prioritised visual accessibility. Recognising that gamers may have varying levels of visual acuity, we incorporated bright colour schemes, animated feedback for damage and actions, and clear health and score displays. These improvements enable players with visual impairments or colour perception differences to fully engage with the game, addressing ethical obligations to inclusiveness and usability.
Secondly, the game design supports different social needs and preferences. Multiplayer mode fosters social interaction and competition, while single-player AI mode ensures that individuals who may prefer or require solitary play can still enjoy a complete experience. This flexibility supports individual well-being and addresses inclusiveness and diversity aspects.
Additionally, ethics played a key role in gameplay design. Unlike many mainstream games that rely on monetisation strategies that can exploit players, Take Aim does not include advertisements, in-game purchases, or addictive reward loops. This ethical design choice promotes healthier gameplay patterns and ensures that the game respects users' time and attention.
Technical Sustainability
Technical sustainability focuses on software maintainability, usability, and long-term viability. Throughout development, we adopted modular design principles and best practices to ensure Take Aim remains adaptable and easy to maintain. Frontend components, such as the character selection screen, health HUD, and game menus, were developed as reusable and independent modules. This approach aligns with good object-oriented design and simplifies future updates, bug fixes, and feature expansion.
Furthermore, by leveraging P5.js — a widely-supported and actively maintained open-source library — we avoided proprietary technologies that may become obsolete. This reduces risks of "software rot" and supports the long-term accessibility of Take Aim for future players and developers.
Finally, development processes also reflected technical sustainability values. Features were incrementally developed and tested, avoiding technical debt and ensuring clean, efficient codebases. These practices support not only maintainability but also contribute to reduced resource consumption during ongoing development and deployment phases.
Conclusion
Take Aim demonstrates that integrating sustainability into game development is achievable and essential. Through lightweight deployment and optimisation for energy efficiency, the game reduces its environmental footprint. By prioritising accessibility, ethical design, and social inclusiveness, the game offers positive social impacts and ethical responsibility. Finally, through modular architecture and maintainable code, it supports technical sustainability for future growth and adaptability.
In conclusion, our project reflects the understanding that software developers have a responsibility to shape technology in ways that promote not only enjoyment and engagement, but also long-term sustainability, ethical practice, and accessibility.
Reflecting on the project as a whole, the team found this to be one of the most engaging and rewarding collaborative experiences.From the very beginning,there was a strong sense of enthusiasm as we began developing a game concept we were genuinely excited to develop. Each team member fully embraced their individual role, and together we worked cohesively to build a shared vision. We were open to experimenting with new ideas, adapting to different approaches, and aligning our efforts around clear design and development goals. One of the key strengths of our team dynamic was our ability to reach decisions through open discussion and mutual respect. We consistently identified and agreed on solutions that balanced creativity with practicality, resulting in a project that truly reflects collective effort.
Table to demonstrate team contributions for Game Project.
| Contributer | Contribution |
|---|---|
| Ching-Yueh Lin | 16% |
| Yu-Hsin Chang | 16% |
| Tzu Wei Lee | 16% |
| Kotzamanidis Nikos | 16% |
| Shabarish Menon | 16% |
| Gioven Posa | 20% |
In terms of challenges, we encountered relatively few significant roadblocks. While every team naturally faces some degree of coordination or scheduling friction, we managed these moments through ongoing communication and mutual support. Regular meetings and informal check-ins allowed us to stay aligned, redistribute tasks when needed, and provide assistance across roles. These interactions helped maintain a positive and productive working environment throughout the project lifecycle. The absence of major conflicts or breakdowns in collaboration is a testament to the group’s willingness to listen, compromise, and remain focused on shared outcomes.
A key takeaway from this experience was the opportunity to work within an agile development framework. Adopting agile principles helped us maintain clear short-term goals while remaining flexible in the face of evolving ideas and feedback. The use of Jira played a significant role in keeping our workflow organized, transparent, and efficient. It allowed us to track progress, assign tasks, and identify bottlenecks early. Additionally, producing formal documentation—such as user stories, use cases, and class diagrams—deepened our understanding of how structured planning supports effective coding and team communication. These processes not only contributed to the success of this project but also provided valuable insights for future development work.
Looking ahead, the team has identified several features for future implementation that would significantly enhance the game’s depth and replayability. One of the next steps is the development of online multiplayer functionality, enabling real-time 1v1 matches between players. This would be paired with a ranked seasonal system, where players compete to achieve the best win ratios and are matched based on skill to ensure fair competition. At the conclusion of each season, players would earn rewards based on their rank. These could then be redeemed in an in-game shop for cosmetic upgrades such as character and weapon skins or unlockable taunt messages to celebrate victories.These features are meant to keep the game fun and exciting for longer, while also helping build a strong, active player community
Alexander, I. F., & Beus-Dukic, L. (2009). Discovering Requirements: How to Specify Products and Services. Wiley. https://books.google.co.uk/books?id=KMZYFzgbXSwC
Braun, V., & Clarke, V. (2006). Using thematic analysis in psychology. Qualitative Research in Psychology, 3(2), 77–101. https://doi.org/10.1191/1478088706qp063oa
Hart, S. G., & Staveland, L. E. (1988). Development of NASA-TLX (Task Load Index): Results of empirical and theoretical research. Advances in Psychology, 139–183. https://doi.org/10.1016/s0166-4115(08)62386-9
Petrillo, F., Pimenta, M., Trindade, F., & Dietrich, C. (2009). What went wrong? A survey of problems in game development. Computers in Entertainment, 7(1), 1–22. https://dl.acm.org/doi/10.1145/1486508.1486521
Ramkumar, A., Stappers, P. J., Niessen, W. J., Adebahr, S., Schimek-Jasch, T., Nestle, U., & Song, Y. (2016). Using GOMS and NASA-TLX to evaluate human–computer interaction process in interactive segmentation. International Journal of Human–Computer Interaction, 33(2), 123–134. https://doi.org/10.1080/10447318.2016.1220729
Nielsen, J., Clemmensen, T., & Yssing, C. (2002). Getting access to what goes on in people’s heads? Proceedings of the Second Nordic Conference on Human-Computer Interaction. https://doi.org/10.1145/572020.572033
Rasheed, A., Zafar, B., Shehryar, T., Aslam, N. A., Sajid, M., Ali, N., Dar, S. H., & Khalid, S. (2021). Requirement Engineering Challenges in Agile Software Development. Mathematical Problems in Engineering, 2021, 1–15. https://onlinelibrary.wiley.com/share/F2YDIFI2KHKFEQFNBW34?target=10.1155/2021/6696695
Said, S., Gozdzik, M., Roche, T. R., Braun, J., Rössler, J., Kaserer, A., Spahn, D. R., Nöthiger, C. B., & Tscholl, D. W. (2020). Validation of the Raw National Aeronautics and Space Administration Task Load Index (NASA-TLX) questionnaire to assess perceived workload in patient monitoring tasks: Pooled analysis study using mixed models. Journal of Medical Internet Research, 22(9). https://doi.org/10.2196/19472
Seyderhelm, A. J. A., & Blackmore, K. L. (2023). How hard is it really? assessing game-task difficulty through real-time measures of performance and cognitive load. Simulation & Gaming, 104687812311699. https://doi.org/10.1177/10468781231169910