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!"

For illustrative purposes, this discussion will talk about a possible game called "Where in the World is Willy". This is just to give concrete examples of types of things one might do in a game.

YOU ARE NOT TO COPY THIS GAME NOR ARE YOU REQUIRED TO MAKE A CLUE-BASED "HUNT" GAME!

Description

• Any game is required to use movement around the world and the interaction with information that is distributed around and related to the Earth. The canonical example would be the classic video game “Where in the World is Carmen San Diego?”, at least in the loose sense of the global movments and integration of information to the geographical locations.
  • 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 or Google Maps, are used in conjunction with and interacting with the game application. These "Geographic Information Systems" (GIS) are used to bring geographical information and interaction into one's application.
• Game consists of multiple client implementations that connect to a central game "server" and possibly amongst themselves as well.
  • The ONLY fundamental requirement of the "game server" is that it be the source of the code that runs the game.
    • A "star" topology is NOT required!
    • The "game server" is NOT required to do ANY game processing other than to supply the necessary commands and initial data needed for the clients to run the game.
      • Once the game commences, it is permissible for the game server to completely drop out of the system! This would be characteristic of a pure peer-to-peer game.
• 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 GIS geolocation service, e.g.NASA WorldWind or Google Maps, is incorporated into the system. The GIS to be used may change from semester to semester, so check the specific requirements for this semester's Final Project for exact details!
• 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.
• Both the game server and game client applications must explicitly support the use of the discovery server system for making an initial connection to a remote machine already connected into the game system.
  • Initially connecting to the game server, while typical, is NOT required.
  • It is highly recommended that an app retain the ability to manually input the necessary information for a direct connection to another machine without the need for the discovery server. This can be a great aid during debugging.
  • While the discovery server system does transparently support the use of arbitrary RMI Registry bound names, it is highly recommended that the API define one or more default names to use as this will aid in debugging the system.

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 Demo Day.  

Reference Links

Not all the material below may be required!

• Javadocs for provided libraries
• 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)

© 2020 by Stephen Wong