game additions

.vscode/settings.json

@@ -0,0 +1,6 @@
+{
+    "java.project.referencedLibraries": [
+        "lib/**/*.jar",
+        "guava-31.1-jre.jar"
+    ]
+}

Item.java

@@ -0,0 +1,21 @@
+/**
+ * The item class creates items that have names, descriptions, and (if they can only be used a set number of times)
+ * sets their limited use and how many times they can be used. 
+ * @author tillie
+ */
+public class Item {
+    String name;
+    String shortDesc;
+
+
+    public Item(String name, String shortDesc) {
+        this.name = name;
+        this.shortDesc = shortDesc;
+    }
+    public Item(String desc) {
+        this.name = desc;
+        this.shortDesc = desc;
+    }
+
+
+}

Place.java

@@ -0,0 +1,79 @@
+import java.util.ArrayList;
+
+/**
+ * The place class creates the rooms that the player can exist in. These places will be added to the map. The places
+ * have a name, descriptions, and a boolean stating if it needs a key to be entered. Each place also has an 
+ * inventory that can be added to and taken away from. 
+ */
+public class Place {
+    public ArrayList<Item> inventory; // an arraylist of interactable objects within a given place
+    public String name;
+    public String shortDesc;
+    public String longDesc;
+    public String needsKey;
+    public boolean explored;
+
+
+    public Place() {
+        this.inventory = new ArrayList<Item>(); 
+        this.name = "name";
+        this.shortDesc = "shortDesc";
+        this.longDesc = "longDesc";
+        this.needsKey = "none";
+        this.explored = false;
+    }
+
+
+    public Place(String name, String shortDesc, String longDesc, String needsKey) {
+        this.inventory = new ArrayList<Item>(); 
+        this.name = name;
+        this.shortDesc = shortDesc;
+        this.longDesc = longDesc;
+        this.needsKey = needsKey;
+        this.explored = false;
+    }
+
+    public Place(String name, String shortDesc, String longDesc, String needsKey, boolean explored) {
+        this.inventory = new ArrayList<Item>(); 
+        this.name = name;
+        this.shortDesc = shortDesc;
+        this.longDesc = longDesc;
+        this.needsKey = needsKey;
+        this.explored = explored;
+    }
+
+    /**
+     * a getter method that returns the name of the place
+     * @return a String containing the name of the place
+     */
+    public String getName() {
+        return(this.name);
+    }
+
+    /**
+     * a getter method that returns the color of the key needed to enter a room.
+     * @return a string containing the color of the key needed to enter a place. 
+     */
+    public String getKeyColor() {
+        return(this.needsKey);
+    }
+
+   /**
+    * a method that allows an item to be added to the place's inventory
+    * @param item an item that will be added to the place's inventory
+    *note: there is a check that makes sure an item won't be added to a place's inventory twice.
+    */
+    public void addItem(Item item) {
+        this.inventory.add(item);
+    }
+
+    /**
+     * a method that removes an item from the place's inventory.
+     * @param item an item that will be added to the place's inventory. 
+     */
+    public void removeItem(Item item) {
+        this.inventory.remove(item);
+    }
+
+
+}

README.md

@@ -4,15 +4,43 @@
  - Your final codebase
  - Your revised annotated architecture diagram
  - Design justification (including a brief discussion of at least one alternative you considered)
+
+    We ended up with three separate classes(Game, Place, and Item) for our game. In the beginning, we actually had an additional Player class but we decided to integrate it into the Game class because Player was doing the same things the Game needed to do so it made more sense to make one larger Game class then have two slightly smaller classes that did mostly the same thing. The Game class essentially keeps track of the user’s progress and place in the game. It instantiates the entire map of the game, holds all the methods containing the player’s actions, and has a play() method that holds the do…while loop and prints the exposition and ending to the game. The main method also sits in the Game class - for simplicity in the main method, the Game.play() method was constructed so that the only code necessary in the main method was the construction of a Game object, and a call to the Game.play() method. 
+
  - A map of your game's layout (if applicable)
  - `cheatsheet.md`
  - Completed `rubric.md`
 
 ## Additional Reflection Questions
  - What was your **overall approach** to tackling this project?
+
+    We both knew that this sort of project would take a lot of time so from the first day we set up a weekly flexible meeting time so we would always have at least one chance a week to talk in person outside of class. We spent most of the first few classes just talking about what we hoped to include and what we thought wouldn’t work. This thoughtful approach, even though it slowed down the actual coding aspect of the project, helped us keep a clear idea of the project in mind. We made sure each of us was having a good time by assigning tasks that were enjoyable as well as challenging. For example, Reed did a lot of the storyboarding and creating descriptions for items and rooms as well as coming up with the puzzles the user would interact with along the way, while Tillie spent more time integrating and adapting those ideas into the actual code.
+
  - What **new thing(s)** did you learn / figure out in completing this project?
