Deliverables

Del.	Deliverable	Week	Marks
D1A	A1: Assignment one (Friday 11:45)	3	5
DXC	Basic Competency Hurdle Assessment	4
D2A	A2: Organize groups, assign roles	4	1
D2B	A2: Analysis and design	5	1
DXM	Mid Semester Exam	6	5
D2C	A2: Completion of part one	6	2
D2D	A2: Individual code implementation	8	1
D2E	A2: Individual class and testing	9	4
D2F	A2: Integration demo and code review	10	3
D2G	A2: Final submission (Friday 11:45)	11	11
D2H	A2: Final demo and presentation	12	2

D1A: Assignment 1 (5 Marks, Individual)

Due 11:45 Friday Week 3, 15 March 2019 (time remaining).

Each student must edit, commit, and push the following to your student repository prior to the deadline:

File	Description
originality.md	Originality statement for Assignment 1.

D1A check-list

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

• Make sure that you completely understand the statement on academic integrity.
• Make sure that you completely understand the statement on deadlines.
• 24 hours before the deadline, check that your assignment works on the lab machines. If your assignment does not work on the lab machines, it will fail the tests.
• 24 hours before the deadline, check that your assignment has been pushed to GitLab (use the web browser to browse your project and see that your commits are visible).
• 24 hours before the deadline, check that your assignment includes a complete and truthful originality statement.
• 24 hours before the deadline, check that you did an upstream pull of the assignment.
• No later than half an hour before the deadline re-confirm that your assignment has been pushed, works on the lab machines, and that your originality statement is complete and truthful.
• 15 minutes before you finish re-confirm that you’ve followed the statement on academic integrity, that you’ve correctly completed the originality statement, and that all of your work has been pushed.

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, you should send a private Piazza post to your tutor and me, asking for your assignment to be marked using a previous commit that you did that works (even if not fully).

Evaluation for Assignment 1

Criteria for gaining 1 / 5

• You have forked the assignment one repository.
• Your originality statement has been edited, committed and pushed.

Criteria for gaining 1.5 / 5

• The previous criteria plus…
• The git log file reveals healthy use of Git (some useful advice here).
• Your edited classes compile correctly (the program runs, even if not correctly).

Criteria for gaining 2.5 / 5

• The previous criteria plus…
• Completion of the Pass-level requirements for Assignment 1

Criteria for gaining 3 / 5

• The previous criteria plus…
• Completion of the Credit-level requirements for Assignment 1
• All of your code is of high quality.

Criteria for gaining 3.5 / 5

• The previous criteria plus…
• Completion of the Distinction-level requirements for Assignment 1

Criteria for gaining 4.5 / 5

• The previous criteria plus…
• Completion of the High Distinction-level requirements for Assignment 1

Criteria for gaining 5 / 5

• The previous criteria plus…
• Your solution is outstanding in its design and implementation.

Partial marks may be awarded within these ranges for completion of individual tasks.

DXC: Basic Competency Hurdle Assessment

Assessed in your scheduled lab, Week 4.

In your lab in week four 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 10/20 or better in lab test 1, you will automatically be exempt from this hurdle assessment.

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 computer science before coming to ANU?
• Where did you grow up?
• Where does your family live?
• What do you think you want to do for your 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 tue12g (where the first five characters indicate the day and time of your lab (use 09, not 9 if your lab is 9am), and the letter is unique to your group, assigned by your tutor).
• One (and only one) member of your group must fork the assignment repo, and then use GitLab to rename the repo to comp1110-<1110|1140>-ass2-<group>, for example comp1110-ass2-tue12g, comp1110-ass2-wed09g, comp1140-ass2-thu09c, etc. (use ‘Settings’ at bottom left of GitLab page, expand the ‘Advanced’ section of the settings, then select ‘Rename repository -> Rename project’. Please be sure that you change both the Project name and the Path). Be sure that the name is precisely correct. See the screengrab below: 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 http://gitlab.cecs.anu.edu.au/<Above_Members_UID>/comp1110-ass2-<group_name>.git.
• If you did the above step correctly, you should find that your group name appears in the URL for the project.
• 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. ‘Select Settings’ -> ‘General’ then expand ‘General Project Settings’. In the ‘Project avatar’ section, select ‘Choose file…’ and upload an appropriate image to identify your repository.
• Add all group members to your group’s repo as ‘maintainers’ (use the ‘Members’ tab at bottom left of GitLab page, then ‘Add members’).
• Verify your repo name 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 is expected to write some code.
• Exchange contact information.
• Arrange a weekly meeting time (this should be one hour and outside your normal lab time).

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

