Deliverables

Note: all deliverable deadlines are in Canberra time using a 24-hour clock.

All assignment deliverables must be submitted with a completed originality statement (see details below). Any deliverable that does not include a completed originality statement will not be marked. For assignment 2, you must adhere to the structural requirements for your Git repository.

D1A: Assignment 1 (5 Marks, Individual)#

Assignment 1 will be made available on Monday of week 2.

Assignment 1 is due 09:00 on Tuesday of week 4, 12th of March 2024.

Please remember that tutors and lecturers will not be available to answer questions on weekends and holidays.

You must edit, commit, and push the following to your GitLab repository before the deadline:

D1A checklist#

Please check that you have done the following before you submit.

• Read and understand the statement on academic integrity.
• Read and understand the statement on deadlines.
• 24 hours before the deadline, do an upstream pull of the assignment.
• 24 hours before the deadline, confirm that your assignment includes a complete and truthful originality statement.
• Push all code to GitLab and confirm that CI tests pass for the tasks you have completed. You will be marked according to the results of the CI tests.
• After you commit and push your final changes confirm that you’ve followed the statement on academic integrity, that you have correctly completed the originality statement, that you have pushed all your work to GitLab, and that the CI result for your last push is what you expect. If things go badly wrong and you end up breaking things right at the deadline, there will be no extension. However, if you made good use of Git and you have a previous commit that works (even if not fully), you may send a private ed post to your tutor and me, asking for your assignment to be marked using that commit.

Evaluation for Assignment 1#

Partial marks may be awarded for some criteria.

D2A: Assignment 2, Stage A (1 Mark, Group)#

Due in your scheduled lab, Week 4.

The same mark will be awarded to all group members.

The main objective of this first stage is to meet your group and create your group repo. Your group will have two or three members, selected at random from your lab group. Your tutor will let you know the members of your group.

Meet your group members and get to know them a little by asking some basic questions. The following might help you get started.

• What degree are you doing?
• Did you do much computing before coming to ANU?
• Where did you grow up?
• Where does your family live?
• What do you think you want to do in your future career?

Once you have met your group members, you should do the following:

• Find out your assigned group name by asking your tutor. It should be something like tue08a1, where the first six characters indicate your lab tutor group, and the last character identifies your assignment 2 project group within that.
• One (and only one) member of your group must fork the assignment repo.
• Use GitLab to add a description to the forked project which contains your unique group name. Go to Settings -> General, then under Naming, topics, avatar add to Project description your group name, e.g., tue08a1, thu16c3, etc… Your group name should be the only text in the field and should be displayed exactly as given by your tutor, including preserving all lower case.
• Add all group members to your group’s repo as ‘maintainers’ (use the ‘Members’ tab at bottom left of GitLab page, then ‘Add members’).

NOTE: From this point on, no group member should fork any version of the assignment 2 repo, even the fork just produced. All members should push, pull and clone exclusively from the fork just produced. This means that the URL all members work on should be https://gitlab.cecs.anu.edu.au/<Above_Members_UID>/comp1110-ass2.git.

