CS-314, Spring 2016
Assignment 5. Apply Design Patterns to Enhance the Adventure Game

Using design patterns to enhance the Adventure Game.

This is an assignment with both team and individual portions.

Check the A5 discussion on the Discussion board regularly.

(Expect Updates.)

DUE Wednesday 20 April 2016, 11:55 PM

CREDIT: 100 assignment points possible.

Updates:

• 4 April 2016: To prepare the UML class diagram of the AdventureGame Model code involved in your implementation of the Abstract Factory Pattern, you may either (a) use an available UML modeling tool, or (b) scan a legible hand-drawn model. Your UML class diagram must be submitted as a PDF file.

Use the instructor's Adventure Game implementation and your solutions to Assignments 2 (A2), 3 (A3), and 4(A4) as the starting point.

You may enhance either the Android interface from Assignment 4 or the Swing interface from Assignment 2.

User Stories:

User Story 1: As a game player, I want to be able to choose a level of difficulty for Adventure game, so that the game is more challenging.

Acceptance Criteria:

• The game has at least 2 levels of difficulty: Level 0, the version from prior assignments, and Level 1, a new level with additional properties and behaviors.
• Difficulty level is reflected in at least Rooms and Items.
• The game doesn't crash or fail, and all commands work properly with each of the different levels of difficulty.

1. Split story 1-A: As a CS 314 student, I want to refactor the game to use the Abstract Factory design pattern so that I can use factories to create at least 2 difficulty levels.

Acceptance Criteria (AC):
• The cave creation mechanism uses the Abstract Factory pattern.
• The abstract factory supports at least 2 levels: Level 0 is the version from prior assignments, and Level 1 has additional properties and behaviors.
• A description of the mechanism that you used to support "levels of difficulty" is created.
• The User Interfaces and Facade are adapted to allow users to select the level of difficulty.
• The User Interfaces work either on Android or on Java (i.e. Swing).
• UML class diagram(s) of your AdventureGame Model Java code that is involved in your implementation of the Abstract Factory Pattern are created.
• New tests are written and pass. Any defects they find are fixed.
• All previous tests run and pass.
• Meet 'Definition of Done' (DoD), below.
2. Split story 1-B: As a CS 314 student, I want to add entities and behaviors for at least Level 1 so that there actually are differences between Level 0 and Level 1.

Acceptance Criteria (AC):
• The game supports at least 2 new entities and 2 new behaviors for Level 1. (See the Notes section below for ideas.)
• A description of the other enhancements that your team has made to the Adventure Game is created.
• UML class diagram(s) of new/changed entities and behaviors are created.
• If you change the configuration/layout of the cave labyrinth, you must submit a UML object diagram (that is, a map) of the new configuration.
• New tests are written for the new entities and behaviors and pass. Any defects they find are fixed.
• All previous tests run and pass.
• Meet 'Definition of Done' (DoD), below.

User Story 2: As a game player, I want to be able to save and restore a game state, so that I don't have to play the entire game at once.

Acceptance Criteria:

• The game can be stopped and later restarted.
• The game doesn't crash or fail, it can be stopped at any time, and it always restarts exactly where it should.

1. Split story 2-A: As a CS 314 student, I want to add save and restore game state to the cave creation so that the game supports this function.

Acceptance Criteria (AC):
1. Complete game state can be saved at any time.
2. Game restoration occurs properly - all necessary state is restored.
3. Game play resumes properly after a restoration.
4. A description of the mechanism used to configure a cave configuration from a file and to save and retrieve games is created.
5. New tests are written for game saving, restoration, and continued play and pass. Any defects they find are fixed.
6. All previous tests are run and pass.
7. Meet 'Definition of Done' (DoD), below.

Definition of Done (DoD):

For all user stories:

• GitHub main branch code runs with no warnings and a user can execute all commands at least using the GUI.
• All code changes are reviewed before being merged onto the main branch (see A1, tutorial 5 for instructions on the GitHub Pull Request Code Review System you must use for reviews)
• All code changes are merged into the main branch

For CS314 development:

• All work is done on individual branches with frequent commits and pushes to GitHub before being merged onto the main branch.
• Commit messages include user story and task
• All user stories and point estimates are in GitHub
• All tasks and time estimates and actual time taken are in GitHub
• The overview.txt file for A5 has all required items in it

Notes:

Ideas for Level 1 Rooms, Players, and objects:

• A flashlight that a player can carry. The flashlight has a battery that can lose power as the game goes on. Flashlight might be a subclass of Item, with a battery attribute, or a battery might be another kind of Item.
• Dynamic cave changes. An earthquake or other event might rearrange the cave configuration while a game is underway.
• An enchanted room might change its connections or description, or do something else weird.
• A knapsack that a player carries. A knapsack could carry several items. A knapsack could be a new Item subclass.
• Doors could rust shut, and not open without oil.

Patterns:

• See the text book for explanation of the Facade design pattern, or do a Google search on "facade pattern".
• You can find many references on the Abstract Factory design pattern. The web page by Stephen Wong and Antonio Garcia Castaneda is an example.

Other deliverables:

• Levels of difficulty: Explain how you implemented and used the Abstract Factory design pattern.
• Other enhancements: Clearly explain your enhancements using one paragraph per enhancement.
• Game save/restore: Include a less than 1 page description of the syntax of cave configuration and saved game files. This may involve a BNF grammar or other notation, if necessary, in order to explain the structure of any files created. This discription should be brief, yet still explain your design. We should be able to understand your design after reading your explanation.

---

Tasks:

1. Continue splitting the user stories if needed. With your team, estimate story points for all split user stories. If you find a split story still has 13 or more story points, split it.

2. With your team, create the tasks needed to implement each split user story so that the Acceptance Criteria can be met. Make sure to meet the definition of done listed above. Add to your team's definition of done if needed. Estimate the number of hours for each task. Create tasks that are between 1 and 10 hours long.

3. Decide which teammembers will be working on which tasks.

4. Add the split user stories and tasks to the UserStory folder of your project, one text file for each user story: e.g. A5-US-1.txt. Please see previous assignment A2, A2-US-1.txt, for an example file format; estimated story points and task estimated and actual times must be included.

5. As each person finishes a task, update the task information in the respective User Story file to include the time it actually took to complete.

6. Make sure the plain text file in the src directory called overview.txt has been modified by each person so that it contains the information required in A5rubric.txt.

7a. If you use Android Studio: create a zip file named cs314Android_A5.zip, which includes all source code (java and xml files) in your solution.

7b. Your Eclipse project: create a jar file named cs314_A5.jar which includes the entire Eclipse project sources, test sources, the overview.txt file, and the user story file(s) (e.g. A5-US-1.txt). (See A5rubric.txt, PART 2 for details on the required jar file structure.)

8. Submit your jar files to the Canvas dropbox for Assignment 5 (A5) to check-in your assignment.

Post questions or comments about this assignment, or problems with the design to the Assignment 5 Discussion on the Canvas discussion board, or send email to cs314@cs.colostate.edu.

---

Grading: (for details see A5rubric.txt)

1. You will receive a team grade based on the Canvas submission, your tests, test results, and game functionality as demonstrated to the TA.

2. You will receive an individual grade based on GitHub logs of your repository submissions and review system comments. Each team member is expected to have created and used branches for their own work for A4, with frequent pushes from their local systems to GitHub, and review requests when they are ready to merge to the master. Each team member is expected to review code changes proposed by their teammates and provide comments.

---

Return to CS-314 Home Page