Assignment

Get your copy of the assignment here

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.

Note: For this week's assignment, you should only work in the adventure directory in the student folder; ignore the server directory for now. Similarly, don't modify any of the given files in the resources folder.

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. Hardcoding all of the rooms & game data into your codebase is inflexible and cluttered, so we will instead use JSON to store data about your map, items in your game, etc. To help get you started, we've provided a sample JSON with a couple of objects filled in: rooms, directions, and an outer layout object. There are three object types described in the given JSON:

Direction

{
  directionName : String
  room          : String        // the String name of the room this direction points to
}

Room

{
  name		    : String
  description	: String
  directions	: Direction[]
}

Layout

{
  startingRoom	: String        // the String name of the room the player starts in
  endingRoom    : String        // the String name of the room the player must reach to win
  rooms		    : Room[]
}

These three are enough to define rooms that your player can traverse by specifying what direction they wish to move in. However, we'd like to add a little extra ingredient. For this week, your game should handle in-game items! An item has a name and any other properties you'd like to add to it. Rooms can store items (representing the item is present in the room). With all of this information, you need to add items to your JSON, as points will be lost if you hardcode items in the code. There is not one correct way to do this, but you'll need to figure out how to modify the given schema to include items on your own.

The example JSON provided is a bit boring... so we want you to create your own adventure map JSON! Try to come up with something creative and with at least a couple more rooms than the example JSON. Feel free to theme it to your interests, e.g.: a favorite show or video game. Using the example JSON as a guide should prove very helpful; just don't forget to add in items.

You could complete this part at any time, but we recommend doing it before you get too deep into your design.

Part 1 - Loading Game Data

You just finished 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. The three objects described in the section above correlate nicely to Java objects, but the design for the Item object is up to you.

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 a special win-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 add another copy of the item.

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
> examine
You are on Matthews, outside the Siebel Center
From here, you can go: East
Items visible: coin, coin

Duplicate items are treated as equals in our specification. If you extend your game to give items with the same name unique properties (like two iron pickaxes with different durabilities), you should define an order for which gets picked up first, or provide a follow-up prompt to the user to choose which they specifically want.

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 about 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"!

[Optional For This Week] Custom Feature

Next week, you will be extending this assignment further. One of the tasks you will be working on is a custom feature for your game. Note, this is not due this week, but if you finish early on the above specifications, you can get a head start on next week. You have a lot of freedom on what this custom feature can be; however, 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.

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.

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 [updated]