FIRST VERSION
Worth: 22% of your final 209 mark
Your task is to implement a game with a GUI. There are two learning objectives. The first is to gain further experience in the use of Java object-oriented facilities, by using them in your own program and by seeing them and using the interfaces provided by the Java AWT library. The second objective is to design your own graphic user interface and to experience the consequences of interface design decisions by using the software you have written. The game setting is one in which user interface design is especially important. A game is only interesting to play if the user interface properly communicates the game state to its users, and allows for convenient play. It is suggested that you do a board-based game that does not need sophisticated animation. Don't be too ambitious, you will not be able to do JavaQuake III in 6 weeks.
To ensure that your program meets the learning objectives, game programs must include the following:
If you cannot reasonably design a hierarchy with at least two subclasses and at least one new interface, then either you should choose another design or another game. Keeping this requirement in mind, come up with a design fulfilling the requirements BEFORE you spend/waste weeks with coding.
You are encouraged to base your game on the provided examples of chapter 5,6,7, and 9. Alternatively, you could start with the idea of a game board, built as an array of cells. But remember that your game should be sufficiently different/enhanced in comparison to the original samples.
Remember: this practical will be marked by hand-in, not a test. Therefore your game must be unique, i.e. no sharing of design or code this time! And no teams this time please, only individuals
Due date final version: Monday, 21th October
In addition, the following grading policy similar to 312 (Communications and Systems Software) applies:
As always, marks will be subtracted for poor programming practice. Make sure you liberally comment your code and keep good Object Oriented design principles in mind. The grade is made over all deliverables, meaning your specification and documentation will be graded as well as the correctness of program execution.
Your programs must be robust. You must perform sanity checks on all inputs from the user to verify sensible information. Your user interface must be intuitive and able to cope with abnormal conditions (like silly user syndrome).
A grade of B+ will be awarded to the submission that meets the specifications of this assignment, and is of average quality. Grade steps will be removed for reasons listed above. In order to get above a B+, you must implement an adequate extra of your choice, over and above the minimum specification. It is possible to get an A+!
We like to encourage self appraisal, so some credit will be given for documentation of known bugs, unexpected and counter-intuitive behaviour.
Late submissions will not be graded without a mitigating Doctor's certificate. It is better to get some marks than no marks, so be sure to submit what you have, even if it isn't complete.