1. The Server Group CS 495 Professor Steflik Fall 2004  Victoria Toujilina  Ryan Leslie  Justin Phillips  Qing Zhang  Yu Ting  Oren Kashi  Mark Bojdak  Farshid Firouzeh  Leonard Wong  Brian Juba

3. Server Integration Responsibility Victoria Toujilina CS 495 Professor Steflik Fall 2004

4. Statistics Client3 Protocol & Threads Database Object Challenge Dispatcher Database Client2 Watson Game Server Player Maintenance & Character Creation Client1 Login/Logout Scoring Handler for Life Challenges Server Group Tasks

6. Server Protocol Handling Ryan Leslie CS 495 Professor Steflik Fall 2004

7. Overview 1. WGListener object waits for client-initiated connections 2. When a connection is established, a WGConnection object is created to handle the connection 3. WGConnection waits for client input 4. Input lines are parsed for commands by WGCmdParser. Each command is encapsulated in a WGCommand object 5. For each command, the appropriate command handler is triggered 6. The command handler writes results back to the client

8. Overview (Cont.) See Loi-Server_Protocol_Handling.doc for further details

9. Commands  Commands currently supported by protocol handler Login / Logout  LoginLogout handler still undergoing development Create Player  CharacterCreation handler still undergoing development Load Player  Need handler in GameKeeper (or elsewhere) to create a Player object given a username Load Game State  No handler implemented Save Player State  No handler implemented Load Challenge  ChallengeDispatch handler still undergoing development Complete Challenge  Scorer handler still undergoing development

10. Commands (Cont.)  Some commands still pending support by protocol handler Move Player Position Get Knapsack Update Knapsack Get Player Statistics (GPA, health, etc.)

11. Implementation Issues  WGConnection lacks class variable to associate each connection with a player Needed so that certain commands can be associated with a particular player Can be set by LoginLogout object when a user successfully logs in  Protocol Handler lacks protection against malformed commands This can cause command handlers to malfunction Problem can be resolved in WGCmdParser

13. Server Thread Handling Justin Phillips CS 495 Professor Steflik Fall 2004

14. Current Implementation  WatsonGameServer.java Creates instances of all objects needed to allow a player to log in. Runs the WGListener and ChallengeDispatcher on separate threads.  WGListener.java Creates a server socket that listens on port 1500 by default A thread running the WGConnection object is created for each new connection request the server receives

15. Design Goals  Problem: Server can only support an estimated 30 to 50 connections at once Performance degradation noticeable as number of connections increase This number will vary depending on what other processes are running on the machine and the amount of available memory and CPU speed

16. Design Goals  Solution: Limit the number of connections server will accept Allow this number to be set through a parameter Send “Connection Failed: too many users” response to any client attempting to connect when limit has been reached Count the active connections, incrementing the counter when a new connection is established and decrementing the counter when a user logs off.

17. Other Goals  Support thread handling in order to aid development in other areas of the WAG  Update documentation on thread handling  Answer questions regarding thread handling

19. Scoring Scheme and Implementation Ryan Leslie Justin Phillips CS 495 Professor Steflik Fall 2004

20. Current Scheme  Player completes challenges and receives a grade for each.  To complete the game the player must earn a 4.0 GPA upon completing all challenges  Implemented in Scorer.java

21. New Scoring Scheme  Object Of the Game Accumulate at least N credits Accumulate a minimum number of college experience points Earn a minimum GPA of X  X will be based on game difficulty Use player intelligence?

22. New Scoring Scheme  Challenges divided into two categories Student Life Challenges  Consists of all challenges not related to academic knowledge  Upon completion the player will gain college experience points Academic Challenges  Test subject knowledge  Upon completion the player will receive A grade that is factored into the GPA 4 credits for completing the challenge if the grade is passing

23. New Scoring Scheme  Academic Challenges must be met in a progressive manner Each academic challenge requires a minimum number of accumulated credits before it may be attempted  Challenges may be retaken Each grade for an academic challenge is averaged into the cumulative GPA  Allows player to increase GPA A player may not receive credit or experience points for a challenge more than once

