Project 2b

Due Date: Tue 20 Nov

Pair Project


An understanding of
  • object-oriented modeling and design
  • SOLID and other design principles
  • Model-View-Controller (MVC) architecture
  • basic design patterns and their implementation in Java
  • graph representation and algorithms
  • Android graphics features


This project stage builds on your design work from the previous project stage. The overall goal for this stage is to develop an interactive application that allows a human player to move around a terrain. We will add other kinds of actors and objects during later stages.

User interface

In this project, you are encouraged to use your imagination to create a touch interface that provides a good playing experience.

Overall design

The suggested overall user interface design is as follows:
  • wide button at the top for moving up to the terrain layer above us
  • two-dimensional view of the current terrain layer
  • wide button at the bottom for moving down to the terrain layer below us
  • menu for other actions such as restarting or quitting the game
You are expected to follow the current design guidelines for the platform of your choice.

Terrain viewport

You will need to create a view-controller pair for the two-dimensional view of the current terrain layer. 
  • Each visible terrain location should be clearly represented by a square big enough for the user to tap comfortably with a finger or thumb (see also these guidelines). This constraint should dictate the number of terrain locations currently shown. For example, in landscape mode, the screen of my phone is about 10cm wide and 6cm tall. If each location is a 1 cm square, then we can show 10 x 6 locations at a time. 
  • Each type of terrain location should be represented by a square of a certain color, for example, green for land, blue for water, brown for swamp, etc.
  • The view should behave as a viewport of the current terrain layer and support swiping for changing the current position of the viewport relative to the whole terrain layer. (Google Maps serves as an example of this concept.)
  • Add any useful visual enhancements you can think of, such as small arrows indicating the connections between adjacent locations.

Controllers and behavior

The player moves around the terrain manually as follows:
  • The player can move to a reachable neighboring location by tapping that location. Because not all connections between locations are symmetric (bidirectional), those that are reachable should be highlighted visually by, say, a bright border.
  • The player can get stuck in certain kinds of locations, such as swamps. (In a later stage, we will allow the player to carry objects that enable him or her safely to enter certain kinds of locations; example: a flotation device for going into water.)
  • The up and down buttons are enabled only when the current location has a connection to the layer above or below, respectively.


You will need a rich internal model to represent the various objects in the game.


Your first job is to create a (Java) interface for locations. Locations are the basic units of the terrain where the game is played. They are responsible for having zero or more neighbors; this relationship allows an actor to move from this location to a neighbor (in this one direction only; there might or might not be a relationship for the opposite direction, but this is the neighbor's responsibility).

Start by creating an enumerated type to represent the directions for the six possible neighbors in three dimensions: the four cardinal directions as well as up and down.

Now create a location interface Location that maps zero or more directions to actual neighboring locations. There should be a mapping only when the corresponding neighbor is present. The Location interface should specify these capabilities:
  • add a neighbor at a certain direction
  • provide a list of neighbors
  • allow an actor to enter the location
  • allow an actor to leave the location
Finally, create a class DefaultLocation that implements this interface. Reuse suitable building blocks from the Android framework. This implementation should be able to 
  • have a unique string name
  • produce a string representation of the location in a standard way (toString)
  • log whenever an actor enters or leaves by printing, e.g. "location <lname> entered by actor <aname>"


Your next job is to create an interface Actor for actors that move around the terrain. For now, the actors have limited capabilities. They are able to explore the terrain, giving a starting location. 

Now create an abstract class AbstractActor that keeps track of its name and current location.

Finally, create a class Player that inherits from AbstractActor that is able to explore the terrain in different ways. 

Portable items

Now your job is to create an interface Portable for carriable items. For now, this item does not need any specific capabilities.

Create a Breadcrumb class that implements Portable. Breadcrumbs come in different colors (use

Location Enhancements

For good reasons discussed in class, additional capabilities of locations are provided not using inheritance but in the form of wrapper or plugin classes that enhance individual location instances as needed. (We will discuss these mechanisms shortly in class.) For now, we will support only one capability or characteristic:
  • holding zero or more objects (such as markers)
Your job is to design these enhancements in such a way that they allow actors to explore the terrain. This means that locations need to provide the actor with a way to find out what enhancements are present at a given location.

You should not use either of the following approaches to enhance the capabilities of a location:
  • inheritance
  • implementing the capabilities in the Location class itself

Main Program and Specific Terrain

Upon application startup, programmatically build a terrain you would not want to be trapped in:
  • at least 50 locations total
  • dead ends
  • one-way passages
  • one-way cycles
  • representable as a vertical stack of horizontal layers
    • first design each layer separately
    • then stack them
    • and create a few connections among adjacent layers
  • at least three layers
Then pick a starting position for the player and center the viewport around that position.

Written Portion

In about 600-900 words (two to three pages), succinctly describe how you used each of the following design principles and patterns in your implementation and discuss to what extent the pattern simplified or complicated matters.
  • single responsibility principle
  • interface segregation principle
  • Decorator
  • Observer
  • Singleton
  • factoring out for future expansion (Coad, Design with interfaces, section 3.3.4)
In particular, discuss whether you used wrappers or plugins for providing enhanced capabilities to locations.

In addition, summarize your experiences with pairing and how it affected the following aspects of the development process:
  • How did you structure tests and split up efforts in light of pairing?
  • Was there a combination of white-boarding/sketching vs. just coding and running?
  • How did you approach functional vs. non-functional aspects in pairing and the TDD process? (E.g., a working visual UI is most gratifying, while non-interactive portions often require some setUp/tearDown fixtures for testing)

Have fun!!!

Nonfunctional Requirements

  • Try to adhere to the usual coding guidelines.
  • Continue to follow test-driven development (TDD) by creating automated unit tests for your various program components.
  • Reuse suitable Java/Android library components whenever possible instead of building your own. In particular:
    • follow the model-view-controller architecture from the dots example in Programming Android ch. 7
    • take a look at this older example to see if any model classes can be reused

Extra Credit

Game-enhancing extra credit ideas are welcome as long as they are proposed publicly on the mailing list and the instructor approves.


Required part, total 20:
  • 4 user interface
    • 2 horizontal touch navigation
    • 1 up/down navigation
    • 1 menu
  • 4 model
    • locations
    • actors
    • portable items
    • locations containing items
  • 3 sample terrain
    • at least 50 locations
    • some one-way passages, dead ends, etc.
    • at least three connected horizontal layers
  • 3 testing
  • 2 code documentation 
    • 0.5 inline
    • 0.5 Scaladoc comments
    • 1 readme
  • 4 written portion
    • 0.5 for addressing each required pattern and principle
    • 1 process summary
Extra credit:
  • 2 terrain viewport as described above


Maintain your code and written portion in your existing project2 repository and notify the instructor and TA when your work is ready to be graded.