ICT221 Java Programming Assignment This is Task 2 of the ICT221 assessment, whichis worth 40% of the course. • Part 1: (Game Engine with Unit Tests) is worth 20%, and is due at the end of Week 9, on Friday5 May 2017, 11:55pm. • Part 2: (JavaFX GUI) is worth 20%, and is due at the end of Week 13, on Saturday 4 June 2017, 11:55pm. Overview In Part 1, your task is to build and test the 'engine' of a simple 2Dgame in Java, plus a temporary textual user interface for interacting with the game. In Part 2 of the assignment (Weeks 10-13) you will add a graphical user interface (GUI) to your game using JavaFX. So you must keep the basic game idea fairly simple, and ensure that it is not too hard to add the GUI to it. 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. Demonstrate your ability to read and write text files, to save game data; 6. Learn to build simple graphical user interfaces using JavaFX (Part 2); 7. Learn to use a distributed source code control system: GIT. Choice of Game Your game needs to be a simple 2D game that uses a discrete 2D grid for the playing board, like a chessboard, a Tetris board, a Crosswords board, or a maze. It could be a one-player game, such as solving puzzles, or a two-player game where two human players take turns to compete. (For multi-player games with very simple rules and strategies, you could experiment with writing a computer player that plays against the human player, but designing good 'artificial intelligence' strategies for computer players is hard, so make sure that this is an optional part of your assignment, and consult the lecturer before you attempt such advanced features). You must choose one of the following games: • Concentration memory game (e.g. http://www.mathsisfun.com/games/memory/); • Draughts/Checkers (see https://en.wikipedia.org/wiki/Draughts); • Columns (e.g. http://www.lutanho.net/stroke/online.html). This is like the classic Tetris game, but a bit simpler. • Minesweeper (see http://www.lutanho.net/stroke/online.html); • Sokoban (see http://www.lutanho.net/stroke/online.html); • Spider Solitaire (seehttp://www.lutanho.net/stroke/online.html); • FreeCell (e.g. https://cardgames.io/freecell/). Or another simple game of your choice, if approved by the course coordinator. Overall Plan The first stage of the assignment (Weeks 6-9) is to write the core game engine, plus your unit tests for that engine, and a simple text-based user interface that allows you to play the game. These will all be submitted in Week 9, marked and returned to you with comments. During the second stage (Week 10-13), you will develop the GUI for your game. From this point onwards, you should not make any changes to your game engine (bug fixes are okay, but don't waste time making other improvements, since the game engine code will not be marked again). By the time you submit your final game in Week 13, it should be playable via the GUI, as well as still playable via the textual user interface that you submitted in Part 1. Important! You must use separate Java packages for: 1. Your core game engine and unit tests (e.g. mygame.engine) 2. Your textual user interface (e.g. mygame.textui) 3. Your JavaFX GUI (e.g. mygame.gui) Part 0: Create your Git Repository As soon as you start work on your game project, you need to create a Git repository to track all your changes. You will use BitBucket.org to keep a master copy of your game project, and it is your BitBucket.org Git repository that you will use to submit your game project for marking. After you have created your Eclipse project, follow these steps to set everything up: 1. Go to BitBucket.organd create a free account ('Get started for free'). Then create a 'private' Git repository in that account (this is the URL that you will submit to Blackboard for marking). 2. Then, in Eclipse, right-click on your whole project and use Team / Share Project / Git / Next / Create to create a new local repository. 3. Commit all your project source files into your local Git repository: (Team / Commit). You should add all the *.java files, the .project and .classpath files, and ALL other image files or data files that are needed to compile and run your game. Do NOT add binary output files such as *.class files. Enter a meaningful commit message (e.g. "First version of game"), and press Commit. 4. Push your project up into your BitBucket repository: (Team / Remote / Push, and then paste in the URI of your BitBucket repository from Step 1). You will need to tell Eclipse your BitBucket.org password. Set the 'Source Ref' to 'Master[branch]' and press the 'Add spec' button, then press Finish. 5. Go back to BitBucket.org and refresh your repository there, and you should see that some files have been created. You should create a README file too, with a couple of sentences to explain your project. 6. Important! Finally, click the 'Send invitation' button and invite your tutor (Mark [email protected], or Amol [email protected])to be able to share your repository (READ permission will suffice). Then invite the Course Coordinator([email protected])as well. If you don't do this, we will not be able to mark your assignment. Now you have joined the world of professional software developers, who use version control to manage their source code safely. Every day after you have made some changes to your game (and tested them of course!), you should use the Team / Commit / Commit and Push command in Eclipse to save a record of your changes into your local repository, and alsopush a copy of those changes up to your BitBucket repository, where they will be safely backed up, and where we will be able to access them for marking. You can even use this feature to keep your home and University computers synchronised with the latest version of your game, if you: • do a 'Team / Commit / Commit and Push' after you make changes. • do a 'Team / Pull' each time you arrive at a new computer, to pull the latest version of your game down to this computer. Part 1: Game Engine and Unit Tests Start by developing a simple first version of the 2D board in your core game engine. You could look at the TicTacToe game for an example of how to do this. Design Decisions 1. Think carefully about whether each cell in your board should be a primitive value (like a boolean, an integer, or an enumerated 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. 2. If you have a multi-player game, think carefully about whether the players should just be numbered, or do you want to be able to switch between computer players and human players? If the latter, then a nice way of doing this is to have a Player superclass (or interface), with one subclass for a human player (which prompts the user and reads their response), and another subclass for a computer player (which implements a simple playing strategy such as choosing a random move). 3. To get high marks, your engine needs to include several classes, with some association/composition relationships between them, and if possible, some inheritance relationships. Think about where you can best use these Java features. Development Process Here are two suggestions for how you can develop your game engine in small iterations, so that you check that each new feature is working correctly. I suggest that each iteration should take at most 10-30 minutes, so that you are doing lots of small iterations, adding one feature at a time. 1. Use TDD to develop your unit tests and game engine at the same time. 2. Write a simple textual user interface first, and use that to test the game engine manually each time you add a new feature. (Hint: to make sure you have not broken any old features, you can also rerun previous tests by recording the input in a text file, and redirecting that file into your program using input redirection. Eg. java -jar game.jar out.txt). Marking Criteria Your submission must contain the following four parts, which are each worth 25% of the Part 1 mark (replace mygame by your own custom package name). 1. Game EngineJava code (package mygame.engine): 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. Game Engine JUnit Tests (package mygame.engine): 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 ofmygame.engine.Foo.java should be in the Java source file mygame.engine.FooTest.java). 3. Textual User InterfaceJava code (package mygame.textui): this will be marked using the following criteria: good OOD of the classes with strong encapsulation of the data fields within classes; saving and loading of the game state or the high score table; good use of exception handling to catch I/O errors; adherence to recommended Java coding style (naming conventions, code formatting etc.); and concise elegant Java code with no duplicated code. 4. Documentation(README1.docx): this should contain four sections: A. Introduction: one paragraph to explain what your game does, how many players, what features are implemented etc. B. A UML diagram: that shows all your game engine and textual user interface classes, and the relationships between them. You do not need to show the unit testing classes. C. A GUI sketch: that shows your 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. Alternatively, you can draw it in MS Word or some other drawing or paint program if you prefer. 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. Part 2: Graphical User Interface (GUI) and System Test The goal of this stage (Weeks 10-13) 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 GUIshould 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 theback-end (game engine) and front-end (GUI) classes using different Java package names, as described above; • loading and saving of game states or high scores into text files, so that a game can be saved and resumed, or so that the high score table is persistent between games; • [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). Marking Criteria You must submit the GIT repository containing your whole game project, including the code and report that you submitted for Part 1. Your submission will be marked using the following criteria: 1. GUI functionality30%: 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. 2. GUI code, worth 50% (in package mygame.gui): 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. 3. Documentation20% (README2.docx): this should contain four sections: A. Introduction: one paragraph to explain how the GUI works, what is the goal of your game, and what data can be saved/restored. Include a list of any keyboard commands supported by your game. B. Updated UML diagram: that shows all your game engine classes, the main GUI classes that you have written, any JavaFX classes that they inherit from (name only, no details), as well as your textual user interface classes, and the relationships between all classes. C. GUI modifications: show your original GUI sketch copied from README1.docx, followed by screen shots of your final GUI, then discuss any changes you made and the reasons for those changes. D. Reflection: a brief discussion of what went well in your GUI development, any difficulties that you encountered, and what you would do differently if you were doing it again. Submission Instructions To submit your assignment each time, you can justsubmit your README.docx file(s). Your Eclipse project has already been shared with us via BitBucket.org!