COMP 310
Fall 2010

Lec36:  Final Project Design

Home  Info  Owlspace  Resources

Today we will continue working on the final project design, considering ideas that people have brought up in the discussion forum. 

Please see the Final Project assignment page for more information.

Note that a Final Project wiki has been set up.

Set up "Watches" for BOTH the forum and wiki!

Something to consider:  NASA WorldWind



Basic Notions:

(Question marks means proposed idea without consensus yet)


  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.




© 2010 by Stephen Wong and Scott Rixner