For 3D strategy game WarMach, starting from a conceptual Clash of Clans, Pinkapp decided to use cloud platform Microsoft. About how it was, the company told App2top.ru. Pinkapp share the experience of working with Azure cloud platform.
WarMach – is a 3D online wargame about the war of human and orcs with the ability to control troops on the battlefield and clan interactions.
The game has a user builds a fortress, it enhances a variety of ways, selects the configuration of the walls and the buildings. If you do not have the resources to build, it is possible to attack another player’s castle, defense and hack it treasures. Unlike many other games of the genre, during the battle the player has full control over the troops and can achieve their strategic talent.
As for game development from the very beginning, we have decided not to reinvent the wheel: at the stage of design chosen ready, proven solutions for scalability and fault tolerance. And our server, which is essentially ASP.NET-application, we decided to use Microsoft Azure.
And in early 2015, we launched a developer’s server Azure – first on a trial subscription, and then switched to a subscription as payable one.
Then it works (and works now) like this: the client uses Unity 5, and the server is written in C # 4.5 is ASP.NET-application. Next: as a repository of data used AzureSQL (devices, basic information about the players, social networks data, gaming metrics), DocumentDb (city players, the history of fights) and AzureStorage (recording fights) To work with AzureSql used ORM Entity Framework. The client sends the data to the gaming server via http-requests. These are serialized into JSON. To connect to the chat server (it is independent from the game servers) using WebSocket-s.
In the process of development and deployment, we took a trip to WhiteNights 2015 and accidentally found out that Microsoft actively supports startups in the framework of BizSpark. Without hesitation, applied to participate, and received an affirmative answer.
Thereafter unfolded in the cloud.
Inside BizSpark program is allocated a certain amount on a monthly basis for the deployment of systems that can operate in production base. This made it possible to save on alpha phase and beta project. After the distribution of our server volume to 5 accounts that provides participants with the program BizSpark, we have reduced our cost Azure virtually to zero.
In summer we scale up a production server in Northern Europe for softlaunch of the game. Server lifted with power reserve, and then accounts for the use of Azure greatly exceeded the limit support BizSpark. Now we are discussing the possibility of obtaining a higher level of support – BizSpark +.
As the number of cores on the subscription BizsPark limited to the 20th and part of them was already occupied by softlanch, the more extensive testing is not conducted. The scale of the database has been chosen with a margin that does not rest on the performance of the database. According to our estimates, the development of its own server infrastructure instead of Azure has increased to around the time of the game development for 1,5x times. So work with the service are satisfied.
With regard to the difficulties encountered.
Of all the effort spent on development, most ate client. Work on the server started much later, time was short, so started to realize what was familiar, and made the server as a Web site. This caused some problems: http-protocol inconvenient for game projects, because the server can inform the client itself is nothing on any event. Nor is it possible to understand exactly where the player completes the game session, because there is no connection, and the logout request may not go (if the user simply unloaded from the application process of device).
As a recommendation we can advise from the very beginning of the development to have a test server with at least two instanced to catch bugs scalability. Also, in the case of the http-server, you should immediately check the work stickysession (for game projects stateless approach is not suitable, even though it is good for the site). The Azure Web Sites for stickysession client should support ARRAffinitycookie. For cloudservices binding occurs by ip and port (there are different configuration options).
Cache player in an instance can only be for a gaming session. On its completion should immediately unload the user’s cache server, because after a while it can login from another ip and get to the other instance (for example, came out of the subway and went to the cafe – ip changed). It should be borne in mind that any data the user can change an instance in another, even when it is online (it is desirable to make such data in a separate table).
An alternative and more correct option – to use a distributed cache that supports approaches read-through and write-behind. Hopefully, this will be Azure, and we can remove the instance of self-made mini-cache, which involves a lot of crutches.
Players can interact with, are on different instances, so you need to consider the exchange of data between instances. Ideally, use a distributed cache, or, for example, azureservicebus, but you can through the database. Another option – for some tasks to do a separate role, which does not scale, but keep in mind that it may become a bottleneck. For example, in our project such a role is a chat, a copy of which is always the same. In the case of very high load it would have to deploy to the most expensive virtual cloud with a bunch of cores and memory.
From our experience, we still do not recommend in the network of the game project messing with http, not to produce crutches when a server wants to send to the client an event – Network layer better use the usual tcp / udp, and the data can serialize, Using protobuff (get more economical than the json). If you are planning a web version or just want to try something new, you can look in the direction websocket. As for working with the database, then in the case of NoSql DB (DocumentDb, MongoDb) sharding problem should not be. But if you select a relational database, we recommend once thoroughly consider the implementation of scale-out data so as to relational databases is not a trivial task.