Chris Harrison
Stacey Kuznetsov
Mariya Lysenkova
Jennifer Refat
Gabriel Sinkin
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)
Server Architecture
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)
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)
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.
Client Architecture
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 ingame 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
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
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
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
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.
Life of a Command