Recommendations: We recommend dedicating approximately 40-60 total hours on the coursework. We expect 30-40 hours of work for those who are aiming for a pass (40+) and 60 or more hours of work for those that are aiming for a first (70+). Please keep in mind that the skill level varies quite a bit in a class with over 350 students, and that the exact number of hours depends on your individual skill level. To help you, we have less required lectures in the last two weeks of term and some of the lab sessions are dedicated to your coursework.

Deadline: Friday 09/12/2022 @ 3pm (to be confirmed)

Assessment: The marks will be split as follows (for details see Appendix 1):

     15% for git use (e.g. push, branch, merge, providing .gitignore)

     30% for maintenance

     30% for additions

     15% for documentation (readme file + source code documentation)

     10% for the demonstration video, explaining your maintenance activities and additions

Questions: Questions can be asked in person during the lab sessions and on Teams. Please read the questions that have already been asked on Teams before you ask or post yours, to avoid duplication. We will try to answer your questions as quickly as possible.

Summary: This coursework is about maintaining and extending a re-implementation of a classic retro

game called Snake. The new implementation has never been completed, but at least it runs, once it is set up properly. More information about original Snake game and the history of it is available on Wikipedia (https://en.wikipedia.org/wiki/Snake_(video_game_genre)). In addition, you will find many opportunities on the internet to play the game online (e.g.https://www.crazygames.com/t/snake).

Requirement Specification

Basic Requirements: To pass the assessment (40%) do all the following (R1-R3):

R1. Set up a PRIVATE git repository on the school's GitLab server and use it actively for version control activities. The URL is:https://projects.cs.nott.ac.uk/(MFA authentication required). IMPORTANT: You will have to add Peer-olaf Siebers, Robert Laramee, and Adam Walker as Developer (not Guest!), otherwise we cannot mark your git activities!

a.   

R2. Do some basic maintenance of the delivered code base (this should include things like providing a meaningful Readme.md file and Javadocs, organising files in a meaningful way into packages, breaking  up  large  classes  in  a  meaningful  way  to  support  the  idea  of  single  responsibility,

improving encapsulation, applying Bob's coding conventions, etc.)

R3. Extend the delivered code base by adding:

a.    A module-info.java file

b.   A START screen (using JavaFX) with some setup options to choose between a minimum of two themes (consisting of a specific background for the game field and a specific colour for the snake) and a button that allows going to the GAME screen.

c.    A SCORE pop-up, appearing at the end of each round, showing the scores from each round

Additional Requirements: For higher marks, in addition to the previous do some (or all) of the following: A1. Refactor the code by adding some design patterns to enhance maintainability

A2. Refactor the code to adhere to the MVC design pattern

A3. Create a permanent high score list (using a file to store scores and player names)

A4. Add interesting levels to the game (based either on your own ideas or on the original game) A5. Use FXML and CSS for your new screens (start / high score)

A6. Add meaningful JUnit tests

A7. Use build files (Maven or Gradle) and make sure they work from the command line (i.e. using "mvn clean javafx:run" or "gradle run")

A8. Adding walls and obstacles

A9. Come up with your own ground-breaking idea ... surprise us :)

Java Version + IDE: You must use Java 17 or higher and JavaFX 17 or higher for the implementation. The project files you are submitting need to be compatible with IntelliJ.

Version Control with Git: To start, please download the given source code from Moodle. Set up a project in IntelliJ and embed the files that you just downloaded. Note that the zip file you downloaded from Moodle only provides source code and resources but no project files. It is good practice to ignore IDE- specific generated files for source control. Add a .gitignore file to your project, to help ensuring that you follow this good  practice as well.  Next, set  up a  remote git  repository at the school's GitLab server (https://projects.cs.nott.ac.uk). It needs to be set to PRIVATE. Then follow the setup instructions provided in GitLab to "Push an existing folder" (i.e. do an initial push to upload files from your local to your remote repository). Now you are ready for coding with version control. When it comes to creating GIT messages, some advice can be found in Appendix 2.

Object-Oriented Implementation: The implementation needs to adhere to some rules. We require these rules, because we want a good product to be delivered. When we look under the hood, we do not want to see a pile of scrap metal, but rather a finely tuned, carefully crafted machine. You are required to follow Bob's Concise Coding Conventions. See Moodle (or Bob's web page) for a copy of this document. And yes, points will be deducted for magic numbers and other rules that are not followed.

