COMP 310
Spring 201

Lec36:  Final Project Design

Home  Info  Canvas   Java Resources  Eclipse Resources  Piazza


Today we will start working on the final project design. 


Please note that the various discussions in the lecture notes are referring to a "Where in the World is Carmen San Diego" type game only as a reference example.   You are not required to make that exact type of game!


Basic Notions:

(The following is based a "Where in the World..." type game, which is not required, aside from the GIS aspects using WorldWind.   The point here is to get you thinking about various issues and features in your game.)


  1. Leveraging ChatApp infrastructure
  2. Teams = chatrooms?
  3. Staged quests -- advance from level to level
  4. Puzzles/quests consist of multiple smaller puzzles whose answers are cluses to larger puzzle?  What is the topology of the clue-solving path?
  5. More complex clue answers than just a new location, e.g. some calculated value from the clues.
  6. Clues as datapacket entities with dynamically programmable behaviors?
  7. Scoring: 
    1. Final locator is winner take all
    2. Overall score includes game play metrics.
  8. Markers = clues?   Or do you have to know a specific location to get a clue?
  9. Are all markers clues?


  1. Manage player location and current clue status.
  2. Interact with map
  3. Communicate with server to submit answers
  4. Chat with teammates
  5. Other "team functions"
  6. Share non-text info with teammates
  7. Clue information automatically send to all team members


  1. Player and team management
  2. Quest management
  3. Score management
  4. New quest uploading
  5. Standardized quest definition file format
  6. Random or prefabricated quests
  7. Intial "lobby" where teams are formed and game is started.
  8. Saving game info


  1. What exactly is a "clue"?
  2. What exactly is a "quest"
  3. What is a "location"
  4. What issues are common API issues and which are implementation-dependent ones?    How much the same do various implementations have to be


Tech note:  Extending without disturbing

It has been suggested that "teams" are essentially chat rooms, though perhaps with more features.    You already have infrastructure that can handle chat rooms, ala IChatRoom.    How do you create something that represents a "team" that doesn require rewriting everything that handles a chat room?   Simple--define an ITeam that extends IChatRoom:

public interface ITeam extends IChatRoom  {...}

This guarantees that whatever a team is, it is always a chat room and thus can always be processed by code that processes chat rooms.    This enables you to leverage the existing infrastructure for chat rooms but with options open for new capabilities.




© 2017 by Stephen Wong