General description of dedicated servers and the problem:
---------------------------------------------------------
Dedicated multiplayer game servers such as those for Half-Life or Quake II are becoming increasingly popular. First of all, they create a sense of community for the regulars on any one server. Most importantly, however is that such servers allow many fans of any specific game to do something towards helping the community surrounding that game grow.

Therein lies the problem. With a lot of these amateur servers, no one is exactly sure what kind of server it is they connect to. Gamers will launch a server query tool such as GameSpy or Kali, update their list, and look for the server with the lowest ping. However, round-trip latency does not qualify as an accurate measurement when it comes to determining the overall quality of any one server. Such factors as CPU speed and RAM capacity may compromise the efficiency of the server and make it perform much like another server that is 200 milliseconds slower in round-trip packet time.

Another problem associated with such servers is bad administration. Server administrators will ignorantly set maximum player limits far beyond those that their dedicated servers can handle. The consequences of such actions result in ping spikes for all players on the server, packet loss, a reduction in the game's frame per second output, and an overall depreciation of gaming quality.

A cluster network:
------------------
Now that it is confirmed that with today's current limitations in bandwidth and processing technology it is nearly impossible to host multiplayer games with an extraordinarily large number of people on a single server, we attempt to look at the utilization of more than one server in order to create pseudo- load balancing such as that found in enterprise networks. If the game's network code were written in such a way that is very similar to what web browser's do, it would definitely solve many problems associated with server load and capacity.

Here is an analogy to describe the current problem with one that has already been solved. Running a dedicated server today would be like creating a world wide web in which it was impossible to have a hyperlink. If you can even imagine how slow the growth of the world wide web would be if it lacked hyperlink technology, it would seem to make sense that in order to create a true multiplayer gaming community, servers would have to be able to drop clients and pick them up without the client even realizing he has been relocated.

What gaming companies attempted to do by creating hyper-capacity gaming servers such as those used for many multiplayer RPG games can be likened to an attempt to put the whole world wide web in the hands of a single company. To make matters worse, most companies charge a monthly fee for access to such servers. Needless to say, not only does that hinder the growth and popularity of the game, but places a huge burden on the company to maintain the server once traffic becomes slightly excessive. Maintenance costs including thousands of dollars spent on hundreds of man hours may in the very end not be enough to give the player a quality connection, which is now expected since he pays a monthly fee. Now the company must spends thousands more on technical support lines and staff to ensure the community that the servers are being upgraded. Wouldn't it be easier if that burden was split among 10,000 server admins?

So now you see why such a network makes sense. Now let me explain the added benefits to having such a network.

Possible utilizations for large cluster networks:
-------------------------------------------------
Imagine a game in which you are a single soldier involved in a very large war. The war could be fictional, taking place in the future, or it could be historic, with events identical to those from World War II. You are dropped on the battle- field, now you must follow your orders. You rush over the hill and assault three infantry men, then proceed to the enemy's base where you will find a fourth. After a short knife struggle, you win, and suddenly you are transported back to a preset entity in the game and the "round" starts over again!

What just happened? Isn't this supposed to be a large scale war? How come there are only five players on the relatively large battlefield? Well, you have just experienced the current limitations of dedicated server technology.

Let's give our game a title. We'll call it, "War", which is short and straight to the point. If War was just released by a company called "Squid Software" that is known to make excellent action game titles, it is without a doubt that a lot of people will pick it up off store shelves. They will then bring the game home, install it, and connect to a dedicated server that has a few players and a low ping time. After about 4 such "rounds", you reach the conclusion that the game is completely unrealistic and it depreciates from gameplay given the scenario of the game, which is large scale war.