Criteria for gaining 1/1

• Your group has forked the assignment repo, all members are maintainers. You have recorded: members, uids, roles, weekly meeting time, and contact details in the admin folder of your group repo.

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

Due at the start of your scheduled lab, Week 5.

Marks will be distributed to group members according to the distribution of effort among the group members as documented in B-contribution.md.

Required Files for Stage B

All parts of this assignment must be submitted via GitLab.

This deliverable is the design of your game. This means that you need to think carefully about how you think you will build your solution. You can plan this on paper, or however you like. However, what you need to submit is outline/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. You then need to create those classes, fields and methods, and give them some documentation. However, the methods do not need to have any useful code in them. You are merely submitting a skeleton (not a finished assignment!). Your implementation must be pushed to GitLab by the deadline. What your tutors will be assessing as they look at your submission is how carefully you’ve thought about the design of the game. It is important to realize that it is perfectly OK to change your design later in the semester. However, we want you to show that you’ve thought carefully about it already.

You should find a template version of each of the administrative files within your group repository, which you should all be able to access. To access your group repository, follow similar instructions as for your personal repository used in lab 1.

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

File	Description
admin/B-originality.md	Originality statement for Stage B.
admin/B-contribution.md	Contribution statement for Stage B.

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.

Criteria for gaining 0.25 / 1

• The required admin files have been correctly filled in, committed and pushed.

Criteria for gaining 0.5 / 1

• The previous criteria plus…
• The Git log or other material provides evidence of healthy teamwork.
• Your skeleton version of the game is appropriately designed.

Criteria for gaining .75 / 1

• The previous criteria plus…
• The skeleton version of the game has well-selected class, method and field names.
• Fields and methods are included in all of the classes.

Criteria for gaining 1 / 1

• The previous criteria plus…
• Your design is outstanding.

DXM: Mid-Semester Exam (5 Marks)

There will be a short mid-semester exam on Friday Week 6 at 18:15.

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

Due at the start of your scheduled lab, Week 6.

Marks will be distributed to group members according to the distribution of effort among the group members as documented in C-contribution.md.

Required Files for Stage C

The simple viewer you build for Part One of the assignment, including all class files, 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.

File	Description
admin/C-originality.md	Originality statement for Stage C.
admin/C-contribution.md	Contribution statement for Stage C.

Evaluation for Stage C

Criteria for gaining .5 / 2

• The required admin files have been correctly filled in, committed and pushed.
• The git log reveals healthy use of Git (some useful advice here).

Criteria for gaining 1 / 2

• The previous criteria plus…
• Completion of the Pass level requirements for Part One of the game.

Criteria for gaining 1.5 / 2

The previous criteria plus…

• Completion of the Distinction level requirements for Part One of the game.

Criteria for gaining 2 / 2

The previous criteria plus…

• The work is exceptional.

This completes Part One of the game. The remaining stages of the assignment are with respect to Part Two of the game.

D2D: Assignment 2, Stage D (1 Mark, Individual)

Due at the start of your lab, Week 8

Each group member will be assessed separately. Your code should be in your group repository, so that your tutor can see your code when they clone your repository. It should be clear from the Git log that you authored the code.

Required Files for Stage D

Each group member must edit, commit, and push the following to your group repository prior to the Week 8 lab.

File	Description
admin/D-originality-<uid>.md	Originality statements for Stage D, each student using their own uid.

Evaluation for Stage D

Each member of the group must show the tutor code that they have developed. You must select at least 10 new statements of original code that you developed for this stage. You must be able to explain your code to your tutor, justifying your programming decisions. Your tutor will give you feedback.

Criteria for gaining 0.5 / 1

• Your originality statement has been edited, committed and pushed.
• The git log reveals healthy use of Git (some useful advice here).
• The class must compile without any errors.

Criteria for gaining .75 / 1

• The previous criteria plus…
• It must be a reasonable implementation of what is required.

Criteria for gaining 1 / 1

• The previous criteria plus…
• Your work must be outstanding.

D2E: Assignment 2, Stage E (4 Marks, Individual)