• To help identify your group’s repository and distinguish it from other versions (including the class assignment repository), you may wish to set an avatar. Underneath where you set the project description, for Project avatar select ‘Choose file…’ and upload an appropriate image to identify your repository.
• Verify your repo description and membership with your tutor before continuing.
• Each person should clone your group’s repo using IntelliJ.
• Assign tasks within the group. The design of the system should be shared by all members, and every member of the group should write some code. Record this in your admin/tasks.md file.
• Exchange contact information. Record this in admin/members.yml (for each member add “contact: ").
• Arrange a weekly meeting time (this should be outside your normal lab time). Record your meeting time at the top of your tasks.md file.

Be sure that you complete each of the above and have your tutor check it off before you finish your week 4 lab.

All files for all deliverables in Assignment 2 must be committed and pushed to the main branch of your group repository. Files in other branches of the repository may not be marked unless your tutor has specifically agreed to consider these in marking.

Evaluation for Stage A#

DXC: Basic Competency Hurdle Assessment#

Assessed in your scheduled lab, Week 5.

In your lab you will be assessed to determine whether you have achieved a level of basic competency in the course. You will need to be able to demonstrate to your tutor that you can write a basic program that covers material from units J1, J2, J3, J4, J5, J6, J7, and O1. Because this is a hurdle assessment, failure of this assessment will automatically mean failure of the course.

If you achieve a mark of 50% or better in the lab test, you are automatically exempt from this hurdle assessment.

D2B: Assignment 2, Stage B (1 Mark, Group)#

Complete this assessment before your scheduled lab in Week 5.

Marks will be distributed according to the relative contribution of each group member as documented in B-contribution.yml.

Required Files for Stage B#

All parts of this assignment must be submitted via GitLab.

This deliverable is the design of your game, which will be manifest two ways:

• A pdf file containing a sketch of your design, admin/B-design.pdf
• A design skeleton consisting of one or more Java classes, with key field and method declarations, but without any method implementation.

To deliver this, you need to think carefully about how you will build your solution. The design sketch is exactly that – it will be a diagram, prepared using which ever tools you want (it’s perfectly fine to draw it on paper and photograph it). The diagram should indicate how the major elements of your game will fit together. You are free to use whatever notation you feel works. The goal is to capture your group’s design in a simple diagram. You must also submit the skeleton of what you plan to build. This means deciding on what classes you think you’ll need and what fields and methods you will most likely want, and brief JavaDoc outlining their purpose.
You need to create those classes, fields and methods, and give them some documentation. However, the methods need not have an implementation in them. You are merely submitting a skeleton (not working code!). Your classes and pdf must be pushed to GitLab by the deadline.
Your tutors will assess how well your design captures the key concepts and functionality required for the game. It is perfectly OK to change your design later in the semester. The goal here is to demonstrate that you’ve carefully considered the design before you’ve started coding.

You will find a template version of each of the administrative files within your group repository, which you should all be able to access (there is no B-design.pdf file – you will need to create that and add that).

You must edit each of the relevant admin files, ensuring that they are filled in correctly, before committing and pushing the changes.

Evaluation for Stage B#

In this stage you need to have generated a sketch/skeleton version of your game which reflects your intended design of the game.

D2C: Assignment 2, Stage C (6 Marks, Group)#

Due 17:00 Friday, Week 1 of Mid-Semester Teaching Break, 5th of April 2024

Marks will be distributed according to the relative contribution of each group member as documented in C-contribution.yml.

Required Files for Stage C#

All relevant class files and assets must be pushed to GitLab.

You must edit each of the files, ensuring that they are filled in correctly, before committing and pushing the changes.

Your statements of best code should simply indicate which code the given group member is most proud of.

A convenient way to list your best code is to provide a gitlab link. To do this, navigate to your group’s repo on gitlab, find the file containing the code you wish to highlight, click on the line number of the first line of your code (eg 38 in the example below), then shift-click on the last line of your code (eg 40 in the example below), and then you should find a URL in the browser navigation bar that captures this information. Open a new browser tab and paste in the URL, and be sure that the code you wish to indicate is correctly highlighted. Once it is correctly highlighted, paste the URL in your best code yaml file. For example, the highlighted code below, for the method isGameStringWellFormed() generates the following URL: https://gitlab.cecs.anu.edu.au/comp1110/comp1110-ass2/-/blob/main/src/comp1110/ass2/RaceToTheRaft.java#L38-40 (notice that this URL is for the class repo, not yours, and notice the line numbers encoded at the end of the URL).

Evaluation for Stage C#

This completes part one of the game.

D2D: Assignment 2, Stage D (2 Marks)#

There are two elements to this deliverable, a group component and an individual component.

Both components should be completed before your scheduled lab in Week 8 and will be assessed by your tutor in the lab.

The purpose of this deliverable is to ensure that each group is making plans for how to test all important parts of their project.

D2D Unit Test (1 Mark, Individual)#

Required Files for Stage D - Individual#

Each group member must demonstrate a good unit test that they authored. They must upload the following to the group repository before their scheduled lab.

Evaluation for Stage D - Individual#

You must show your tutor working JUnit tests that you created. You should write the unit test for code that you developed yourself. However, if the original code you develop is JavaFX code, you may write tests for other code within your project, providing that: a) you have the agreement of your group members, and b) the code you write the test for does not already have sufficient tests. (The reason for this exception is that it is difficult to write JUnit tests for JavaFX code.)

