The Server Group

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

2
(No Transcript)
3
Server Integration Responsibility

• Victoria Toujilina
• CS 495 Professor Steflik
• Fall 2004

4
Server Group Tasks

Login/Logout
Scoring
Player Maintenance Character Creation
Watson Game Server
Challenge Dispatcher
Database
Database Object
Protocol Threads
Statistics
Handler for Life Challenges
5
(No Transcript)
6
Server Protocol Handling

• Ryan Leslie
• CS 495 Professor Steflik
• Fall 2004

7
Overview

• WGListener object waits for client-initiated
  connections
• When a connection is established, a WGConnection
  object is created to handle the connection
• WGConnection waits for client input
• Input lines are parsed for commands by
  WGCmdParser. Each command is encapsulated in a
  WGCommand object
• For each command, the appropriate command handler
  is triggered
• 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

12
(No Transcript)
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

18
(No Transcript)
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

26
(No Transcript)
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
• Players Privilege
• Professors Privilege

33
(No Transcript)
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.

41
(No Transcript)
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?

48
(No Transcript)
49
Login/Logout Support

• Mark Bojdak
• CS495 Professor Steflik
• Fall 2004

50
How its 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)

CLIENT
SERVER
DATABASE
Request
Username/Password
51
How its 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

Request
SERVER
DATABASE
CLIENT
Request
Response
Username/Password
-1 or 0 or 1
52
How its 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 doesnt 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

No Communication
SERVER
DATABASE
CLIENT
Request
?
Username/Password
?
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 users game
  attributes
• Format of data
• Verify the data being sent and received by the
  database is of the proper format

Add Request
?
SERVER
DATABASE
CLIENT
Request
Username/Password
?
Must be -1, 0, or 1
55
(No Transcript)
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 players
• history from database.

60
Previous Coding

• Gamekeeper.java
• - function addNewPlayer (to the game)
• 1.) Doesnt 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.

64
(No Transcript)
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 clients 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?

73
(No Transcript)
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 theyve 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

78
Structured Query Language (SQL)

• ANSI Standard but there are many different
  variations.
• When a query is performed a result set is
  returned.

SELECT Last Name FROM Persons
Persons
Last Name First Name
Martin Curtis
Walnuts Paully
Last Name
Martin
Walnuts
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.