Click Here to Watch A Demo Video
Name | |
---|---|
Hamza Ahmed | io23632@bristol.ac.uk |
Yiran Liu | fm19201@bristol.ac.uk |
Gunho Ryu | jm23986@bristol.ac.uk |
Xiaoqian Lu | fd23007@bristol.ac.uk |
Feng Xue | zp23769@bristol.ac.uk |
requirements: MAC OS / WINDOWS, Halloween adventure will not work on linux machines Processing, which can be downlaoded here: https://processing.org/download
Open Processing from your Mac OS or windows computer
Click on File - > Open
5.Once the file is open, click on the Play Button on the bottom Left corner of Processing
Our game is a 2D platform game which, like other similar 2D platforms, allows for a character to jump through obstacles, avoiding enemies and collecting points.
Enemies Chase Mechanics
The added twist within our game is the addition of a timed flying mechanic. This ‘power-up’ allows the player to fly for a short period of time, making traversal through the game world easier.
Flying Mechanics
Early on the inspiration for our game was the fondness all team members had towards games like Super Mario, we chose this because it also gave a simple vision to consitantly aim for in the game development process. This was reflected in our initial idea for the game where the twist would be that princess peach would be rescuing Mario. Over time however this evolved, as we sought after our own story line and unique game aesthetic.
Game Playing
(videos have been editted by VEED.io)
Controls
Use the arrow keys to move adventurer left and right. Press the up and down arrow key to make adventurer jump. Adventurer can also use this key to climb ladders.
Objective
Your goal is to safely guide adventurer through each level to reach the mystical flag at the end.
Avoid Enemies
<img src="https://github.com/UoB-COMSM0110/2024-group-12/assets/126887318/1874678e-9a90-473b-944e-fab58c0d646a" alt="redsprite" style="width:40px; height:40px;" <img src="https://github.com/UoB-COMSM0110/2024-group-12/assets/126887318/d1966a87-bd81-45de-bfb0-5cb37c4d4dd4" alt="witch"style="width:40px; height:40px;"
<img src="https://github.com/UoB-COMSM0110/2024-group-12/assets/126887318/b7ef13d3-beef-4896-b51d-73d5a5ccfb65" alt="redsmile" style="width:40px; height:40px;"
<img src="https://github.com/UoB-COMSM0110/2024-group-12/assets/126887318/257a5d24-e355-409d-a888-f318bc312d14" alt="pumpkinmonster" style="width:40px; height:40px;"
Beware of the lurking enemies ! Dodge the menacing pumpkin monsters, evade the spells of wicked witches, watch out for the mischievous red sprites, and beware of the eerie Redsmile. Use your agility and quick reflexes to outmaneuver them.
Along the way, collect pumpkins scattered throughout the levels. Pumpkins are essential for scoring points.The more pumpkins you collect, the higher your score will be.
Look out for special power-ups hidden throughout the levels. They might enhance advanturer jumping abilities, allowing him to overcome obstacles and enemies with ease.
ideation, Use-cases and User Stories
Our group first came up with six game ideas, these were narrowed down to two potential games that looked the most promising. The games that we selected were :
For both these games, we identified the stakeholders, user stories and the potential challenges, we then prepared our paper mock ups, divieing up the task within the group. We used the paper prototypes to visualise how the main game screen would look and to work out the aesthetics of the game.
Identifying the stakeholders
We identified the primary stakeholders for the game are the individuals who will be directly playing the game and reviewing it, these are:
The interaction of the stake holders with this game is designed to be identical so the user specification and user stories can be condensed for all stake holders identified above.
User Case Story
User Story
“Meet Hanna, a novice gamer: As a new gamer, I want to control the characters movements using simple controls that are immediately responsive. These controls should be intuitive so that I can navigate through the game easily and enjoy a immersive gaming experience.”
“Meet John, a casual gamer: As a causal player of the game, I want a clear objective that provides a rewarding experience, I want to unlock special levels or achievements by collecting specific power-ups or achieving certain in-game milestones so that I can explore additional content and challenges. e.g. a method to earn points."
“Meet Fenix, a experianced gamer: As an experianced user, I want a challanging game, I want to know I am the best player!!”
Use Case Section | Easy Mode | Hard Mode |
---|---|---|
Description | A run through the game with fewer enemies and more power up placements | A run through of the game with more enemies and fewer special power upgrades |
Game Screen | The player can enter their name, view the game tutorial, select the game difficulty and view the leaderboard | The player can enter their name, view the game tutorial, select the game difficulty and view the leaderboard |
Basic Flow | Complete the game with no loss of life, collecting as many points as possible | Complete the game with no loss of life, collecting as many points as possible |
1 | The player presses uses the RIGHT, UP, LEFT and DOWN keys to traverse through the game map | The player presses uses the RIGHT, UP, LEFT and DOWN keys to traverse through the game map |
2 | The player collects pumpkins to increase score | The player collects pumpkins to increase score |
3 | The user collects power up to navigate around the map, avoiding enemies | The user collects power up to navigate around the map, avoiding enemies, these power ups however are less abundant |
4 | The user navigates to the end of the map | The user navigates to the end of the map |
Alternative Flow | Collision with the enemy or falling off the edge | Collision with the enemy or falling off the edge |
1 | The player presses uses the RIGHT, UP, LEFT and DOWN keys to traverse through the game map | The player presses uses the RIGHT, UP, LEFT and DOWN keys to traverse through the game map |
2 | The player encounters an enemy and loses a life. | The player immediately encounters an enemy and loses a life, there are more special enemies which have the apperance of pumpkins but are transfomring |
3 | The player player falls of an edge and is returned to the start of the game screen | The player player falls of an edge and is returned to the start of the game screen |
4 | When all three lives are list the game ends there with the option to restart the game | When all three lives are list the game ends there with the option to restart the game |
System Architecture
The architecture of the game consists of largely three main components: Game Manager, UI and In-Game Components. It was of critical importance for all components to be fully integrated to develop a functioning game.
Game Manager corresponds to the default main.pde file of the newly created Processing Project, implying that the file manages the overall flow of the game and renders the UI and In-Game Components only under relevant situations. It overrides most built-in functions from Processing in which its keyboard and mouse actions are then controlled by this Game Manager.
To display the right UI and perhaps the In-Game components, main.pde has to identify current state of the game. For instance, if it is on start state, it may display the Game Start Page with a lot of helper features (Start, Intro, Levels, Name) while at game-play state, it may display what is relevant for the play state (the player, enemies, and maps).
User Interfaces corresponds to all the user-friendly components including the start button, intro, leader board, difficulty levels, and a back button. They are designed to be well recognisable by users by their names without requiring understandings from the users on what to do and how to use these.
In-Game Components includes all the game related objects from a player, platforms, enemies, and score relevant collectables. Each of these game components are of a separate object with unique methods, and properties and if relevant may inherit from an identical parent class. It might be also important to find appealing visuals for each in-game components in which they may all look visually appealing.
CLASS DIAGRAM
To have a common static view of the game, our group devised a class diagram where it may roughly represent a good view of the classes that may be in used for the project.
Our game features an intricate system centered around the creation of "AnimatedSprite," a class housing the base character animations responsible for loading and executing various actions. Built upon this foundation, we implement the attributes of the player character, enhancing their functionality atop the AnimatedSprite framework. The core logic governing the behavior of boss characters takes precedence in our game, encompassing elements such as damage calculation, pursuit tactics, movement speed, and engagement range. Notably, classes like "PumpkinMonster," "RedSmile," and "RedSprite" derive from the original Boss class, loading distinct actions to diversify gameplay.
To orchestrate the game's mechanics and level progression, we utilize the "Game" class for initializing maps, characters, and classes, while employing "Map" to dynamically generate environments and adversaries. Meanwhile, "PlayPage" facilitates seamless transitions between various game states, encompassing the start screen, end screen, and leaderboard interfaces. Additionally, the "Movement" class governs character movement logic and key mappings, ensuring fluid player control.
Throughout the development journey, we encountered a myriad of challenges, ranging from optimizing character animations to managing the intricacies of boss logic and crafting dynamic game maps. Moreover, implementing interactions between players and enemies presented its own set of obstacles. In our pursuit of refining the game's quality and enhancing user experience, we'll delve into the specific challenges encountered and detail our strategies for overcoming them, ultimately fortifying our game development process.
During our development process, we encountered a challenge related to preserving the correct game state after a character's death and game restart. Specifically, utilizing the gw.create() method post-character death and subsequent game restart failed to maintain the intended game state. Despite collecting crucial elements like a pumpkin before the character's demise, certain elements were not retained upon game restart. This issue led to an accumulation of items and an abrupt termination of the game due to inadvertent duplication of item quantities.
To tackle this dilemma effectively, we implemented a solution that involved resetting all monster lists and character information within the gameworld object. By doing so, we ensured that the game starts afresh with the accurate state upon each restart, thereby mitigating the risk of unintended item duplication and ensuring a smoother gameplay experience.
In our game, when the difficulty level is set to "Hard," enemy behavior involves calculating the distance between enemies and the player. However, a critical flaw in our collision detection logic causes enemies to inaccurately perceive the player's position. As a result, they mistakenly believe they've collided with the player, particularly when the player is positioned above a brick (as depicted in the provided video). This erroneous perception leads enemies to cease their pursuit, disrupting the intended gameplay flow.
To swiftly address this issue while prioritizing efficiency, we opted for a pragmatic solution rather than investing extensive resources into modifying the complex collision detection mechanism. Our chosen approach involves elevating the brick, thereby increasing the distance between the player and enemies. By implementing this adjustment, we effectively mitigate the impact of the collision detection error. Enemies are less likely to mistakenly converge on the brick, ensuring that their behavior aligns more closely with the intended gameplay dynamics.
During gameplay, clicking on the leaderboard button consistently triggered a sudden switch to a new game, preventing players from accessing the leaderboard in time. This issue arose because the restart button shared the same location as the leaderboard button. Consequently, double-clicking on the leaderboard button often inadvertently activated the restart button, leading to unintended game restarts.
To address this usability issue and improve player experience, we relocated the restart button to a different position. By separating the restart button from the leaderboard button, we reduced the likelihood of accidental activations during interactions with the leaderboard interface. This adjustment aimed to minimize player frustration and ensure that accessing the leaderboard remained a smooth and uninterrupted experience.
During the development phase, we encountered a significant challenge related to the character's collision box, which was oversized. This discrepancy caused the character to appear suspended above the ground rather than properly grounded. Additionally, when the character flipped, improper collision positioning resulted in a subtle yet noticeable displacement of the character's image. Upon investigation, we identified that transparent pixels within the character's image were causing issues in collision detection. These transparent pixels inadvertently triggered collisions prematurely, especially when the character approached a wall or obstacle.
To address this issue effectively, we implemented a transparent pixel cropping technique on the character's image. This process involved trimming away the transparent pixels surrounding the character's visible portions, ensuring that the collision box accurately represented the character's silhouette. By restricting the collision box to encompass only the visible areas of the character, we significantly enhanced the accuracy of collision detection.
Evaluation is fundamental in software development as it enables developers to analyse and refine the software to meet users’ requirements effectively. To ensure that our project meets users’ requirements, our group implemented two evaluation measures: qualitative and quantitative evaluations. Any issues identified from these evaluations, if applicable, were addressed and some evaluations were run multiple times to better evaluate the project.
Our game’s main objective could be summarised as below:
Go as far as you can.
Given the tasks, for qualitative evaluation, two methods were introduced: Think Aloud and Heuristics Evaluation. Think Aloud evaluation requires users to verbalise their thoughts and impressions while performing the requested tasks. Such verbalised thoughts are highly associated with the user’s experience and addressing these potential issues or bugs pointed out by the participants is essential to ensure the quality of a developing software is consistent and reliable.
The below represents the results from the Think Aloud evaluation of the prototype game. The game was run on the test map and with test features. Two participants, one facilitator and two observers joined the evaluation and the issues identified during the evaluation were then addressed to improve the real game. The collected data were then processed into customised categories: “Nothing to be addressed”, “Issues to be addressed”, “Issues to be discussed”, and “Uncertain”. The first two categories identify data that their names clearly suggests while the “Issues to be discussed” identifies issues that is worth discussing at a group level since this could be viewed as a bug or perhaps the game developers’ (our) intention. Lastly, the last category identifies data that could not be interpreted.
Two more participants joined the same evaluation after Easter holiday right after the real game features and the two difficulty levels were finally introduced into out project. Its following results are presented underneath in the same style as above.
For better analysis, Heuristic Evaluation was also conducted as well. The below results represent the Heuristic Evaluation. Overall, qualitative evaluations in which Think Aloud combined with Heuristic Evaluation may have proposed what could be better improved in the context of developing a user friendly software (game).
For quantitative evaluation, NASA TLX have been implemented to evaluate the perceived difference of the two game levels, namely “easy” and “hard”, and these results then have been analysed in the context of W test statistic. NASA TLX is one of the most widely used tool to measure the subjective workload perceived by the users and it is used across various industries including software engineering, health, and so on. It specifically, measures the multidimensional workload from executing a specific requested task and these dimensions are comprised of Mental Demand, Physical Demand, Temporal Demand, Performance, Effort, and Frustration. The detailed explanation of these components is provided underneath.
The overall derived results and its subscale measures from NASA TLX is valid as demonstrated from significant independent research. Considering all these, NASA TLX appeared to be the most appropriate quantitative method to evaluate the designed level systems, “easy” and “hard”, in the game.
For the evaluation, 10 participants (N=10) were recruited. The participants were then requested to play the designed two different levels (easy, hard) of the game with the required task. All participants first played the “easy” level then played the “hard” level. After the completion, the same participants were asked to finish the NASA TLX. It is worth noting that there could have been a training effect where a participant after finishing the “easy” level had higher chance of better performing at the “hard” level, implying that there could have been a plausible bias for participants to underestimate the “hard” level. However, due to the difficulty in recruiting participants, the evaluation continued with its original design. Finally, the collected NASA TLX data has been processed into the raw TLX scores as suggested from some researchers.
The below represents the processed TLX scores. To find its statistical differences, the processed data were passed to conducted Wilcoxon-Signed-Rank-Test and the test at its sample size, proved that the given results to be statistically highly significant at (p = 0.005) level. This may imply that the two designed levels of the game were perceived by our potential users to be significantly different where our design then meets our intention.
The goal for our project was to create a simple visually aesthetic game that gave players a fun yet challenging experience. We aimed to create in one level a replayability factor for the game which would:
To meet these objectives, we adopted the Agile methodology, emphasising:
In our initial team meeting, attended by Hamza, GunHo, Yiran, Feng, and Lu, we brainstormed potential game concepts, prioritising personal passion over feasibility. We subsequently narrowed our focus to 2D platformers, dismissing more complex ideas like 3D and online multiplayer games due to time constraints.
Challenges during this phase:
Solutions:
We conducted a GitHub tutorial. For example, one of the team members (GunHo) had significantly more GitHub experience than the rest of the team. So we had all team members (Hamza, GunHo, and Yiran present) go through a tutorial on branching, merging, and rebasing. We did this by ‘practice’ codes that we pushed onto git, where each member practised creating their branch, merging code and resolving conflicts.
Organisation and Communication
We decided on a 2D platformer with mechanics similar to those in Super Mario Bros and Flappy Bird, where players could fly by repeatedly pressing a button. Our organisational tools included the Kanban board on GitHub and personal notes on Notion. Unlike traditional Agile methods, we opted for continuous communication via WhatsApp instead of daily stand-ups.
Challenges:
Solution:
Tasks were assigned using a method akin to planning poker, where each member assessed task difficulty before distribution, these sessions also helped us to clarify roles:
Development intensified during reading week and the Easter holiday. An initial minimal viable product was evaluated using Think Aloud and Heuristic evaluation methods, highlighting:
Challenges:
Solution: Focusing on a core narrative, we redefined our game around a ghost character collecting pumpkins. We simplified the flying mechanics to better suit the game's aesthetic, transitioning from a flapping to a continuous flight model within a time frame.
During Easter, we held sprint days, refining features and incorporating feedback from friends and family, crucially expanding our tester base to include novice gamers. This feedback led to the implementation of smoother controls and personalised start screens.
Challenges:
Solution: We decided against a detailed narrative, opting instead to enhance the gameplay and visual elements. Unimplemented ideas included gameplay mechanics like collecting donuts for extra lives and transforming the ghost into a human.
In conclusion, our journey in developing this 2D platform game has been a testament to the power of collaboration, iteration, and user-centric design. Through the Agile methodology, we navigated various challenges, from refining our initial concept to addressing technical hurdles and user feedback. Our commitment to regular communication, role clarity, and task prioritization helped us stay on track despite the complexities of game development.
As we progressed, user feedback played a pivotal role in shaping our game's direction. Whether it was tweaking mechanics for smoother gameplay or refining visual elements for better immersion, every iteration brought us closer to our goal of creating a compelling gaming experience.
While not without its challenges, our journey reinforced the importance of adaptability and resilience in the face of setbacks. By embracing feedback, iterating on our designs, and remaining focused on our objectives, we were able to overcome obstacles and deliver a game we're proud of.
In the end, our game stands as a testament to the power of teamwork, creativity, and perseverance. Our adherence to Agile practices such as pair programming and iterative testing was instrumental in creating a game that was both enjoyable and aesthetically pleasing. This project underscored the importance of user feedback and continuous iteration, and taught us effective use of tools like Kanban boards and GitHub. These experiences will undoubtedly benefit our future projects, as we apply the lessons learned to new challenges and endeavors in the world of game development and beyond.
Name | Role | Individual Weight |
---|---|---|
Yiran | Lead Developer and Coder | 1 |
Hamza | Project Manager and Coder | 1 |
GunHo | Secondary Developer and Designer | 1 |
Feng | null | 1 |
Lu | null | 1 |