D2D Test Plan (1 Mark, Group)#

Required Files for Stage D - Group#

The group must edit, commit, and push the following to the group repository before their scheduled lab.

Evaluation for Stage D - Group#

The purpose of test planning is for the group to identify which components of your game should be unit-tested. The test plan is a simple document, which should:

• List the classes in your implemented design that should have some unit testing.
• Within each class, list methods that can be tested in isolation.
• For each class, if there are conditions on the class’ behaviour that cannot be tested by calling one method in isolation, give at least one example of a test for such a condition. A very simple example could be something like “After calling add(...), the number returned by size() has increased by 1.”

Do not include in your test plan the predefined static methods for which we have already provided unit tests.

You do not have to implement the tests at this point. However, implementation of appropriate unit tests is one of the critera that will be evaluated in the your final code submission (D2F).

If your implemented design does not have any classes or methods that can be tested, other than the predefined ones, then it is not a good design, and your group will not be eligible for the marks associated with this deliverable.

D2E: Assignment 2, Stage E (2 Marks)#

There are two elements to this deliverable, a group component and an individual component.

Both components should be completed before your scheduled lab in Week 9 and will be assessed by your tutor in the lab.

D2E Group Integration (1 Marks, Group)#

Marks for this part of the deliverable will be distributed according to the relative contribution of each group member as documented in E-contribution.yml.

Required Files for Stage E - Group Integration#

The group must edit, commit, and push the following to the group repository by the deadline.

Evaluation for Stage E - Group Integration#

This week you must demonstrate that all of the classes work together. You should package your program as a JAR file called game.jar.

Note - getting your program working as a JAR file can sometimes be tricky, particularly getting the images loading properly, so make certain you work this out plenty of time before the lab time. You should be able to do so using the following steps:

1. Select File->Project Structure.
2. Select “Artifacts”
3. Add a JAR: “+” -> JAR -> From modules with dependencies…
4. Select the “Main class” to be your Game class, and ensure “extract to target JAR” is selected
5. Ensure the “Directory for META-INF/MANIFEST.MF” is set to your src subdirectory.
6. Press “OK”
7. Changed the “Name” to game.
8. Ensure the “Output directory” is the subdirectory out/artifacts/game relative to the project root.
9. Check the “Include in project build” checkbox.
10. Change the file name by selecting the JAR at middle of window, under “Output layout”, and right click, “Rename”, then type game.jar
11. Press “OK”
12. Build game JAR: Build -> Build Artifacts…, select build.
13. Use git to commit the .idea/artifacts/game.xml and src/META-INF/MANIFEST.MF files (do not include “out/artifacts/game/game.jar” in version control).

Your JAR should now be visible under out/artifacts/game/game.jar. Note, don’t commit this to version control, it will be reconstructed each time your project is built. Ensure that you can run the JAR external to intellij, e.g., from the command line within the root of your project directory run:

java --module-path ${PATH_TO_FX} --add-modules=javafx.controls,javafx.fxml,javafx.media -jar out/artifacts/game/game.jar

Your game should run, creating a new window.

If you run into troubles with these steps, you can start over by doing steps 1 and 2 and then using the “-“ sign to delete the artifact. Also see IntelliJ documentation on how to build a JAR.

D2E Code Review (1 Mark, Individual)#

Each group member will be assessed separately for this part of the deliverable.

Required Files for Stage E - Individual Code Review#

Each group member must upload the following to the group repository prior to their scheduled lab.

