2025-group-30

Table of Contents

• 1. Game & Game video
• 2. Team
• 3. Introduction
• 4. Requirements
• 5. Design
• 6. Implementation
• 7. Evaluation
• 8. Sustainability, Ethics and Accessibility
• 9. Process
• 10. Conclusion
• 11. Contribution Statement
• 12. References

1. Game & Game video

Watch the demo video

Play the game

Our game lives in the docs folder, and is published using Github pages to the link above.

2. Team

Figure 1: Group photo of the team

Table 1: Team members, from Left to Right of Figure 1

Name	Email	GitHub username
Lingchen Li	[email protected]	lingchen2333
Hanying Bian	[email protected]	Hanying-Bian
Liyang Li	[email protected]	Misaki-1
Lei Gao	[email protected]	Muilka
Shiyu Dou	[email protected]	hl24597
Zhuoyan Qiu	[email protected]	1003-qzy

3. Introduction

Our game is a lighthearted, fast-paced stacking challenge inspired by a classic mini-game from Mole Manor, reimagined with a fresh farmyard twist. Set during harvest season, players must move their character left and right to catch falling haystacks and deposit them into a barrel before time runs out. The goal: hit the hay collection target to progress to the next level.

What sets our game apart is the blend of intuitive mechanics with subtle strategy. Players can carry up to five haystacks at once—exceeding this limit causes them to stumble and lose everything, introducing a risk-reward dynamic that keeps the action engaging. As players gather more hay, their movement slows, forcing thoughtful decisions about when to offload and when to keep stacking.

Beyond its core mechanic, the game introduces novel twists to deepen the experience. In single-player mode, players must dodge falling obstacles like shovels while collecting power-up items. In two-player mode, players can either team up in cooperative gameplay with a shared hay quota, or face off competitively in a race to complete their goal first.

By combining charming visuals, progressively tricky mechanics, and multiple play modes, our game offers an accessible yet addictive take on the stacking genre. Whether playing solo or with a friend, players are treated to a fun and strategic farming experience that's easy to pick up but hard to master.

The following table shows the main elements of the game:

Table 2: Game Elements

Category	Image	Description
Player with basket		Player collects hay bales to their basket.
Barrel		A barrel where the caught hay bales in the basket are emptied to.
Hay bale		Catch to stack in player's basket.
Shovel		Cause player to lose all current stack if hits the player.
Protein shake		Increase player's strength temporarily so that they could carry more hay.
Speed boot		Increase player's speed temporarily.

4. Requirements

Requirements engineering (RE) is a crucial component of software development, as the success of a project heavily relies on how accurately its requirements are identified during this phase [1]. Unlike traditional development models, where RE is typically confined to the early stages, agile development views RE as an ongoing process throughout the entire development cycle, with continuous refinement and adaptation as the project progresses [2].

Ideation Process

Our team initially brainstormed five distinct game concepts, which we narrowed down to two after group discussions evaluating feasibility, appeal, and gameplay potential. To explore these ideas further, we developed paper prototypes for both shortlisted concepts, allowing us to simulate and assess the core mechanics before moving forward.

Figure 2: Paper Prototype for Haystacking

Figure 3: Paper Prototype for Fireboy & Watergirl

During this process, we observed a shared preference within the team for mini-games that feature simple rules yet offer surprisingly engaging and addictive gameplay. We appreciated how these types of games require minimal time, effort, and cognitive load—making them ideal as casual, everyday stress relievers that can be played anywhere, at any time.

With these factors in mind, we ultimately selected Haystacking as our final concept. Its straightforward yet strategic mechanics and lighthearted tone aligned well with our vision for an accessible and enjoyable game experience.

Identifying Stakeholders

As shown in Figure 4, we conducted a stakeholder analysis using the Onion Model [3]. This helped us to categorise key parties based on their proximity to the systme, understandand their needs and prioritise them accordingly during the development process.

Figure 4: Onion Model of Haystacking Game

Table 3: Stakeholders Analysis

Stakeholder	Description
Group 30-2025	Primary developers responsible for design, development, and implementation of the game
Players	Includes first-time player, returning players, casual players, competitive, players with disability (motor)
Lecturers and TAs	Evaluators assessing project quality
Other Teams	Other student teams working on similar projects
Bystanders	Potential future players who may be attracted to the game

