2025 COMSM0166 group 23
PLAY TAKE AIM HERE
During this week, our game selection process began. Our goal is to create a game that calls back to classic games in the past but brings another level of fun, freshness and challenges. Therefore, 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, it was our responsibility to discuss potential development challenges we, as developers, could face during production. A summary of some of our game ideas are listed below with their brief description.
| Game | Description |
|---|---|
| Tetris | Tetris begins with an empty screen, and requires the player to fit falling blocks together. - Twist: there will be two players competing against each other, player 1 will have the ability to change the shape of the blocks falling in player 2's screen, vice versa. - Development Challenges: server creation; check matching and deletion of blocks. |
| Bounce | The original bounce game is a platform game revolving around the player controlling a red ball and navigating through levels and obstacles.. - Twist: Imagine a new bounce game where the maps includes different terrain such as water, wind, and ice. - Development Challenge: hard coding multiple maps of the game with different game objects and their properties. |
| Flappy Bird | The premise of Flappy Bird's endless runner game is simple: tap the screen to navigate a bird character object through the gaps between pipes without hitting them. - Twist: the addition of different weather and terrain can add combinations of wind, rain, obstacles and power ups, affecting the birds movement. - Development Challenges: developing different movement mechanics according to different weather types. |
| Snake Game | In the game of Snake, the player usually use the arrow keys to move a "snake" around the board. As the snake finds food, it eats the food, and thereby grows larger. The game ends when the snake either moves off the screen or moves into itself. - Twist: Imagine a board where every 30 seconds, sections of the floor fall and the snake has to traverse the map without falling. - Development Challenges: random map generator for map generation; adding new parts of the snake at the tail. |
| Doodle Jump | In the classic Doodle Jump game, player must guide a creature up an endless series of platforms without falling out of the screen. - Twist: Imagine a doodle jump game where there is a color instruction that you must follow for the platform you must land next. - Development Challenge: generating new platforms at random location at specific distance from each other at the top of the screen, at the same time being in-synced with the color instruction. |
| Cat vs Dog | This game is an entertaining game in which these two characters, a cat and a dog, they will face each other in a battle throwing things at each other. - Twist: characters randomly shrink every set amount of time, making it harder to target accurately. - Development Challenge: programming the character being paused when it is hit; character shrinking mechanics. |
| Temple Run | In Temple Run, the player steers the explorer across a maze, avoiding obstacles while also collecting coins, the longer the explorer survives the higher the score. - Twist: during gameplay the direction of the run go reverse mode. - Development Challenges: 3D modelling of the map; storing data for game objects to allow reverse mode. |
| Breakeout | The classic Breakout Video Game uses a single ball where the player must knock own as many bricks as possible by using the walls and/or the paddle below to hit the ball against the bricks and eliminate them. - Twist: add treasures within the blocks that once knock down, they can be used for power ups. - Development Challenge: ball mechanics and collision handling for multiple balls. |
| Crossy Road | Crossy Road has been one of the more recent fan favourite arcade hopper. The chicken collect custom characters to be used and navigate freeways, railroads, rivers while avoiding cars. - Twist: Imagine, a crossy road game where you not only cross the road from one to the next but also move along into the direction of where the car is moving towards, pushing you to new environments. - Development Challenges: frontend constraints for designing objects; programming a large amount of game object mechanics, generating adaptive environments for different obstacles. |
| Tower Defence | The goal of tower defence is to defend a player's territories or possessions by obstructing the enemy attackers or by stopping enemies from reaching the exit by placing defensive structures along their path of attack. - Twist: Imagine each tower has no weapons of its own, but it granted unique abilities by adding gems to the tower, allowing to give it a different power depending upon which combination you use. - Development Challenge: generating wave function for enemies and how they interact with different tower abilities. |
This week, we conducted a team excercise where we practiced the foundations of P5.js, a JavaScript library. This was both fun and vital as we will be using P5.js as our main language to create our game. Our goals was to create drawing app similar to Window's Paint.
Screenshot of Paint Prototype
As we are closing onto our game finalisation, we have set up a new project in Jira to be the center backlog of our sprint meeting. Here, all members of our team can easily share critical insights of our agile processes and highlight areas to improve on for our upcoming sprints.
Screenshots of Jira backlog and sprint 2
- Take Aim is a dynamic 1-2 player action game that emphasizes precise movement and strategic combat. Players compete to be the first to reduce their opponent’s Health to 0%, requiring quick reflexes and tactical decision-making. The game features character and map selection, allowing for varied playstyles and environments. At the start of each match, weapons drop from above within the first three seconds, setting the stage for intense battles. Players navigate the map using fluid movement—running, jumping (Up), and shooting (Space)—while avoiding hazards like moving walls. More mechanics and features were under discussion.
- Tank Duel is a combat game where two players (or a player vs AI) take turns firing projectiles at each other. Each turn, the player controls a rotating aim that moves between a defined angle range (-X° to Y°) and a power bar that determines the shot’s strength. The objective is to reduce the opponent’s HP to zero by accurately hitting their tank with missiles. Shots deal different amounts of damage based on where they land: 1)A critical Hit: A direct hit on the tank's head deals extra damage. 2)A normal Hit: A hit anywhere else does standard damage. Players must carefully time their shot to optimize both angle and power for maximum effectiveness. The game can be played against an AI opponent with varying difficulty levels and the first player to deplete the opponent's HP wins the match
- 1. Development Team
- 2. Introduction
- 3. Requirements
- 4. Design
- 5. Implementation
- 6. Evaluation
- 7. Process
- 8. Conclusion
- 9. 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 | [email protected] | Frontend Developer |
| 2 | Yu-Hsin Chang | [email protected] | Frontend Developer |
| 3 | Gioven Posa | [email protected] | Backend Developer |
| 4 | Tzu-Wei Lee | [email protected] | Backend Developer |
| 5 | Kotzamanidis Nikos | [email protected] | Product Owner |
| 6 | Shabarish Menon | [email protected] | Scrum Master |
- 5% ~250 words
- Describe your game, what is based on, what makes it novel?
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 insert 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 (insert Paper Prototype figure).
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).
.
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. 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.
| 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. |
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 below), where the competitive gamer (actor) interacts with the game system through use cases like "Start Game".
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
Use Case Diagram 2: Gameplay System
Screenshot of Use Case Documentation Introduction
Screenshot of Use Case 2: Start Game (used as an example above)
Screenshot of Use Case Documentation Conclusion
- 15% ~750 words
- System architecture. Class diagrams, behavioural diagrams.
-
15% ~750 words
-
Describe implementation of your game, in particular highlighting the three areas of challenge in developing your game.
-
15% ~750 words
-
One qualitative evaluation (your choice)
-
One quantitative evaluation (of your choice)
-
Description of how code was tested.
-
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.
-
10% ~500 words
-
Reflect on project as a whole. Lessons learned. Reflect on challenges. Future work.
- 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.
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?