24. Implementation Details  Database Group Shall support the following character attributes  Experience Points  GPA  Cumulative Credits All other character attributes will not be utilized this semester

25. Implementation Details  Client Group Should provide a means to display the previously mentioned character attributes

27. Game Statistics Qing Zhang CS 495 Professor Steflik Fall 2004

28. Game Statistics  General Statistics Number of Players Number of Professors Number of Locations

29. Game Statistics  Player Statistics Identification Number Name GPA Current Status

30. Game Statistics  Professor Statistics Identification Number Name Courses Teaching Office Location

31. Game Statistics  Locations Statistics Location ID Number Location Status  Challenge or Help  History Statistics Positions of Locations

32. Game Statistics  Usage of game statistics Player’s Privilege Professor’s Privilege

34. Challenge Dispatcher Yu Tak Ting CS 495 Professor Steflik Fall 2004

35. Challenge Dispatcher  Its role is to contact the database object and obtain information about challenges to dispatch back to a client, based on the coordinates of a hotspot that client has bumped into.  Only one will exist, created by the WatsonGameServer class and instantiated to run in its own thread.  Multiple threads are created by the WatsonGameServer when players request for challenges.

36. Server Side Duties  Get information from Client.  Check that the player can take the test.  Obtain questions from Database for the specific test.  Update player statistics depending on the result of the test.

37. Client Side Duties  Challenge Hotspot Coordinates  Send player information to server.  Execute the test.  Send test result to the server.

38. Database Duties  Decide on the database structure of the questions. Format of the questions Different Majors

39. Details  Will a player be allowed to take a test again?  Show correct answer or not?  How much information does the client have to send over to the server? How much information does the server have to update Knapsack,Major,PlayerID, Test Result

40. Possible Enhancements  Different levels of difficulty in questions  Hints for questions – additional database storage  Variable length and difficulty tests.

42. Handler for Client Generated Challenge Triggers Oren Kashi CS 495 – Professor Steflik Fall 2004

43. Handler for client generated challenge triggers  New addition of Student Life challenges  Need a different method of dispatching the challenges  Student Life challenges  Broken hard disk  Injuries  Virus deletes your computer  Etc…

44. How to “trigger” the trigger?  Bump into a wall.  Get stuck in the elevator.  Drop your laptop.  Failing your test.

45. Implementation  The client generates a request for a challenge.  The protocol handler deciphers request and creates an instance of the handler.  The handler will then query the database and return the challenge to the protocol handler.  The protocol handler will then pass the challenge off to the client.

46. Flow

47. Future aspects to think about  How to check if student completed the task?  Is the task mandatory, or optional?  How to implement the point system for each challenge?

49. Login/Logout Support Mark Bojdak CS495 Professor Steflik Fall 2004

50. How it’s designed to work…  Login After the user enters a username and password, a request to logon to the server is made When the client makes this request, it passes two strings to the server (username and password) CLIENTSERVERDATABASE Username/Password Request

51. How it’s designed to work… The server then queries the database to see if a valid username and password were entered Database returns a value to the server, indicating if it was successful  -1  invalid username  0  valid username / invalid password  1  successful login SERVERDATABASE Request Response -1 or 0 or 1 CLIENT Username/Password Request

52. How it’s designed to work…  Logout When the user logs out, the database will be updated with the latest game attributes (game statistics) unique to the user When the same user returns to the game, they will inherit all of the attributes from the previous time they played

53. Current Problem  Server doesn’t query the database to verify whether a valid username and password were entered As a result, any user can login, regardless of the name and password entered No attributes are assigned to the player SERVERDATABASE ? ? CLIENT Username/Password Request No Communication

54. Solutions to be Implemented  Query the database A request must be sent to the database to verify both username and password entered If both are valid, load all of the user’s game attributes  Format of data Verify the data being sent and received by the database is of the proper format SERVERDATABASE ? ? CLIENT Username/Password Request Add Request Must be -1, 0, or 1

