| |
|
Your score |
Max score |
Coding style (marks independent of program functionality)
|
|
|
| |
- Follows good programming conventions common to all programs
(e.g., Appropriate source code white space, self documenting names,
clear/simple expressions, methods implementing one task/max 30 lines
of code, appropriate used of named constants): Never (0), Sometimes
(4), Often (8), Mostly (12), Always (14)
|
|
14 |
| |
- Follows good Object-Oriented conventions
|
|
|
| |
|
Information hiding: Never (0), Sometimes (1), often (2), Mostly (3),
Always (4) |
|
4 |
| |
|
Class attributes are logical to the definition (e.g., not variables that
are just local to a method but belong to each instance): Never (0),
Sometimes (2), Often (4), Mostly (6), Always (8) |
|
8 |
| |
|
Each class (save the "Driver" and "Debug"
classes) consists of at least 3 methods |
|
6 |
| |
|
Program decomposition into classes is logical e.g.,
Driver does not include code for the user
interface |
|
5 |
| |
|
Static variables employed (the attribute of class "Debug"
specified in the assignment description excepted), -4 marks each
instance with a max of 12 marks lost |
|
-12 |
| |
|
The code for the classes are not included in its own file (-3 each
instance, max of 15 marks lost) |
|
-15 |
| |
Sub total
|
|
37
|
Documentation (marks independent of program functionality)
|
|
|
| |
- Header documentation includes full name and tutorial section
|
|
8 |
| |
- Some form of versioning system is demonstrated in the header
documentation
|
|
2 |
| |
- Each method is documented (similar to documentation for the
entire program but applies only to that method)
|
|
6 |
| |
- Program limitations documented
|
|
2 |
| |
- Program features documented (cut and paste out of the assignment
specifications acceptable but it MUST be detailed, clear and
specific...the marker must be able to know exactly what features in
this marking key were actually working)
|
|
20 |
| |
Sub total
|
|
38
|
Functionality (only qualify for these marks if the program runs:
note some features obviously requires other features to be implemented
before credit will be granted)
|
|
|
| |
- Classes listed in assignment description submitted (the class methods
can be largely empty)
|
|
5 |
| |
- Each track is properly initialized and displayed at appropriate
time
|
|
2 |
| |
- Displays clear and sufficiently detailed instructions in the
introduction
|
|
2 |
| |
- Game proceeds on a turn-by-turn basis
|
|
1 |
| |
- Order of the turns is correct (1 mark per sub-turn in correct
order)
|
|
6 |
| |
-
Displays an appropriate status message when the program ends (quit,
win/lose, tie)
|
|
4 |
| |
- SUV and sports car movement menu
|
|
|
| |
|
Displays menus |
|
2 |
| |
|
Gets user input for the SUV and sports car menu and repeats prompts
until valid input is entered. |
|
2 |
| |
|
Player can quit/program runs indefinitely until end game condition met |
|
2 |
| |
|
Cheat menu can be invoked from either car menu. |
|
2 |
| |
|
|
|
| |
|
Gets user input for the cheat menu and repeats prompts until valid input
is entered. |
|
2 |
| |
|
Can toggle debug mode |
|
2 |
| |
|
Can change fuel of sports car |
|
2 |
| |
|
Can change fuel of SUV |
|
2 |
| |
|
Can change location of sports car |
|
4 |
| |
|
Can change location of SUV |
|
4 |
| |
|
Can invoke a blizzard in the artic track during the artic track sub-turn
in the next turn (current sub-turn has already passed) |
|
4 |
| |
|
Can invoke a heat wave in the desert track during the desert sub-turn
coming up in the same turn |
|
4 |
| |
|
|
4 |
| |
- SUV can move and consume fuel as specified in the class
description (non-AWD mode)
|
|
4 |
| |
- Sports car can move and consume fuel as specified in the class
description
|
|
4 |
| |
- Program checks and properly handles when cars run out of fuel
|
|
4 |
| |
- SUV can move and consume fuel as specified in the class
description (AWD mode)
|
|
4 |
| |
- Artic track can randomly generate and properly handle the
effects of a blizzard on the SUV (regular mode)
|
|
8 |
| |
- AWD mode working properly during a blizzard
|
|
4 |
| |
- Desert track can randomly generate and properly handle the
effects of a heat wave on the sports car
|
|
8 |
| |
- Program can determine when one or both cars have reached the end
|
|
4 |
| |
- Graphical display of output (input may still be console-based)
|
|
6 |
| |
- Program has appropriate sounds effects
|
|
4 |
| |
Subtotal
|
|
106
|
Design requirements (may modify the raw functionality score)
|
|
|
| |
- Implements static methods (other than 'main()'
and methods that access the "GameStatus"
static attributes)
|
Divide
functionality marks by two1 |
| |
- Program consists of only one class (style marks will also be
lost)
|
Divide
functionality marks by two1 |
| |
- Original code for the Car and Track classes have been excluded
or extensively modified
|
Divide
functionality marks by two1 |
| |
- Functionality not assigned to the appropriate class as specified
in the assignment description (e.g., the attacker implements a task
that belongs to the defender).
|
Max loss of 8
marks to functionality (tallied after the above two modifiers, if
applicable) |
UML class diagram (marks independent of program functionality)
|
|
|
| |
- Class Track attributes (3) and
methods (3) properly specified and matches actual code
|
|
6 |
| |
- Class ArticTrack attributes (3) and
methods (3) properly specified and matches actual code
|
|
6 |
| |
- Class DesertTrack attributes (3) and
methods (3) properly specified and matches actual code
|
|
6 |
| |
- Class SUV attributes (3) and
methods (3) properly specified and matches actual code
|
|
6 |
| |
- Relationship properly specified (multiplicity not needed)
|
|
3 |
|
Subtotal
|
|
27 |
OVERALL ASSIGNMENT RAW TOTAL
|
|
208
|
GRADE POINT
|
|
4.3
|