please follow the instructions and send me screenshots of the program once it starts to run
ICT221 Java Programming Assignment This is Task 2 of the ICT221 assessment, which is worth 30% of the course. Your solution must be clearly separated into two separate parts, in separate Java packages: · Part 1: (in module boardgame_engine): your Game Engine classes with Unit Tests. · Part 2: (in module boardgame-gui): a JavaFX GUI that allows users to play your game. Overviewhttp://www.zorsay.com/question/23/Suggest-some-good-fun-and-educational-board-games-to-gift-for-a-10-year-old-for-his-birthday Your first task is to choose a simple one-player, two-dimensional (2D) board game, and then implement the 'engine' of that game in Java. You should write some unit tests to check that your game logic works correctly. You second task is to use JavaFX to add a graphical user interface (GUI) to your game, which displays the 2D board and allows the user to play the game. So you must keep the basic game idea fairly simple, and ensure that it is not too hard to add the GUI to it. You MUST use JavaFX, not any other Java GUI libraries. Learning Objectives 1. Learn to use object-oriented design (OOD) to design Java programs; 2. Be able to use inheritance and subtyping relationships between classes; 3. Be able to use association or composition relationships between classes; 4. Be able to develop a comprehensive suite of unit tests for the core logic classes of an application (e.g., for the game engine); 5. Build simple graphical user interfaces using JavaFX. The 'FullHouse' Game You must implement the game called "FullHouse" from: · http://www.lutanho.net/stroke/online.html This is a simple 2D puzzle game that uses a discrete 2D grid for the playing board. The game requires the player to move one blue piece around the board (using arrow keys or mouse clicks) to try and visit ALL the empty squares. To make the puzzles more challenging, the player can click at the beginning to choose a starting location. This game was invented in 2004 by Erich Friedman. Hint: to solve Puzzle 1, try starting at position (2,2)? Requirements for full marks: 1. You should implement at least three levels of the puzzle. 2. You should allow the player to choose which level they want to play. 3. Your game should show a "Oops!. Try again?" message when the player is stuck. (Either as a popup Alert, or as a message on the main window). 4. Your game should keep track of the total time (NNN seconds) spent on each level and report that time when the user finally passes the level. 5. Your game should show a "You won in NNN seconds!" message when they succeed in passing the current level (visiting all empty cells). 6. To get full marks some of your levels should be different size boards (e.g. 5x5 board for an easier level and 7x7 for a harder level). 7. You should use images to make the game look more visually interesting. Part 1: Game Engine (Weeks 9-10) 1. Set up your Git Repository. When you click on the Blackboard link for this assignment, you will automatically create your own private GitHub repository containing two simple modules: boardgame_engine and boardgame-gui. a. Clone this repository onto your computer using IntelliJ. b. Make sure you also have Java JDK 11 installed on your computer. 2. Check you can run JavaFX. I have set up the boardgame-gui project to use the 'Gradle' build tool, which means that it should automatically download and install the necessary JavaFX and JUnit libraries when you build and run the project on each new computer. (You may see a popup message down the bottom of IntelliJ: "Gradle projects need to be imported". Click on "Enable Auto-Import" and IntelliJ will automatically download and install JavaFX for you! If IntelliJ asks you for the location of Gradle, you may need to turn off the "Use local gradle distribution" and select the alternative option: "Use gradle 'wrapper' task configuration" – this uses the gradle that is built into IntelliJ). Run the RunGame class to check that you can run the GUI – it should show a simple GUI with a single button that says: "Amazing Board Game coming soon…". (If this does not work on your computer, then follow the same steps that you did in Task 1 to create a JavaFX library and add it to your project (See Blackboard / Learning Materials / Resources and Links if you need instructions). Then check that you can run RunGame.java.) 3. Data Design Decisions: Think carefully about whether each cell in your board should be a primitive value (like a boolean, an integer, or an enum value), or should it be an object? Using objects is more flexible, since it allows you to use Java subtyping to make different cells have different behaviour. But many of the games suggested above do not require the cells to have fancy behaviour, so a primitive value might be sufficient for your game. 4. Implement and Test Your Game Engine: I strongly suggest that you use TDD to develop your unit tests and game engine at the same time, in parallel. Recall: Write a test for each new feature and check that it fails, then implement that feature in your engine classes and rerun the test to check that it now passes. Repeat… You can refactor (rename and reorganise) your code at any stage, if you see a way of making it simpler and more elegant. By the time you have finished implementing your game engine, one (or several) of your tests should be stepping through a complete game from start to end, calling the methods of your engine API and checking the results, including the game win/lose verdict at the end. 5. Class Relationships: To get high marks, your engine needs to include several Java classes, with some association/composition relationships between them, and if possible, some inheritance relationships. Think about where you can best use these Java features. Part 2: Game GUI (Weeks 11-12) The goal of this stage is to use JavaFX to add an elegant and fully functional GUI to your game so that it can more easily be played on desktop computers. Your GUI should have the following features: · event-handling of mouse and/or keyboard events; · display of bitmap images (I recommend you use some large images for the background of the whole game or each panel, so that the game looks professional and entertaining); · multiple panels, with a main gaming panel to display the game, plus one or more panels around the edges to display game options, score information, and control and help buttons etc.; · correct resize behaviour when the user adjusts the main window to different sizes for different devices; · a clean separation between the back-end (game engine) and front-end (GUI) classes using different Java package names, as described above; · [optional] use of a timer to have ongoing real-time activity in the game (for example, to make the blocks fall in the Columns game). Start by drawing one or two paper sketches of the GUI you plan to build. Take a photo of each sketch, as you will need to include these in your final report. Submission and Marking Criteria You must submit a single Microsoft Word Report to Blackboard, based on the report template given in the Assessment / Task 2 area on Blackboard. You do NOT need to submit your code, as we already have access to your GitHub repository. You are reminded that your submission must be completely your own individual work, in your own words, and you must correctly reference any external sources that you use in your report, or in your code. Your submission will be marked using the following criteria: 1. [20%] Game Engine Java code: this will be marked using the following criteria: good OOD of the game engine classes with strong encapsulation of the data fields within classes; correct implementation of association or composition relationships between classes; good use of inheritance and subtype polymorphism; good choice of data structures; adherence to recommended Java coding style (naming conventions, code formatting etc.); and concise elegant code with no duplicated code. 2. [20%] Game Engine JUnit Tests: these tests will be marked according to: how thoroughly they test all the Game Engine classes; and how well they follow correct JUnit naming conventions (eg. tests of mygame.engine.Foo.java should be in the Java source file mygame.engine.FooTest.java). 3. [20%] GUI functionality: this will be marked using the following criteria: a playable and robust game; good use of JavaFX widgets, layout panes, and controls to build an elegant and functional user interface; appropriate use of bitmap images in the GUI; good resize behaviour when the main window is resized; and saving/restoring of games states or high score tables. This will also demonstrate that your textual user interface still works after you have added the GUI. 4. [20%] GUI code: this will be marked using the following criteria: good use of event-driven programming; good OOD of the GUI classes with strong encapsulation of the data fields within classes; good use of inheritance and subtype polymorphism; adherence to recommended Java coding style (naming conventions, code formatting etc.); concise elegant code with no duplicated code; and good use of exception handling to catch and report any I/O or game errors. 5. [20%] Documentation (Report.docx): this should contain four sections: A. Introduction: one paragraph to explain what your game does, how a player can win the game, what features you implemented, etc. B. Your UML diagram: that shows full details of all your game engine classes, plus the GUI classes that you have written. It should also show the main JavaFX classes you have used (just the class name is enough – you do not need to include all their data fields and methods!), and the relationships between them and your classes. You do not need to include your unit testing classes in your UML diagram. C. GUI sketches: that shows your original ideas for the GUI you plan to build for your game. This should be drawn by hand and then scanned or photographed and inserted into the Microsoft Word document. It just needs to be a rough sketch, possibly with some labels to show the contents of each panel or the function of certain buttons, if that is not obvious. D. Reflection: a brief discussion of what went well in your game development, any difficulties that you encountered, and what you would do differently if you were doing it again.