Java Client – Server

Nowadays, most of the games available out there include a multiplayer mode. It could be massive and persistent (MMOG) or not (just like FPS games), there are a lot of issues to fix in order to provide a comfortable game to play with.

Common Issues

Persistence

The world does not have to be reset but has to keep living all the time. If an object is dropped, it has to stay there unless another player takes it back. It gives the illusion of that the world is living.

Consistency

the world has to stay consistent. If a player kills a monster, he does not want to be killed by this monster (unless the game allows that). The lack of consistency is often a consequence of the latency.

Latency

when a player performs an action, some messages are sent to the server which then spreads updates of the world to all the players. This operation takes time and if the network is busy, it could take an intolerable time. So, the game, which is running on the player’s computer, has to try to forecast as good as possible the next changes in the world (and still updates the world when server’s messages are received) with dead-reckoning algorithms.

Synchronisation

by forecasting the following updates, we try to let the player be independent from the server to avoid latency. Since it is not possible to guess what the other players will do, the forecasts are often wrong and the game has to stay synchronised with the server to correct the events.

Bandwidth savings

since we cannot make the Internet better, a solution is to reduce as much as possible how many messages we have to send. The main idea is to send only what is necessary and it is up to the developers to decide what is necessary.

Architecture

one of the most important criteria to take in consideration because it has an impact on every others issues. What kind of servers? For what purpose? It is not cheap but a lack of server increases the risks to have latency or connection problems and so, the risks to lose more and more players.

Scalability

because it is not possible to guess how many players will use the servers, it is important to deploy enough servers to handle hundreds and hundreds connections and maybe more. This is even more valuable with a MMORPG which should host thousands and thousands player at the same time. The scalability is the fact that our architecture can handle more and more connections.

Cheating

something really irritating for everyone, cheaters can very deteriorate online games because no one wants to play against a player who has unlimited ammo or life, can fly, avoid damages, etc… In the end, they can put honest players off playing. Moreover, the security can save money to players or even us. If they can steal an account and use the credit card associated or directly alter in-game shops to change the prices of items, it would be a disaster.

Server Architecture and Algorithms

Some thinkings

The architecture would be based on multi-servers communication and zone-based. This choice implicates to split the virtual world into distinct zones and so probably think again about the gameplay to adapt it to the principle of zoning. Some tests have to be processed because it is not possible to guess precisely the requirements of such architecture: some zones could be too big for the server or, on the contrary, too much server could be deployed which is a synonym of a loss of money. With approximation algorithms, it is possible to provide an idea about the money required.
However, some issues could be solved without spending more money with appropriate algorithms and techniques such as the dead reckoning algorithms or the limitation of the update frequency.

Finally, cheating could be split in sub-sections: first, the use of glitches, bugs or game exploit. Some are harmless but others can become very annoying for the honest players. These cheats are inherited to the game implementation. A player who disconnects its console to not lose a fight on Street Fighter could be penalized but if the problem came from the game which just crashed? It is not always possible to detect intentional cheats and it is difficult to fight it. It is so up to the developers to handle this. However, since the game will use real-money for some transactions, it is mandatory to secure this with SSL/TLS encryption for instance. If some persons can steal credit card details of some players, it would be a disaster. It could be also possible to steal accounts and so, items it owns. It seems to be a good strategy to set up one or more authentication server independent from the others for log in purpose, in order to increase the security. The encryption might be slow; it is useless to use SSL/TLS for update events while it is mandatory for authentication and sales.

In order to keep players on our servers, it is essential to keep the latency very low. Some techniques are available to avoid the latency: a good communicating architecture, clock synchronization, dead reckoning algorithm and the interest management. First, dead reckoning algorithms are difficult to implement in online FPS essentially because a human player is unpredictable and often, adopts a very unrealistic behaviour (by jumping all the time, suddenly change his direction). Moreover, even with a good clock synchronization (computes the theoretical latency with some exchanges with the server to try to compensate it), it cannot be perfect and the game has to keep staying up to date with the server. Unfortunately, the latency can cause the world to lose its consistency. Which player is still alive? Is the player damaged by the shot? The deadline-base consistency model could be advocated: if an event was not processed after some time, it just has to be ignored. In this way, there are no “late” events and so, instantaneity (when a player triggers an action it is directly displayed to every other players) or at least the simultaneity (the event happens for every players at the same time) of the game is preserved. Finally, the interest management is the fact of reducing the number and size of messages sent.