Each member of the group must review a substantial (>20 lines) contribution from another member. Reviewers must be assigned in a round-robin fashion, i.e. for a group of three, author A reviews a contribution of author B, author B reviews a contribution from author C, and author C reviews a contribution from author A. If you do not have any code to review because your teammates have not contributed to the assignment, contact the lecturer who will provide some alternative code to review.

See lecture S05 for an overview of code review. Your review should at least address the following questions:

• What are the best features of this code?
• Is the code well-documented?
• Is the program decomposition (class and method structure) appropriate?
• Does it follow Java code conventions (for example, are methods and variables properly named), and is the style consistent throughout?
• If you suspect an error in the code, suggest a particular situation in which the program will not function correctly.

Evaluation for Stage E - Individual Code Review#

D2F: Assignment 2, Stage F (21 Marks, Group)#

Due 17:00 Thursday Week 11, 16th of May 2024.

This is the major deliverable. Aside from the demo and presentation, all elements of the assignment will be assessed.

Marks will be distributed according to the relative contribution of each group member as documented in admin/F-contribution.yml.

A snapshot of your group’s Git repository will be taken at the deadline. It is essential that you strictly follow the instructions on the structure of your Git repository and the list of required files below. Files that are misnamed or are not included in the stipulated location may not be marked.

It is your responsibility to check that the version of your system in Git at the deadline is working correctly.

Required Files for Stage F#

Your statements of best code should simply indicate which code the given group member is most proud of.

Evaluation for Stage F#

As always, penalties may apply on an individual basis for violating core assumptions, e.g. for failing at teamwork or for exploiting the structure of our tests to pass them, insufficient documentation of originality (such as missing or inaccessible logs of interactions with generative AI), etc.

D2G: Assignment 2, Stage G (2 Marks, Group)#

Video due 17:00 Sunday Week 11, 19th of May 2024.

Presented in your scheduled lab, Week 12.

Marks will be distributed according to the relative contribution of each group member as documented in admin/contribution-G.yml.

Required Files for Stage G#

Evaluation for Stage G#

Each group is expected to give a 10 min demonstration of their project (5 minutes for a presentation video and 5 minutes for a few questions). In this demonstration, you should: explain the problem you looked at, run a demonstration of your program, describe your design approach, describe interesting aspects of your game.

Your presentation must be suitable for viewing on a 1280x720 screen, and must include the following:

• Names of all students who contributed.
• A summary of what you did.
• Screen shots of your game.

We will run the presentations in the regular lab session. Each team must record a video presentation that your tutor can show during the session. Every member of the team should contribute to preparing the video. (You can choose one member to speak.)

One member of your group should upload the file to OneDrive:

• Select “Share the selected item with other people”
• Change the sharing settings from “Anyone with the link can edit” to “People in Australian National University with the link” and uncheck “Allow editing”
• Select “Copy Link” and record the link in the file G-presentation.yml

You should attend your regular lab session to view others’ presentations and answer questions on your own presentation. You will be marked both on the quality of the presentation and on your answers to questions during the lab.

Late or no video submission#

If your group fails to submit a video by the deadline, you can still prepare a video to be shown in your lab, or do a short live demonstration of your game. (Remember, 5 minutes max!) However, you will only be marked for your ability to answer questions.

Required Structure For Your Git Repository for Assignment 2#

For the most part, the details of how you manage your repository are up to you. However, you must observe the following requirements strictly:

• You must have a folder called admin in your base directory (not “Admin” or any other variation). This folder should have been in your repository since the beginning.
• Your admin folder must contain each of the files listed in the deliverables above, using exactly the file names specified. These should have been in your repository since the beginning (although you must fill in the details).
• Your admin folder should not have any sub-folders in it.
• In the above, when the file name says something like best-<uid>.yml, if your UID was u2345678, then your file should be called best-u2345678.yml.
• You must have a build artifact setup to create a working out/artifacts/game/game.jar file automatically when your project is built (see D2E instructions).
• All of your source code must be in the repository (IntelliJ will put it in a folder called src).