Client Group
Jessie Yu
Nicole Mendolera
Lee Seversky
Dave Alazraki
Min Kang
James Luk
Syed Mohammed
Adam Sail
Woo Lee
Overall Client Design
Nicole Mendolera
Improvements to the Client
Design
3D Character Display
Opening and Closing of Office Doors
Door Knock Logic & Knapsack Support
Player Creation
Game Status Info
Challenge Triggers
Game Statistics
Integration
Player Avatar / 3D Engine



Keeping track of other players
Avatar movement
Consistent character speed
Opening and Closing Office
Doors

Doors are included in current game


Do not open or close
Update “scenery behind doors”
Door Knock Logic / Knapsack



Knock on door
Will allow door to open or remain closed
Knapsack

Works well just updating it
Player Creation Support

Changes to way player is created

Includes GPA, Major, etc.
Game Status Info

Game Status is shown for active players



Names
Locations
Session times
Challenge Triggers

Currently only 3 hotspots


Boring and restricted
Adding new and more exciting
challenges
Game Statistics Button

Game Statistics will be shown

Includes



Total Playing Time
Session Time
Other active player totals
Integration

CVS

Uniform Code

Comments
Player Avatars / 3D Engine
Lee Seversky
Overview



Player avatar support
Current 3D engine discussion
Final goals
Player Avatar Support




Adding avatars gives positive feedback
of other players in the game to the user
Avatars provides new ways for player
interaction
Increases game play options
Requires changes to the current 3D
engine structure.
Avatars

What is an avatar?



An avatar is a 3D model representing a player
Avatars can have other attributes such as color
and text that help identify different players.
Internally


An avatar is an object that knows how to render
itself and its attributes in the 3D world
Each player in the current sector has an avatar
rendered to the screen.
Avatar Manager




The avatar manager is responsible for
handling all avatar movement
Responsible for updating current player
location to the server and asking server for a
list of player locations
Contains all players in current sector that
need to be rendered
Reduces server communication by projecting
player locations based on their view vector
Changes / Additions

Game Logic

Expand player attributes






Add current view vector (x,y,z) for orientation
Add player avatar id (int) for selected avatar model
Add current velocity (x,y,z) for player location projection
Add player sector (int) for sector within game
Change location vector from int to float
Add avatar manager in runScene logic loop
Changes / Additions

Client / Server

Add two client messages

Sends “UpdateSelf” messages





Sends “GetPlayers” message


player->location
player->view vector
player->velocity
player->sector
player->sector
Receives List of players

player->location, player->view, player->velocity, player>sector
Current 3D Engine Limitations





Player movement inconsistent, speeds up /
slows down. Camera movement based on
velocity and acceleration
Collision detection fails occasionally. Player
collision handling logic at fault, not mesh
Memory Leaks
No frustum culling! No Voxel/Octree of world.
Increase speeds dramatically
Poor model geometry rendering support
Final Goals

Implement an avatar system that can
smoothly display player avatars within the 3D
world






Minimize server communication
Minimize client rendering overall load
Maximize fluid movement
Assist with door animation
Assist with replacing current hot spot markers
Improvement overall engine structure and
robustness
Opening and Closing Doors
David Alazraki
Current Doors in the Game

Doors are already a separate part of the
terrain from the walls



They are all shown together in the Cterrain class
Not meant to move
What needs to be done


Terrain needs to be added behind these doors
Doors need to created for the faculty offices since
there aren’t any in the current game
Modeling Doors



Doors For stairs, elevator, bathroom are
already in the game
An office door needs to be added for all
of the faculty offices
The doors will have an both an open
and closed mode, so we need to model
all sides of the door
The CDoor Class



A child of the Cmodel class
Represents a single door in the Watson
building
Each door on the 3rd floor of the
Watson building will have an object of
type CDoor to represent it
The CDoor Class - Data

Has all of the data necessary to know where
the door is


Location (x,y,z) of front bottom corner of the side
where the hinge is
Size –





Height
Width
thickness
Orientation
Open or Closed
The CDoor Class - Functions

bool OpenDoor()



bool CloseDoor()



Opens the door in the player’s view, and changes the
collision model so that the player can walk through the door
Returns true if successful
Closes the door in the player’s view, and changes the
collision model so that the player cannot walk through the
door
Returns true if successful
bool IsOpen()

Returns true if the door is open
Door Knock Logic & Knapsack Support
Min Sung Kang
Knapsack Support

What is the Knapsack?


A virtual bag that holds everything the
player obtains or needs in order to
complete the Watson Adventure Game.
ex) ID, Pencil, Pen & The Dars Report, etc.
Current conditions.

Works well and no further systematical
development is necessary.
Things to be done