56. Player Maintenance & Character Creation Support Farshid Firouzeh CS 495 Professor Steflik Fall 2004

57. Player Maintenance  Task 1: Ensuring no duplication of same player.  Possible Solutions? - Check Database - Make a quick checker via server code, potential list (Is it faster? More efficient?)

58. Player Maintenance  Task 2: Dealing with players that have not played for a while.  Possible solutions? -Use Java Time() functions to define a counter. This counter will keep track of when players last logged on.

59. Task 2 continued - After counter expires, player considered inactive. Therefore, must erase player’s history from database.

60. Previous Coding  Gamekeeper.java - function addNewPlayer (to the game) 1.) Doesn’t check for already-existing players. Need to be Fixed?  Add counter code here? Or elsewhere?  Suggestion for Database Group: - add “inactive” attribute to NPCharacter Table?

61. Character Creation Support  Modification of existing attributes for players?  Attributes will differ for CS, ME, EE students?  Main concern : Updating DataBaseObject, CharacterCreation code.

62. Previous Coding  CharacterCreation.java - Checkuser() : Not working? Put in right file? (GameKeeper, perhaps?) - Other than this, CharacterCreation seems fine. Maybe brushing up of previous code plus code to add as is needed.

63. Previous Coding  DataBaseObject.java 1.) playerExists() : Not working? Needed in this file? 2.) createCharacter() : Puts all info in database. Most likely needs update.

65. Challenge Dispatching Leonard Wong CS 495 Professor Steflik Fall 2004

66. Design Inputs  Player bumps into challenges triggers event that sends server a request for challenge Coordinates or code of challenge is received by server  Server receives the client’s answer to the challenges

67. New Design Inputs  Timer on client side fires a trigger that sends server a request for challenge Code for challenge is received by server  Server receives messages that challenges have been completed

68. Design Processes  Server must determine if client qualifies for challenge Server retrieves “level status” of the client Server compares this to the level of challenge the client is requesting If client qualifies, retrieve challenge data (actual question, possible answers, correct answer)  Match client answer to retrieved correct answer

69. New Processes  Server retrieves information for physical challenges from database  Client side keeps track of challenge status When message received that challenge has been completed:  Figure out what attributes will be updated and by how much

70. Outputs  The actual challenge information to the Client Question Possible Answers  Update “level” information from answering challenges correctly

71. New Outputs  Student life challenge information Actual challenge description Reward for challenge?  Track physical challenge progress Collecting number of items Speaking with specific faculty etc  Update player attributes upon challenge completion

72. Open for discussion…  Player attributes? What role will they play What type of attributes How to increment them  Type/Nature of “student life” challenges  Table names and description of attributes in the database  Penalties for failing challenges or answering challenges incorrectly?

74. Game Status Info Request Handler Active Player and Database Object Support Brian Juba CS 495 Professor Steflik Fall 2004

75. Game Status Handler  Will give statistics to the user.  About the Game # of players currently, # of all players # of sessions made total  About the User Last login Total time played # of sessions they’ve had

76. To Do This…  Need to add fields to the character table Last login, # of sessions, active (0 or 1), time  Create a handler class that computes numbers based on data from the database object.  Then pass the information to the client to pop up a window with the stats.  Add a command to the protocol, Get Stats

77. Database Object Support  Acts as an interface to the database.  Creates a common object that all the handlers can access.  Handles all the types of queries. SELECT, UPDATE, DELETE, INSERT Server Database Object Database

78. Structured Query Language (SQL)  ANSI Standard – but there are many different variations.  When a query is performed a result set is returned. Last NameFirst Name MartinCurtis WalnutsPaully “SELECT Last Name FROM Persons” Last Name Martin Walnuts Persons

79. Adding MySQL  WAG currently runs off a MS Access database.  New version will run Access for a local game, while MySQL for a remote game.  Need to create a flag to specify.  Game should behave the same way using both databases.  SQL queries already created might have to change due to variations between them.