diff --git a/README.md b/README.md
index fc93948..4ea4374 100644
--- a/README.md
+++ b/README.md
@@ -4,9 +4,20 @@
[![Promotional Video](Assets/Images/mainMenu9.PNG)](https://www.youtube.com/watch?v=ispMEXkR_t4)
+## TABLE OF CONTENTS
+
+- [1. TEAM](#1.-TEAM)
+- [2. INTRODUCTION](#2.-INTRODUCTION)
+- [3. REQUIREMENTS](#3.-REQUIREMENTS)
+- [4. DESIGN](#4.-DESIGN)
+- [5. IMPLEMENTATION](#5.-IMPLEMENTATIONs)
+- [6. EVALUATION](#6.-EVALUATION)
+- [7. PROCESS](#7.-PROCESS)
+- [8. CONCLUSION](#8.-CONCLUSION)
+
## 1. TEAM
-![Group members sitting behind a paper prototype of the game](Assets/Images/group_meeting.png)
+![Group Picture](Assets/Images/videoStill.PNG)
05.02.2024
@@ -20,7 +31,7 @@
## 2. INTRODUCTION
-Our game ‘Bomberman Dungeon’ is based on NES and SNES era [Bomberman]( https://en.wikipedia.org/wiki/Bomberman) games. Like it’s namesake our game offers a single player as well as a multiplayer mode in which players clear their way through a grid-based map with the help of their trusty bombs.
+Our game *Bomberman Dungeon* is based on NES and SNES era [Bomberman]( https://en.wikipedia.org/wiki/Bomberman) games. Like it’s namesake our game offers a single player as well as a multiplayer mode in which players clear their way through a grid-based map with the help of their trusty bombs.
Both modes feature the established combat mechanics of bombs being able to blast through breakable walls, enemies as well as the players themselves. Multiplayer mode largely remains true to its inspiration, offering a two-player death match on a map that dwindles as time progresses. Single player mode however adds two exciting new features. Not only is the player now able to collect coins instead of points, which they can then trade for all-new single or multi-use power ups in the store. But they can also find hidden doors leading deeper into the dungeon.
## 3. REQUIREMENTS
@@ -46,46 +57,60 @@ During the week 3 workshop we quickly made a firm decision to go ahead with 'Bom
### 3.3 Stakeholder Stories
->"As a player, I want intuitive and reconfigurable controls." (Physical Impairment)
+
+ As a Player:
+
+>"I want intuitive and reconfigurable controls." (Physical Impairment)
->"As a player, I want sprites to be distingushable based on shape, not colour." (Visual Impairment)
+>"I want sprites to be distingushable based on shape, not colour." (Visual Impairment)
->"As a player, I want to customise my character."
+>"I want to customise my character."
->"As a player, I want a clear understanding of the game mechanics."
+>"I want a clear understanding of the game mechanics."
->"As a player, I want achievable yet challenging goals."
+>"I want achievable yet challenging goals."
->"As a player, I want a straightforward HUD to efffectively strategize."
+>"I want a straightforward HUD to efffectively strategize."
->"As a player, I want a to keep track of my achievements."
+>"I want a to keep track of my achievements."
->"As a player, I want replayability and a sense of progression."
+>"I want replayability and a sense of progression."
->"As a player, I want to explore different game modes and difficultiy levels"
+>"I want to explore different game modes and difficultiy levels"
->"As a player, I want to relive the nostalgia of 8-bit games on a CRT."
+>"I want to relive the nostalgia of 8-bit games on a CRT."
->"As a player, I want to blow up my friends, even if they are far away."
+>"I want to blow up my friends, even if they are far away."
+
+
+ As a Developer:
->"As a developer, I want to gain industry relevant skills"
+>"I want to gain industry relevant skills"
->"As a developer, I want to work well as part of a team"
+>"I want to work well as part of a team"
->"As a developer, I want to plan my time well and do my fair share of work."
+>"I want to plan my time well and do my fair share of work."
->"As a developer, I want to set a good example for the next cohort."
+>"I want to set a good example for the next cohort."
+
+
+ As a Marker:
->"As a marker, I want to experience all core game mechanics within 5 minutes."
+>"I want to experience all core game mechanics within 5 minutes."
->"As a marker, I want to feel compelled to play the game in my own time."
+>"I want to feel compelled to play the game in my own time."
->"As a marker, I want to not be bored by a generic game clone."
+>"I want to not be bored by a generic game clone."
+
### 3.4 Use Case Diagram
+
+
![Use Case Diagram](Assets/Diagrams/useCase.png)
+
+
Created with PlantUML
### 3.5 CASE SPECIFICATIONS
@@ -118,39 +143,53 @@ Created with PlantUML
Created with PlantUML
-### 4.2 System Architecture
+### 4.2 Discarded System Architecture
+
+The main `GameLoop` class outsources most functionality to other classes such as dedicated Event Listener classes `Keyboard` and `Mouse` and the `Assets` class which at present loads fonts and sprites. The `Settings` class aims to provide a centralised place to adjust values influencing the game state such as Boolean Variables representing whether powerups have been acquired.
+
+#### 4.2.1 Map & Tile Class
+
+When called, `Map.generate()` populates a 2D array in the main class with Instances of `Tile` that each contain information on the type of object placed on the map as well as its position and sprite. At present the only objects spawned are floor, rock and inner as well as outer wall. Map RNG can not only be customized by defining the size and number of rooms but also by including additional types of objects or further specialising present objects. Iterating over rocks could therefore assign them items such as coins or powerups to hide. As the map exceeds the screen size, `Map.render()` saves resources by only addressing tiles contained within the game window.
+
+![Example Map](Assets/Images/map.PNG)
+
+Legend: # Unbreakable Wall
-#### 4.2.1 Main Menu
+#### 4.2.2 Collision & Player Class
+
+The player may get stuck in ‘dead corners’ of junctions between inner walls if they over- or undershoot the centre of the junction while attempting to make a turn. `Collision.check()` is fed a snapshot of the current user input due to the discrepancy between the game refresh rate and the speed at which the event listener registers keypresses. The function sanitizes user input, and cascades into further functions that assign the attempted movement to one of 12 categories which either allow for a direct execution on movement if no collision is involved or task the autopilot to reposition the player to the nearest junction prior to execution if the centre has been just barely over- or undershot. If the tiles between the player and their goal are of type ‘floor’, then no collision has occurred. In order to traverse the map, player movement affects translation of the map along a 2D axis, displacing it within the display window, making the player appear stationary.
+
+### 4.3 Present System Architecture
+
+#### 4.3.1 Main Menu
Upon entering the world of ‘Bomberman Dungeon’ the player can choose between one of three game modes, single player easy, single player hard and two player duel or use the settings menu change the key bindings. In hard mode, the player's FOV is reduced whereas in duel mode the map shrinks every 10 seconds.
-#### 4.1.2 Map
+#### 4.3.2 Map
The map is based on 30x30px tiles which the player views top-down. It consists of non-destructible walls enclosing the dungeon as well as additional walls placed in a checkerboard pattern. In multiplayer mode map RNG is limited to breakable rocks. In singleplayer mode rocks and enemies as well as two shops are randomly distributed throughout the map. Rocks furthermore have the potential to hide powerups, coins, keys, and the door until they are destroyed. The door requires a key to open and leads to the next level.
-#### 4.1.3 Player and Combat System
+#### 4.3.3 Player and Combat System
The player is attributed with a modifiable health state, movement speed and coin inventory. They are equipped with bombs that blast away enemies and breakable rocks both horizontally and vertically. The players own bombs however can also cause them to lose a health state. In multiplayer mode this also extends to the enemy player.
-#### 4.1.5 Powerups and Skills
+#### 4.3.5 Powerups and Skills
The player can obtain classic powerups such as ‘speedup’ which increases player speed, ‘bombup’ for an increased bomb carrying capacity, ‘fireup’ for an increased bomb range and ‘healthup’ for increased player health.
5 novel single use skills can be purchased with coins in the shop. ‘RemoveAllRocks’ removes all breakable rocks on the level, whereas ‘KillAllEnemies’ removes all enemies and ‘MoveToTheDoor’ teleports the player to the door. ‘VerticalFlames’ and ‘RoundFlames’ further increase the destructive range of bombs.
## 5. IMPLEMENTATION
-### 5.1 Three Challenges
-
During the development process, we encountered numerous challenges. While the implementation of individual features was relatively straightforward, integrating them often required modifications to the existing code base. Three challenges stood out.
-### 5.1.1 Smooth Player Movement
+### 5.1 Smooth Player Movement
Prior to populating the map with additional items, collisions were detected by comparing the players goal coordinates with the coordinates of all walls and rocks present.
Adding new items initially did not affect framerates, however once the powerup increasing player speed was introduced, we were baffled to see that player movement would not increase regardless of the chosen speed value. Once we identified the culprit to be a lack of optimization of collision detection, we were able to tackle this challenge. Our solution took the form of a 2D Boolean Array that marks impassable areas on the map as false. Subsequently goal coordinates must now only be checked against their corresponding Boolean value within the array.
However, by the time this issue had been addressed, we had already implemented map RNG and the association of powerups with breakable rocks. Modifying the collision detection therefore also required changes to the aforementioned features, substantially increasing the workload.
-### 5.1.2 Power-ups
+### 5.2 Power-ups
Adding powerups to the game revealed itself to be a compound of two challenges.
@@ -159,7 +198,7 @@ The first challenge involved ensuring that the same rock was not repeatedly chos
The second challenge involved displaying the correct item once their associated rocks were destroyed. Unfortunately, the existing approach to destroying rocks did not support adding this feature requiring modifications to both classes for bombs and flames. We chose to introduce an intermediate state between the destruction and disappearance of the rock. Furthermore, we added a Boolean flag to the rock class indicating whether or not it stored an item. When the rock was put in the intermediate state, its other properties determined which item to generate, and an instance of the item was created.
-### 5.1.3 Resetting the Game State
+### 5.3 Resetting the Game State
Nearing completion of the game, we were missing a feature that would allow the player to reset the map and any progress made. Unfortunately map RNG was bound to the setup section of Processing, where statements are executed only once at the start of the game.
@@ -167,8 +206,6 @@ Implementing this feature required adjustments to vast amounts of code pertainin
For instance, in order to reset breakable rocks, the map must first be cleared of and repopulated with rocks. Then the collision detection array must be updated according to the placement of the new rocks. Finally, new items need to be associated with the rocks.
-### 5.2 Three Challenges
-
## 6. EVALUATION
We invited a total of 10 users to participate in user testing in order to gain a better understanding of the functionality, usability, and reliability of our game. Insights gained were used for further optimization of our game.
@@ -232,14 +269,14 @@ Finishing touches in the form of sound effects and updated assets were made by Y
### 7.1.2 Video
-The Video was scripted, directed and edited by Zilou.
+The Video was scripted, directed and edited by Zilou, although team member scripted their own introductions.
### 7.1.3 Report
- Section 2: Tianyu
- Section 3: Lea
-- Section 4.1 + 4.3: Zilou
-- Section 4.2: Lea
+- Section 4.1+4.2: Lea
+- Section 4.3: Zilou
- Section 5: Yiguang
- Section 6: Zora
- Section 7: Lea
@@ -268,14 +305,17 @@ public class Bomberman extends PApplet {
```
## 8. CONCLUSION
-In conclusion, we based our game on the iconic Bomberman, but infused lots of innovative ideas to enrich the gaming experience throughout our development process. For example, in the single-player mode, the primary goal for players is to enter as more as possible round of the game by getting the key to enter the door. So we innovatively introduced coins, shops and five special skills, players can buy skills in the shop by collocting coins to achieve higher achievements. In the two-player mode, the main purpose for player is to eliminate the opponent to win the game. To increase the tension and excitement of the game, we creatively added a countdown feature to narrow the combat zone. All these innovations not only set our game apart from the traditional Bomberman but also enhance the game’s enjoyment and novelty.
-During the process of the game development, to align with the agile principles, we used Jira to assign tasks and effectively monitor team progress. We communicated in the real time via WeChat. And code updated and maintenance were conducted through GitHub.
+Developing *Bomberman Dungeon* was our first official introduction to using libraries and excellently complemented our journey of learning Java and OOP throughout the term. It additionally gave us a creative outlet for digital art and videography among other disciplines. For those of us looking to work in industry, learning the agile approach and associated techniques provides great soft skills.
+
+Reflecting on our project as a whole, reveals how far the game has come compared to initial predictions made in the Use Case and Class Diagrams. With our newfound knowledge of System Architecture however, it is clear that drafting more detailed Class and Behavioural Diagrams would allow for a smoother development experience as features could be integrated more easily.
+
+Along the way we have certainly improved our individual problem-solving skills but as a group we lacked effective communication. Separating the workload based on individual features discouraged active involvement of other members leading to a longer and less efficient development process. Using an instant messenger as opposed to a teamwork centric platform caused crucial bits of information to be overlooked. This in turn led to accidently discarding and having to recreate large sections of code, putting strain on the group overall.
-However, we encounted several challenges while we were developing our game. While the implementation of individual features was relatively straightforward, implementing some features required modifications to other already completed sections. These intertwined issues made implementation particularly difficult. Collison detect, power-ups and game restarts are the main challenges that we faced. Nevertheless, due to our exceptional teamwork, we successfully overcame all obstacles and significantly enhanced team members’ game development capabilitie.
+If we were to continue work on our game, then refactoring and documenting our code to create a modular and legible code base would be a top priority. This would allow for previously discarded code to be integrated and enrichen the dungeon with exciting new maps and an even smoother gameplay. These new, larger maps would highlight the need to rework the game balance which would provide us with an opportunity to add new enemy types and perhaps ‘power-downs’. Furthermore, we could revisit Jira tickets filed as optional such as providing online multiplayer via web sockets and transforming Singleplayer easy mode into an untimed mode that increases in difficulty the longer the player remains in the game and hard mode into a timed mode in which the player aims to reach high scores by killing enemies under a time constraint. Last but not least a refactored code base would allow for selective resetting of achievements, which could open up an opportunity for a meta progression system.
-Moreover, to ensure the game was user-oriented, in the later stages of game development, we collected player feedback through the Think Aloud method and quantitative survey, then we optimized our game based on those constructive comments.
+In conclusion, this project gave us valuable insight on industry standard software engineering methodology and the experience needed to confidently approach future projects. While we all saw individual growth, we need to reconsider new approaches and tools for improving our teamwork. Our game still offers many future opportunities, however, not matter how fun the challenge we must now move on to apply our new skills to our upcoming summer project.
-To sum up, we are all proud of the game we have developed. In terms of innovation, fun, and usability, we believe our game has reached an impressive level. However, due to the time limit, there are some feeatures that could be optimized and impoved in the future, For instance, a feature where players would return to the starting position and lose all items and skills they had upon death could make the game more challanging. Additionally, the bomb’s firepower and timing of their explosions may be affected by nearby explosives, so that it would increase the thill and competition in the two-player mode.
+Goodbye and thank you for your time!