Need help for making maze programme in java 11
coursework-II-manual 1. Instructions 2. How to plan the work 3. Marking In this coursework we'll be asking you to implement a JavaFX application that programmatically solves, and visualises, mazes. The application must meet the provided specification, so you should take time to read all instructions carefully. 1. The structure of the following UML class diagram informs the design of the application. Your implementation must meet the structure provided in the UML diagram. Note that additions to the UML are fine as long as all packages, class names, variables and method signatures in the UML diagram are implemented. 2. Most classes and methods are self-explanatory but the following description should resolve any ambiguity. The MazeApplication is a JavaFX application that allows users to specify a text file containing a maze representation. The graphical representation of the maze is displayed to the user. The user will also be able to: (i) step through the solving process Coursework II: Maze Table of Contents 1. Instructions Document version: 1.6, April 1st © Sarah Clinch. All rights reserved. with the visualisation updating to the current state, (ii) save the current route-solving state to a file, and (iii) load route-solving state from a file. For example, a simple implementation of this might look as follows: The MazeDriver class is an optional Java application used during the development process. It may be used to print Maze and RouteFinder state to the console/terminal. This class will not be marked. A Maze is an object that represents the maze to be solved. Each Maze contains a two-dimensional ArrayList of Tile objects. Each Maze contains exactly one entrance, one exit, and all rows of tiles must be the same length. If any of these constraints are not met, an appropriate subclass of InvalidMazeException should be thrown. The fromTxt method allows a Maze object to be created by reading in a txt file (the file path is passed as a String parameter), and the toString method should return a string that visualises the entire maze. For example: A Tile is an object that represents one space within a maze. A tile may be of Type CORRIDOR (represented in text files as a . ), ENTRANCE ( e ), EXIT ( x ), or WALL ( # ). The fromChar method creates a new Tile from its text representation (supplied as a char ). Conversely, the toString method returns the the string representation used in text files (i.e. "e" for tiles of Type ENTRANCE ). A Tile of Type WALL cannot be navigated through; all other Tile types can be. Each position within the Maze can be represented as a Coordinate whose toString method returns "(x, y)" where x represents the column number (indexed from 0, where 0 is the left of the maze) and y represents the row number (indexed from 0, where 0 is the bottom of the maze). The Maze class provides methods to get the Coordinate of a specified Tile ( getTileLocation ), and to get the Tile at a specified Coordinate ( getTileAtLocation ). From each Tile it may be possible to navigate in one of four directions (diagonal movement is not possible). These directions are represented by an enum Direction with the values NORTH (up), SOUTH (down), EAST (right), and WEST (left). The Maze class provides a getAdjacentTile method that returns the tile next to a specified Tile in a given Direction . The RouteFinder class provides the core logic for solving a given Maze . The RouteFinder uses a java.util.Stack to maintain state as it steps through the maze from the entrance to the exit (possibly/probably via a few dead ends). Only once the stack contains the complete path from entrance to exit (inclusive), will the isFinished method return true . Once a maze has been solved, the Stack representing the route should not contain multiple handles to any one Tile (each Tile in the maze will appear at most once). The step method within RouteFinder is responsible for updating the Stack that holds route-finding state. A call to the step method should make exactly one move through the maze -- i.e. either adding or removing one element to/from the Stack . It should not be recursive. Once a maze has been solved, further calls to step should have no effect on any of the state of the RouteFinder . The step method returns a boolean indicating if the maze is complete. If the step method gets stuck in a circular route or otherwise finds that no route to the exit is possible then it should throw a RouteNotFoundException . The getRoute method within RouteFinder should return a List of Tiles representing the current (complete or incomplete) route, from start to end (i.e. the first value in the list should be the entrance, and the last should be the element on the top of the route stack). The load and save methods in RouteFinder allow RouteFinder objects to be serialised out to a file. The toString method should return a string that visualises the entire maze and route-solving state. For example, the following screenshot shows the result of calling printing the return value from toString for a partially solved maze. In addition to the above functionality, this coursework will require you to: Organise your code into packages (see Chapter 19 of book). Package maze contains the core code to provide maze representations. Package maze.routing contains the maze solving implementation. Package maze.visualisation contains JavaFX components to support visualisation of mazes and the stages of route-solving. Use Javadoc to document your code (see Chapter 11 of book). Do not leave it until the last moment! ☺ The coursework is designed to assess material from Weeks 5-9. However, as with Coursework I, there is plenty that you can do on Coursework II before the end of teaching in Week 9. Week 6: you should be able to implement all classes in the core maze package, including reading maze data from a text file. Week 7: you should be able to implement a basic UI using JavaFX (including some classes in maze.visualisation ). Week 8: you should be able to implement classes in the maze.routing package. Week 9: you should have additional knowledge to refine your JavaFX UI and the maze.visualisation package. Note that unlike Coursework I, we have not provided any of the code for Coursework II. Marking will be conducted offline in Weeks 11 and 12. As in Coursework I, there will be automated tests. Automated test results will account for 40% of the marks (40 marks). Some of these tests will be provided to you in week 9, others will be new but will match the provided specification. The coverage of the number of tests passed (including those you are provided with) will be part of your marks. To ensure that the tests are successful, you must follow the provided UML diagram and specification. This accounts for 60% of the marks (60 marks) distributed as follows: Reading Text Files: Does the application successfully read mazes from a text file? Does the maze state (tiles) correctly correspond to the contents of the text file? [3 marks] Rendering: Does the application successfully render the maze? Is the representation correct? Does it work for mazes of different sizes / configurations? [15 marks] Interactivity: Are users able to load maps and routes, save maps, and step through the maze using the user interface? [7.5 marks] 2. How to plan the work. 3. Marking Automated testing Non-automated assessment Quality of User Interface: Is the user interface attractive? Does it demonstrate a variety of JavaFX components? Are component choices appropriate? [3 marks] Route Solving: Does the RouteFinder work for mazes of different sizes / configurations? Does it make appropriate use of a Stack? [15 marks] Object Serialisation: Does the application save/load route solving state successfully? Does it use the Serializable interface to do this? Does it save/load successfully in all possible states? [7.5 marks] Javadoc: Is the code documented using Javadoc? [3 marks] Package Structure: Is the code arranged into the packages specified by the UML? [3 marks] Star Quality: Has the student implemented exciting features beyond the specification? [3 marks] Since we (unfortunately) won't be able to ask you to demo the application yourself, we will also ask you to submit a short demo supplement (just a couple of questions that will help us spot star quality). Demo supplements will be submitted through Blackboard with a deadline of Monday, Week 11 at 6pm. Note that this is later than the deadline for code submission (Friday, Week 10 at 6pm). If you do not submit the demo supplement then we will still mark the coursework but we cannot guarantee to spot your extra features (and thus will not be able to allocate them marks) Your code will be tested and marked on a machine with Java 11. Your code will be run from the console -- it must be able to be run in this manner. Code that only runs in an IDE could result in a zero for this entire exercise. A reminder that your work will be checked for plagiarism. This is an individual coursework exercise and you must not work collaboratively on code with others. You may not include code from any other source. If you are found to have submitted code that you did not write yourself or to have knowingly shared code with others then penalties will be imposed and disciplinary action may be taken. Consult department and university guides for more information about plagiarism and its penalties. We appreciate that some students may have questions about their marks. Any questions about your marks or feedback must be made within one week of the grades and feedback being released. Queries received after this time will not be accommodated. Some IMPORTANT marking notes Plagiarism Marking Disputes / Queries