|
Actual mark
|
Max
|
| |
Naming conventions
variables and constants |
Poor -2 |
Some poorly named
identifiers +0 |
Good and clear
throughout +2 |
|
2 |
| |
Layout and appearance of the Java source code (alignment, formatting, whitespace) |
Very cluttered, no
whitespace -2 |
Slightly too
much/too little +0 |
Appropriate use of
whitespace: +2 |
|
2 |
| |
Layout and appearance of the program output (when the program
is actually running) |
Very cluttered, no
whitespace, formatting -2 |
Slightly too
much/too little +0 |
Appropriate use of
whitespace: +1 |
|
2 |
| |
Appropriate use of constants |
|
A few obvious
missed: +1 |
Good: +2 |
|
2 |
| |
Variables
initialized prior to use |
|
|
Always +1 |
|
1 |
| |
Use of
decomposition into classes and methods (e.g., do class definitions have
appropriate attributes and behaviours, is the decomposition into methods
appropriate (no all powerful methods) |
Major problems -2 |
|
Appropriate +2 |
|
2 |
| |
Method
implementation: methods implement well defined task, method length does
not greatly exceed a screenful of text, method names well chosen and
well designed (not excessively complex) |
Major problems -2 |
|
Appropriate +2 |
|
2 |
| |
TOTAL |
|
|
|
|
13 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DOCUMENTATION
|
|
|
|
Actual mark
|
Max
|
| |
Overall
documentation should include: some sort of versioning system, a
description of the features of the program (what it does rather than how
it does it), limitations of the program (features not implemented or
cases that it can't handle). |
No documentation:
-4 |
Minor omissions or
other problems: +2 |
Appropriate level
of detail: +4 |
|
4 |
| |
Documentation for
each class |
Some: +0 |
Most: +1 |
All classes: +2 |
|
2 |
| |
TOTAL |
|
|
|
|
6 |
| |
|
|
PROGRAM FUNCTIONALITY
|
|
|
| |
Actual mark |
Max |
| Class
CommandProcessor defined as specified
in the assignment description1 |
|
2 |
| Class
Escape defined and initialized as
specified in the assignment description1 |
|
1 |
| Class
Forest defined and initialized as
specified in the assignment description1 |
|
2 |
| Class
ForestItem defined and initialized as
specified in the assignment description1 |
|
2 |
| Class
GameStatus defined and initialized as
specified in the assignment description1 |
|
1 |
|
Displays intro that explains the rules of the game |
|
1 |
| Displays
signoff conclusion, it should display the neutral game status: the game
is neither won nor lost |
|
1 |
| Displays main
(move) menu - options are not yet working to get this mark |
|
1 |
| Game will continue
running (displays and prompts for movement) until the player quits
(win/lose conditions not yet implemented to get credit for this feature) |
|
1 |
| Can access and
display the cheat menu through a hidden menu option in the main menu |
|
2 |
| Cheat menu
implemented (loops until valid input received then returns to main menu,
marks for debug and cheat mode are extra to this) |
|
1 |
| Debug mode
implemented |
|
2 |
| Program can read
starting positions from input file |
|
2 |
| The steps in a
turn properly ordered |
|
2 |
| The forest is
displayed with a bounded numbered grid |
|
2 |
| Party's courage is
reduced by one each turn |
|
2 |
| Party's courage is
reduced by ten when adjacent to a token |
|
4 |
| Cheat mode
implemented |
|
2 |
| Tokens are
randomly distributed in the forest during the turn (you only get credit
for one approach) |
|
6 |
| |
Exactly 5 tokens
are distributed (4 marks max) |
|
|
| |
5 - 8 tokens are
randomly distributed (6 marks max) |
|
|
| Game can detect
the win game condition (party reaches (9,9) on the board, conclusion
indicates win |
|
3 |
| Game can detect
the lose game condition (party courage is zero or less), conclusion
indicates loss |
|
3 |
| Party can move
(unlike distributing tokens as you implement more of the different
aspects of panic mode you get a progressively higher mark) |
|
9 |
| |
Party can move
onto an adjacent square (4 marks) |
|
|
| |
Properly checks
for array bounds (1 mark) |
|
|
| |
Player can only
move onto empty square or the exit (4 marks) |
|
|
| Panic mode
implemented (much like regular movement as you implement more of the
different aspects of panic mode you get a progressively higher mark) |
|
11 |
| |
Game can detect if
party has a chance of panicking (courage too low: 1 mark) |
|
|
| |
Game can generate
a random probability (50% chance to panic: 1 mark) |
|
|
| |
Movement algorithm
for panicking is properly implemented (tries to move 3 times to
adjacent: 4 marks, 2 marks lost if debug mode doesn't indicate when
movement not possible) |
|
|
| |
Properly checks
for array bounds (1 mark) |
|
|
| |
During panicked
movement the player will only move onto empty or exit (4 marks) |
|
|
|
TOTAL FOR PROGRAM FUNCTIONALITY |
|
63
|
| |
|
|
1 Implementation marks for filling in the bodies of these classes is extra.
For the class definition marks you essentially get these marks for properly
laying out the skeleton or design for these classes.