User Stories and Acceptance Criteria

Throughout the development processes, we continuously evaluated and refined our user stories after every sprint review to make sure our game align with evolving users requirements. This iterative approach allowed us to stay responsive to feedback and maintain a user-centered design focus.

In the later stage, we also incorporated sustainability-conducive requirements from the Sustainability Awareness Framework (SusAF), which enabled us to evaluate the potential impacts of the game from a more holistic standpoint. Table 4 presents the finalised user stories along with their corresponding acceptance criteria.

Table 4: User Story and Acceptance Criteria

User Type	Epic	User Story	Acceptance Criteria
Developer	Modular Architecture	As a developer, I want the game logic to be modular so that it is easy to maintain and expand later.	Given I am updating the game, when I modify a gameplay function, then it should not affect unrelated systems or cause bugs.
Casual Player	Beginner-Friendly Experience	As a casual player, I want the game controls to be simple and intuitive so that I can quickly learn and enjoy the game.	Given I am playing the game, when I use the controls, then they should be minimal and easy to understand.
		As a casual player, I want a clear tutorial when I first enter the game so that I can quickly learn how to play.	Given it is my first time entering the game, when I start playing, then a tutorial should appear explaining the basic controls and rules.
		As a casual player, I want a pause and resume function so that I can play at my own pace.	Given I am in a game session, when I click the pause button, then I should be presented with options to pause, resume, or restart.
	Replayability	As a casual player, I want to replay levels to improve my skills and gain a sense of achievement.	Given I complete a level, when I choose to replay, then I should be able to restart the same level without restrictions.
Competitive Player	Game Challenge	As a competitive player, I want the game to become more challenging over time so that it remains engaging.	Given the game progresses, when I reach higher levels, then the game should introduce faster speeds or new obstacles.
Social Player	Multiplayer Mode	As a social player, I want to compete or cooperate with my friends so that we can play together.	Given I enter multiplayer mode, when I choose competitive or co-op, then the game should support both modes and show rankings after matches.
Player with motor disability	Keyboard Accessibility	As a player with motor disability, I want to navigate and interact with all parts of the game using the keyboard only, so that I don't have to use a mouse.	Given I am in the game, when I use the keyboard (Tab, Shift+Tab, Enter, Esc), then I can access and operate all interactive elements without a mouse.
Player	Support Individual Health, Safety, and Learning	As a player, I want the game to have a clear end (5 levels only) so that I don't feel the need to keep playing endlessly.	Given I am in the game, when I finish the 5th level, then I should see a completion screen.
Player	Support Individual Health, Safety, and Learning	As a player, I want to play the game without logging in or giving personal data so that my privacy is protected.	Given I am in the game web page, when I want to start playing the game, then I should be able to do so without needing to login or signup.

Use Cases Breakdown

To better understand the interactions between the game and its users, we used a Use Case Model [4] to describe the game's functional requirements.

Figure 5: Use-Case Diagram

Table 5: Use Case Specifications for: Stack Hay, Pause Game, and Start Game

Element	Stack Hay	Pause Game	Start Game
Actors	Player	Player	Player
Description	Player catches the falling hay.	Player pauses the game.	Player starts the game and engages with core gameplay.
Main Flow	1. Hay bales fall. 2. Player catches hay. 3. Hay is added to stack.	1. Player pauses the game. 2. System shows pause menu. 3. Player chooses Resume, Restart, or Exit.	1. Player clicks "Start". 2. Game initializes. 3. Player interacts with game elements.
Extensions	Perfect Stack (if balanced precisely)	Resume, Restart, Exit	N/A
Include	N/A	N/A	Move Left/Right, Stack Hay, Empty to Barrel, Avoid Obstacles, Catch Special Items
Alternative Flow	1. Hay bales fall. 2. Player fails to catch. 3. Hay disappears offscreen.	N/A	N/A

5. Design

Having analysed the system requirements, we then proceeded to the design phase. We adopted object-oriented (OO) design principles to create a modular and maintainable system architecture.

