Items and location data from the data files
3 -1 4
becomes [['1','2','5'], ['3','-1','4']] OR [[1,2,5], [3,-1,4]]. It must be either one of these.
Objective
Your adventure game will allow players to try to find all of the required items prior to the exam starting.
In PyCharm, File > Open and select this directory.
Baseline Requirements
Each location in the game has an associated description. Keep in mind that a location does not necessarily have to be a "room" -- it could be a courtyard, a portion of a street surrounding the building, etc.
Print either a full or brief description upon each visit.
The "look" command prints out the full description of the current location.
Each location must be stored as an instance of the Location class provided in the starter code.
Each item must be stored as an instance of the Item class provided in the starter code.
MOVEMENT
READING FROM FILES INTO CLASSES
You are required to implement the game by writing an "adventure engine" that uses data files to obtain location and item information. In other words, information about the actual locations and items in your particular game should not be hard-coded, but should instead live in data files that are read by your program. (The benefit of this approach is that you can change your data files to create a new "game world", without touching your source code.)
items.txt
The sample data in these text files can be removed or incorporated into your game.
The (x, y) position of these locations will be used in your code, to determine movement from one location to another
The number "-1" is used to represent non-existent areas
Here, the only accessible locations are 1, 2, 3, 4, 5. The "-1" are empty areas.
So, from location 1, the player is allowed to travel only south. From location 3, the player is allowed to travel either north or east. And so on.
As an example for item data, we might store items in "items.txt" using a one line per item format, such as:
1 10 5 Cheat Sheet
Line 3: one line (i.e. brief) description of where you are. Brief descriptions are often used when revisiting a location.
Line 4: start of (long) descriptive text for the location. Multiple lines are permitted. The word END at the beginning of a line is used to indicate the end of the descriptive text.
As mentioned, the gamer wins the game if they are able to bring all exam-related items to the exam room before the exam starts. In your game, you should settle on the number of moves that the gamer is allowed to make prior to the exam starting. If they exhaust their allotted number of moves, then the exam starts and the gamer does not win.
You are not required to physically time the gamer. They can take as long as they like to play the game. What matters is the number of moves they make, not the actual wallclock time that elapses while they play. (Is look or inventory a "move"? That's for you to decide!)
QUIT
Another required command is "Quit", allowing the player to quit the game at any time.
All location and item data is read from external files "locations.txt" and "items.txt", and stored as instances of the Location and Item classes (the file structures and data structures used to store this info is up to you)
Minimum required items: T-card, Cheat Sheet, Lucky Pen
Each location has a description.
Full description is given when "look" command used, or when first visiting a location.
Make sure only items in inventory can be used or dropped, and only items in the current location can be picked up.
Score
Player can win the game
Player loses the game if max. number of moves reached
For a good description of the reasoning behind puzzles, and common types of puzzles, see this page all about puzzles. Some puzzles are rather elaborate, relying on performing specialized verbs on multiple items or imposing specific timing requirements. Your puzzles can be simple -- finding a key in a remote location from the door that it opens -- or more complex. Regardless, implementing puzzles will require that you extend the commands you support and/or extend the information you store in your data files.
If you wish to further increase the complexity of your game, in addition to this puzzle, you could implement any additional features you like (just keep it G-rated :P).
Give items a weight, and limit the total weight of items that the gamer can carry. (And why not add a puzzle that requires several items to be present at the same location, but which cannot be carried at the same time because they weigh too much?)
Please don't ask how many marks your enhancements will earn: we can't evaluate your code before the due date!
Settle the specification and plan your enhancements.
The specifications provided tell you what operations your program must provide, but not all the details of how it should behave under every circumstance. Go through all of the operations and make those decisions. For example, how does the gamer indicate that they are ready to "write the exam"? (This could occur automatically once all of the items are in the proper place, for example.) Next, plan what your puzzle(s)/enhancement(s) will be. If you have ambitious plans, you would be wise to have some simpler enhancements in mind, just in case you get behind. Finally, you should work with your partner to create a schedule for milestone completion. Write it down and refer back to it often.
Implement the movement commands.
Implement the directional commands (north, south, etc.) so that the gamer can travel between locations. Descriptions of locations should be displayed, including any items present there, but item manipulation itself will be left to the next milestone. Here, ensure that the gamer cannot travel in a direction that is not prescribed by your world map. For example, if a location has no exit to the north, trying to go north should yield a suitable "there's no exit in that direction" message or something similar.
Hand in all code and files inside your adventure project directory as an "adventure.zip" file.
This should include:
solution.txt, gameover.txt, enhancements.txt (described below)
Before you submit your project, place all of the files you are giving us in a new directory and try to run the game. If you receive unexpected errors, you're missing some of your required game files, and we won't be able to play the game.
This should be a plain text file that has one command per line, from beginning of the game to victory.
The commands in the file should be exactly as they need to be typed during gameplay.
This should be a plain text file that has one command per line, from beginning of the game to a game over state.
The commands in the file should be exactly as they need to be typed during gameplay.
These files should be named gameplay1.txt, gameplay2.txt, and so on.
Like the solution and gameover text files, these files should ONLY contain gameplay commands (one command per line) and NOTHING ELSE.
Remember that spelling of filenames, including case, counts: your file must be named exactly as above.
Important: Make sure that we can run your project simply by running the code in adventure.py.
Based on that, up to you to decide what the minimum number of locations should be. If you want to make a game so boring that all of the items can be found in one location, then you can make a game with one location (although it would be really hard to get all the four directional commands, and a score, and a max number of moves / lose condition applied to a game with just one location).
Q: Can I change the backstory?
World has many Locations
World has a single Player
'''
Algorithm:
brief_description = readline
long_description = readline # well not really, it could be many lines
Q: Can I change the format of locations.txt?
Yes. You may change the format of locations.txt and items.txt however much you like.
You are also allowed to remove/rename functions in Player, Location and Item class. (For the World class only, DO NOT REMOVE/RENAME anything, but you can still add things).
Marking Scheme
[_] Interactions with at least three items ("cheat sheet", "t-card", "pen")
[_] "Look" feature
[_] Program design and structure
> Reading Location data from external files into appropriate structures
> Code is of reasonable length; loops used appropriately to reduce repetitive code
> Helper functions used appropriately
[_] One puzzle that requires additional functionality to support (see enhancements.txt): Out of 10
[_] Creativity and difficulty of enhancements are considered (see enhancements.txt): Out of 10