CIS 1200

HW09 Rubric

HW09 Rubric

Summary

  • Proposal (8 points)
  • Basic Requirements (19 points)
  • Autograded Style (5 points)
  • README.txt (4 points)
  • 4 concepts (64 points total, 16 points each)

Non-compiling submissions only receive proposal and README points (up to 12 points). Games that do not use Java Swing only receive proposal points (up to 8 points).

Game Demo

  • TAs will send out sign-up times for after the submission deadline
  • Changing a selected time slot requires 24 hour notice
  • After missing a game demo without 24 hours’ notice, students are allowed one make-up demo at a 20 point deduction.
  • If a student misses the rescheduled demo, they only get proposal and README points (up to 12 points).
Important: TAs have final say regarding whether your implementation meets rubric standards. Please check in with your TA if you are making changes from what you wrote down in your proposal to ensure it still meets the rubric.

Detailed Breakdowns

For conciseness’ sake, numbers between parentheses represent point values. So (5) means a 5-point rubric item.

Proposal

Proposed concepts are worth 2 points each, graded on an all-or-nothing basis for each concept. The student has to provide an explanation that describes how they will use the concept for their game.

No credit is given for late or improper submissions.

Basic Game Requirements

  • (5) Mouse/keyboard input. Requires mouse and/or keyboard input to be present and functioning
  • (4) Instructions
    • (2) Present
    • (2) Fully, accurately reflects the game
  • (9) Displaying State
    • (2) Game status displays on screen
    • (2) Game status updates in real time
    • (2) Game status updates correctly
    • (3) End state is present and correct
  • (3) Testing
  • (max -5) Manual deductions by TA discretion. For example:
    • Game is unplayable, difficult to play, and/or inconsistent
    • Bugs that prevent certain gameplay or show unexpected behavior

Autograded Style

Determined by the autograder on submission.

README

A submission will receive:

  • 4 points if README is present, filled out, and reflective of submission
  • 2 points if README is present and filled out, but is not reflective of submission
  • 0 points if README is missing or empty

Four Concepts

2D Arrays

Note: Cannot model the same state as Collections or Maps

  • (2) 2D array(s) present
  • (3) Iterating through and/or accessing entries of the array properly (no ArrayIndexOutOfBoundsexceptions or try/catch blocks to hide them)
  • (3) No redundant information (not using more than one 2D array when one would suffice)
  • (3) Array is encapsulated properly
  • (3) Justification of using the 2D array
  • (2) Justification of using the type contained in the 2D array (e.g. int, String, or some other type)

Collections and/or Maps

Notes: Cannot model the same state as 2D Arrays

  • (2) Collection and/or Map to model significant portion of game state present
    • Does not count if the only use of Collections/Maps is to store file data in memory (unless the file stores the game state)
  • (3) Iterating through collection properly or accessing map elements properly
    • No unnecessary for loops when a for-each loop will suffice
    • No unnecessary iteration when get() or other map methods will suffice
    • No ConcurrentModificationException exceptions or try/catch blocks to hide them
  • (3) No redundant information (not using more than one collection or map when one would suffice)
  • (3) Collection or map is encapsulated properly
  • (2) Justification of using a Collection and/or Map (as opposed to an array, etc.)
    • Must resize during game execution
    • If implementing an undo feature, must implement unlimited undo functionality (i.e. you should be able to undo to initial state unless the game is closed with I/O)
  • (3) Justification of using type of Collection and/or Map (i.e. Set for unordered data, etc.)

File I/O

  • (6) File format stores all of the game state
    • Data must be persistent across game sessions
    • Only storing high scores does not count as sufficiently storing game state
    • Only storing images does not count
  • (4) Catches and handles IOExceptions (game doesn’t crash)
    • e.g. FileNotFoundException, improper formatting, blanks/whitespace, stuff similar to HW08’s FileLineIterator
  • (3) Parses input files correctly - does the game reflect what we expect to see based on file data?
  • (3) Writes to files correctly - does the file data reflect what we expect based on game state?

Note that you must NOT use built-in serialization and deserialization classes (like ObjectOutputStream and ObjectInputStream) to read/write their game state from/to a file. A Leaderboard is insufficient to satisfy this requirement.

Inheritance and Subtyping

  • (2) Interface/abstract class/concrete class present and at least two classes implementing/extending them
  • (4) Justification of interfaces/subtyping
    • Interface: subtypes do not need to inherit any implementations
    • (Abstract) Classes: subtypes do need to inherit implementations/methods
    • Dynamic Classes: the implementations differ significantly and in a manner that merits subtyping
  • (6) Differences between subtypes are distinct method implementation(s)
    • Cannot be represented by a variable (common issues are creating subtypes just for color, size, speed, point value, or up/down/left/right/one directional movement)
    • Cannot only override the draw method
  • (4) Dynamic Dispatch present

