COMP 310 Fall 2017	Final Project Specifications and Requirements

Where in the World is Willy?

Premise:

You must have a premise for your game that motivates the game play.   For instance:  "Willy has been stolen and you and your team must comb the world to find clues to the nefarious group that stole Willy and to Willy’s hidden location. The winner is the first team to locate Willy!"

Description

• The idea here is that the game would be (very) loosely based on the classic video game “Where in the World is Carmen San Diego?”, at least in the sense of requiring movement around the world and the interaction with information that is distributed around and related to the Earth.
  • Adherence to the rules and game play of the original "Where in the World is Carmen San Diego" game is NOT required!
• Teams of players compete to gather and use clues and other devices, to make guesses and/or complete various tasks in an atttempts advance in a quest to win the game, e.g. to find Willy above.
  • Game play must involve cooperative interaction amongst the team members to enable their team to win.
  • Winner is first team to complete the objective of the game.
  • The game MUST have a winner and the game must be winnable in about a 15-20 minute timespan so that an entire game can be played during demo day.
  • The number of teams must be at least 2 and can be fixed or dynamically determined. 
    • The total number of players must however be unbounded.   The game should be able to handle at least 20 players.
• Clues and/or other game devices are “virtually” placed in real locations around the globe and relate in some manner to that location.   This may include requiring that the player figure out that the clue is in that location through other means.
• Real geolocation data and services, e.g. NASA WorldWind, are used in conjunction with and interacting with the game application.
• Game consists of multiple client implementations that connect to a central game server and possibly amongst themselves as well.
• Team members can communicate and share information.  Communications should not be limited to simple chatting.  Other modalities such as clicking a button to share one's GPS coordinates or team voting capabilities are highly encouraged.

Specifications

• Real geolocation service, e.g.NASA WorldWind, is incorporated into the system.
• Different client implementations can all interoperate during game play. 
• The client's ability to play the game is independent of game server implementation.
• Official API specs will be discussed and finalized in class on Piazza.
• BOTH the common network API and the individual team's game architecture MUST be based on a system of cooperating message handlers (i.e. commands) that receives messages directly from the network without any routing whatsoever.
  •  Routing incoming messages to teams is explicitly disallowed except for messages that are being passed from one team to another.
    • Likewise, centralized routing of messages to clients is explicitly disallowed unless the target recipient can only be determined by dynamic game information only available on a specific receiver, e.g. only the central game server knows who the closest enemy is and a message needs to be sent to that particular recipient.   Inter-team communications often but not always falls under this umbrella as well.
  • "Message forwarding" by simply passing messages on to a monolithic "game object" for message-dependent processing is explicitly disallowed.
    • Don't replicate the existing capabilities!
  • All communications in a game must comply with the protocols and available services defined by the common network API.
    • As in a real application host, the communications subsystem must be an encapsulated, protected process that all hosted applications (here, the non-well-known message-handling commands) must use for any inter-client or server communications.
      • Any communications operations, except for communicating directly with the sender of a specific datapacket, must be handled through services provided by the command-to-model adapter that serves as the "sandbox" within which any non-well-known message handling command must operate.
        • This is also highly recommended even for well-known message commands as it creates a much more consistent and reliable communications process across the system. 
    • Utilizing Remote objects, i.e. stubs, that are not part of the common network API is explicitly disallowed because doing so bypasses the API-defined communications protocols.
      • This actually has operational problems in general due to inadequacies in the remote dynamic class loader so it is not a good idea no matter what.
    • Using existing Remote stubs for direct communications is disallowed when the API defines explicit local host-managed processes for the same purpose, e.g. if a "cmd2ModelAdpt.sendTo(stub, id, message)" method is defined by the API, then directly calling stub.receive(datapacket) should be disallowed.
    • Communications between non-well-known message-handling commands on a given client application must be established only through a service(s) provided by the command-to-model "sandbox" adapter, e.g. via a shared mixed data dictionary for storing data, references and/or adapters.
      • Due to their nature, well-known message handling-commands may need to use other means to access internally stored and protected shared information.

The common network API and the game architectures will be evaluated based on criteria that are independent of game-related applications.    An important goal of the assignment is as an introduction to building large complex systems from smaller decoupled but cooperating subsystems.  Here, the message-processing commands are like specialized applications interacting and cooperating to create a larger whole.

Requirements

• Each development team will deliver
  • One client implementation
  • One game server implementation
  • The game client and game server implementation must be compliant with the class-wide common network API.
  • Full documentation
    • Full UML diagrams in project source
    • Full Javadocs in HTML form in project source
    • Text document describing how to use the client and game server -- This game User Manual should be written in the course Owlspace wiki so that it is easily accessible by the players.
    • Tool tips on all components on GUI.
•  10% of the final project grade will be a single class-wide score based on the percentage of development teams that deliver operational client and game servers. 
  • Communication and discussion amongst yourselves is required!

Due Dates

• See main class schedule for official times and dates.
• Project proposals are due BEFORE the first Milestone!
• 2 Delivery Milestones:   One mid-process milestone and one final delivery
• Full functionality required by Comp310 final exam time (demo day).  
  • Scheduled Comp310 final exam period will be used as a demo/game play time. 
  • Functionality will NOT be tested beyond the demo time period!
    • Corrections in the final submitted code, if clearly noted in the documentaion, will be considered for partial (<50%) credit on non-functionality seen on demo day.
• Final deliverables (final commit) must be submitted by 5:00 PM on the last day of  the final exam period.  

Reference Links

Not all the material below may be required!

• Comp310 WWJ Resources
  • NASA WorldWind Java SDK  (includes links to NASA's site and WWJ on-line documentation)
  • Libraries in Java (includes installation instructions for Eclipse projects)

© 2017 by Stephen Wong