Due at the start of your lab, Week 9

Each group member will be assessed separately.

Required Files for Stage E

Each group member must upload the following to the group repository prior to the Week 9 lab.

File	Description
admin/E-originality-<uid>.md	Originality statements for Stage E.

Evaluation for Stage E

Along with your working code you must show your tutor working JUnit tests that you created, which test your code. If the code you develop is JavaFX code, you may write tests for other code within your project, providing that: a) you have agreement of your group members, and b) the code you write the test for does not already have tests (the reason for this exception is that it is difficult to write JUnit tests for JavaFX code).

Criteria for gaining 1.5 / 4

• Your originality statement has been edited, committed and pushed.
• The git log reveals healthy use of Git (some useful advice here).
• Both the code and the tests compile.
• Your code provides a reasonable implementation of the aspect of the problem you are addressing.
• Your contribution comprises at least 20 statements of original code.

Criteria for gaining 2.5 / 4

• The previous criteria plus…
• The code includes a good test of the code you implemented (or if your tutor agrees, the test for some other code—see above).

Criteria for gaining 3 / 4

• The previous criteria plus…
• Your code is substantial and of a high quality (well designed, well documented).

Criteria for gaining 4 / 4

• The previous criteria plus…
• Your work is of an exceptionally high standard.

D2F: Assignment 2, Stage F (3 Marks)

Due at the start of your lab, Week 10

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

D2F Group Integration (2 Marks, Group)

Marks for this part of the deliverable will be distributed to group members according to the distribution of effort among the group members as documented in F-contribution.md.

Required Files for Stage F - Group Integration

The group must edit, commit, and push the following to the group repository prior to the Week 10 lab.

File	Description
admin/F-originality.md	Originality statement for Stage F.
admin/F-contribution.md	Contribution statement for Stage F.
All .java files	Complete source code for your assignment.
game.jar	A working executable JAR file for your game, in the base directory of your repository.

Evaluation for Stage F - 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. You should be able to run your code using:

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

or, on the lab machines, to ensure you use the correct version of Java, you may need to type:

/usr/local/jdk-11.0.2/bin/java --module-path ${PATH_TO_FX} --add-modules=javafx.controls,javafx.fxml,javafx.media -jar 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 Board class, and ensure “extract to target JAR” is selected
5. Change the output directory to be your project’s root directory, not the src directory or any other (you can click the “…” and navigate there)
6. Check the “Include in project build” checkbox.
7. Ensure that the “Output directory” field is the root of your project, not a subdirectory.
8. Change the file name by selecting the JAR at middle of window, under “Output layout”, and right click, “Rename”, then type “game.jar”
9. Press “OK”
10. Build game JAR: Build -> Build Artifacts…, select build.

Your JAR should now be visible in your project’s root directory. Ensure that you can run the JAR (right click on the JAR, select “Run game.jar”. Your game should run, creating a new window. Ensure the JAR is added to Git (select it, right click, Git->Add). Be sure to check that your JAR is up to date with any changes you make (repeat step 10 if in doubt). 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.)

Criteria for gaining 1 / 2

• All of the required files are correct and have been committed and pushed.
• The git log reveals healthy use of Git (some useful advice here).
• All the classes must compile without error and that the game works (or at least partly works).

Criteria for gaining 1.5 / 2

• The previous criteria plus…
• All the code contains authorship details and is commented well, and is formatted properly. (Note: ‘authorship details’ is fairly open-ended. It may mean stating that the code was written by the group, or by one or two members, or that it was heavily adapted from some third party. Either way, it should be absolutely clear to the reader which person or persons were responsible for the code and the ideas behind it.).
• The game should execute correctly from the JAR file on the lab machines (although it may not yet be complete).

Criteria for gaining 2 / 2

• The previous criteria plus…
• You show a very good understanding of the limitations of your code and you are able to discuss possible ways of improving the quality, functionality, and/or performance.

D2F Code Review (1 Mark, Individual)

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

Required Files for Stage F - Individual Code Review

Each group member must upload the following to the group repository prior to the Week 10 lab.

File	Description
admin/F-originality.md	Originality statement for Stage F. (Only one statement required for D2F.)
admin/F-review-<uid>.md	Code review for Stage F.

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.

Your review should 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 F - Individual Code Review

Criteria for gaining 0.5 / 1

