Warscale Client Server architecture
by Guimo · 03/16/2008 (9:29 pm) · 0 comments
Introduction
On my last blog I talked a little about Warscale. Now its time to give more detail about the architecture design. Basically I want to talk about how Warscale is organized and how I made the login server, shard servers, database and clients all work together.
Building blocks
Warscale requires 5 elements to be present.
a. Web and Registration server
This server is the Warscale web server and allows for new players to download the latest version of the game, serves patches and register new accounts.
b. Database server
The database server holds all the player information. The Login/Password, the ammount of money, the armies and magic items and the number of strikes (hacking attempts). Warscale currently uses a MySQL 5.0 server as the Database server and uses the excellent SQLAPI library for connecting to it.
c. The Master Server
The master server is the first server a player connects to. It receives the Login information of the player and checks his account information. If he successful the login server sends a list of the shards which are up and running. The player then selects the desired shard and requests a connection to the Master Server.
When the master server receives a request connection it request the shard to accept the player. If the shard acceps the player then it sends the IP/port of the shard and unique code in that specific shard which the player must use in order to successfully connect to the shard.
d. The Shard
The shard is the main game server for Warscale. When a shard startups it connects to the master server and sends its information (name/ip/port) so the master server can register it to identify the shards.
When the master requests a space for a client, the shard reserves a slot for him and returns this slot id to the master server. If the code is not used in 2 minutes by the client then the code is invalidated.
Once the player successfully connects, the shard sends a list with all the players and informs all the players about the new arrival.
The player can decide to create a new game or join a existing game. In that case a game room object is created and the player is appended to it. The player now can chat with the players in this game room and wait until the game starts. If it is a new game then the shard informs all the players that a new game has been created.
When the game creator starts the game, shard informs all the game is starting and sends the game information (random seed, armies, avatars, items) and than waits for all the clients to inform if they have finished loading. Once all the players have finished the shard starts the game by giving the turn to the first player.
The shard then waits for player input. It executes each command from the client (move, attack, play spell, play special ability) and if the movement is valid then it informs everyone about this action. All games have the same information and the same seeds so they all should run exactly the same way. If one presents a different response then it gets disconnected. The shard validates the game status and when the game ends it sends a end game message to all the players and returns them to the game room so they can start again, change the map or just leave to the main room.
The shard also allows to configure the player armies or buy and sell spells and items.
e. The client
The client is the interface to the game. It presents the client with the loading screen. If the client logins successfully then it proceed to the shard selection screen. After selecting a shard the client enters that shard main room. Here he can chat with other players. From here he may enter the army editor where he can modify his armies or pick its magic items or he may enter the Store where he can buy new items or sell old ones.
When he is ready he can join a game or create a new game. In either case he enters the game room where he can chat with the other players and wait for the game creator to start the game.
When the game starts he sees the loading screen and then the 3D map appears. In the 3D map he will see the battle and make its selections. The player can see the spells he currently has available to cast (in hand) if he has enough mana. Any spell he uses is placed in the graveyard (represented by tombs and crosses). He cant see the spells his opponents have but can see their graveyards. The player can play spells and move its units. Once he has no move movements left he can pass the turn to the next player.
When the player avatar hot points reach 0 then the avatar and all the player unit dies. He may stay and continue watching the other players. When the battle ends the player is presented with a resume of the game and then he can return to the game room.
How it all connects?
The master, shards and clients all use a modified WSTCPObject class which can handle binary information instead of text information. This allows to send less information each message. The points communicate using packet classes. The objects are accessible from TorqueScript so the scripts can send and receive packets. For example:
//The client requests the shard to create a new game:
$Shard.sendCreateNewGamePacket(%gamename, %password)
...
//The shard receives a packet
function WsClient::onCreateNewGamePacket(%this, %gamename, %password) {
... do something
}
So... why not use a standar Torque architecture?
The benefits of this architecture is that I can process the information as binary inside the engine and save some bandwidth. The drawbacks is that you have to encode and decode the information on each packet with specific functions.
I was thinking about writing a TorqueScript library able to encode and decode the text numbers as ints and words and send the information using the standar TCPObject in order to be decoded in the other side. This may save me some problems but Im too advanced in the game to make this kind of core rewrite so maybe for my next game.
A second and more important reason is that Warscale allows the players to create and destroy games at at any time. This just cannot be done with a Torque server. My alternative was to start about 50 dedicated servers in the same server and allow clients to connect to them but I guess that would be a loss of resources.
Third reason, I do not need a real time connection. This is a turn based game so it works more like a chat. All the events are resolved in the shard and all the clients and all should be sinchronized.
But the most important benefit is that all the game connects on a TCP layer only, meaning that I really dont need the players to use the same platform...
So... what is exiting about this?
Simple, this meand that, as the server has been developed using Torque 1.5.2 it can run on a Window, Linux or even OSX platform!
Still not surprised? Well think the other way around. This means that if I get the client running in TGE then I can make the game work in Windows, Linux and OSX. But not only that. Warscale works basically like a communications layer so later I may decide to implement a client in TGEA or TorqueX or T360, Torque Wii or even TGB and they will all be able to connect to the same game! Think about portability and player interconection...
Ending
Well, Thats all for now. In my next blog I will talk about my experiences synchronizing a client and a server seeds.
On my last blog I talked a little about Warscale. Now its time to give more detail about the architecture design. Basically I want to talk about how Warscale is organized and how I made the login server, shard servers, database and clients all work together.
Building blocks
Warscale requires 5 elements to be present.
a. Web and Registration server
This server is the Warscale web server and allows for new players to download the latest version of the game, serves patches and register new accounts.
b. Database server
The database server holds all the player information. The Login/Password, the ammount of money, the armies and magic items and the number of strikes (hacking attempts). Warscale currently uses a MySQL 5.0 server as the Database server and uses the excellent SQLAPI library for connecting to it.
c. The Master Server
The master server is the first server a player connects to. It receives the Login information of the player and checks his account information. If he successful the login server sends a list of the shards which are up and running. The player then selects the desired shard and requests a connection to the Master Server.
When the master server receives a request connection it request the shard to accept the player. If the shard acceps the player then it sends the IP/port of the shard and unique code in that specific shard which the player must use in order to successfully connect to the shard.
d. The Shard
The shard is the main game server for Warscale. When a shard startups it connects to the master server and sends its information (name/ip/port) so the master server can register it to identify the shards.
When the master requests a space for a client, the shard reserves a slot for him and returns this slot id to the master server. If the code is not used in 2 minutes by the client then the code is invalidated.
Once the player successfully connects, the shard sends a list with all the players and informs all the players about the new arrival.
The player can decide to create a new game or join a existing game. In that case a game room object is created and the player is appended to it. The player now can chat with the players in this game room and wait until the game starts. If it is a new game then the shard informs all the players that a new game has been created.
When the game creator starts the game, shard informs all the game is starting and sends the game information (random seed, armies, avatars, items) and than waits for all the clients to inform if they have finished loading. Once all the players have finished the shard starts the game by giving the turn to the first player.
The shard then waits for player input. It executes each command from the client (move, attack, play spell, play special ability) and if the movement is valid then it informs everyone about this action. All games have the same information and the same seeds so they all should run exactly the same way. If one presents a different response then it gets disconnected. The shard validates the game status and when the game ends it sends a end game message to all the players and returns them to the game room so they can start again, change the map or just leave to the main room.
The shard also allows to configure the player armies or buy and sell spells and items.
e. The client
The client is the interface to the game. It presents the client with the loading screen. If the client logins successfully then it proceed to the shard selection screen. After selecting a shard the client enters that shard main room. Here he can chat with other players. From here he may enter the army editor where he can modify his armies or pick its magic items or he may enter the Store where he can buy new items or sell old ones.
When he is ready he can join a game or create a new game. In either case he enters the game room where he can chat with the other players and wait for the game creator to start the game.
When the game starts he sees the loading screen and then the 3D map appears. In the 3D map he will see the battle and make its selections. The player can see the spells he currently has available to cast (in hand) if he has enough mana. Any spell he uses is placed in the graveyard (represented by tombs and crosses). He cant see the spells his opponents have but can see their graveyards. The player can play spells and move its units. Once he has no move movements left he can pass the turn to the next player.
When the player avatar hot points reach 0 then the avatar and all the player unit dies. He may stay and continue watching the other players. When the battle ends the player is presented with a resume of the game and then he can return to the game room.
How it all connects?
The master, shards and clients all use a modified WSTCPObject class which can handle binary information instead of text information. This allows to send less information each message. The points communicate using packet classes. The objects are accessible from TorqueScript so the scripts can send and receive packets. For example:
//The client requests the shard to create a new game:
$Shard.sendCreateNewGamePacket(%gamename, %password)
...
//The shard receives a packet
function WsClient::onCreateNewGamePacket(%this, %gamename, %password) {
... do something
}
So... why not use a standar Torque architecture?
The benefits of this architecture is that I can process the information as binary inside the engine and save some bandwidth. The drawbacks is that you have to encode and decode the information on each packet with specific functions.
I was thinking about writing a TorqueScript library able to encode and decode the text numbers as ints and words and send the information using the standar TCPObject in order to be decoded in the other side. This may save me some problems but Im too advanced in the game to make this kind of core rewrite so maybe for my next game.
A second and more important reason is that Warscale allows the players to create and destroy games at at any time. This just cannot be done with a Torque server. My alternative was to start about 50 dedicated servers in the same server and allow clients to connect to them but I guess that would be a loss of resources.
Third reason, I do not need a real time connection. This is a turn based game so it works more like a chat. All the events are resolved in the shard and all the clients and all should be sinchronized.
But the most important benefit is that all the game connects on a TCP layer only, meaning that I really dont need the players to use the same platform...
So... what is exiting about this?
Simple, this meand that, as the server has been developed using Torque 1.5.2 it can run on a Window, Linux or even OSX platform!
Still not surprised? Well think the other way around. This means that if I get the client running in TGE then I can make the game work in Windows, Linux and OSX. But not only that. Warscale works basically like a communications layer so later I may decide to implement a client in TGEA or TorqueX or T360, Torque Wii or even TGB and they will all be able to connect to the same game! Think about portability and player interconection...
Ending
Well, Thats all for now. In my next blog I will talk about my experiences synchronizing a client and a server seeds.