Better representation of the Knapsack.
Icons will be replaced.
ex) old ID card image to new ID card image.


Support any added items in the
Knapsack.


Create icons for the added items.
Make sure the items are added and the
icons are shown in the Knapsack.
Door Knock Logic

A new feature for the players from the
client group to provide an opportunity
to knock on the door to further explore
the Watson Adventure Game.
The way it works

When the player approaches the door, a
message will be displayed.
“Press space bar to knock on the door.”

If the player does press the space bar,
the knocking sound will be generated.
What will happen?

By knocking on the door, one of the
following will occur.

Door remains closed and a message will be
displayed.




“Come back later!” (the professor is busy).
“No one hears you!” (no one is in the office).
“No permission!” (wrong door for the major).
Door opens.
How will it happen?


New hotspots will be defined for each
door.
Player, by colliding with the door
hotspots, will given the opportunity to
knock on the doors.
Door Knock Logic
&
Player Creation
James Luk
Defining Door Hotspots

Two hotspots for each door



In the hallway.
In the room.
Hotspots will be defined on the client
side.
Knocking Function


Invoked when on door hotspot and on a
Spacebar key press event
Knocking sound will be played.
Knocking Function cont.

Knocking function checks a player’s
major against the major allowed for a
particular room.

Door opens



CDoor Class OpenDoor function is called.
Door remains closed
Invoking the knocking function within a
room simply opens the door.
Player Creation


Utilizes Person class
New data fields in Person class




Orientation
Avatar
Major
Intelligence attribute will be removed.
Person Class

Contains:








Playername
Password
Location(x,y,z coordinates and orientation)
Avatar
Major
Knapsack
Number of challenges completed
GPA
Player Creation and Login

When creating a character, the data will
be sent to the server.


Server will return a success or error code.
Login

Username and password will be sent to
server

Login success


Player data is sent to the client.
Login failure
Player creation and Login

All communication will be handled
through the protocol handler
Game status Info Display
(Active Players)
Syed Mohammed
Module Description

Event Handling Module




Coordination Module




Input- Notification from the event handling module
Process- Queries the database for the list of active players
Output- Gives the list of active players to the display module
Database Module


Input- Fired By the Tab Key
Process- Action Listener for the Tab Key
Output- Notifies the coordination Module
Returns a list of active players in response to the query form the
coordination module
Display Module



Input- Gets the list of active players from the coordination module
Process- Arranges the data in a desired fashion
Output- Displays the information on the screen.
Information Displayed




Name
GPA
Avatar ID
Location
Client Generated Challenge
Triggers
Adam Sail
Outline





Current Situation
Goals
Examples
Implementation
Dependencies
Current Situation

Hard coded challenges


Pencil, Paper, Professor Head
Limitation on number of hotspots

InteractionManager::Init


3 hotspots per/map
Hard coded display challenge code

CWatsonGamePlay::DisplayChallenge()

Professor Heads challenge only
Goals

Fix the code to handle challenges


Make the client query the server for
challenges
Add more hotspots to generate
challenges


Walls, Floor, Objects
Add a level of randomization to increase
replay value
Examples
Zelda


Walking into
walls presents
Link with an
obstacle
Walking into view
of enemies
presents danger
Examples continued…


Add HotSpots
to walls and
other locations
Random set of
challenges to
increase replay
value
Implementation

Load a set of possible player challenge
hotspots into a data structure by
messaging the server


Some Academic and some Reslife
When a player collides with an
Academic or Reslife HotSpot, do a
random selection on the set of loaded
challenges
Dependencies



Scoring System
Server must be able to receive and
answer requests for hotspots
Database must differentiate between
Academic and Reslife hotspots
Game Statistics Button
WooJin Lee
Statistics as a new function



Currently there are no game statistics
present in the game
Game statistics will be helpful in giving
players relevant information to track
their progress against other players.
Called up via the F1 button, will go
away once the button is no longer
pressed
Game Statistics Workings
Requests Stats
Client
Server
Sends Stats
Shows Stats
Screen
Requests
Information
Sends
Information
Database
Statistics Shown

Information that will be relevant and
useful to the player
•
•
•
•
•
# of challenges passed
Avg. GPA of all players in game
Most popular major
Avg. playtime of all players in game
etc
Client Integration
Jessie Yu
Code Repository

CVS




Source code
management software
Access to the latest code
Avoid conflicts
Organize the modify
history
During Coding Phase

Make sure the source compiles


If not, find out the problem
Run the game during the meetings to
discuss about any existing problems
During Integration Phase



Minimize redundancy
All functions are well-commented
Consistent commenting style
Test Plan

Test for requirements





Incorrect or missing functions
Interface errors
Performance errors
Test as a regular player
Third-party testing