Team Portion of Grade: Submission: 25 possible points. ================================================================ - The names of all team members must be at start of each file and the name of the test author must be in the comments at the start of each JUnit test file: 2 pts. - Each member of the team must have written and successfully run at least 1 test: 5 pts. - Jar file: 10 pts. - The jar file must have separate packages for the game source code and for tests. Source code must be in a package called cs314_A2 and test source code must be in a package called cs314_A2Test. - On extracting from the jar file, the game source code and overview files (AdventureGameView.java, AdventureGameModel.java, ... , overview.txt) should get unpacked into directory src, with the source code files in package cs314_A2. The user stories should get unpacked into the directory UserStories. The test source code must also be in the src directory, in a package called cs314_A2Test - No class files or other unneeded files are in your jar file. - Compile/Run: - Files should compile successfully and without warnings. - Run: Your program should start without warnings and take user input without crashing. - User story files: 5 pts. - Each user story file must contain the user story, acceptance criteria, any split stories, story point estimates, and all tasks needed to complete the user story, along with their estimated times and actual time taken. - Overview.txt file: 3 pts. - Names of all team members. - Specific contributions by each team member. - Time spent by each team member. - Summarized test results for all unit tests: how many tests were created and the test results (include any defects that were found). All tests must pass. - The CSU Honor Pledge: "I have not given, received, or used any unauthorized assistance." with the team members' names listed below. ===============================PART 2=========================== Team Portion of Grade: Design Quality: 25 possible points. Partially based on how consistent your implementation is with the instructions. ================================================================ - Architectural design quality - maintain model-view separation: 15 pts. - No game functionality in AdventureGameView or other view classes. View classes include only code relevant to the user interface & reference only AdventureGameModelFacade or other View classes. - AdventureGameModelFacade makes all connections to internal Adventure Game classes. - Modifications represent clear logic: 5 points Program logic and data structures are clear and simple. - Code quality: 5 points - Each class is in a separate .java file. - All state variables (AKA instance variables, fields) are private, unless inherited fields must be visible in sub-classes; declare these fields protected. - Capitalize the first letter in class names. - Use lower case letters for variables that reference objects. - Use a hierarchical indentation scheme, but do not indent so far that your code wraps when printed. - Use good names for classes, variables, and methods --- names should describe the intent of the named entity rather than the algorithm. A name should be meaningful to the client --- a method name should describe what the method does, not how it does it. - Use the instructors code as a style guide. - Room descriptions should use correct grammar and spelling. - Other design criteria may be announced. ================================PART 3 ========================= Team Portion of Grade: Functionality - 30 possible points. This is for having a running system that allows someone to play the game as specified, through the GUI. You do not get any functionality points if your program will not compile or run. The program should run by invoking the main method in "cs314_A2.AdventureGameView". ================================================================ - Player can move from room to room using the new interface: 4 pts. - must be able to explore the cave system correctly. - must be able to bump into walls & remain in same room. - player can bring the gold bars to the outside. - should not crash. - User interface: 10 pts. - system functionality matches user interface requests. - responds to reasonable inputs without crashing. - complete/reasonable response to user's reasonable actions. - original terminal interface still works (implementation may change). - Player can pick up Items and drop them. 8 pts. - When the player pick up an Item it moves from the room into his/her hands. - Player can carry 2 items. - Room can contain 2 items. - Player can carry the goldBars out of the cave. - System acts appropriately if the player. - tries to drop an item that is not carried. - tries to drop items when his/her hads are empty. - tries to pick up items when the room is empty. - All methods have JUnit tests that pass: 8 pts. ===========================PART 4=============================== Individual Portion of Grade: Development Process - 20 possible points. ================================================================ - GitHub logs fshow at least 1 branch for each student on the team: 5 pts. - Branch name is descriptive of the changes made, including a way to tell which student is working on it. - Branch commits occur often, with a small amount of changes in each commit. - Branch commit logs are descriptive of the changes made. - Multiple pushes have been made to each student branch. - GitHub logs show the student has requested reviews of their proposed changes to the master: 5 pts. - GitHub logs show the student has reviewed their teammates proposed changes to the master: 5 pts. - GitHub logs show that all student branches have been merged into the master: 5 pts.