Final Project Issues

(Back to Final Project description)

Final Project Issues:

• How restrictive is the API?    Does it rule out certain system architectures, e.g. only client-server topologies are allowed?    Remember, that this assignment is not at all about games but rather about enterprise communications architectures that are connecting arbitrary systems together, so is it reasonable to make such restrictions?
  • Focus on what the fundamental behaviors and data are needed for message-based communications across an enterprise, not on what is "easiest to code" or "makes it easy to create a particular type of system".    The communications subsystem is one of the most invariant parts of an enterprise system and what it is asked to do today may not look anything like what it will be asked to do tomorrow.   Don't base your decisions on whether or not you think that the implementation will be "too hard"--do  the right thing, not the easy thing.
  • Focus on the notion of the game as an application comprised of cooperating, communicating components rather than as a monolithic whole.
• Communications modalities -- consider the role of the API in terms of both network-based communications to remote entities and local commnications to other local entities through local data storage and/or other means.
  • to individuals
  • to groups of individuals, e.g. teams, rooms, etc.
  • to other commands
    • installed in the same visitor
    • installed in the same application
• In client-server or other game architectures where different machines are not equivalent, what are the implications about what commands are being used to process the same message on different machines?
  • Are different clients required to process the same mesage type equivalently?
  • Are different "rooms" on the same machine even required to process the same message identically?
• Is there a semantic difference between the process used to initially connect the game clients and game server together and initialize the game vs. the actual in-game processes and is the API able to clearly express the differences and similarities?
  • Note that semantic differences can be expressed at many levels, e.g. at the receiver level, at the method level, at the message level or some combination of these techniques.
• Does an externally-sourced command have/need access to local system information, e.g.
  • the name of the local user,
  • the name of the room/team,
  • etc?
• Does the GUI interactions enable the added components to be labeled?   This makes it a lot easier for the GUI to make a sensible presentation of the custom components.
  • Try to make your system maximally respectful of  the local system's MVC separations, including notions that code running under the command's (usually RMI) threads are not directly working with GUI threading.    This can be accomplished by having the command create a "mini-mini-MVC" where the command's "view" is installed into the local system's GUI.
• Stale data problems:
  • E.g. when a game is started, many clients will be simultaneously joining, so the possibility of stale data during the joining process becomes significant.
• Robustness:
  • It is critical that a game inclding both the game server and game clients keep operating even if one of the clients fails in any manner.
• Startup ambiguity:
  • A game client has no idea what the game on a game server is
  • A game client has no idea how that game wants to initiate and perform the team joining process.
  • The steps that the game client and game server must perform immediately after the auto-connect-back must be unequivocable.
    • The API must define what happens at that point, e.g.
      • Client must wait for server to do something or
      • Server must wait for client to do something.
    • What is it that must happen at that point?
      • What process will give the most flexibility to the game designer while minimizing the complexity of the API?

© 2020 by Stephen Wong