• Due date: 2nd of October (Sunday) 2022, 11:59pm NOTE THAT THIS IS A WEEK MORE THAN CLASS SUMMARY
  • Assignment Weighting: 20% of total grade
  • Starting the assignment: See the instructions
  • Submission: Submit your code through GitLab - See further instructions below
  • Group Assignment 2 FAQ: See the FAQ for this assignment
  • Policies: For late policies, plagiarism policies, etc see the policies page
  • Changelog: For any changes to the assignment sheet, see the changelog.

Group Assignment 2: Adding Features [100 MARKS]

Very carefully read through the entire document before starting. Tasks will depend on previous tasks and tie in with each other. You should also take a look at the assignment FAQ.

For this group assignment, each group will be required to develop a simple text-based role-playing roguelike game (RPG) in Java 1. The game should include some sort of a game engine and a way to automatically test the game.

A Graphical User Interface (GUI)#

Your game does not need to have a graphical user interface (GUI), in fact, this is an optional extension task ONLY.

If you are in a group of 6 or more members a GUI is required. See Optional Task 0.2 for more details.

The goal of this assignment is not on the actual game itself. Instead, the focus is on how you, as a team, work to organise, plan, and work together to produce the game using the software engineering principles, practices and theory taught in this course and apply it in a practical project.

Some examples or inspiration can be found here, be creative:

There are three major components that should be added to the game.

Game Engine#

Game designers should be able to customize various game settings and environments, such as game levels, maps, stories, plots, etc, by editing suitable files such as JSON/YML game configuration files. It is up to you how you want to go about creating the game engine that runs the game. You will need to detail why you approached it the way you did, and how it works.

The game engine can generate an RPG game from the game configuration files. For example, in a treasure hunting game, game designers can customize the game maps, levels, items, etc in the configuration files.

An existing Java game engine can be used (to handle the heavy-lifting computation) if you do not wish to create one and it is still customisable via files like JSON/YML. As long as any instructions required to install, setup and run the game are provided and documented on the Wiki in Activity 3. You should show evidence of how you selected the game engine (what else did you consider?), and any steps you took to implement/integrate it into your game/game design. You can also do this if your group wishes to focus more on the actual gameplay, graphics, adding additional features etc. See Changelog - Change 2.

Automatic Game Tester#

The game tester can generate suitable user input test cases to test the game from the game configuration files in the game design stage. The game tester should also run the game automatically and output the testing results to game designers. For example, in a treasure hunting game, the game tester should generate test cases in terms of player movements in a maze to test if there are errors in the game plot, generate test inputs or validate any other aspect of the game.

The Game#

You should also design an exciting playable RPG to showcase the abilities of your game engine and game tester. Remember, the goal of this assignment is not the game itself, but rather how you went about creating the game.

While the code itself will not be directly marked, code quality and best practices will be. See Tutorial 3 - Code Critique and the Software Engineering @ Google Book for more information on code quality and best practices.

Game Requirements#

  • You should use Java Version 18, i.e. OpenJDK 18. If you or your group need to use the lab computers, keep in mind they only have JDK 17 installed, this is fine, just make sure to note it down for the tutor marking. See Changelog - Change 7.

Activity 0 - Creating a Game Skeleton [10/100 MARKS]#

You are required to create the base game in Java that you will build on top of for the rest of the assignment. You will have creative freedom in creating this game and additional features in later tasks, provided it contains the following features.

Task 0.1 - The Game#

The game you create MUST include the following features:

  • A text based maze or some other kind of map/level that a character(s), enemies and anything else you want to include can interact with the player(s) and each other.
    • The maze or level must allow the player to have some basic movement/actions:
      1. Movement - Left, Right, Forward, and Backwards. If you plan on having a multi-layered maze or level you could add in Up and Down movements.
      2. One type of basic interaction with enemies or Non-Player Characters (NPCs). For example:
        • Fight
        • Talk
        • Move
    • Have some basic text. For example:
      • Text when interacting with NPCs or enemies
      • Tooltips/information
      • A storyline/plot
    • A basic inventory system

Be creative, and have fun with what you make! You can always come back and change aspects of the game. In fact, this would show that you have engaged in multiple Agile-like sprints. Keep a history of how your game evolves over time by editing the Wiki in Activity 3. You can list any notes from meetings/discussions, user stories, features, what you changed/added/removed etc.

Task 0.2 - Graphical User Inteface (GUI)#

If you have a group size of 5 or less this is an optional extension task is NOT required nor will it grant you any additional marks. If you are in a group of 6 or more members at least a basic GUI is required.

If you determine that it is within the reach of your group to add a graphical user interface (GUI) using something like JavaFX you may do so to complement and/or extend the game you are required to create for Task 0.1. Your GUI may also choose to implement it purely in the terminal, as seen in some of the provided games for inspiration if you do not wish to use JavaFX. Remember, the focus of the assignment is not on the game itself. While working on this task, you should remember to record your history and document your progress in the Wiki - Activity 3 as you work through it as a group.

