Stranded: The Rover Game

Objectives

Use object-oriented design and 2D arrays (Phase 1 & 2)
Implement and use a List ADT as linked nodes (Phase 3)
Implement and use a Stack ADT as linked nodes (Phase 4)
Implement and use a Queue ADT as a circular array (Phase 5)
Do a Big-O analysis on an ADT (the Queue) implementation (Phase 5)

The Story

The year is 2022. Personal space transport is common and you have taken your space ship out exploring. You find an ancient abandoned planet and decided to land and investigate. There was a huge storm as you landed and your ship now lies in pieces on a landing pad. There is no oxygen in air but you are able to move around in your rover. You have a repair manual, which tells you how to fix your ship, but you don't have the needed spare parts.

You see strange items scattered around on the ground. Maybe they will be useful. You also see strange glowing orbs big enough to swallow your rover. When you touch one, you get sucked in and appear in another place with items and orbs. The orb was a portal! When you re-enter the same portal, it takes you back where you came from.

Your goal is to move about the portal system and collect enough spare parts to fix your ship.

Other Phases

Phase 1 | Phase 2 | Phase 3 | Phase 4 |

Phase 5: Completing the Game

This is the final section of the project: Your Rover is in a race against time to fix the ship. You must collect items across the Martian landscape to repair your ship. However, as time passes in the brutal climate, more things go wrong, leaving you with more things to fix before you can get off the planet. If you aren't quick enough at repairing your ship, you may find yourself permanently stuck on Mars.

Your objectives:

Create and display tasks that the Rover must complete to fix their ship.
Build a task queue that keeps track of upcoming tasks.
Build functionality to complete tasks - repair parts of your ship
As time passes, add more tasks to your task queue.

Think about what new classes (if any) that you should create to fulfill these goals. Design matters! Don't have a class do too much!

Task Generation

Tasks are shown as a string in the task field of the GUI (much like the inventory):

Broken Engine! To fix the engine, you will need:
- 3 Screws
- 2 Cakes
- 1 Cabbage

When the game first starts, you should randomly generate 2 tasks for the user to complete. The first should immediately be shown in the task window.
Every X steps that the rover moves, a new task is automatically generated and added to the queue. I'll let you decide what a good X is.
When all the tasks are completed, the task window tell the user that they have won the game!

About Tasks

Each task has accompanying text (like "Broken Engine!" above)
Each task must have exactly 3 types of supplies that it requires
The types of items must be randomly selected
The amount of each item must be randomly selected
The string given to the GUI must fit in the space provided
The ".ppm" extension of an image name must not be displayed

Storing Tasks in a Queue

Tasks should be stored in a Queue
The Queue is implemented as a circular array
Once a task is completed it should no longer be in the queue
Tasks should be enqueued in the order that they were created (and as a result, should be dequeued in the same order).

Fixing Your Ship

To complete a task, the rover must successfully repair the specified ship part.
To repair a ship part, the rover should be on top of the relevant broken part (as specified by the task). When the player hits the Perform Task button, the items get used up (assuming they have enough of the part).
When a ship part is repaired, its image should show that it is repaired.

Creativity

For the last 10% of your grade, you are encouraged to augment your project in any way that you'd like. No matter what you do you must include a README.txt file describing your functionality.

We will roughly use the following guide to grade creativity:

0 PTS: No viewable additions to the Rover Project
2 PTS: Trivial change that essentially require copy-and-paste (changing an image)
5 PTS: Multiple small changes.
8 PTS: At least one change that requires significant thought
10 PTS: Either a single change or series of changes that shows exceptional creativity or effort.

Grading Breakdown

Graded item	Number of points
General Running
The rover and ship components and the parts all still have working images	3 pts
The quit button still works	3 pts
The rover can still move	3 pts
The rover can still stand on things	3 pts
The rover can still go through portals	3 pts
The inventory still works	3 pts
The pickup button and way back button both still work	3 pts
Queue
Something about tasks must be stored in a Queue ADT written by the student (not built into python)	4 pts
The queue is implemented as a circular array (a Python list or the 204Array from a previous lab)	4 pts
The queue methods are appropriately named enqueue and dequeue	3 pts
The queue code contains only generic things (no mention of your game)	3 pts
Perform task button
A) Task button works when pressed if:
Inventory contains needed items	5 pts
Rover is standing on correct broken component	5 pts
B) After the task is performed:
Used items leave the inventory	5 pts
Ship component image becomes fixed	5 pts
A new task is brought up (or the user has won the game)	5 pts
Tasks
The top task in the queue is the one that is displayed in the GUI	3 pts
Each task is displayed with a name	3 pts
The types of supplies will be randomly selected from the possible types of supplies	3 pts
Tasks use exactly 3 types of supplies	3 pts
The amount of items is randomly selected	3 pts
Good design principles used
Every method has a docstring	3 pts
No methods are too long	3 pts
Uses classes to hide some functionality	3 pts
Creativity	10 pts
[every person on team] Can adequately explain any block of code in solution requested by Prof. Dancy	6 pts

Total	100 pts