Pinkapp spoke about the experience of working with the Azure cloud platform

WarMach is a three-dimensional online wargame about the war of humans and orcs with the ability to control troops on the battlefield and clan interaction.

In the game, the user builds a fortress, strengthens it in many ways, chooses the configuration of the walls and the composition of the garrison himself. If there are not enough resources to build, you can attack another player’s fortress, hack his defenses and steal the treasures. Unlike many other games of the genre, during the battle the player has full control over the troops, you can realize your generalship talent.

This is if about the project.

As for the creation of the game, from the very beginning of development, we decided not to reinvent the wheel: already at the design stage, we chose ready-made, proven solutions for scaling and fault tolerance. And we decided to put our server, which is essentially an ASP.NET application, on Microsoft Azure.

And so at the beginning of 2015, we deployed developer servers on Azure – first on a trial subscription, and then switched to a pay-as-you-go subscription.

It worked then (and it works now) like this: the client uses Unity 5, and the server is written in C# 4.5 and is an ASP.NET application. Further: AzureSQL (devices, basic information about players, links to social networks, game metrics), DocumentDB (player cities, battle history) and AzureStorage (battle records) are used as data storageORM Entity Framework is used to work with AzureSql. The client sends data to the game server using http requests. The data is serialized in JSON. WebSockets are used to connect to the chat server (it is independent of the game servers).

During the development and deployment process, we went to WhiteNights 2015 and accidentally found out that Microsoft actively supports young developers within the BizSpark program. Without hesitation, they applied for participation, and received an affirmative answer.

After that, they turned around in the cloud.

Within the BizSpark program, a certain amount is allocated monthly for the deployment of systems that can work in production. This made it possible to save money at the alpha and beta testing stage of the project. After distributing our developer servers to 5 accounts, which are provided to the participant of the BizSpark program, we reduced our Azure costs to almost zero.

In the summer, a production server was deployed in Northern Europe for a soft lunch. The server was raised with a margin of power, after which the bills for using Azure greatly exceeded the BizSpark support limit. Now we are discussing the possibility of obtaining higher-level support – BizSpark+.

Preliminary load tests of game servers (not optimized yet) by bots look like this:

Since the number of cores on the BizSpark subscription is limited to 20, and some of the cores have already been occupied for softlanch, larger-scale tests have not yet been conducted. The scale of the databases was chosen with a margin so as not to rest on the performance of the database. According to our calculations, developing our own server infrastructure instead of Azure would increase the game creation time by about one and a half times. So we are satisfied with the work with the service.

As for the difficulties encountered.

Of all the efforts spent on development, the majority was eaten by the client. Work on the server began much later, there was little time, so they began to implement it on what was more familiar, and made the server as a website. This entailed some difficulties: the http protocol is inconvenient for game projects, since the server itself cannot tell the client anything about any event. It is also impossible to understand exactly when the player ends the game session, since there is no connection, and the logout request may not be sent (if the user simply unloaded the application from the device processes).

As a recommendation, we can advise you to have a test server with at least two instances from the very beginning of development in order to catch scalability bugs. Also, in the case of an http server, you need to immediately check the operation of stickysession (the stateless approach is not suitable for game projects, although it is good for websites). In Azure Web Sites, for stickysession on the client, you need to support ARRAffinitycookie. For cloudservices, binding occurs by ip and ports (there are different configuration options).

You can cache a player on an instance only during the game session. Upon its completion, you need to immediately unload the user from the server cache, since after a while he can log in from another ip and get to another instance (for example, he left the subway and went to a cafe – the ip changed). It should be borne in mind that some user data may change on another instance, even when it is online (it is desirable to put such data in separate tables).

An alternative and more correct option is to use a distributed cache that supports the read-through and write-behind approaches. I hope this will appear in Azure, and we will be able to remove a self-written mini-cache from the instance, which is associated with a lot of crutches.

Players can interact while on different instances, so you need to think about the exchange of data between instances. Ideally, use a distributed cache or, for example, azureservicebus, but you can also use a database. Another option is to make a separate role for some tasks that does not scale, but keep in mind that it can become a bottleneck. For example, in our project, such a role is a chat, of which there is always one instance. In case of a very heavy load, it will have to be deployed on the most expensive virtual machine with a bunch of cores and memory.

Based on our experience, we still do not recommend messing with http in the network part of the game project, so as not to produce crutches when the server wants to send an event to the client – for the network layer, it is better to use the usual tcp/udp, and data can be serialized using protobuff (it turns out more economical than in json). If a web version is planned or you just want to try something new, you can look towards websocket. As for working with the database, in the case of using NoSQL DB (DocumentDB, MongoDB), there should be no problems with sharding. But if a relational database is selected, we recommend that you immediately think carefully about the implementation of horizontal data scaling, since this is a non-trivial task for relational databases.

By the way, at the Moscow White Nights, our game designer Vsevolod Ivanov briefly spoke about the experience of using Microsoft Azure described in the article (the video will appear in a few days).

Official website of the game: http://warmach.pinkappgames.com
The project itself is currently available on Windows Phone platforms.

You can download it from here.