Group Assignment 2: Adding Features [100 MARKS]

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 as well as testing (e.g. JUnit).

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 repository in GitLab. The repository is https://gitlab.cecs.anu.edu.au/comp2120/comp2120-assignment-3-workshop-xx-group-x.

You should also ensure:

  • Your repository will need to be named COMP2120-Assignment3-Workshop-<WORKSHOP NUMBER HERE>-Group-<GROUP LETTER HERE>. For example, for Workshop-01-Group-A, it would be COMP2120-Assignment3-Workshop-01-Group-A.
    • When forking, make sure to name both the Project name correctly, as well as setting the Visibility level to Private. NOT INTERNAL, otherwise other students would be able to see your repository.
  • All team members must be granted maintainer rights in the repository.
  • You MUST also add your tutor to the repository as a maintainer for marking. Failure to do so will result in loss of marks.

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. Only your last commit before the due date will be what is marked. Your tutor must also have been added to your repository to mark your git history, issues, PRs, Wiki, etc.

  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 evaluate 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.

    • Based on course feedback - See Scaling of marks for information on how your marks will be scaled based on this feedback.

A Graphical User Interface (GUI)#

Your game will need to have a graphical user interface (GUI). It does not need to use JavaFX or any other library, but rather can be implemented purely in the terminal. See the examples below for the types of basic GUIs that we would be looking for.

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

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

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.

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.

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. These can be hard coded tests to ensure logic changes do not break existing functionality, or randomised tests to ensure that the game is robust and can handle unexpected inputs.

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 5 - Code Critique and the Software Engineering @ Google Book for more information on code quality and best practices.

Game Requirements#

  • You should use Java Version 17, i.e. OpenJDK 17.

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.

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.

Something to take into consideration early on is Activity 4 and using Docker.

Activity 1 - Project Planning [28/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

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. For example, multiple difficulties or a tutorial.

Be creative when coming up with the additional 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 forked repository.

Take a look at the Lecture slides for INVEST principles.

Task 1.2 - Planning the Work [18/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 Ed 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.

Remember, while the game itself is not the main focus, 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. Marks will be deducted if it does not compile and run.

Make sure you have a .gitignore file. See also gitignore.io.

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 (unless you decide to do so). We are primarily concerned about how your group works together using Git to implement and work on the game and add features.

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#

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 [2/2 MARKS]#

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.

Task 3.3 - Testing [4/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. You MUST also 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 - Docker [2/2 MARKS]#

Task 4.1 - Dockerise [2/2 MARKS]#

You must create a Dockerfile to build and run your game. Using Java 17, and whatever build system you decided to use, if any (i.e. Maven or Gradle).

It is easiest if you install Docker desktop.

You must then also build your Docker image using your Dockerfile. You should then run your game using the Docker image you created.

Take a look at the CI and Docker Tutorial, and ask your tutor if you get stuck.

You can also take a look at this tutorial from Docker themselves, they also use Maven (for dependencies and build) and Java 17 - https://docs.docker.com/language/java/build-images/. There are also guides on running the container, running tests, and setting up CI/CD.

GitLab also has a docker CI template you can look at and modify with the official Docker tutorial steps. Go to CI/CD -> Editor -> Docker Template

Dockerising your game means that it is easier for yourselves, and others (i.e. your tutor) to build and run your game on any computer with Docker installed.

This would be especially useful if you use various libraries or other dependencies that may be difficult to install or setup, and you want to ensure that your game runs on your tutors computer correctly as well as during development by all group members. This was a major paint point in the past iteration of the course.

Besides, Docker is a very useful tool to know and use!

If you want to use the course provided CECC runner, make sure to include a comp2120 tag for each step/stage of your Docker file so the runner knows to pick it up.

tags:
  - comp2120

Example of how to tag a build stage. Yours will be different so don’t just blindly copy paste this as this is just an example.

build:
  tags:
    - comp2120
  stage: build
  script:
    - javac -encoding ISO-8859-1 $JAVAFX_OPTIONS -cp $CP src/comp2120/homework/*/*.java
  artifacts:
    paths:
      - src/comp2120/homework/*/*.class

Alternatively, you can also setup a CI runner for your repository https://gitlab.cecs.anu.edu.au/comp2120/comp2120-assignment-3-workshop-xx-group-x/-/settings/ci_cd if you want somewhat faster build times and don’t want to wait for shared runners to free up. However, you will need somewhere to install the runner (e.g. your laptop/PC/server somewhere).

Rough steps are:

  1. Install runner - https://docs.gitlab.com/runner/install/ as well as the details on the CI page above.
  2. Create runner - name it something meaningful, with your workshop and group name
  3. Register runner
  4. Enable runner for your project
  5. Create CI file with correct tags
  6. Link CI to docker build steps or however else you want to configure your CI (e.g. running tests etc)

Submission Checklist#

  • Read the assignment sheet properly and fully
  • Added your team members and tutor to your repository
  • Have forked and added your team members to your repository.
    • 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
  • 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
  • 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#

Can I use Github Copilot or ChatGPT?#

In line with the course policy, 2120 FAQ on Copilot or ChatGPT for code. However, it cannot be used to any writing components of the assignment, such as the wiki.

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.

For example, you may choose to allocate a Project Manager (PM) of sorts, to help delegate work and ensure everything is done on time. You may also choose to have a rotating PM, where each member takes turns being the PM for a week or so. It is up to your group, talk to your tutor if you are unsure or want some feedback.

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.

Members will be scaled via this formula https://comp.anu.edu.au/courses/comp2120/scaling based on group feedback provided in the Wattle Quiz.

I need help#

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

bars search times arrow-up