Activity 1 - Project Planning [30/100 MARKS]#

Task 1.1 - User Stories [10/30 MARKS]#

For this task, you are required to create fine-grained (detailed), INVEST-appropriate, template-abiding user stories for the following features.

For a group of 4 members#

  • Movement
  • Maze/Map/Level
  • Enemies
  • Inventory system

For a group of 5 members#

  • All the features required for a group of 4 members
  • Saving and loading the game
    • Can also include saving/loading from multiple saves

For a group of 6 members#

Additional Features#

You must also identify as many additional features as there are members in your group (e.g. A group of 5 should identify 5 additional features) that have not been already identified.

Be creative when coming up with features!

How to present these features: You will have to write your selected features as fine-grained (detailed), INVEST-appropriate, template-abiding user stories. Present these along with the estimated time to complete them; prioritise these user stories. List these within the Activity_1_User_Stories.md file located within your repository.

Take a look at the Lecture slides.

Task 1.2 - Planning the Work [20/30 MARKS]#

Given all the features identified from Task 1.1 refine them into tasks and establish any pre-requisites for implementation that you consider essential.

You MUST show good history of work, this means that you should convert each created task into an issue in GitLab and assign them to people as they work on them. You will lose marks if history of work cannot be verified or followed. There should be history of work throughout the duration of the assignment.

You MUST roughly schedule when you want tasks/issues completed by, you should roughly schedule by when you want stages done, who will be assigned what. Add this to your wiki as seen in Activity 3.

Some things you could also consider when planning include:

  • Feature vs Trunk based development?
  • Will you use Agile, or something else?
  • PBIs?

e.g.

  • Student X is going to work on implementing the game maze/map by X week or date
  • Student Y is going to get a basic GUI working by X week

Take a look at the Lecture slides.

You should aim to at least have a rough plan, and some rough user stories completed during the Week 6 Tutorial, where you MUST show your tutor.

Activity 2 - Project Work, Git/Repository History, and Code Style [40/100 MARKS]#

Implement, refine, add, change, and work on Activity 0 and Activity 1 following the best practices.

This activity will be assessed by looking at how you work as a team, your Git use, and code style. The project as a whole will be assessed.

You should read and understand the following. Ask your tutor, and/or post on Piazza if you want any clarifications.

Remember, from Activity 0 and Activity 1, project planning and analysis of what is possible is a vital skill. Make sure that you do not go overboard and bite off more than you can chew, resulting in a wildly unfinished game.

That being said, while the game itself will not be marked, your progress over the duration of the assignment, with respect to your group size will be taken into consideration.

As long as your game includes at least the basic features that you had to create in Activity 0, any additional features or additions do not need to be fully completed. You can write about what was not yet finished or implemented in the Wiki in Activity 3.

However, the game you submit MUST compile and run without errors. There should be consistent history of work throughout the duration of the assignment.

Add any addtional files or directories to the provided skeleton .gitignore file.

Good project history includes:

  • You have shown you have tried to adhere to the plan created in Activity 1 - Task 1.2
  • You have shown you have assigned tasks to group members
  • Issues are opened and closed as appropriate
  • You have good git repo history (commits, PRs, merges, etc)
  • Shown good code review of group member PRs
    • Evidence of working through PRs
  • You follow the code quality styles.

Branches are not required for small-scale changes, such as things like adding or modifying the Activity_1_User_Stories.md file, modifying the SoO, or other miscellaneous changes. We are primarily concerned about how your group works together using Git to implement and work on the game and add features. See Changelog - Change 3.

See Changelog - Change 5 and 6 for clarification on branches asked on Piazza.

You will have a second project check in with your tutor in the Week 7 Tutorial after the teaching break regarding your progress overall.

Activity 3 - Project Documentation, JavaDocs and Testing [20/100 MARKS]#

Task 3.1 - Project Documentation [8/20 MARKS]#

You must create a GitLab Wiki within your repository. Here, you must detail any and all instructions, dependencies, and/or steps needed to build, run, and test your game.

The wiki also serves as documentation of your game:

  • Project summary
    • List of features in your game, game engine, and game tester with examples and screenshots
    • Description of your game
    • Anything you planned to do but didn’t have time to implement
    • Any additional notes or information about the game/your process
  • Shown evidence of planning and scheduling of tasks/issues
  • You can also document meeting minutes, a team structure/roles, etc
  • You must also have an installation and setup section detailing exactly what dependencies (if any), steps, or any other process(es) required to build, run, and test your game which will be followed by the tutor marking your assignment.

Reflection#

See Changelog - Change 10.

