Assignment

Get your copy of the assignment here: https://classroom.github.com/a/xUq-14uj

You may encounter "Non-managed pom.xml file found". You should select "Add as Maven Project"

This week's assignment is a creative exercise where you get to build a text adventure game! In the previous assignment, we asked you to find a JSON and parse it. This time, you'll actually be creating the JSON to our specifications and using it in a console adventure game.

Gradescope

There is no autograder for this assignment, but you still must submit your GitHub repository to Gradescope.

Goals

• Separating UI code from game logic code
• Receiving input from the console and sending it output
• Designing JSON from a list of requirements
• Designing a (hopefully fun and interesting) JSON representation of a game layout

Instructions

Background

The Adventure Game is a classic video game genre that generally features a protagonist exploring a map and solving puzzles. From Wikipedia:

Initial adventure games developed in the 1970s and early 1980s were text-based, using text parsers to translate the player's input into commands. As personal computers became more powerful with better graphics, the graphic adventure-game format became popular, initially by augmenting player's text commands with graphics, but soon moving towards point-and-click interfaces. Further computer advances led to adventure games with more immersive graphics using real-time or pre-rendered three-dimensional scenes or full-motion video taken from the first- or third-person perspective.

You'll be designing a text-based adventure game, where the user will input commands and your game engine will parse them into actions. You'll send back the feedback in text form to the user.

You'll also be designing a map for the game (no, not a Map<K, V>; the normal kind of map). Your map should have rooms with paths/connections to other rooms, and there should be a goal room that when reached, the player wins the game. However, you can also interpret this to be more of a story-based format where "paths" represent dialogue options; you have a lot of freedom here so long as you can interact with the world or story in some meaningful way.

Part 0 - Designing JSON

It's time to put your JSON knowledge to the test. We are going to describe the basic interactions an Adventure game needs to support, and it's up to you to include the relevant data in your JSON. Because of this, it is critical that you read through all the parts of this assignment before starting to write JSON, especially Part 2's command structure.

When designing a schema, you should always try to relate concepts in the simplest way possible. This simplicity may come from grouping certain fields together (e.g. creating a JSON object to group data about a game element), making the schema easily expandable to include new fields, and designing the schema to translate well to a Java object.

For designing an Adventure state schema, a good place to start is with nouns. Think about what the state needs to know and write it down. Then think of how all those things can be organized into groups. For example, the state would definitely include your current room. What fields would a room have and how do they translate to JSON?

Part 1 - Loading Game Data

You just created a JSON schema with all the data that your game needs, but now you need to load it for your game engine to consume.

The first thing you should tackle is creating POJOs corresponding to the objects in your JSON. Because you are the architect of the schema, you can go back and change the JSON if you find a better way of expressing your objects.

You should have experience loading JSON from the last assignment; in this assignment, you may use GSON or Jackson again to preform this task. However, this time loading JSON is part of your application, so you must handle & test it. Pay attention to what happens when:

• A JSON doesn't conform to your expected schema
• A file doesn't exist or can't be read
• Any other edge case specific to your use case arises

, and be sure to handle these cases gracefully.

Part 2 - The Game Engine

You now need to write the brains of your game. Once again, we are giving you a lot of freedom in how exactly you accomplish this, but we have some basic interactions we would like to see. The game should accept input from the user in the console, and should output data back to the console.

Because you are requesting user input, it would be helpful to have a prompt. A prompt is a small string that gets printed at the beginning of the line in the console to indicate that the user should type input. Before you request input from the user, we'd like you to print this prompt: "> " (a greater than sign followed by a space). To accomplish this, think about what System.out.print does differently than System.out.println.

Below are the interactions your game must support. Note that the examples are collapsed for ease of reading purposes, but they represent exactly how we want your console interaction to work, so pay close attention to them.

Quitting

If the input is either quit or exit, then the game should wrap-up and the program should exit.

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> quit

Moving Around

If the input matches the pattern go <direction_name>, then the current room that the user is in should change to the room in that direction.

Whenever a room is visited, it should print the room's information, including its name, description, possible directions, and items.

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> go East
You are in the west entry of Siebel Center. You can see the elevator, the ACM office, and hallways to the north and east.
From here, you can go: West, Northeast, North, or East
Items visible: sweatshirt, key

