2025-group-7

2025 COMSM0166 group 7

Your Game

Link to your game PLAY HERE

Link to game ideas: HERE

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

Include a demo video of your game here (you don't have to wait until the end, you can insert a work in progress video)

Your Group

Group Member	Name	Email	Role
1	Yaseer Alluwaim	[email protected]	role
2	Ajinkya Bhalerao	[email protected]	role
3	Guo Xuanpu	[email protected]	role
4	Nagat Guled	[email protected]	role
5	Harry Jackson	[email protected]	role
6	Haorui Cai	[email protected]	role

Project Report

Introduction

• 5% ~250 words
• Describe your game, what is based on, what makes it novel?

Requirements

• 15% ~750 words

• Use case diagrams, user stories. Early stages design. Ideation process. How did you decide as a team what to develop?

• Ideation

Initial ideation was conducted through individual submission of game inspirations through Github. We narrowed the choices down to two core ideas – a tank combat game inspired by Tank Trouble, and a generic Tower Defence game – by simple group voting, which we then confirmed by an in-person meeting. One common point in support of both options was the scope they offered for innovation on the existing formula, and a feeling that the engineering challenges they offered were correctly pitched for the length of the project.

• Prototyping

Both ideas were prototyped during the January 28 workshop, with Tank Trouble prototyped on paper and Tower Defence prototyped via Powerpoint. The team agreed to focus on the Tank Trouble prototype at the outset, indicating an existing common preference for that idea. After prototyping, the decision was taken to focus on the Tank Trouble idea because of the team’s greater familiarity with the core game mechanics – and because we had already identified some interesting twists on the existing game design that would help differentiate our game from its inspiration.

• Testing Feedback

Testing of the paper prototype at the February 6 workshop elicited useful feedback on the design of the game, and some of the engineering challenges we might face. On game design, some people were confused about the “one hit to kill” philosophy present in the original game – thinking it would make the game too chaotic and might undermine the value of power-ups that enhance the tank’s weapons. Others were unsure of certain ideas about environmental destructibility, highlighting the importance of communicating this information to the player visually. On engineering, we were warned that a two player game operated from a single keyboard might risk input conflicts, allowing one player to prevent another player from moving by spamming keys and confusing the game.

• User Stories

Design

• 15% ~750 words
• System architecture. Class diagrams, behavioural diagrams.

Implementation

• 15% ~750 words

• Describe implementation of your game, in particular highlighting the three areas of challenge in developing your game.

Evaluation

• 15% ~750 words

• One qualitative evaluation (your choice)

We conducted a Heuristic evaluation for the (25th February version) prototype of our game. Due to the game lacking in much of the UI elements we plan to implement, much of the feedback was concerning the tasks we have not yet completed. However, the evaluation was useful in gaining insight on what users value most, and therefore, helped us understand which of our remaining tasks we should prioritise. System status was the Heuristic that was most frequently mentioned during our evaluation. The issues include, remaining lives, remaining bullets and the effect of damage taken, all not being visible to users. These were also the issues rated with the highest severity by users. A user experienced initial difficulty in moving the tanks because they rotate left and right rather than move laterally. This is not an uncommon feature in games in which players play as vehicles, and it is a feature we have not changed from the original Tank Trouble game. We have discovered that we may receive feedback that highlights issues that are anticipated in a game similar to ours, and we must carefully consider how much weight we give such feedback. This evaluation also affirmed that we need to include some form of tutorial that explains the controls of the game, especially as it is developed and more elements are introduced. Users appreciated the minimalist aesthetic of our game and expressed that it was enjoyable to play.

• One quantitative evaluation (of your choice)

• Description of how code was tested.

Process

• 15% ~750 words

• Teamwork. How did you work together, what tools did you use. Did you have team roles? Reflection on how you worked together.

Conclusion

• 10% ~500 words

• Reflect on project as a whole. Lessons learned. Reflect on challenges. Future work.

Contribution Statement

• Provide a table of everyone's contribution, which may be used to weight individual grades. We expect that the contribution will be split evenly across team-members in most cases. Let us know as soon as possible if there are any issues with teamwork as soon as they are apparent.

Additional Marks

You can delete this section in your own repo, it's just here for information. in addition to the marks above, we will be marking you on the following two points:

• Quality of report writing, presentation, use of figures and visual material (5%)

  • Please write in a clear concise manner suitable for an interested layperson. Write as if this repo was publicly available.

• Documentation of code (5%)

  • Is your repo clearly organised?
  • Is code well commented throughout?