JUnit Testable Component

If the student did not test core-game state/model, their score is halved (this section is graded out of 16, then the score is divided by 2).

There must be at least 10 tests present for this section to earn any points.

  • (2) JUnit tests are being used
  • (6) Code designed to be unit-testable
    • Separation of concern
    • Model doesn’t rely on GUI components
  • (6) Test style
    • (3) Correct assertions (e.g. delta for floats, assertTrue/False, etc)
    • (3) Distinction of tests (i.e. no two tests do the same thing)
  • (2) Edge cases

Recursion

  • (2) Recursion is present
  • (4) Justification of recursion (why not iteration?)
    • Examples where recursion is justified:
      • Recursive BFS/DFS
      • Searching through user-defined data structure
    • Recursion should not attempt to mimic syntax of a for-loop
  • (2) Does not cause an infinite loop / stack overflow / out of memory error
  • (1) Base case exists
  • (3) Base case is correct
  • (4) Recursive step (change between each call) makes sense
    • Input to recursive call moves towards base case
    • Computes value for each recursive call correctly

Novel Linked or Recursive Data Structure

Must not exist in Java, Apache Commons, Google Guava, or other common third-party libraries.

  • (2) Novel linked / recursive data structure present
  • (4) Justification of why new data structure is needed
  • (3) Interface (adequate methods to interact with & access data structure – e.g. getNeighbors() for a graph)
  • (3) Encapsulation
  • (4) Distinct from existing data structures (more than a wrapper)

Complex Game Logic

Rubric for Chess complex game logic is below - other games must be approved by TA and graded on a case-by-case basis.

  • (6) All check features implemented correctly
    • Straightforward check works (opposing piece puts the other player’s King into check)
    • King can’t move into check
    • You can’t move a piece such that it puts its own King into check
    • When in check, the player must resolve check (either moving King, eating the piece that’s placing King in check, blocking the check with another piece) before other moves
  • (5) Checkmate implemented correctly
    • Check should be announced first
    • Use Fool's Mate if a quick test is needed
    • Ends the game
  • (3) Castling correctly implemented
    • Only when rook and king haven’t moved
    • Works on both king and queen side
  • (2) En passant correctly implemented
    • Occurs when a pawn moves two steps forward and could have been captured if it only moved one step forward
    • Only valid for the turn that the above event occurred

Advanced Topics

  • All of these require prior approval in the student’s proposal or on Piazza
  • Students may get credit at most one advanced topic

Collisions

  • Must be complex physics simulation

    • Simple shapes receive at most 2 points
    • Must implement full elastic collisions using position/velocity/normal vectors, etc.

  • (2) Collisions present

  • (4) Proper justification for collisions

  • (10) Works correctly

3D

  • (2) 3D present
  • (4) Proper justification for 3D
  • (10) Works correctly

Network I/O

If the student is using both I/O and Network I/O in the same area of their game (e.g. using I/O to parse the protocol), the network protocol must be sufficiently complex such that it requires different kinds of messages / responses, AND the data format of the individual messages sent must be sufficiently complex that the message parsing is nontrivial.

  • (2) Network I/O present in the game
  • (2) Communication protocol data is complex – input data has multiple pieces of information
  • (6) Catches and handles IOException - game does not crash
  • (2) Parses input correctly - does the game reflect what we expect to see based on data?
  • (2) Writes output correctly - does the output data reflect what we expect based on game state?
  • (2) Justification for network I/O

Concurrency

  • (2) Concurrency present
  • (4) Catches and handles InterruptedException and other checked Exceptions - game does not crash and Exceptions are not propagated
  • (4) Justification for why the student is using concurrency (not just creating multiple threads for the sake of doing it)
  • (6) Avoids race conditions/deadlock/livelock
    • methods and/or blocks are synchronized
    • multiple threads won’t attempt to change the same data at the same time (and, consequently, all threads will see consistent data values)
    • the game won’t hang due to multiple threads waiting for each other to release resources/finish running

AI

This is a scale from 1 to 16 points - the TA determines which scenario best matches the student’s implementation, and assigns the corresponding point value.

Shortest path does not count for AI, and there should be some non-random heuristic involved.

  • (1) Computer randomly makes a move in every situation
  • (2) Have something that remotely resembles an AI - not random, but very generic
  • (4) Have something that looks one step ahead and applies some heuristic, but the heuristic doesn’t really vary. AI doesn’t vary on a case-by-case basis.
  • (6) AI looks one step ahead, applies some heuristic that varies/is specific to that situation
  • (10) AI looks multiple steps ahead and applies a heuristic that performs poorly (e.g. you always beat the AI or win a significant majority of times) or a heuristic that doesn’t make sense.
  • (16) Real AI. Looks multiple moves ahead, applies a good heuristic, and performs well.