Chris Harrison Stacey Kuznetsov Mariya Lysenkova Jennifer Refat Gabriel Sinkin

1. Chris Harrison Stacey Kuznetsov Mariya Lysenkova Jennifer Refat Gabriel Sinkin

2. System Architecture • Server and Client exchange messages, player commands, game data • Server Database - contains comprehensive network and game related data for all players • Client Database - only stores data last sent by the server and only contains a subset of game data (items needed for graphics)

3. Server Architecture

4. Server Architecture • Network Communication • BSD Sockets • One socket per client, two-way data flow • TCP (not UDP) • Server broadcasts commands once (no streaming data) • Data less time-sensitive than other applications • TCP Header: 20 bytes. Movement Command: ~25 bytes. • ~50 bytes per command • Clients generate a command every ~2 seconds • 1000 concurrent clients • ~25Kbps upstream data • Naïve Broadcasting: 25Mbps! (intelligent broadcasting based on locality)

5. Server Architecture • Handle many concurrent clients • Posix Threads • Main Accept thread • Waits for new client connection • Spawns new client handler thread • Thread for each client • Receives command string • Adds command to command queue • Sleeps • Broadcast (responder) thread • Continuously processing commands unless queue is empty • Selectively broadcasts to relevant clients • Movement, chat, combat to local area • Private chat, trade, to single player • Taps into player-data-storage class (updating and getting information)

6. Server-Specific Classes • Main: Boots server, spawns broadcast thread and client threads. • Broadcast thread: broadcasts relevant data (fetched off the queue) to clients. Spawned once. •ClientHandler thread: listens for, receives and processes incoming commands. One ClientHandler thread is spawned for each Client. • Database: Contains a large array of player data structures: index = unique PlayerID, which assigned when account is first created, A matrix of LinkedLists, which store player IDs mirror the in game regions. This is used to facilitate intelligent broadcasting of data.

7. Client Architecture

8. Client-Specific Classes • Main: Boots client, fetches the positions of all players from Server and writes them to Client Database. • GameEngine:processes incoming commands, updates ship positions, renders graphics. Graphics interface includes: renderSea(), renderLand(), renderShips(), renderWeather(), renderAccessories(), etc. • CommandHandler: waits for commands from server. Received commands are pushed onto command queue • CommandSender: Sends player commands to the server. Commands generated in-game are pushed onto an outgoing command queue. The commandSender thread is responsible for reading from this queue and sending commands to the server. • Database: Like the Server database, contains large array of all players indexed by id number. Unlike the Server database, it contains not two but four coordinates: x_current, y_current, x_destination and y_destination, as well as ship velocities (the server does not care about this data, as it relates to graphics). This enables the game engine thread to animate the ship as it gradually moves from the current location to the destination

9. Protocol • Plain text (abstracted) • Simple and extensible • Command Composition • Leading character determines command type • Server and client know command structure • “M 45 1356 2483 1401 2237” • Movement; Player 45 moving from x=1356, y=2483 to x=1401, y=2237. • To Server from Client: • Login, Logout, Movement, Chat, Private Chat, Trade Funds, Trade Items, Attack, Request Missions, Accept Mission, Mission Completed (Used to synchronize funds), Request Services/Items, Buy Service/Item, Create Group, Join Group, Leave Group. • To Client from Server: • Movement (sent to all clients in the region), Chat (sent to all clients in the region), Private Chat (sent to DestinationPlayer only), Trade Funds (sent to DestinationPlayer only), Trade Items (sent to DestinationPlayer only), Attack (sent to all clients in the region), List Missions, List Services/Items, Join Group Response, Login Response

10. Player Movement Logistics Player Location:The world will (initially) be split up into 3 regions (rows). Having players split up this way will enable us to broadcast player actions only to those players who are in their vicinity, instead of broadcasting data to the entire world.Player Movement: setPosition(int id, int x, int y) function, which • Locates the player with the given id in the players' array • Changes his coordinates to the specified coordinates • Determine the Row(s) the player is in, and return a list of the sockets of all players that are in the same Row(s) so that the server can broadcast the changed location to all surrounding players, including the moving player himself Data Storage Logistics:When the system is idle or not running, game data will be stored in a file, in the following format:Player ID:::Player Name:::Player Password:::X Coord:::Y Coord

11. Player Movement Logistics Upon startup, the Data() constructor will do the following: • Open data file • Parse data file and create a Player Object for each player specified in the file • Place each Player Object into the players array, indexing them by id number • Determine the Row(s) each Player belongs in • Copy pointer of each Player Object into the corresponding Row list(s) • When the system shuts down, the Data destructor will: • Iterate through the players' array and replace the old file • Delete the players array and all lists Login:The server will call login(char *name, char * password) on a player's information when a player logs in. The login function will: • Determine of the name and password are valid. • Return -1 if information is invalid • Return user id if login is valid

12. Player Movement Logistics Exit: • When a player exits the game, the server will call Exit(int id), which will • Remove the player from any Row lists that may point to him so that his socket is no longer returned when other players move • Return -1 if exit status caused an error New Player: • The newPlayer(char *name, char *password) function creates a new Player Object and generates an id for that player, the id being the next available index in the players array. Player Surroundings:When a player first logs in or is created, the server will call getLocalPlayers(int id). This function will return a list of GameData data structures with everything needed for the server to process commands. Essentially, these will be the players in the Row(s) of the player.

13. Life of a Command