Our design follows closely to core OO principles. Abstraction is used to define base classes such as Screen and FallingObject, which provide common functionality to their subclasses while hiding specific implementations. Encapsulation ensures that classes like Player manage their internal state—such as their haystack stack and scoring logic—independently. Inheritance is used to structure the system logically; for example, Single, Coop, and Pvp all extend from GameScreen to reuse shared logic. Polymorphism allows different object types (e.g., game modes, falling objects) to implement shared methods in different ways, facilitating flexibility and code clarity. Collectively, these principles allowed us to design a clean and extendable system.

Class diagram

We created a class diagram to present the static relatonships between objects. To improve readability and focus on high-level structure, only key attributes and methods are shown.

Figure 6: Class Diagram

Some of the key classes and relationships highlighted in the design:

1. Screen hierarchy: Screen is the abstract base class for all screens in the game. GameScreen extends Screen and is the base class for all gameplay screens (Single, Coop, Pvp). A ScreenManager manages all screens and handles transitions between them.

2. Game modes: Single player mode has one player and one barrel. Coop mode has two players sharing one barrel, while Pvp mode has two players and two barrels.

3. Player: Each Player manages a stack of Hay objects and is connected to a Barrel for scoring. It also interacts with a SoundManager for feedback and includes visual effects such as Flash.

4. Game objects: FallingObject is an abstract class extended by Hay and SpecialItem. Specific SpecialItem types (e.g. Shovel, ProteinShake, SpeedBoot) implement unique gameplay effects..

5. Game logic: Level manages game progression and modes. Barrel handles scoring and target scores

6. Sound management: SoundManager is a central class for handling all game audio. It maintains a map of sound effects and provides methods for playing sounds and controlling volume. It is connected to ScreenManager via composition and Player via aggragation.

7. Help system: StepByStepHelpScreen is an interactive tutorial. SingleHelpScreen is for single player mode, whereas DoubleHelpScreen is an abstract base for two-player help screens: CoopHelpScreen and PvpHelpScreen.

Sequence diagram

To demonstrate the dynamic behaviour of the system, we first developed a sequence diagram [5] that focuses on the basic single-player mode, as shown in Figure 7. This diagram illustrates the flow of messages exchanged between objects during gameplay, how components collaborate to manage user input, object movement, collision detection, and game state updates.

Figure 7: Sequence diagram for Single mode

Building on the single-player sequence diagram, we subsequently developed sequence diagrams for both co-op (Figure 8) and PvP modes (Figure 9). In the co-op mode, the core game mechanics remain consistent with single-player gameplay; however, both players contribute to a shared barrel, reflecting a combined scoring system. In contrast, the PvP mode introduces independent barrels and scoring for each player, along with additional win, lose, or draw conditions determined by comparing individual scores at the end of the game.

Figure 8: Sequence diagram for Coop mode

Figure 9: Sequence diagram for PvP mode

6. Implementation

Challenges

We encountered three main challenges when developing the game:

1. Managing the timing of dropping objects
2. Implementing rule-based stacking mechanics
3. Managing screen switching logic

Challenge 1: Managing the timing of dropping objects

A key gameplay mechanic in Haystacking involves dropping hay bales and other items (e.g., shovels, speed boot) at regular intervals. To implement this, we initially used setInterval() function to call object drop every few seconds.

However, we ran into a timing issue when implementing pause and resume functionality. If the player paused and resumed the game multiple times, objects would begin dropping too frequently — sometimes multiple items would fall at once. After debugging, we found that every time the game was resumed, a new interval was being created without clearing the previous one, leading to multiple concurrent timers calling object drop.

To solve this, we updated the code to ensure that only one interval exists at any time. We used clearInterval() and set the reference to null before starting a new interval, which added a guard to prevent multiple intervals from stacking:

if (dropInterval) {
  clearInterval(dropInterval);
  dropInterval = null;
}
dropInterval = setInterval(dropItem, dropRate);

This change allowed us to reliably manage the start and stop behavior of the object drops. It also made the codebase more maintainable and predictable when adding new features related to item timing or difficulty scaling.

Challenge 2: Implementing rule-based stacking mechanics

