Optimal server structure for the MMO game project

    It makes sense to choose the optimal server structure at the very beginning of the project.  This is not only an important technical consideration, but also directly affects the entire project’s profitability and viability. If you are going to work on a massively multiplayer online (MMO) gaming project, you must clearly understand that here, “massive” refers to an infinitely large number of users.          Undoubtedly, no one wants to deliberately limit the number of application users, because every user is a potential source of profit. Server structure is the element that is responsible for accepting and supporting all of the available users. Therefore it has to meet very high standards of speed and reliability. Let us help you select the best server structure for your application. To illustrate the process, we will consider two parallel solutions for online project development.

Project A and Project B are presented in the diagram above. Both are in the business of developing similar games and are competing against each other. Project A uses a standard server solution that employs one location server (sometimes several) and one SQL database.

Project "A" is a server solution that followed a precise plan and was designed to fit a particular game:

• Very fast computers were selected to reduce the time required for game play calculation
• The database was designed specifically for this project (for maximum performance)
• The server was fully debugged and laboratory tested (with excellent results)
• Approximately 10% of the budget was allocated for server development.
• The developers worked hard and were able to build the server on a fast deadline

Project B featured a distributed server solution:

• A distributed structure was created

• A manager program was created along with local communication resources (protocols and interfaces for service interaction)

• Additional work was performed to test automatic start and stop of the services (called Automated Resource Management), and to test Load Balancing between services that are currently running

The resulting servers were more unified, but not as fast as the server in Project A. Also, it took more time and money to develop the servers in Project B – about 30% of its budget. Both projects were successfully launched, and it really looked like the server solution in Project A ran faster and smoother. Yet, there was more to Project B than was immediately obvious.

In Project A, the server was built on a structure that was not scalable and could not perform distributed computing.  Therefore, when the server reached its user capacity - it became unstable, which resulted in frequent collapses. The project was no longer able to accept new users, which stifled its overall growth and earning potential. To keep the project running, additional funds were allocated to rewrite the server code (about the same amount that was originally spent on its development). Project A ended up losing time, money and users (who left to join the competing project). Eventually, the project returned to its initial, stable state. But with the passing of time, Project A ended up in second place; only after a long while it rebounded from losses and became profitable. However, most projects in the real world would not be able to “stay in the game” after such a disruption.

Following its advertising campaign, Project B saw an increase in users.  After their number reached a certain level, additional server capacity was added, allowing to distribute the load evenly among the project’s services. What observations can we make? Users are happy - the project is stable - the profit increases. Since there were no server collapses, each new advertising campaign attracted the greatest number of users possible. Project B quickly paid for itself, which freed up some of the funding for further development. Because the server end allows for logical and functional improvements, new game levels can be created, and modifications can be made for adaptability to other platforms. This upward movement even helps attract new users from other projects. Project B finishes in first place and becomes a trend-setter for other players in the market. So why did Project A, with its perfectly balanced server, start out in front, but finished considerably behind Project B?

It is fairly obvious that the choice of server structure in Project B was much more optimal.

So how do you find the right server solution for your project?

Formula for stable server operating conditions.

The figure above shows a simplified formula for stable server operating conditions. Each gaming application has a maximum range of game object calculations (tick calculation), above which it becomes impossible to continue playing (Tmax)

Tk – time required for single user calculation
Nk – number of users

According to the formula, stable server operation can be achieved by:

1) Reducing the time required for single user calculation (database optimization, improved coding procedures, increased computing power), or
2) Reducing the number of users

When constructing an ordinary server, we cannot reduce the number of users, so only the first option remains: code optimization and computing power increase.  However, this fix cannot be applied infinitely and upon reaching the limit (called the ceiling), the system becomes unstable.

    In the case of distributed computing, when calculations are made by many services simultaneously, the number of users is equal to one. In other words, the number of users does not affect the distributed system. This means that server operating conditions depend only on the time required for single user calculation. Theoretically, the system can handle an infinitely large number of users. Of course, there are limitations. But compared to the sizeable advantage of distributed systems they are quite negligible. Search engines and social networks (e.g., MySpace with 130,000,000 active monthly users and 300,000 new daily users) serve as a vivid proof of this advantage.

Fundamentals of distributed server solutions
  .

• Server structure is divided into parts
• Each server component is independent and does not store information about previous calculations
• Each server component can quickly access the data necessary for calculations
• The data are distributed based on their type and quantity
• Server Communications are based on messages across RAM Pipes TCP UDP

The fundamentals of distributed server solutions are listed above. What we are doing (in plain English) is breaking the server system down into unified components.  Further on, we will use these building blocks (shown in the figure below) to put our distributed server back together.

The components are created in such a way that each has a universal application anywhere in the server system. Therefore, we can combine our building blocks in any way we want in order to create the optimal server structure. So, the next time you decide to use a typical server engine, make sure that its components can be lined up in the best possible way for your particular gaming project. Otherwise, you may need to change your game play to fit that server. As for our distributed server, let us take a look at how the building blocks are combined to make it work.

The diagram above shows a simplified structure (a.k.a., a program) for calculation of game objects. A distributed system consists of many such programs; they could either work simultaneously or asynchronously. When game object data are calculated, they are entered into the calculation program that determines the object’s properties via appropriate tools and formulas. In other words, the program has access to all of the scripts and formulas for game object calculation. Afterwards, the results are communicated to each user and to other game objects with which the user has interacted. This simplified diagram allows us to understand the general idea behind a distributed server system.

This is a functional diagram; it does not describe where these services are actually located on a computer. Any computer can contain services (or portions thereof) for calculation, communication and operational data storage. The exact setup depends on specific project requirements. Each group of services undergoes dynamic changes with fluctuations in data load. When a large number of users are connected, new instances of services are automatically started. Likewise, when the number of users goes down, unnecessary services are automatically closed.  This work is performed by the service manager.

Possible service locations on a computer 

Above is a sample arrangement of services. Usually, the best location is determined by reliability and speed of processing. For example, this diagram shows a part of the server structure that is responsible for processing commands received from the user. Services can be placed in one or more applications. Thus, for command processing services, it is most convenient to use a dynamic thread pool at the end port of Windows operating system. Distributed server solutions are available on different platforms (Windows, Linux, etc.) as long as they feature all the necessary implementation tools. Other important criteria are how fast and stable the entire system is. Our team has adopted the .NET technology, as it meets both of the above criteria: it is very fast and sufficiently stable.

Which server solution is right for your project? It is up to you, whether you want to choose a typical server, order a custom design, or create your own solution. From my experience, I can tell you that creating a server solution for a specific project is much more effective than using a typical server. And custom server solutions based on each project’s requirements is what our team does best.

We are always ready to start a new partnership. 

Let our experience and best practices be at your service. 

Paul Shtoler

[email protected]