1. Tools
We created a Github organization for our team to work together on GitHub, and each of the members’ Github accounts has access to this organization. In the organization account, there are three repositories: one is for the demo of the game, one is for our team website, and the last one is the storage space for other things.
The link to our website: https://kuri-team.github.io
The link to our Git repository: https://github.com/kuri-team
On GitHub, the audit trail has moderately reflected the Game and Web Development teams’ contribution to this assignment but not for the research and writing group, since they mostly worked outside of GitHub. From our observation, all Kuri team members were very proactive and contributed to the best of their abilities to this assignment.
2. Roles
For the project, we have defined roles for each member of Kuri.
Mike is the Team Leader who leads the team and oversees the project to make sure that our project is on the right track, and that our goals and aim are achieved. He is also the Lead Game Developer, meaning that he will be in charge of programming and developing the HTML game. We decided that he should have these positions because Mike has great leadership skills, he is the most experienced in the IT field out of all the members, and this is his project idea. Furthermore, Mike is familiar with various languages that can help him develop the game
The next member is Linh, and he is Kuri’s Game Developer and Lead Web Developer. As a Game Developer, he will make and code the game with Mike, while as a Lead Web Developer, he will be making, managing, and overseeing the web development process for our team’s website on GitHub. He will also report back to our Team Manager the progress of his web development team and if there are any issues with the website. Linh is given this position because he is proficient in HTML, CSS, and JavaScript, and he already has experience with web development. He is also familiar with JavaScript, so he will be able to code the game.
Thirdly, since Huy has some experience with HTML, he will be responsible for making and designing our website with Linh; hence, Huy is our team’s Web Developer.
Lastly, Nhi is the Leader of the Research and Writing group and Manh is another member of this group, and their main task is to write, edit, and proofread the final report for our project. They will also do some research about the theories and concepts related to our project, such as game testing. In addition, as the Leader of the Research and Writing group, Nhi will have to update the progress of the project’s report writing and research to the Team Leader, and decide what specific tasks will be completed each week regarding the final report. Nhi and Manh are assigned to this role because they both have a lot of experience with Academic Research and Academic Writing, and Nhi specifically has good management skills, which makes her very fitting for the Lead Writer and Researcher role. Since we only have four weeks for assignment 3 of the course Introduction to IT, we will only make the game; we do not plan to implement the game into RMIT’s network during these four weeks. However, if we want to continue with the project after the assignment, we will have to implement the game into the network, and this will be the main responsibility of Nhi and Manh in the future. Therefore, their future positions will also be Network Administrators if Kuri decides to further pursue this project.
3. Tools and Technologies
• Game engine: Phaser (https://phaser.io) version 3.50.1 “Subaru”. Phaser is a popular and easy-to-learn open-source 2D HTML5 game framework. Mike and Linh are using this framework for the first time, but both already had previous experience with programming in JavaScript
• Languages used: HTML/CSS and JavaScript are used to make the website. Huy, Linh, and Mike all have previous experience with front-end development in these languages.
• Font tool: WebFont Loader version 1.6.26 is used to control and load fonts for our project.
• IDE: Visual Studio Code version 1.5.2 is our choice of IDE for web development. It supports our choices of language to build the website and we can use Git commands with it. As for game development, we use Jetbrains Webstorm 2020 since it mainly supports JavaScript, which is what Phaser needs.
• Sprites and other arts: Aseprite version 1.2.25 for pixel arts (Mike bought the software for his previous projects), Photoshop CC2018, Illustrator CC2018, or other open-source equivalents such as Gimp and Inkscape for more complex raster and vector photo editing capabilities. Mike has previous experience with all of those software applications.
• Sound design: Audacity version 2.1.0 for rudimentary audio editing and Studio One version 4.5.2 (free version) for studio-level-quality audio engineering. Mike has previous experience with both software applications.
• Browser: Google Chrome 87.0 and Firefox 84.0.2 are used for game debugging.
• Version control: Git version 2.30.0 with repository hosted on GitHub (https://github.com). All members of Kuri are proficient in using Git and GitHub.
• Hardware: For initial testing of the game, we will need a sample wi-fi network. This could be the wi-fi network at one of the members’ homes. Back-end components will be overseen by Mike with consultation and collaboration from team TTNC’s leader Dang Vu Thang (S-3879303).
• Permission to access RMIT University Vietnam SGS Campus wireless network hardware. This would be the hardest part of this project due to strict network authorization at RMIT SGS campus. None of Kuri members has knowledge about back-end programming and network administration, so we will need to consult the school leaders and the IT department in this regard.
4. Risks
There will be various risks that we probably or must face when we follow this project.
Regarding the development of the game, we have identified many risks. First of all, the Phaser 3 framework and MatterJS physics engine might be too complex to learn, so it may take us a long time to understand and get used to the concepts to code our game. This leads to the possibility that we might not be able to add certain features, or the game might perform poorly due to the complexity of the tools used. Furthermore, Phaser 3 does not support many old devices, so it can be hard for the game to reach users who do not care so much about technologies or simply love their old nostalgic devices. Another risk that we might face is scope creep, where we may try to add more features and functions to the game that are not initially in our plan. It is a problem that some projects might have because of careless preparation and planning; hence, we could avoid that by setting our scope, aims, and goals clearly at the start of the project. Lastly, due to the limited time for the project, we might not have enough time to playtest the game, which can result in poor game balance and many bugs in the final product submitted for the assignment.
There are a few risks associated with the development of our team’s GitHub website. To begin with, the website can run slowly and have low performance. Furthermore, we might not be able to upload the game onto a page of our website if our game’s source code is somehow not compatible with the website platform.
And the last and most challenging risk is that we cannot request authorization from the school to implement the game into the campus’ network. Even though it is reasonable due to security problems, having the game as an RMIT’s artefact to lift students’ mood during bad Internet connection times is what the project is also about.
5. Group process and communications
Regarding our group communication, we will have an in-person weekly group meeting every Thursday or Wednesday outside of lecture and tutorial sessions to discuss our project, ask questions, and plan what we will do for the project in the following week. If some members could not attend the meeting, we will text them the main points of the meeting and their tasks. We will also update our weekly progress in a Google Docs file every Friday. Furthermore, if some urgent issues or problems come up, we can text or call each other on our Messenger group chat, or we can have a face-to-face meeting on Monday. Lastly, if a member does not respond to our messages or attend our weekly meetings, we will apply our three-warnings system. This member will first receive a personal warning from our team leader or another member of the group, and if they repeat it for the second time, there will be a warning on the group chat. If this incident still occurs after two warnings, our group will raise this issue with our lecturer.