Initially, we planned to use a physics engine such as Matter.js to simulate the realistic falling and stackking of hay bales. However, we quickly realised it introduced significant complexity, including collision handling, rotation, and gravity simulations. We then opted for a simpler design of using only rectangular hay blocks in a cartoon-like aesthetic. The challenge then became making the stacking feel realistic and rewarding.

We first introduced a minimum horizontal overlap threshold for a hay bale to be considered caught. We also implemented some feedback mechanisms such as a gradual speed decrease as the player take on more hay bales. We thought we should impose a penalty for missing any hay bale, so we added a Flash object to the Player, which would cause the player to freeze and flash for a 0.5s. However, many users complained about this feature during the initial evaluation process. In fast-paced later levels, players could enter a frustrating loop where a missed bale triggered a flash, which caused them to miss the next bale immediately upon resuming — resulting in a chain of unavoidable penalties. Therefore, we scrapped this setting. However, we were able to repurpose the Flash mechanics to be activated when a player exceeds the maximum number of hay bales they could carry.

Finally, to encourage precision, we implemented a PerfectStack reward system. If a player achieved a stacking alignment of 90% or greater with the hay bale or basket below, they received a time bonus.

Challenge 3: Managing screen switching logic

As none of us had any prior experience with game development, one of the early challenges we faced was to implement the logic of switching between different screens.

At first, we started with a single-page prototype focused solely on the stacking mechanic. As we introduced additional screens (e.g. home screen, pause screen, gameplay, game over), we used simple conditional statements to handle the screen changes, e.g.:

if (isPaused && screen === "game") {
  // ... game paused logic
} else if (screen === "home") {
  // ... home screen logic
}

However, as the number of screens grew, this became increasingly difficult to maintain. To solve this, we impleemented a state management class - ScreenManager which encompasses different screens such as the game screens and home screens, and each of the game screen has their respective target score screen, level up screen etc. The ScreenManager also maintains a currentScreen property and has methods to change and display the current screen.

7. Evaluation

To ensure a balance between functionality and usability during the game development process, we chose to combine both qualitative and quantitative evaluation methods. Qualitative analysis helped us identify issues within the game, while quantitative evaluation provided insights into user perceptions, guiding us to iteratively improve the design.

Qualitative Evaluation - Heuristic Evaluation

Heuristic evaluation is a quick and cost-effective method that provides clear, concrete, and specific guidelines for directly refining games [6]. For our evaluation of the Haystacking user interface, we selected Nielsen's ten usability heuristics [7] as the guiding framework.

By systematically reviewing every screen of our game, we identified several usability issues. Each issue was evaluated across three key dimensions (Frequency, Impact, and Persistence) to determine its overall severity. The findings are presented in the following table, ranked in descending order of severity:

Table 6: Heuristic Evaluation Table

Interface	Issue	Heuristic(s)	Frequency (0-4)	Impact (0-4)	Persistance (0-4)	Severity = (F+I+P) / 3
Hay	A hay bale is considered "caught" even when only its corner touches the hay or basket below.	Error prevention	4	4	4	4.0
Barrel	Inconsistent minimal distance required to put down hay into the barrel.	Consistency and standard	4	3	4	3.7
Score	The score is displayed in the top-left corner and isn't clearly visible during gameplay.	Visibility of system status	3	3	4	3.3
Tutorial	Wordy instructions without visual representations.	Recognition rather than recall	2	4	4	3.3
Home Screen	The extra "Start" button is unnecessary; players should select the mode first and then start.	Aesthetics and minimalist design	3	2	3	2.7
Mode Selection	Player cannot return to the home screen from the mode selection screen.	User control and freedom	2	3	3	2.7
Keyboard shortcut	No keyboard shortcut to navigate between game pages.	Flexibility and efficiency of use	3	2	3	2.7

Based on the severity score, we were able to identify a couple of top priority issues.

1. Collision detection of a hay bale

The current collision detection logic is too lenient, and unrealistic or unintended "catches" are allowed. To address this, we addressed the collision logic to check for at least 20% surface overlap rather than just any contact. We also added visual cues to indicate when a hay bale is considered to be perfectly stacked (more than 90% overlap) and awarded player with extra time.

2. Inconsistent hay dropping logigc to the barrel