+    The biggest “new thing” to learn was definitely Guava maps. There were a lot of different classes to comb through before we could settle on the final one. We even had to change the class last minute from MutableGraph<Place> to ImmutableGraph<Place> after making a secondary design decision about how the take() method would work (previously thought it would add a connection between nodes if a room had been unlocked, scrapped that idea for the current procedure). Although it didn’t end up being used in the final iteration, we also learned a bit about the Pattern() and Matcher() classes, because there was a moment when we wanted to parse through the user-input action to find the secondary action specifier (i.e. ‘red key’ in ‘take red key’), but realized halfway through implementation that it was much simpler to just test for equality using String.contains(). 
+
  - Is there anything that you wish you had **implemented differently**?
+
+    It would have been nice to impose a size limit on the user’s inventory, so that if they took a lot of extraneous stuff, they would be forced to drop some items. Perhaps we could have even imposed a limit that forced the player to think about which keys they no longer needed, adding another layer of thinking ahead.
+
  - If you had **unlimited time**, what additional features would you implement?
+
+    If we had more time, we would have developed a relationship between the items in a room and the description that gets printed out when the user looks around. As is, taking an item does not change the description at all, but it would be more realistic for the Item() class to have some sort of attribute that gets added to the longDesc attribute of a Place() when it is added to the Place’s inventory. 
+
  - What was the most helpful **piece of feedback** you received while working on your project? Who gave it to you?
+
+    One piece of feedback we heard a few times (but primarily from Ian Eskesen) during workshop 3 was to make it clearer what interaction options were available to the user. This led us to capitalize every interactable item so that it was more clear to the user what was meant to be examined, picked up, etc. We were slightly concerned that it would be too much “hand holding” but reasoned that meta-knowledge infiltrates even the most open-world games, so it’s probably fine for this small-scale project. 
+
  - If you could go back in time and give your past self some **advice** about this project, what hints would you give?
- - _If you worked with a team:_ please comment on how your **team dynamics** influenced your experience working on this project.
+
+ We would tell our past selves that they have to consider making a smaller game than what they originally thought of. Our original game concept was about double the size with a whole mirror realm-rescue situation. While it was a great idea, we definitely didn’t have the time to achieve it so it's very good that we ended up cutting it down. Having it be smaller from the start probably would have lessened the collective stress though.
+
+ - _If you worked with a team: please comment on how your **team dynamics** influenced your experience working on this project.
+
+We had very good communication! Frequent discord messages, meetings, etc. Specifically the frequent meetings were very helpful in keeping each other up to date. Each team member played to their strengths in terms of planning and execution of the game idea. 
+
+Thank you to Reed for the amazing and wonderful idea of not doing a two-layered tower game when we realized how little time we had left…… the puzzle that ended up being executed was much more manageable and fun to play in one sitting!! 
+
+Shout out to Tillie for slaying so much of the code. I would not have been able to complete even a fraction of what they did in the given time by myself. 
+
+Also apologies to Jordan for the many many pull requests…

cheatsheet.md

@@ -2,7 +2,70 @@ This file will contain documentation for all commands available in your game.
 
 Note:  It's a good idea to also make this list available inside the game, in response to a `HELP` command.
 
+All possible player commands:
+move to [place]
+move to [color] [door]
+look around
+examine [item]
+take [item]
+drop [item]
+pour [color] potion
+exit
+print inventory
+print past locations
+help
 
 # SPOILER ALERT
 
 If your game includes challenges that must be overcome to win, also list them below.
+All possible player commands:
+move to [place]
+move to [color] [door]
+look around
+examine [item]
+take [item]
+drop [item]
+pour [color] potion
+exit
+print inventory
+print past locations
+help
+
+take brass key
+Move to entryway
+Take red key
+Move to red door
+Pour purple potion*
+(*Note:* here, you can immediately pick up the blue key, but the game will only tell you it is there if you pour the purple potion)
+Take blue key
+Move to entryway
+Move to blue door
+Examine rug*
+(*Note:* here, you can immediately pick up the orange key, but the game will only tell you it is there if you examine the rug first)
+Take orange key
+Move to orange door
+Examine pillow*
+(*Note:* here, you can immediately pick up the white key, but the game will only tell you it is there if you examine the pillow first)
+Take white key
+Move to white door
+Examine trash bin*
+(*Note:* here, you can immediately pick up the yellow key, but the game will only tell you it is there if you examine the trash bin first)
+Take yellow key
+Move to bedroom
+Move to study
+Move to entryway
+Move to yellow door
+Move to brass door
+Answer “yes” or “no” (this will have no bearing on the completeness of the game, merely a slightly different dialogue from the mage).
+[Game is complete]
+
+*Optional!!*
+*While in the kitchen, do:*
+
+Examine cabinet*
+(*Note:* here, you can immediately pick up the black key, but the game will only tell you it is there if you examine the cabinet first)
+take black key
+move to black door OR move to basement
+examine parchment
+
+*Literally nothing of consequence is in the basement, it is just a fun side area that makes the player think there is something larger and potentially more nefarious (or at least violating of building code) going on here*

rubric.md

@@ -1,48 +1,50 @@
 ## Front-End Design (10 pts)
 
