Stranded: The Rover Game

Objectives

1. Use object-oriented design and 2D arrays (Phase 1 & 2)
2. Implement and use a List ADT as linked nodes (Phase 3)
3. Implement and use a Stack ADT as linked nodes (Phase 4)
4. Implement and use a Queue ADT as a circular array (Phase 5)
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.

Getting Started with the Code

First, copy the code from the following directory: ~csci204/2019-fall/student/projects/p2Dancy/
We have provided an executable prototype of the game. You should see the following set of files in your project folder:

• Game.py the file you need to edit. Contains the framework for the game. Also contains code that communicates with the GUI (Graphical User Interface)
• gameboard.py and graphics.py contains the remainder of the GUI code. You should not have to edit these files.
• .ppm files that provide the image files for the game

The Point class

The GUI makes use of a Point class - a basic data structure that simply holds an x and y attribute. This class is used in the get_rover_location() and get_image() methods.

class Point:
  def __init__(self, x, y):
    self.x = x
    self.y = y

Existing Functions (Game.py):

• go_up, go_down, go_left, and go_right methods. When the arrow buttons are pushed in the user interface, these methods are automatically called. Your Rover should move one space in the direction specified.

• Look carefully at the implementation of get_image in Game.py. It accepts a Point as the input, which (as we showed earlier) contains Point.x and Point.y.

  • Whenever the game starts or someone hits a button, the game will automatically call the get_image function for every single coordinate point in the room. This is similar to how Ecosystem's get_inhabitant(self, index) functioned in your previous project. Now, we are operating in two dimensions, and instead of returning an object, we are directly returning the image name.
  • The role of the function is to return the name of the image at Point.x and Point.y. For example, if a portal is at point x and y, return "portal.ppm".
  • Note that there are different functions to get your Rover's image and coordinates. You should never return "rover.ppm" here.
  • Currently, the function returns a random image (no matter the input) so that the interface works. This is why all the images jump around on the screen. You should delete this code.

• get_rover_location: this function should return the current position of your rover - expressed as a Point object

There are a lot more methods that you'll eventually need to complete as we progress through the game development.

---

Phase 1: Rover Movement

The goal of part 1 is to focus on your class design and to build movement into the system.

Overview

• The initial room must appear with all its contents correctly generated
• The rover must be able to walk around the room in response to pressing the arrow buttons
• The portals do not have to go anywhere yet. The Tasks, Inventory, and rest of the buttons do not have to work.

Configuration Details

• The rover must start at a random location in the room.

  • When the rover moves, it can be on top of other items in the room.
  • You'll have to consider what should happen when the rover is near a wall. Should it stop? Should it wrap around to the other side? This is up to you.

• The ship must have at least 3 different kinds of ship components and at least 6 ship components in total.

  • The ship components should be roughly in the middle of the room and must be adjacent (touching each other). You can hardcode where in the room they are by putting the exactly coordinates in the code.
  • At least 4 of the ship components must be broken (use the images we provide).
  • To figure out what the possible ship-components are, see the image files provided.

• There will be a random assortment of parts (gears, screws, cake, etc.) scattered around the room. There must be at least 4 different kinds of parts.

  • Use randomness for both the number and location of the parts
  • The total number of parts in the room should be roughly similar to the picture above. While there is quite a bit of flexibility, your room shouldn't be packed full of objects.

• There will be at least 2 portals. Use randomness for both the number and location of the portals

• No two items (ship components, parts, portals) may be in the same location

OOP Design

Although the design is largely up to you this time, think carefully about how you will structure your program. We are going to progressively expect better design from you each project, and a portion of your grade will be based on this design. Here are a few things to consider

• Portals, Parts, and ShipComponents all have certain things in common. How should you express that relationship?
• Create a class that represents the current Room that you are in. Keep in mind that you will have to create many rooms in future parts of this project.
• Create a class that represents a Rover

Think carefully about the relationships between these objects. This is the hard part of design! But if you do it right, it will make all your future parts go much smoother.

---

Phase 2: An Infinite Universe

The universe is infinite. This means that you could constantly walk through portals into new rooms. The objective of phase 2 is to make the portal system functional.

Portals

Portals are inter-dimensional doorways to other rooms. If the rover steps on a portal, it must go through the portal. It will arrive on a portal in another room (and not get sucked back through until it steps off and on again).

• Portals must be connected in a permanent 1 to 1 relationship. This means that if portal A connects to portal B, no other portal connects to A or B. A and B are never disconnected. It also means that if the rover goes back through portal B, it should pop out on portal A
• Rooms after the first one will have parts and portals but not any ship-components. Each new room should also have a random configuration of parts.
• If the rover steps on a portal, it is transported to another room on top of another portal. It must step off the portal before it is allowed to reenter.

Implementation Hints

• Add a current_room data attribute to the Game class. Always keep this variable updated with a reference to Room the rover is currently in. You'll have to think carefully how you will keep this reference updated as the Rover goes through portals.
• Consider writing a Portal class. Think about what information the Portal class needs to know about (what other objects in your game).
• When the rover steps on a portal for the first time, create a new room and fill it with random parts and portals. Connect one of its portals to the portal the rover just entered.

---

Phase 3: Gathering An Inventory

The objective of phase 3 is to make the inventory and 'pick up' button work. Whenever the 'pick up' button is clicked in the interface, pick_up(self) will be called in your Game class. The rest of the implementation is largely up to you, but you should follow these rules:

• The rover can pick up the parts (cake, gears, etc.) lying around the room.
• The rover cannot pick up the portals or ship-components
• If the rover is standing on an empty space, portal, or ship-component and tries to pick it up, nothing happens.

Inventory in a List

The inventory is a list of parts the rover is carrying. The inventory shows as a string in the inventory field of the GUI. Think carefully how you want to design your Inventory so that you can keep track of the number of each item.

• Parts in the inventory must be stored in a List implementation.
• The List is implemented as linked nodes
• Each node in the list should have a name field
• A part is only kept in the list if its count is above zero

The get_inventory(self) function in Game.py will expect you to return a string representing your current inventory. For Example:

3 Cabbage
1 Screw
2 Gear

• A part is only in the inventory if its count is above zero
• Parts displayed in the inventory must have names (such as Cake or Cabbage)
• Parts must be displayed with their count
• The string given to the GUI must fit neatly in the space provided for the inventory
• The .ppm part of an image name is not displayed.

---

Phase 4: Finding the Way Back Home

• The portal system and Way Back button must now be fully functional.

As your rover travels deep into this barren world filled with both vast desert landscapes and delicious cake, it's likely that you will get lost. How do you find your way back to your ship? To help the rover, you'll implement the Way Back button. Whenever this button is hit, the room's portal that contains a path to your ship will change color. This will allow you to always get back to your ship.

Notes and Constraints

• When the player hits the Show the way back button, the GUI will call show_way_back().
• The rover should NOT magically teleport home. It must make the journey itself.
• As soon as the rover enters a 'flashing' portal, revert all portal images from that room to normal. The portal shouldn't stay flashing after you've entered it.
• As you make your way back to your ship, you should have to hit the button again for each room that you enter. Hitting the button shouldn't light up ALL the portals on the path to your ship - just the one in your current room.

Implementation

Whenever you have to develop a feature that allows users retrace their steps (either in a browser with the back button or ann app with an undo button), your mind should jump to using a Stack. Think carefully about how you should use a Stack in your program to recover the rover's way back home.

• What should you store in the Stack?
• When should it push?
• When should it pop?

We are intentionally leaving these details open for interpretation. It's up to you to decide the way to make your program functional. Don't forget to do lots of testing!

---

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.