Classical techniques to help reduce bandwidth usage are listed:

• Money: buy more servers to increase the bandwidth
• Reducing the number of hosts to which information is sent: there is no point to send our position to a player located too far away from us.
• Reducing the update frequency: depending on the game, sometimes dead reckoning algorithms provide good enough results. By reducing the update frequency, the number of addresses and concatenating messages, we should end up with better performances without buying more servers.
• Message aggregation: messages are concatenated to be sent all at once. The sending is triggered when a fixed size or time (or both) is reached.
• Encryption: by encrypting messages, their size is reduced but it this process could take time depending on the CPU.

With MMOG the world is the persistent so, the servers have to run 24/7 because players can be connected at any time and for a long game session. One thing to decide is the patch policy: Patch Day No Play? Or is it applied on the fly with the client? Since World of Warcraft or Dofus apply the policy of “Patch Day No Play”, I am in favour with.

The scalability and the robustness of the architecture are some valuable criteria. Once again, it is depending a lot on the kind of game. A FPS server would host a moderated number of players. The largest number of clients on the same map I have ever seen is 128 with the game M.A.G. (stands for Massive Action Game) only on PlayStation 3. In the other hand, a MMORPG such as World of Warcraft should be able to host thousands of players. The only solution seems to buy more servers.

Technical Design

Once we have outlined the main issue, we can start thinking about the architecture which will be deployed and listing the pros and cons. I have chosen the zone-base architecture. This architecture implicates to delegate one or more zone of the virtual world to a particular server. It is so a multi-server communication architecture. The virtual world is partitioned into zones. So, players are connected to the server hosting the corresponding zone of the world they are.

The advantages are many:

• Optimised use of bandwidth
• Not optimised for latency (but not necessarily that bad)
• Synchronisation facilitated for a part of the game-state (interest management)
• Has an impact on the game-play.

Since we are concerned by bandwidth savings and interest management, this architecture provides a good start point. Nevertheless, it requires splitting the map into zones and this task does not have to be underestimated. Indeed, one server is hosting one part of the world, so how the world will be split in a way to not have to deploy a huge amount of servers? This is the problem of under-provisioning and over-provisioning. There is also the assignment of zones to distributed servers. For all of these matters it is recommended to use approximation algorithms to try to guess the needs.

Diagram

The class diagram of the application

Features:

• The application is fully written with the JAVA NIO package; so, every IO operations are configured in non-blocking mode.
• Each selector uses an Executor to delegate its tasks except for the Client. The executor permits to let the selector continue. Tasks will be processed later by “workers”.
• Communications between clients and servers are based on a Message base class. Every kind of messages inherits from this base class. They are serialized to be able to be sent through the network.
• A server uses a dispatcher to handle a room. In this way, the Server started is only used for accepting new connections. A three-phased handshake is done with the client; if the connection is validated, the client is put in a room and delegated to a dispatcher.
• Every channel is associated with a Handler. That means a worker can process any kind of channels without wondering itself which type of channel it is (SocketChannel, ServerSocketChannel and DatagramChannel are supported).

The application

The client features a chat interface and a 2D graphics zone, representing the players using simple geometrical shapes. These avatars are identified by a name, they can move smoothly and are controlled by the players through the mouse. Their moves are transmitted to all the clients with avatar in the same « room »: players’ positions are transmitted to the server and then forwarded to the other players using UDP unicast. The keyboard is used for entering text into the chat interface to communicate with other players using the TCP protocol following client/server architecture. Clients can communicate with all the other clients whose avatar is in the same room.

The game takes place in at least 2 « rooms », each one presenting a portion of the map, and each room is handled by a different server program. Thus, there are at least 2 server programs composing the application. Each server can run a number of distinct rooms and they are reasonably robust. The first client connected to the server has the tag. This latter is transmitted to another avatar when they collide.

Java Nio Chat + Documentation