Scoring Scheme and Implementation

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
Server Integration Responsibility
Victoria Toujilina
CS 495 Professor Steflik
Fall 2004
Server Group Tasks
Login/Logout
Client1
Scoring
Player Maintenance &
Character Creation
Database
Challenge
Dispatcher
Database
Object
Watson
Game
Server
Protocol & Threads
Client2
Client3
Statistics
Handler for Life
Challenges
Server Protocol Handling
Ryan Leslie
CS 495 Professor Steflik
Fall 2004
Overview
1.
2.
3.
4.
5.
6.
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
Overview (Cont.)
See Loi-Server_Protocol_Handling.doc for further details
Commands

Commands currently supported by protocol handler

Login / Logout


Create Player


No handler implemented
Load Challenge


No handler implemented
Save Player State


Need handler in GameKeeper (or elsewhere) to create a Player object given a username
Load Game State


CharacterCreation handler still undergoing development
Load Player


LoginLogout handler still undergoing development
ChallengeDispatch handler still undergoing development
Complete Challenge

Scorer handler still undergoing development
Commands (Cont.)

Some commands still pending support by
protocol handler




Move Player Position
Get Knapsack
Update Knapsack
Get Player Statistics (GPA, health, etc.)
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
Server Thread Handling
Justin Phillips
CS 495 Professor Steflik
Fall 2004
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
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
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.
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
Scoring Scheme and
Implementation
Ryan Leslie
Justin Phillips
CS 495 Professor Steflik
Fall 2004
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
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?
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
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
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
Implementation Details

Client Group

Should provide a means to display the previously
mentioned character attributes
Game Statistics
Qing Zhang
CS 495 Professor Steflik
Fall 2004
Game Statistics

General Statistics



Number of Players
Number of Professors
Number of Locations
Game Statistics

Player Statistics




Identification Number
Name
GPA
Current Status
Game Statistics

Professor Statistics




Identification Number
Name
Courses Teaching
Office Location
Game Statistics

Locations Statistics


Location ID Number
Location Status



Challenge or Help
History Statistics
Positions of Locations
Game Statistics

Usage of game statistics


Player’s Privilege
Professor’s Privilege
Challenge Dispatcher
Yu Tak Ting
CS 495 Professor Steflik
Fall 2004
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.
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.
Client Side Duties




Challenge Hotspot Coordinates
Send player information to server.
Execute the test.
Send test result to the server.
Database Duties

Decide on the database structure of the
questions.


Format of the questions
Different Majors
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
Possible Enhancements



Different levels of difficulty in questions
Hints for questions – additional database
storage
Variable length and difficulty tests.
Handler for Client
Generated Challenge
Triggers
Oren Kashi
CS 495 – Professor Steflik
Fall 2004
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…
How to “trigger” the trigger?




Bump into a wall.
Get stuck in the
elevator.
Drop your laptop.
Failing your test.
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.
Flow
Handler
Client
Server
DB
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?
Login/Logout Support
Mark Bojdak
CS495 Professor Steflik
Fall 2004
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)
Request
CLIENT
Username/Password
SERVER
DATABASE
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
Request
Request
CLIENT
SERVER
Username/Password
Response
-1 or 0 or 1
DATABASE
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
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
No
Communication
Request
CLIENT
SERVER
Username/Password
?
?
DATABASE
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
Add Request
?
Request
CLIENT
SERVER
DATABASE
Username/Password
?
Must be -1, 0, or 1
Player Maintenance &
Character Creation
Support
Farshid Firouzeh
CS 495 Professor Steflik
Fall 2004
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?)
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.
Task 2 continued
- After counter expires, player considered
inactive. Therefore, must erase player’s
history from database.
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?
Character Creation Support



Modification of existing attributes for
players?
Attributes will differ for CS, ME, EE
students?
Main concern : Updating DataBaseObject,
CharacterCreation code.
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.
Previous Coding

DataBaseObject.java
1.) playerExists() : Not working? Needed in
this file?
2.) createCharacter() : Puts all info in
database. Most likely needs update.
Challenge Dispatching
Leonard Wong
CS 495 Professor Steflik
Fall 2004
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
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
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
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
Outputs

The actual challenge information to the Client



Question
Possible Answers
Update “level” information from answering
challenges correctly
New Outputs

Student life challenge information



Track physical challenge progress



Actual challenge description
Reward for challenge?
Collecting number of items
Speaking with specific faculty etc
Update player attributes upon challenge
completion
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?
Game Status Info Request
Handler
Active Player and
Database Object Support
Brian Juba
CS 495 Professor Steflik
Fall 2004
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
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
Database Object Support



Acts as an interface to the
database.
Creates a common object
Server
that all the handlers can
Database Object
access.
Handles all the types of
Database
queries.

SELECT, UPDATE,
DELETE, INSERT
Structured Query Language (SQL)


ANSI Standard – but there are many different
variations.
When a query is performed a result set is
returned.
Persons
“SELECT Last Name
FROM Persons”
Last Name
First Name
Last Name
Martin
Curtis
Martin
Walnuts
Paully
Walnuts
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.