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 player->location player->view vector player->velocity player->sector Sends “ GetPlayers ” message 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 3 rd 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() 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 bool CloseDoor() 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. If the player does press the space bar, the knocking sound will be generated. “ Press space bar to knock on the door. ”

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 Input- Fired By the Tab Key Process- Action Listener for the Tab Key Output- Notifies the coordination 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 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 ClientServer Database Requests Stats Requests Information Sends Information Sends Stats Screen Shows Stats

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