From feedback and concerns from a number of groups, you can choose to add a Reflection section to your wiki. We understand that many of you/members of your group may not have had much real-world experience working with a project/Git before. Understanding where/how you/your group made mistakes, how you could improve, and learn from these is a vital skill.

If your group is concerned about Git, or anything else in your repository (i.e. branch usage, commit messages, etc), or things that cannot be easily changed/corrected. You can highlight these issues within this reflection section. You MUST be very specific about what you are concerned about.

  • Provide a handful of examples for each concern
  • Explain why you are concerned
  • What you think the issue(s) are
  • How you think it could be fixed and mitigated in the future

Your reflection will then be taken into consideration by the marker when they are looking through your assignment.

Adding/raising a large number of issues to your reflection, purposely misusing Git or other processes because of the addition of this section, not properly following instructions within this document, poor code quality, or any other issues that are able to be corrected within your repository will be detrimental to your reflection when taken into consideration by the marker.

Task 3.1.1 - Project License#

Discuss and choose what kind of license you want to add to the project by creating a LICENSE.md file. Justify why you chose this license in the wiki in Activity 3.

Take a look at things like:

Task 3.2 - JavaDocs [6/20 MARKS]#

Any functions or code should have a corresponding JavaDoc comment. See the following for JavaDoc syntax and other examples:

A JavaDoc must contain at least:

  • A short description of the class/method/field/etc.
  • @author - The author. If multiple authors add another line, i.e 
      @author Alex Potanin
  @author Brian Schmidt
  • @param A parameter that the method or constructor accepts 
      @param trueValue the value to match for
  @param falseValue the value not to match for
  • @return What the method returns 
      @return true if the value matches the trueValue, false otherwise

/**
<Description>

@author Alex Potanin
@author Brian Schmidt

@param trueValue the value to match for
@param falseValue the value not to match for

@return true if the value matches the trueValue, false otherwise
*/

Add anything else you think is relevant to the JavaDoc. See Changelog - Change 4.

Task 3.3 - Testing [6/20 MARKS]#

You should aim to have as high a code coverage percentage as possible using Java JUnit tests. Plugins such as the one for IntelliJ IDEA are good examples of tools which help you verify the extent to which your code is covered by unit tests. If you feel up to the task, you can optionally setup CI/CD in your repository to automatically run all of your test cases every time a commit is made to the main (master) branch.

Your automatic game tester will also be used to test your game, and the tutor marking will also have a go at playing it. Examples of a game tester could include:

  • Passing commands to the game and expecting to end up in a specific state
  • Performing certain actions and expecting specific actions to have occured or end up in a specific state
  • Using it to verify gameplay logic, i.e. can it walk through walls or perform illegal actions. Add a page about running the tester, what it does, does it do what you expect?

Activity 4 for COMP6120 Students ONLY#

You will need to submit through Wattle an individual essay of around 1000 words that will be worth 25% of your mark for this Group Assignment (the other 75% will be as per the above instructions - the same as the COMP2120 students). Your submission must be in PDF format.

UPDATED: Instead of 10% it is now 25% of your mark and you are allowed to write up to 1500 words if it helps but 1000 words is the expectation. Please note that to be fair to those of you who planned on the 10%, I will pick the better of the two grades: 10% for Essay and 90% for Group versus 25% for Essay and 75% for Group.

In this short essay we want you to reflect on the process of modernising old applications and the question of long term maintenance of projects. After all, the number 6 (out of 10) security vulnerability category according to the OWASP Top 10 for 2021 is Vulnerable and Outdated Components.

Also, reflect on what lessons can you learn for any future development projects you will produce in the world where the other components quickly become obsolete despite many other projects depending on them.

Start by reading the following two recent research papers on using the out of date API’s and detecting such cases when developing Android Apps:

If you have trouble accessing the PDF - try to do it via the ANU library web site.

Check out ANU Academic Skills

Setup and Preliminary Instructions#

Very carefully read through the entire document before starting. Tasks will depend on previous tasks and tie in with each other. You should also take a look at the assignment FAQ.

Before starting the assignment, a single team member should fork the assignment repository from GitLab. You should also ensure:

  • All team members should be granted maintainer rights in the repository.

After you have forked the repository, you can then clone it to your local machine, git clone <repository-url>

Submission Instructions#

  1. You will need to submit your code through GitLab. Your last commit before the due date will be what is marked.

  2. You will also be required to submit a group and individual reflection via a Wattle Quiz. This is anonymous to your group members and should be used to honestly evalulate the performance and contribution of every group member. This group reflection will be taken into consideration when marking and individual marks may be adjusted accordingly as required. Your group size will also be taken into consideration. See also FAQ: Contribution.

  3. Fill in the Statement of Originality within the repository confirming that any work you contributed and submitted was your own. See Statement of Originality for more details on how to fill it in. Signing this is required for marks to be awarded.
  4. COMP6120 Students ONLY - See Activity 4

