COMP 310
Fall 2011
|
Lec36: Final
Project Design
|
|
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
NOT ALL LAB GROUPS HAVE POSTED THEIR IDEAS!!
Basic Notions:
(Question marks means proposed idea without consensus yet)
General:
- Leveraging ChatApp infrastructure
- Teams = chatrooms?
- Staged quests -- advance from level to level
- Puzzles/quests consist of multiple smaller puzzles whose answers are
cluses to larger puzzle? What is the topology of the clue-solving
path?
- More complex clue answers than just a new location, e.g. some calculated
value from the clues.
- Clues as datapacket entities with dynamically programmable behaviors?
- Scoring:
- Final locator is winner take all
- Overall score includes game play metrics.
- Markers = clues? Or do you have to know a specific location
to get a clue?
- Are all markers clues?
Client
- Manage player location and current clue status.
- Interact with map?
- Communicate with server to submit answers
- Chat with teammates
- Other "team functions"?
- Share non-text info with teammates?
- Clue information automatically send to all team members?
Server
- Player and team management
- Quest management
- Score management
- New quest uploading?
- Standardized quest definition file format?
- Random or prefabricated quests?
- Intial "lobby" where teams are formed and game is started.
- Saving game info?
Questions
- What exactly is a "clue"?
- What exactly is a "quest"?
- What is a "location"?
- 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.
© 2011 by Stephen Wong and Scott Rixner