• Your originality statement has been edited, committed and pushed.
• You have reviewed another group member’s contribution, and the review file has been committed and pushed.

Criteria for gaining 1 / 1

• The previous criteria plus…
• Your review comments are appropriate and actionable.

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

Due 11:45 Friday Week 11, 24 May 2019 (time remaining).

Marks will be distributed to group members according to the distribution of effort among the group members as documented in admin/G-contribution.md.

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.

Required Files for Stage G

File	Description
admin/G-originality.md	Originality statement for Stage G (this must reflect assignment in its entirety, not just changes since the previous stage).
admin/G-contribution.md	Contribution statement for Stage G. (This covers each team member’s contribution to everything that is assessed in this stage of the assignment i.e. not just work completed since D2F.)
admin/G-best-<uid>.md	Statements of best code.
admin/G-features.md	A concise list of the key features implemented by your game. Please use the G-features.md template, replacing - with X for each implemented feature, using the feature lists provided for your assignment, as appropriate.
All .java files	Complete source code for your assignment, in the provided src directory.
game.jar	A working executable JAR file for your game, in the base (root) directory of your repo.
presentation.pdf	Group presentation (to be used in Week 12 lab), in the base (root) directory of your repo.

Your presentation pdf file must be suitable for viewing on the lab projectors, and must include the following:

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

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

Evaluation for Stage G

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

Criteria for gaining 3 / 11

• All of the required files are correct and have been committed and pushed.
• Authorship of each class needs to be clearly stated in a comment of each class. (Note: ‘authorship details’ is fairly open-ended. It may mean stating that the code was written by the group, or by one or two members, or that it was heavily adapted from some third party. Either way, it should be absolutely clear to the reader which person or persons were responsible for the code and the ideas behind it.).
• The git log must indicate appropriate use of version control.
• The game is executable on a standard lab computer from the game.jar file which resides in the root level of your group repository.

Criteria for gaining 5 / 11

• The previous criteria plus…
• Your game correctly implements all of the Part One criteria.
• Your game must have at least Pass-level functionality.
• You have made appropriate use of object-oriented features such as inheritance and enum types.
• Your presentation pdf must have all required components.

Criteria for gaining 6-7 / 11

• The previous criteria plus…
• The program is well designed.
• Comments are clear and sufficient.
• Your game must have at least Credit-level functionality.
• Your coding style is good.
• You make good / appropriate use of JUnit tests throughout the project.

Criteria for gaining 8-10 / 11

• The previous criteria plus…
• Your design and code must be of very high quality.
• Your program demonstrates interesting extensions that go beyond the basic task.
• Your game must have at least Distinction-level functionality.
• Your game works well and is easy for a new user to run.

Criteria for gaining 11 / 11

• The previous criteria plus…
• Your game must have at least High Distinction-level functionality.
• Your game must be exceptional.

D2H: Assignment 2, Stage H (2 Marks, Group)

Due during lab, Week 12

Marks will be distributed to group members according to the distribution of effort among the group members as documented in admin/contrib-H.md. Your presentation must use presentation.pdf, which was submitted as part of Stage G.

Required Files for Stage H

File	Description
admin/H-originality.md	Originality statement for Stage H.
admin/H-contribution.md	Contribution statement for Stage H.

Evaluation for Stage H

Each group is expected to give a 10 min demonstration of their project (you must include in the 10 min time 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 will be marked out of 2 by your classmates and your tutor. Each group will submit a mark to the tutor. The final mark will be based 50% on your tutor’s mark and 50% on the average of the marks given by the other groups.

Criteria for gaining .5 / 2

• All of the required files are correct and have been committed and pushed.
• The presentation must be no more than 10 mins long, this includes time for a few questions.

Criteria for gaining 1 / 2

• The previous criteria plus…
• The presentation must appear well planned and rehearsed.

Criteria for gaining 1.5 / 2

• The previous criteria plus…
• The presentation must be engaging and clearly summarize your project.

Criteria for gaining 2 / 2

• The previous criteria plus…
• The presentation must be outstanding.

Required Structure For Your Git Repository

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&gt.md, if your UID was u2345678, then your file should be called best-u2345678.md.
• You must have a working JAR file named game.jar in the base directory of your repo.
• All of your source code must be in the repository (IntelliJ will put it in a folder called src).