Submission Checklist#

  • Read the assignment sheet properly and fully
  • Have forked and added your team members to your repository. See Changelog - Change 1.
    • Checked in with your tutor in the Week 6 Tutorial regarding Activity 1
    • Checked in with your tutor for the second check in during your Week 7 Tutorial regarding your progress overall
  • Have committed and pushed before the due date. Last commit will be marked.
  • The game you submit MUST compile and run without errors
  • Have at least a basic skeleton from Activity 0
  • Created appropriate user stories for features and issues have been created Activity 1
  • Have good history of work within the GitLab repository
    • Shown planning of stages and allocation of work to group members
      • You can list roles and responsibilities for each member of the team within the Wiki
    • Shown you have tried to follow and adhere to the schedule you created in Activity 1
    • Use of Git and other relevant features
    • Shown good code review of group member PRs
  • Follows good code quality styles and other best practices
  • At least a basic GUI if you are a group of 6 or if you have chosen to create and add one
  • Follow good best practices as detailed in Activity 2 throughout the duration of the project
  • A wiki, JavaDocs, tests and a tester with the requirements listed in Activity 3
    • Have justified any design choices you made and/or anything else you think is relevant.
  • A license for your project Activity 3.1.1
  • COMP6120 - Completed Activity 4
  • Filled in the Statement of Originality file. Signing this is required for marks to be awarded.
  • Submitted the group and individual reflection Wattle Quiz

FAQ#

Will my submission be run though plagiarism detection software?#

Yes. See Academic Integrity

How should we allocate or split up work?#

There is no one-size-fits-all answer here. As long as everyone in your group is happy with how the work is split up, that should be a good indication that you are probably doing something right.

My group member(s) aren’t contributing/There are issues with my group/I feel like I am doing everything.#

If you feel like your group members aren’t contributing or you are “doing everything”, talk to your group about it if it is something you feel comfortable doing.

Let your tutor and Alex know as soon as possible if any issues arise. The earlier the better. Letting your tutor know early on means they can try and help resolve the situation.

Remember, you also have the opportunity to honestly reflect and evaluate the performance and contribution of every group member. Your individual mark will be calculated based on a number of factors, including, but not necessarily limited to things like: contribution, history of work, the Wattle individual and group reflection.

Trying to “game” the system by artifically inflating things like number of pull requests or issues opened/closed will not work.

I need help#

If you need help, ask your tutor, or post on Piazza. Also check Piazza or this FAQ for common questions over the course of the assignment.

What kind of Branches/PR usage is required?#

See Change 3.

Branches in Development#

See Piazza @156.

Opening branches from open issues.#

See Piazza @161.

Changelog#

Change 1#

Removed the need to add tutor to the assignment repository.

Change 2#

An existing Java game engine can be used (to handle the heavy-lifting computation) if you do not wish to create one and it is still customisable via files like JSON/YML. As long as any instructions required to install, setup and run the game are provided and documented on the Wiki in Activity 3. You should show evidence of how you selected the game engine (what else did you consider?), and any steps you took to implement/integrate it into your game/game design. You can also do this if your group wishes to focus more on the actual gameplay, graphics, adding additional features etc.

Change 3#

Branches/PRs are not required for small-scale changes, such as things like adding or modifying the Activity_1_User_Stories.md file, modifying the SoO, or other miscellaneous changes. We are primarily concerned about how your group works together using Git to implement and work on the game and add features in Activity 2.

Change 4#

Clarified what is needed in a JavaDoc. A JavaDoc must contain at least:

  • A short description of the class/method/field/etc.
  • @author - The author. If multiple authors add another line, i.e 
      @author Alex Potanin
  @author Brian Schmidt
  • @param A parameter that the method or constructor accepts 
      @param trueValue the value to match for
  @param falseValue the value not to match for
  • @return What the method returns 
      @return true if the value matches the trueValue, false otherwise

/**
<Description>

@author Alex Potanin
@author Brian Schmidt

@param trueValue the value to match for
@param falseValue the value not to match for

@return true if the value matches the trueValue, false otherwise
*/

Add anything else you think is relevant to the JavaDoc.

Change 5#

Added good question from Piazza @156 to FAQ.

Change 6#

Clarified you can remove the fork dependency from a project to be able to create a branch from an open issue to FAQ.

Change 7#

Amended to allow for JDK 17 if using lab computers. JDK 18 served only for consistency for marking. Just make sure to note it down within the wiki for the tutor marking.

Change 8#

Amended the COMP6120 marking weight to 25% instead of 10% as per this Piazza Post.

Change 9#

Updated scaling formula for assignment.

Change 10#

Added clarification for groups who have had issues/problems/inconsistencies in their Git history/usage.

  1. Project inspired by old COMP2100 group assignment. ↩

bars search times arrow-up