We found that sometimes a player must be very close to the barrel, and other times they can drop hay from farther away. To address this, we defined a consistent interaction radius around the barrel. We would also like to add some visual indications in the hay drop logic.

3.Score visibility

Intially when a player added hay to the barrel, the score update is shown on the top-left corner of the gameplay, which was not prominent enough during gameplay.

To improve this, we first recognised that the score should be part of the system's real time feedback. Therefore, we moved the score display to be visually attached to the barrel, and added visual feedback to the barrel by increasing its brightness as more hay is added. In this way, players can perceive progress without needing to look away from the main interaction area.

4. Wordy instruction

Even though our instructions were relatively short, we recognized that purely text-based explanations might be skipped or misunderstood by players. To lower the user's cognitive load, we used visual representations such as arrow icons to help player to recognise the game action more easily. We also introduced a step by step animated and interactive tutorial for first time users who prefer a more guided experience.

Quantitative Evaluation - NASA TLX evaluation

The NASA TLX [8] is a quantitative evaluation method used to assess users' subjective workload during task performance, helping designers understand sources of stress in an interface or interaction process. In evaluating the differences between levels in HayStacking, we invited 11 users to play the game at two difficulty levels (Level 1 and Level 2). After completing each level, participants answered the NASA TLX questionnaire, rating six dimensions of workload—mental demand, physical demand, temporal demand, performance, effort, and frustration. This allowed us to obtain each user's perceived workload scores under different levels. The chart below shows the players' ratings visually, and the original scoring data can be accessed here.

Figure 10

Figure 11

To analyse these results, we used the Wilcoxon Signed-Rank Test, a non-parametric statistical method suitable for comparing paired samples—particularly effective for assessing changes in subjective ratings from the same group of users under two different conditions.

At a significance level of p = 0.05, the critical value for n = 11 is 10. Our calculated test statistic was W = 1, which is less than the critical value of 10, indicating a statistically significant difference in perceived workload between the two levels. Players experienced a notably higher workload in Level 2 than in Level 1. This outcome aligns with our design goal of progressively increasing the game's difficulty and challenge.

Test

For Haystacking, we primarily conducted black-box testing [9]. The test cases were designed using equivalence partitioning and focused on validating the core functionalities of the game. Testing covered five key areas: UI interaction, player movement control, game mechanics, score calculation system, and the special item system.

As shown in the table below, all test cases passed, confirming that the core functions have been successfully implemented and are operating as expected.

Table 7: Black-Box Test Table

Test ID	Funtional Unit	Input Condition	Category	Expected Output	Test Result
UI-01	UI Interaction	Click "Tutorial" button on Menu screen	Valid Input	Turorial screen appears	Passed
UI-02	UI Interaction	Click "Confirm" button on the Level screen	Valid Input	Corresponding game mode starts	Passed
UI-03	UI Interaction	Press "tab" on the Menu screen	Valid Input	Select the first button on the Men Screen	Passed
UI-04	UI Interaction	Pressed "enter" when the "Back" button on Menu screen is tab selected	Valid Input	Home screen appears	Passed
UI-05	UI Interaction	Click on empty space on a screen	Valid Input	Nothing changes, user remains on the same screen	Passed
PC-01	Player Control	Press left arrow key	Valid Input	Player moves left smoothly	Passed
PC-02	Player Control	Press right arrow key	Valid Input	Player moves right smoothly	Passed
PC-03	Player Control	Player tries to move beyond the game screen	Invalid Input	Player stops at the boundary	Passed
GM-01	Game Mechanics	Player moves left/right and intersect with falling hay bale with over 20% overlap	Valid Input	Hay bale lands and stacks on the player's basket or the top most caught hay bale	Passed
GM-02	Game Mechanics	Player catches hay bale near edge of existing stack	Valid Input	Hay block continues to fall, item not added	Passed
GM-03	Game Mechanics	Player moves while carrying increasingly more hay bales	Valid Input	Player movement speed reduces	Passed
GM-04	Game Mechanics	Hay bale falls outside the screen	Valid Input	Hay block disappears	Passed
SS-01	Score System	Successfully empty a hay bale to the barrel	Valid Input	Score increases by 1 point	Passed
SS-02	Score System	Player tries to empty their basket when far away from the barrel	Invalid Input	Player unable to empty their basket	Passed
SS-03	Score System	Reach target score	Valid Input	Advance to next level	Passed
SS-04	Score System	Time runs out before reaching target	Valid Input	Game over screen appears	Passed
SS-05	Score System	Score updates for individual player in Pvp mode	Valid Input	Each player's score updates independently	Passed
SI-01	Special Item	Player is hit by falling shovel	Valid Input	Player freezes and flashes temporarily	Passed
SI-02	Special Item	Player is hit by falling speedboot	Valid Input	Player does not slow down as they carry more hay bales in their basket	Passed
SI-02	Special Item	Player is hit by falling protein shake	Valid Input	Player does not slow down as they carry more hay bales in their basket and is able to carry unlimited number of hay bales	Passed
SI-03	Special Item	Protein shake timer runs out	Valid Input	Extra speed boost disappears. Player will freeze and flash if they exceed the limit of 5 by catching another hay bale	Passed