Swing Knowledge: The legacy code uses Swing rather than JavaFX. It is not a requirement to translate the code into JavaFX, although you might want to attempt this if you are aiming for a very high mark. If you are not familiar with Swing or want to brush up your Swing skills, we recommend the following YouTube course:https://www.youtube.com/playlist?list=PLTMybUaeagJagT2qoftaf5CkCvgc3pBTn.

Assignment Submission and Organisation

This section describes which files need to be submitted for assignment and how they should be organised. You are  required to create  a  root folder called  COMP2013-SurnameFirstName, where  "Surname"  is replaced  with  your  surname,  likewise  for  "FirstName".  The  COMP2013-SurnameFirstName  folder contains (and organises) digital copies of all the files that compose the assignment.

Project Information: A README.md file (max. 300 words and up to three screen shots) capturing relevant project information under the following headings:

1.    Project Title + Author Name

2.    Brief project description

3.    How to install and run the project

4.    How to use the project (i.e. how to play the game)

5.    Credits [if any third-party element were used]

Claims List: An Excel spreadsheet, called SurnameFirstName_Claims.xlsx, using the provided marking scheme (a draft version can be found in Appendix 1; the final version will be released during w/c 7 Nov) documenting your claims regarding your maintenance activities and additions, with a clear statement about how you did it and where we can find the evidence (e.g. providing names of classes and methods involved). This information needs to be provided in the "Justification of Claim: … " column of the Excel spreadsheet. The overall word limit is 500, so keep it concise. This is the most important document of your coursework, so take extra care when write it. WARNING: If you do not mention it here, do not blame us later if we missed it.

Design Diagram: A file called SurnameFirstName_Design.pdf that contains a high-level class diagram that shows the structure of the final version of your game, considering only classes  (excluding fields and methods, unless they are relevant for understanding design principles/patterns), interfaces, relationships, and multiplicity. If you use software to reverse engineer your class diagram, make sure the delivered diagram is correct and follows the above requirements.

Project Implementation: A zip file containing your ENTIRE LOCAL PROJECT FOLDER except for the "out" folder. It needs to be possible to OPEN AND RUN your project in IntelliJ. To avoid disappointment later, test your final version by unpacking and running your project on an alternative computer. This should help to uncover hardcoded path dependencies, which was a major issue in previous years. Name your zip file SurnameFirstName_JavaVersion.zip, where JavaVersion represents the Java version you used.

Source Code Documentation: A copy of your generated Javadoc documentation is required. Javadoc produces a series of linked HTML web pages in order to facilitate the browsing of project implementations. The HTML web pages produced by Javadoc are to be placed in a folder called javadoc that resides in the COMP2013-SurnameFirstname folder described above. Recall that the Javadoc output contains a brief description of each class and a description of each method including input and return parameters. The

new Java classes you write use the following author tag convention: @author FirstName Surname. All

modified Java classes from the previous code base use the following author tag convention: @author FirstName Surname-modified. In addition to reading your Claims-SurnameFirstName.xlsx file, we will look at the Javadoc to find out how you maintained and extended the game. If it is not obvious from there, we might miss it. Also, we have only a limited amount of time to look at each coursework submitted. So, please make sure to provide informative but concise Javadocs.

