1. Aims and Goals
• Aims:
Our aim for the project during these four weeks is to create and deliver an HTML spider game that has already gone through beta-testing. To be more specific, we want to make a simple but engaging spider game where users will try to overcome the obstacles and go as far as they can with the spider to earn points. As mentioned in the Motivation section, we would like to make this game so that users can play the game to destress and relax while waiting for RMIT’s Wi-Fi connection to improve. To accomplish this aim, we will need to fulfill the following goals.
• Goals:
The first goal that we would like to achieve is to learn and familiarize ourselves with the fundamental tools and skills that we will be using to develop our game, which is Phaser 3, JavaScript, and WebStorm. To do this, we will have to do some research into the framework, the language, and the IDE by reading the documentation, and/ or watching tutorial videos, as well as practice and try the tools and language out. This is necessary for us to achieve our aim because we need these tools to build the game, and JavaScript and Phaser are very suitable tools because Phaser is an HTML5 game framework that is very easy to understand. We also need to know more about WebStorm because it is a good IDE for JavaScript.
Our second goal is to set up the basics and foundation of the game. We will investigate and finish the physics engine, the design, the mechanics, and the gameplay of the game. This includes the swinging mechanism, the camera following mechanism, the endless scrolling mechanism, the creation of obstacles, and the scoring system. All of these are the core characteristics and setups of our game, which makes it very important to accomplish this goal.
Thirdly, we also need to design a Github website for our IT team Kuri. This will be a website that will display the information about our team and the project that we are currently working on, and included in this website will be a place for us to put and publish our game. The website should be user-friendly, intuitive, responsive, and compatible with many devices. This website is also needed because it will show who we are as a team and our journey and process of making this project, which can help us further promote Kuri and our current project.
2. Scope and Limits
Our group has decided what we would like to include in the scope of our project and features that are out of scope, as well as the level of importance or priority of each of the components in the scope.
To begin with, many elements are of high importance in our scope, which means the final product that will be submitted by the end of week 4 will contain all of these items. Regarding the game, the high priorities include the scoring system that will calculate and display the user’s score after each round, and the game design and artwork, such as the design of the spider character and the creation of obstacles. Further aspects of the game that are also of high importance are the physics of the game, which uses the MatterJS physics engine to make the game behave more realistically, and some basic mechanics of the game like endless scrolling, web-swinging, and camera following. All of these have a high priority in our scope because they are all the core and fundamental aspects of the game, so we must complete these features. The two last high-priority elements of this project that are not related to the game are our website and final report. The website and the final report are very crucial to this project because they showcase more in-depth and detailed information about our team Kuri and this project.
Secondly, we have defined compatibility, touch input, sound, lives, bomb, and high score system in the game to be the project’s medium priorities, meaning that these elements do not necessarily have to be in our project for the time being; nevertheless, we still want to include them because they can make our project so much more convenient, interesting, and engaging. Compatibility is the ability for the game to be able to work on different devices, such as phones and computers, and this characteristic is related to the touch input feature, which allows players to play on phones and tablets by touching the screen. For the lives system, we want the spider to have three lives per round so that users can play the game longer. Additionally, we also want to implement a high score system that can display the user’s highest score so that we can encourage users to play more to get a higher result. Regarding the bomb system, we would like to have bombs appearing randomly during the game so that the spider will lose one life if it hits the bomb, which would make the game harder for players. Lastly, we want to add sound and sound effects to the game, like a sound effect when the spider hits an obstacle, to make the game more captivating and engaging.
Regarding the features with low priorities, they are the aspects of the project that are not essential for now and we will only work on them after the high and medium priorities are achieved, and if we still have the time and resources to finish them. For this project, the elements with low importance are the booster earning system and optimization. A booster earning system is when the spider can move faster if it gains a speed booster, while optimization is when we optimize the game so that it can run faster and smoother.
Lastly, some aspects will be out of scope for this project. Since we only have four weeks to work on the project, we will not make a scoreboard system, which is a system that shows and compares your score to other players, and we will not try the network implementation step. Furthermore, due to the time constraint, we will not be able to ask for authorization from the school to access their network.
3. Plans and Progress
After four weeks, our project will deliver a game with a retro/ arcade theme and Rupert the Redback Spider as the main character with three lives per round. The game will function similarly to Google Chrome’s Dinosaur game: the score is calculated based on the distance travelled by the spider, so the main goal of a player is to travel as far as possible while avoiding obstacles and bombs to accumulate the most points. Of course, we have modified and added some features to the game so that it fits with the spider character and makes the game more interesting. In the beginning, there will be a start screen displaying the spider attached to a web along with an error message. To start the game, a player can press the right or left arrow keys on their keyboard or touch their screen, since doing this will cut and then reattach a new web to the spider. When there is no web, the spider will free-fall within the world bounds until it hits the ground, which will make it lose one life. The direction of travel of the game is to the right, so the player can use the right arrow key or touch the right side of the screen to move the spider forward. The game can scroll endlessly as long as the spider is still alive and moving forward, and the spider will lose one life if it hits the obstacles, the bombs along the way, or the world bounds, which are the ceiling, the ground, and the wall on the left. In addition, some obstacles can move up or down during the game to make it harder. When the player loses all three lives, the game will display a game-over screen containing the player’s score, their high score, and a restart button. There will also be sound effects to make the game more interactive and engaging. To deliver this outcome, we will have to develop all core features of the game using suitable tools and technologies like Phaser 3, JavaScript, and learn about the tools through documentation and tutorials.
The progress of all three teams will be presented, starting with the Game Development team.
The idea of this project all started when Mike came across a lot of confessions and comments from RMIT students complaining about the school’s Wi-Fi issue. Hence, while working on Assignment 2 of the course Introduction to IT, he came up with a potential idea where we could implement a game similar to Google Chrome’s Dinosaur game into RMIT’s network to entertain the students when they cannot connect to the school’s internet. Mike also did some sketches of the game’s basic concepts and made a diagram to show how the game will be returned when the Internet connection is slow. The idea was very interesting and unique, so when it was brought up and discussed during our group meetings before Week 8, every member of Kuri liked it a lot and decided that it would be the best project idea to work on. We also assigned roles and tasks to each member of Kuri as soon as we settled on this idea so that we could start working on the project right away after Christmas break, and Mike started to learn more about JavaScript before the break.
Kuri officially started this project in week 9 after the break, and during this period, Mike familiarized himself with the game framework Phaser 3 through documentation, did some planning for the game development, and finished some basic artwork of the game, such as the artwork for the spider. Since it was right after Christmas break, Kuri’s working pace was relatively slow.
During week 10, Mike did a lot of work regarding the game: he successfully implemented four of the game’s core features: camera following to follow the spider, endless scrolling so that the game can continue for as long as the player is alive, obstacle creation to generate obstacles and the scoring system. He also added animations when the spider is hurt and sound effects when the spider hits an obstacle or the world bounds, when a new web is attached to the spider, and when the game is over. A game-over screen was added to the game, which could display the score and a restart button after a player loses. Next, Mike implemented high resolution scaling and world bounds within the game so that the spider cannot go backward or fall forever. Some changes were also implemented, such as the modification of the player collision box to not include the spider’s legs and the use of a joint system to have a more accurate player physics. He also did some gameplay balancing, changed the background of the game for easier visual debugging, created debug mode, and added more debugging information to make the debugging process easier and more efficient. While making and testing the game, numerous bugs were discovered, such as the player not being able to shoot the web after cutting it for the first time, the spider web not displaying correctly after the game restarts, and the camera bug not scalable for x- and y-axes for different initial player positions. Hence, Mike had to go through the code many times and fix a lot of bugs; nevertheless, he still managed to successfully fix some important bugs during week 10, like the three bugs mentioned above. Lastly, since the code of the game was quite messy, Mike reformatted the code to make it easier to follow.
During week 11, the Game Development team mainly added some features, fixed bugs, and redesigned the game. Firstly, on 14/1/2021, Mike fixed some bugs relating to the obstacles and successfully implemented web-shooting at the correct height above the player. Next, some changes were introduced to the game: the obstacles were redesigned to look better and more suitable for the game, and the control scheme was modified so that it is simpler, more intuitive, and easier to port to implement on touchscreens. Since the game was ready for Alpha Testing, it was officially released as v0.1-alpha “Kanamori”, and the rest of the Kuri members did Alpha Testing during our group meeting to try the game and give feedback. Mike also added a release package for v0.1-alpha. On the 15th, the Game Development team successfully implemented touch input as well as modularizing and objectifying obstacles in the game. He also adjusted the obstacle placement so that spamming the controls was no longer a viable strategy to prevent players from spamming the game. While working on the game, Mike opened a few development branches so that he could experiment and test some ideas. On the 16th, he redesigned the graphics of the entire game and implemented dynamic obstacles so that some obstacles could move up and down to increase the difficulty of the game. Next, he added a persistent high score to the game-over screen to display a player’s high score and added a start screen with the spider and an error message to hide the game. Mike also implemented the bomb pack where hitting a bomb would make the spider lose one life, and released v0.3.1-alpha “Kanamori” for another Alpha Testing within our group. On the last day of week 11, Mike redesigned the bomb, rebalanced gameplay, and fixed many bugs in the game, such as the disappearance of bombs and the bomb collision detection not working in some cases, the web was cut immediately upon restart, and the spider might violently jerk around.
In the last week of the project, which was week 12, Kuri had a meeting on 18/1/2021 where we did another Alpha Testing to detect bugs and come up with some suggestions for the game. Afterward, all members of Kuri did some game balancing to adjust the difficulty of the game, such as modifying the size of the bomb and changing the chances that the bomb will appear. Later in the week, we did a Beta Testing of the game by sending it to our classmates and teacher so that they could try the game and give us feedback. From the feedback from our testers, the Game Development team did some more game balancing and fixed some bugs found during the testing period. Hence, our game is at the stage where it has gone through Beta Testing, and this concludes the progress of the Game Development team during the four weeks of this assignment.
Next is the progress of the Writing group. The Google Docs for the report writing group was created on 22/12/2020 by Nhi, and the Google Docs file is only accessible by members of the Writing group to write and edit the final report on there. Therefore, a copy of the report was sent to Kuri’s leader, Mike, every week to inform him of the up-to-date progress of the Writing group. On the same day, Nhi added the common background information of the group members to the report. After the break, at the beginning of week 9, the Writing group managed to collect and put together all Kuri member’s personal information, mainly about our interest in IT and career plans. Manh made the cover page and table of contents, while the career plans comparison was written by Nhi. The Overview section of the Project Description was also completed, with Manh writing the Topic of the project while Nhi handled the Motivation and Landscape sections. Nhi also completed the Group Processes and Communication in the meantime. In the middle of week 9, Manh received the Tools and Technologies list and edited it on the report; however, this list was incomplete since the other two teams just started the project. At the end of week 9, Nhi finished writing about the Roles of each member in the Project Description, and both members revised what they had written so far in the report.
In week 10, Manh wrote about the Testing and Risks sections, while Nhi added the Timeframe table and filled up the first two rows. Both Nhi and Manh also finished writing about the Aim and Goals of the project. In the middle of week 10, Nhi completed the Scope and Limit section, while Manh started to work on the Tools part. It was unfinished due to the requirement of commenting on the Github commit trail, which could only be done in week 12. Manh also updated the Tools and Technologies list, added a tool called Webfont Loader and the information of each tool’s version. At the end of the week, both Manh and Nhi proofread and edited the new sections of week 10.
At the start of week 11, Nhi added her feedback of each member and started writing the Plans and Progress. Nhi mainly wrote about what the project will do and the process of the game development team. Later in the same week, Manh added his feedback and wrote about the report writing and web development’s plans and progress, while the other members of Kuri also finished their feedback. From the end of week 11 until the start of week 12, the remaining sections (comment on Github commit trail, Plans and Progress, Group Reflection, and Timeframe) were updated, completed, and edited by both members. In the middle of week 12, Nhi sent all the content to Linh, Leader of the Web Development team, so that Linh could upload the content to our website, while Manh fixed the Table of Contents and reformatted the report to make it look cleaner. The final report was then checked and revised by Nhi again before sending it to Kuri’s leader, Mike, for the final submission. In conclusion, the Writing group has reached the stage where our initial project report is finished.
Lastly, the progress of the Web Development team will be discussed. Kuri’s GitHub organization account and the website repository were created very early on by Mike (on 6/12/2020). In week 9, the Web Development team nominated 3 website templates for every Kuri member to vote for the best one, and the template named WebHostingService got the highest rating from all the members due to its modern style. After deciding on the template, the development group started to fix the index page of the website to fit the theme of our team Kuri and pushed all HTML files to Kuri’s GitHub repository.
In week 10, the development group did more styling and optimizing work. The group fixed all HTML files’ footers and navigation bars, uploaded the Kuri logo, and updated the team members’ names and photos on the homepage and About Us page.
In week 11, the development team updated the Blogs page. Four blogs of our project, which were blogs for Game, Feedback, Group Reflection, and Skills and Jobs, were created with nice thumbnails and were ready for more content. In the Game blog, the Web Development team included a slideshow of multiple photos of the game along with a “Play game” button to redirect users to our game. The last element of the website that the Web Developers edited was the Contact page: they added some contact information of Kuri, such as email and address, and a Google Map pinpointing the location of RMIT.
At the start of week 12, this team created three other blogs for Project Setup, Project Plan, and Timeframe. For the Game blog, the Web Developers decided to remove the Play button and put the game directly into the blog instead. In the middle of the week, the Web Developers uploaded all the content from the Writing group and did some styling to the blogs, uploaded our group photo to our website, and changed some details to the website. At the same time, they also completed the presentation slides and script for our demo pitch, which was recorded later in the week. To sum up, Web Development has reached the stage where our Kuri website can display information about our team and our current project in a visually pleasing manner.