8. Sustainability, Ethics and Accessibility

In the development of Haystacking, we applied the Sustainability Awareness Framework (SuSAF) to align with the principles outlined in the Karlskrona Manifesto [10]. SuSAF is a question-based framework designed to assess the potential sustainability impacts of software, promoting the creation of sustainability-conscious requirements. We evaluated the impacts of our game across three of the five sustainability dimensions:

1. Individual Sustainability

Table 8: Individual Sustainability Impact

Topic	Impact
Health	Offers stress relief and entertainment, promoting mental well-being. Game capped at 5 levls to prevent overuse and reduce risk of screen fatigue and eye strain.
Privacy	Does not collect any personal data.
Lifelong learning	Encourages cognitive skills like spatial awareness, reflexes and decision making. Multiplayer modes may enhance communication and collaboration skills.
Safety	Non-violent, cartoon-style game makes it suitable for a wide age range.

2. Environmental Sustainability

Table 9: Environmental Sustainability Impact

Topic	Impact
Energy	Development done on personal machines with relatively low energy usage. Minimal energy use as the game is browser-based and runs client-side only. Optimises codes and assets to minimise CPU/GPU use.
Biodiversity and Landuse	Promotes environmental themes (e.g. sustainable farming, recycling mechanics) subtly through game storyline.
Material and Resources	As a digital game developed with p5.js, it consumed no physical materials (e.g. packaging, discs).

3. Technical Sustainability

Table 10: Technical Sustainability Impact

Topic	Impact
Maintainability	Use modular code with clear comments and Git for version control.
Usability	Intuitive and simple game mechanics (catch and stack), clear help screen and feedback UI.
Extensibility & Adaptability	A mode-based structure offers a clean entry point for adding future game modes or challenges.
Security	No storage of any user data.
Scalability	No back-end dependencies yet, could potentially expand to mobile platforms.

We then classified the identified sustainability impacts into three categories: immediate, enabling, and structural effects. To demonstrate how these impacts evolve and interact across different dimensions, we created the Sustainability Awareness Diagram, presented below.

Figure 12: Sustainability Awareness Diagram

Additionally, we applied several patterns published by the Green Software Foundation to keep Haystacking emissions minimum. These included:

Table 11: Green Software Foundation Patterns

Patterns	Implementation in Haystacking
Serve images in modern formats	A range of cartoon-style visual assets are used in Haystacking. We ensured all image assets are optimised and served in WebP format, which offers significantly smaller file sizes than PNG or JPEG without sacrificing visual quality. In this way, we are able to lower bandwidth usage, speed up image load times, reduce device power consumption and the game's overall SCI (Software Carbon Intensity) score.
Defer offscreen images	As Haystacking is implemented entirely in JavaScript using p5.js and contains no HTML image tags, the specific solution described in the pattern (i.e. using loading = lazy on the <img>) is not directly applicable. However, the core principle of the pattern - on-demand loading of assets - is still very relevant. To implement this, we load assets for a specific screen only when that screen is about to be shown and we ensured that nothing is loaded in sketch.js at game boot. As a result, we can reduce device processing and memory usage by loading fewer images at startup.
Avoiding tracking unnecessary data	Haystacking does not include any advertising scripts and uses no third-party analytics. All gameplay is handled locally on the client device and does not collect or store any personal data. As such, we are able to reduce the processing and storage demands on both client and server systems as well as enhance user privacy and safety.