If the user inputs an invalid direction, then the game should inform them it can't go that way by saying: I can't go "<direction_name>"!

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> go Eastward
I can't go "Eastward"!

Reaching the ending room should result in the room description being displayed (this could be some "win" text; it's up to you), and the program should exit.

You are in your room, in front of your computer.
From here, you can go: log in to Zoom
Items visible: keyboard, mouse
> go log in to Zoom
You've made it on time to code review; you win!

Examining a Room

If the input is examine, the game should repeat the information about the room, including its name, description, possible directions, and items.

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> examine
You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin

Items

If the input matches the pattern take <item_name>, the room should attempt to give that item to the user.

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> take coin
> examine
You are on Matthews, outside the Siebel Center
From here, you can go: East

If no such item exists in the room, then the game should respond with There is no item "<item_name>" in the room.

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> take icard
There is no item "icard" in the room.

If the input matches the pattern drop <item_name>, the user should remove an item from their inventory and place it in the room.

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> drop icard
> examine
You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin, icard

If the user doesn't have the item, the game should respond with You don't have "<item_name>!".

If the room already has that item, the game should respond with The item "<item_name>" is already in this room!, and it should not add the duplicate.

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> drop proof that P=NP
You don't have "proof that P=NP"!
> drop coin
The item "coin" is already in this room!

User-Friendly Commands

Your goal should be to design a consistent yet user-friendly experience for your players. As such, you should be able to handle casing errors and extra whitespace.

You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin
> go       East
You are in the west entry of Siebel Center. You can see the elevator, the ACM office, and hallways to the north and east.
From here, you can go: West, Northeast, North, or East
Items visible: sweatshirt, key
> TAKE SWEaTSHIRt
> examine
You are in the west entry of Siebel Center. You can see the elevator, the ACM office, and hallways to the north and east.
From here, you can go: West, Northeast, North, or East
Items visible: key

Note you don't need to worry whitespace handling for stored values like direction names, item names, etc, as shown below.

You are on Matthews, outside the Siebel Center
From here, you can go: up and out, East
Items visible: coin
> go   up    and   out
I can't go "up    and   out"!

Unknown Commands

If the user types anything that doesn't match the above specification, then you should inform the user that they typed an invalid command.

You are on Matthews, outside the Siebel Center
From here, you can go: up and out, East
Items visible: coin
> fly airplane
I don't understand "fly airplane"!

Part 3: Custom Feature

In addition to the features listed above (movement, items, and quitting), you should implement your own custom feature. You have a lot of freedom on what this feature can be, however there are a couple stipulations:

1. The feature cannot be trivial to implement. It cannot be a slight variation of a required command nor can it rely on the code used in those commands for the most part.
2. This isn’t the main part of the assignment; It shouldn’t take more than 1-2 hours so don’t stress out over it.

Here are a few examples of valid custom features to inspire you:

• A command that prints your history of traversed rooms, in order
• A command that prints the shortest distance between two rooms (feel free to look up algorithms for this)
• A feature that interacts with a web API in some creative way (here are some examples)
  • You could use a riddle/trivia API to create puzzles that block your path
  • You could use a profanity checking API to react in some interesting way (like when your user gets super frustrated at your Desert Bus homage map)

Testing

Testing might seem a little bit nebulous for a large user-facing project like this. Certain designs will be more testable than others, so try to think about how you can design your classes & methods to be easily testable. You should be able to isolate smaller units of your total operation into unit tests.

Deliverables and Grading

For the project to be considered complete, your submission must:

• Have a JSON Adventure map of your own design.
• Have a game engine that players can interact with through the console.
  • Must parse the JSON you wrote to initialize its data.
  • Must handle all the commands and edge cases listed above.
  • Must implement (at least) one custom command/feature as specified above.

As always, many points on this assignment are made up of aspects of your physical code and your design. Keep using correct style conventions according to the Google Java Style Guide, and think about how you can make a large application like this modular.

We're also paying a lot of attention to Object Decomposition on this assignment, as you will be working with a variety of objects. Make sure you are placing methods in the classes where they make the most sense, and also make sure data flows through your objects in a clean, extensible manner.

Assignment Rubric