COMP 310
Fall 2015

Lec36:  Final Project Design

Home  Info  Owlspace   Java Resources  Eclipse Resources  Piazza

 

Today we will start working on the final project design. 

 

FOR THE FINAL PROJECT, YOU ARE ALLOWED TO CHOOSE YOUR OWN PARTNERS.    2 PEOPLE PER TEAM ONLY.   

Respond to the specified Piazza post by 1 PM Wed. 11/11/15 with the partner information in the standard form (netid1, netid2) plus real names.

 

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.)

General:

  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?

Client

  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

Server

  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

Questions

  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.

 

 

 


© 2015 by Stephen Wong