We updated our product backlog to incorporate new requirements and user stories specifically focused on sustainability and accessibility. These additions aimed to ensure that our development process considered environmental impact, long-term maintainability, and inclusive design. Examples include optimising visual assets to reduce energy consumption, and designing user interfaces with high contrast and keyboard accessibility.

9. Process

1. Collaboration

Team Formation and Roles

During term time, we held regular in-person meetings to brainstorm ideas and build team rapport. In our first session, each member shared games they personally enjoyed, which led to a shortlist of five titles. We then used Strawpoll, a platform the team relied on throughout the project, to vote and finalise the reference game concept.

Once the concept was confirmed, team roles began to take shape. Initially, all members contributed to the game development to build a shared understanding of the system. However, this approach quickly led to challenges such as unclear module boundaries, inconsistent coding styles, and frequent merge conflicts. To address this, we adopted a more clearly defined team structure:

• Liyang focused on implementing foundational features and later worked with Lingchen on advanced gameplay development.

• Lei served as the lead UI designer and also collaborated with Lingchen on refactoring the core framework.

• Shiyu, Zhuoyan, and Hanying led user research, organizing playtesting sessions and collecting data to guide design iterations.

Communication and Agile Practices

Throughout development, we followed the Scrum framework. We conducted Planning Poker sessions to estimate task efforts and plan the sprint accordingly. At the end of each sprint, we held reviews to reflect on progress and adjust features based on user feedback.

One particular sprint, which focused on fine-tuning the gameplay settings for each level, turned out to be more time-consuming than anticipated. We had to iteratively test and adjust parameters such as item behavior, hay bale drop speed, and level objectives to accommodate players of varying skill levels, ensuring the game became progressively more challenging while still remaining fair and completable.

Figure 13: Burndown Chart for Spring 7

One notable challenge we faced was the misalignment in team members’ perceptions of work quality. While everyone was committed, expectations varied regarding what constituted a “complete” or “polished” deliverable. This occasionally led to rework, delays in reviews, and friction during integration. To address this, we established clearer definitions of done, introduced peer reviews earlier in the sprint cycle, and fostered open communication to align quality standards across the team.

2. Tools and Techniques

Project Management Tools

We used Jira as our main project management platform for organising work. Sprints were structured around clearly defined tasks, each tagged with story points, deadlines, and assignees. Tasks were broken down into subtasks for better granularity and accountability.

Figure 14: Sprint Management on Jira

We also leveraged Jira’s Kanban board to track progress in real time. Visual columns like “To Do,” “In Progress,” and “Done” helped the team identify bottlenecks and reallocate resources efficiently.

Figure 15: Kanban Board

Feature Prioritisation and Planning

To prioritize development, we applied the Value-Effort matrix, which allowed us to distinguish high-value, low-effort features ideal for early sprints. These quick wins enabled us to build a playable prototype early on. More complex, high-effort features, such as core framework development, expanded game modes, and level design, were scheduled for dedicated sprints to ensure thorough implementation without sacrificing quality. This phased approach helped us maintain momentum while gradually adding depth and polish.

Figure 16: User Story Value vs. Effort Matrix

Development Practices

We adopted pair programming for core game logic, which enhanced both code quality and team understanding. Regular rotation of helm and tactician roles ensured that all developers were engaged with key architectural decisions.

As development progressed, we followed GitHub-based merge request workflow. All code changes required approval from at least two team members before merging into the main branch. This practice promoted accountability, minimized integration issues, and maintained a clean, stable codebase.

10. Conclusion

Through the development of our farm-themed stacking game, our team has gained valuable hands-on experience in the software development lifecycle: from ideation and prototyping to implementation and evaluation. The process not only improved our programming skills but also taught us how to manage a project collaboratively using Agile methods. Weekly sprints, regular meetings, and clear role distribution allowed us to keep track of progress and adapt swiftly to changes.