With large scale cluster servers, though, each server will contain part of the very large battlefield. More servers that are inter-connected equates to more players that are simultaneously playing and a seemingly larger battlefield. If the current scenario is the invasion of Normandy, then the beach landing will be on one server, and as the players move further into France, they hop from one server to the next on the cluster. This will result in players actually feeling that they are in a large scale war, with anywhere from 500 to 1000 or possibly even more players on the battlfield! When the player dies in the game, he is brought back into the game as a military reinforcement unit, landing on the beach once again. An alternate possibility is having the player out of the game until a certain trigger event takes place, such as troops reaching a certain location or the commanding officer gives the order for the paratroopers to land. The possibilities are endless.

Cluster network topology:
-------------------------
Now that we discussed the problem, the solution, and a possible use for such technology, it is important to discuss possible ways that this technology can be implemented. Cluster networks generally mean networks that are interconnected with each other in such a way that every node of the cluster can communicate with every other node. So if you have 5 servers, A, B, C, D, and E, server A can communicate with B, C, D, and E. Server B can also communicate with A, C, D, and E, and so on. Such a cluster is said to be PARALLEL, because every server shares information with every other server. While this seems like a very good way to implement our sought technology for gaming purposes, if you factor in the bandwidth limitations that most people are subjected to things can become very complicated. Given the fact that most dedicated servers found in server query tools are run on a cable modem connection, it is quite difficult for 5 servers to share information with each other all at once. Congestion will occur, because server A will have to upload player information not only to server B, but also to servers C, D, and E. This consumes a large portion of server A's upload bandwidth. If you include the bandwidth required to update the clients (e.g. players) with other player information, you will soon realize that each server needs five times the amount of bandwidth that every player is consuming COMBINED. If you were running a cluster of 150 servers, you will soon realize that such an implementation on a large scale is not only impractical, but impossible.

There is a solution, however. If administrators were given the option of including their server in the cluster in the form of a SERIES network, in which every server talks to only the one before it and after it in the cluster, the server would only need to have three times the bandwidth that players are consuming. This data rate can be calculated by taking the data rates necessary for a single player to have a good connection with minimum frame loss, multiplying it by the number of players on the server, and then multiplying it by three. In a series network, assuming there were 26 servers A through Z, server H would only need to communicate with servers G and I. The layout of such a topolgy can be directly correlated by events in the game. For example, let's go back to our Normandy scenario. Players that are on the beach cannot view players that are a mile into France. It would only make sense that as players move in, they are "rolled" over from one server to the next, and in that sense, their view distance is directly related to what server they are on! Server A can be the beach confrontation, and about 500 relative yards into France they can be moved to server B, and so on and so forth. Hopping across servers would need to be flawless. Maps would need to be precached into video memory in a segmented pattern. Today's current .bsp map standard is too localized and inefficient for our purposes. We have to make maps small so they load without clients noticing a change. Mapstream technology allows maps to load continuously, flushing old data from video memeory and replacing it with new texture data and visual entities. Kill/death statistics would be calcuated through client side network code which sends a packet every time the player dies or kills someone to a central database server which compiles the information and submits it into the cluster. Server power will ultimately be limited to determing the position of the players on the map, and wether or not a player is hit. The data would then be relayed to either all or nextdoor neighbor servers depending on the cluster mode, where each server will submit the data back to its clients. Client side processing includes 3D modeling and the processing of player positions as dictated by the server, and kill/death stat updates to the scoreboard server. At the end of the game scenario, all of the servers in the cluster submit the data that the scoreboard server compiled to the clients, where it is then displayed on screen. Up until that moment though, everyone's score is kept to themselves.

I urge all those developers interested in the implentation of such technology in their game to contact me as I have many many ideas I would like to share, and I would prove to be an excellent asset to your project team.

CLUSTER GAMING NETWORKS - Dedicated multiplayer game servers

ZiN
drx@tampabay.rr.com

Avoiding making a fool of myself, I must inform you of that I am mainly a video gamer and seldom play PC multiplayer games. That said, I admit that some of the details in your most excellent article/idea about server problems and possible solutions went beyond my knowledge on the subject. But I don't see that as a problem. After all, this article is not dedicated to me :]

Idea Reviewer:
-Vegard Aure-