-_____ 2 pts: Game has a **robust, understandable text-based interface** that allows the player to control their movement through the game.  Player should be able to enter any command at any time, and if it makes sense in the current context it will be carried out.
+**YES** 2 pts: Game has a **robust, understandable text-based interface** that allows the player to control their movement through the game.  Player should be able to enter any command at any time, and if it makes sense in the current context it will be carried out.
 
-_____ 2 pts: Submission includes a **cheat sheet** (`cheatsheet.md`) documenting all of the available commands, as well as a **description of the layout** of your game world's underlying physical layout; this can be described in words, or included as a separate image file if you prefer to sketch a map by hand.  If your game includes **challenges** that must be overcome to win, also describe them here.
+**YES** 2 pts: Submission includes a **cheat sheet** (`cheatsheet.md`) documenting all of the available commands, as well as a **description of the layout** of your game world's underlying physical layout; this can be described in words, or included as a separate image file if you prefer to sketch a map by hand.  If your game includes **challenges** that must be overcome to win, also describe them here.
 
-_____ 2 pts: Storyline driving the game is **engaging**, and individual elements of play make sense within the context of the story.
+**YES** 2 pts: Storyline driving the game is **engaging**, and individual elements of play make sense within the context of the story.
 
-_____ 2 pts: Game has **multiple possible paths / outcomes** (i.e. gameplay depends on player's choices and is not the same every time).
+**YES\*** 2 pts: Game has **multiple possible paths / outcomes** (i.e. gameplay depends on player's choices and is not the same every time).
 
-_____ 1 pt: Gameplay supports **reversible moves** where reasonable (e.g., if you pick up an object, you should be able to put it back down again later, possibly in a different place; if you go north then you should be able to return to the previous location by going south unless something has blocked your return path).
+\* The game has one "win path" but it is possible to wander around lost/confused for a while without conequence before finding the win conditions. Also, there's the basement which is just there for fun and has absolutely 0 effect on the game's final outcome. 
 
-_____ 1 pt: Some paths through the game have **restricted access** until the player has completed a task or acquired a specific item (i.e. a key to open a door, etc.).
+**YES** 1 pt: Gameplay supports **reversible moves** where reasonable (e.g., if you pick up an object, you should be able to put it back down again later, possibly in a different place; if you go north then you should be able to return to the previous location by going south unless something has blocked your return path).
+
+**YES** 1 pt: Some paths through the game have **restricted access** until the player has completed a task or acquired a specific item (i.e. a key to open a door, etc.).
 
 
 ## Back-End Design (10 pts)
 
-_____ 2 pts: Selected classes(s) are **effective, efficient** at supporting the desired operations and program behavior.
+**YES** 2 pts: Selected classes(s) are **effective, efficient** at supporting the desired operations and program behavior.
 
-_____ 2 pts: Design justification includes a discussion of at least one (reasonable) **alternative design** that could have been used, and the reasons why you decided against this alternative.
+**YES** 2 pts: Design justification includes a discussion of at least one (reasonable) **alternative design** that could have been used, and the reasons why you decided against this alternative.
 
-_____ 2 pts: The project makes effective use of **Java built-in classes** whenever they are appropriate.
+**YES** 2 pts: The project makes effective use of **Java built-in classes** whenever they are appropriate.
 
-_____ 2 pts: The project's design is **extensible** (i.e. someone else could pick up where you left off, adding on or modifying the game without requiring a total rewrite).
+**YES** 2 pts: The project's design is **extensible** (i.e. someone else could pick up where you left off, adding on or modifying the game without requiring a total rewrite).
 
-_____ 2 pts: Submission includes an **architecture diagram** describing the relationships between all classes.
+**YES** 2 pts: Submission includes an **architecture diagram** describing the relationships between all classes.
 
 
 ## General Items (10 pts):
-_____ 4 pts: Program compiles without errors or warnings.
+**YES** 4 pts: Program compiles without errors or warnings.
 
-_____ 2 pts: Executes fully & consistently without crashing (exception/freeze).
+**YES** 2 pts: Executes fully & consistently without crashing (exception/freeze).
 
-_____ 2 pt: Complies with style guidelines (missing items 1 pt each):
+**YES** 2 pt: Complies with style guidelines (missing items 1 pt each):
 
-      _____ Classes & class members all have Javadoc header comments.
+      **YES** Classes & class members all have Javadoc header comments.
 
-      _____ Clear and consistent indentation of bracketed sections.
+      **YES** Clear and consistent indentation of bracketed sections.
 
-      _____ Adheres to Java conventions on naming & capitalization.
+      **YES** Adheres to Java conventions on naming & capitalization.
 
-      _____ Methods & variables all have clear and accurate names.
+      **YES** Methods & variables all have clear and accurate names.
 
-      _____ Methods avoid confusing side effects.
+      **YES** Methods avoid confusing side effects.
 
-_____ 1 pt: All required files included with submission (including completed checklist file).
+**YES** 1 pt: All required files included with submission (including completed checklist file).
 
-_____ 1 pt: `readme.md` contains your reflection on the project and responses to all prompts .
+**YES** 1 pt: `readme.md` contains your reflection on the project and responses to all prompts .