Throughout the project, we encountered several technical and design challenges, such as managing object drop timing, balancing gameplay difficulty, and ensuring stable cross-platform performance. To address these issues, we constantly made trade-offs, refined debugging skills, and adjusted mechanics based on continuous testing and user feedback. These experiences significantly deepened our understanding of modular code architecture and user-centered development.

Additionally, we prioritized sustainability and accessibility in our development. By reusing assets, designing for short gameplay sessions, supporting local multiplayer, and implementing basic accessibility features, we created a game that is both environmentally friendly and inclusive. In particular, our design is more accessible for players with motor disabilities, reflecting our commitment to user diversity.

In the near future, we plan to introduce new game items such as freeze sprays, glue bottles, and magnetic gloves to enrich gameplay variety. These additions will offer new tactical options—such as hindering opponents or boosting player speed—making matches more dynamic and engaging. We also aim to expand level design and enhance visual effects to improve immersion and aesthetic appeal.

Looking further ahead, we plan to implement online multiplayer functionality, enabling players to compete or cooperate remotely. We also intend to develop a mobile version of the game to reach a wider audience and provide a more accessible, on-the-go experience. As our technical capabilities grow, we aim to introduce a progression system, global leaderboard, and a story mode—features that will add longevity, structure, and narrative depth to the overall game experience.

11. Contribution Statement

Name	Contribution
Lingchen Li	1
Lei Gao	1
Hanying Bian	1
Shiyu Dou	1
Zhuoyan Qiu	1
Liyang Li	1

12. References

1. Wang, X., Zhao, L., Wang, Y. and Sun, J., 2014. The role of requirements engineering practices in agile development: an empirical study. In: D. Zowghi and Z. Jin, eds. Requirements engineering. Communications in Computer and Information Science, vol. 432. Berlin, Heidelberg: Springer. Available at: https://doi.org/10.1007/978-3-662-43610-3_15 [Accessed 5 May 2025]
2. Fægri, T.E. and Moe, N.B., 2015. Re-conceptualizing requirements engineering: findings from a large-scale, agile project. In: Scientific Workshop Proceedings of the XP2015. Helsinki, Finland: Association for Computing Machinery, pp.1–5. Available at: https://doi.org/10.1145/2764979.2764983.
3. Alexander, I.F. 2005. A Taxonomy of Stakeholders. International Journal of Technology and Human Interaction, [online] , pp.23–59. Available at: https://www.academia.edu/91630227/A_Taxonomy_of_Stakeholders.
4. Muhairat, M. (2010) ‘UML diagrams generator: A new case tool to construct the use-case and class diagrams from an event table’, Journal of Computer Science, 6(3), pp. 253–260. doi: 10.3844/jcssp.2010.253.260.
5. Bjørner, D. 2006. Software Engineering 2: Specification of Systems and Languages. Berlin: Springer-Verlag. [online] Internet Archive. Available at: https://archive.org/details/softwareengineer0000bjrn_p3g9.
6. Choi, J. and Bakken, S., 2010. Web-based education for low-literate parents in Neonatal Intensive Care Unit: Development of a website and heuristic evaluation and usability testing. International Journal of Medical Informatics, 79(8), pp.565–575. Available at: https://doi.org/10.1016/j.ijmedinf.2010.05.001.
7. Nielsen, J., 1995. 10 Usability Heuristics for User Interface Design. Nielsen Norman Group. Available at: https://www.nngroup.com/articles/ten-usability-heuristics/ [Accessed 6 May 2025].
8. Hart, S.G. and Staveland, L.E., 1988. Development of NASA-TLX (Task Load Index): Results of empirical and theoretical research. Advances in Psychology, 52, pp.139–183. Available at: https://www.sciencedirect.com/science/article/abs/pii/S0166411508623869.
9. Roman, A. and Roman, A., 2018. Black-Box Testing Techniques. In: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus: Test Techniques and Sample Mock Exams, pp.25–60. Available at: https://link.springer.com/chapter/10.1007/978-3-319-98740-8_4.
10. C. Becker, R. Chitchyan, L. Duboc, S. Easterbrook, M. Mahaux, B. Penzenstadler, et al., "The Karlskrona manifesto for sustainability design", 2014, [online] Available at: http://arxiv.org/abs/1410.6968.