Demo via Screen Capture: Use screen-capturing software to demonstrate your achievements. The demo needs to show your software running (if you claim it runs) and then, for the main part, explain your maintenance activities and additions. In addition, you should highlight the two achievements you are most proud of. The video must be approximately 3 minutes in length (a penalty is applied if the video is shorter than 2.30 or longer than 3.30 minutes). The video file must be saved in MP4 format (a penalty is applied if you use a different format). Your screen capture demo must be called SurnameFirstName_Demo.mp4 and reside in the COMP2013-SurnameFirstName folder described above. Note that the demo video will be the primary way in which we assess whether or not your software is working.

You should end up with the following components in your COMP2013-SurnameFirstName folder:

     javadoc/... (javadoc files)

     README.md

     SurnameFirstName_JavaVersion.zip

     SurnameFirstName_Claims.xlsx

     SurnameFirstName_Demo.mp4

     SurnameFirstName_Design.pdf

Uploading your coursework to Moodle

For this coursework,  Moodle  limits  uploads to a single file of up to 250MB.  Before you upload your coursework,  please  create  a  zip  archive  with  the  name  COMP2013-SurnameFirstName.zip  of  your

COMP2013-SurnameFirstName folder and then upload that zip archive to Moodle.

If I would submit a project, it would look like this:

Assessment

To give you an idea about what we are looking for when we do the marking, we provide a draft marking scheme in Appendix 1. Please note that this is only a guide for us and does not guarantee you marks when you have done certain things. There is always an aspect of quality that needs to be considered as well, which often accounts for up to 50% of the mark. We also reserve the right to revise the marking scheme (within limits), if we see the need for this during the marking process.

Penalties: Besides the late submission penalty, which follows UoN standards, there will be a penalty for each of the following offences:

●    Using an incorrect document format (e.g. word instead of pdf)

●    Using an incorrect video format (e.g. swf instead of mp4)

●    Failing to comply with naming conventions requested above

Important Notes

Source code: This coursework is about maintaining and extending existing code. So, for the maintenance part YOU HAVE TO USE THE CODE WE PROVIDE (snakee-grp34-v7-src.zip) as a basis, and not write your own game from scratch, or use source code from other campuses or the internet.

Interview: Make sure you understand what you are writing in your source code and the Javadoc. We reserve the right to briefly interview you if we think that you do not understand it.

Changes:  Please  note that we may make some small  modification to the coursework specs. We will announce these on Moodle and keep a change log there as well.

Feedback: Dr Siebers and Dr Laramee will of course be happy to answer questions and give high-level interim formative feedback on your assignment. If you get stuck, please get in touch! However, we might refuse to answer very detailed technical questions, or very general questions (like "What do you think about my project so far?").

Tips: Please be aware that there will also be a lot of useful tips and answered questions on the COMP2013 Moodle page in the Announcement section, and in the Teams COMP2013-DMS(2022) Questions channel. If you want to know a strategy for getting started with this project, check out Appendix 3.

Plagiarism: You are gently reminded that we are at liberty to use plagiarism detection software on your submission. Plagiarism will not be tolerated, and academic offences will be dealt with in accordance with university policy and as detailed in the student handbook. This means you may informally discuss the coursework with other students but your submission must be your own work. Please also note that it is not permitted for you to copy and paste text from another source without correct referencing. If you are unclear about this process, please discuss with the module convenors during one of our lab sessions or at the end of a teaching session.

Appendix 1: Marking Scheme

Please keep in mind that for each item, marks are given for quality as well as delivery. For example, for the category "Start screen with theme choice (background/snake), using JavaFX" a very basic Start Screen with a very complicated approach to choosing a theme will give you 3 marks, while a well thought through and attractive looking start screen with an easy to handle theme choice mechanism will give you the full 5 marks. Adding some "welcome music" to the start screen or anything else exciting will then give you some extra marks in the "Anything else exciting (reward) or bad (penalty)" category.

Please note that the "Anything else exciting (reward) or bad (penalty)" category refers to "Maintenance" as well as "Additions"; so you should list here what you think is worth extra marks from both categories.

Appendix 2: Git Messages "HowTo"