Time for a second look at how our backend is made. In the previous one, we showed how technological foundations can positively influence development. Now it’s time to show how the architecture of the entire system can improve the gameplay.
MMO games have a fundamental problem – scaling. In an ideal world, such games could handle any number of players while maintaining stability. Unfortunately, our world is not perfect and most titles show problems sooner or later. A sudden influx of players can cause slower responses from the server and more errors. There are several ways to deal with it, and each is used by different games.
The most popular solutions are:
- private instances – players are divided into groups that get their own “copy” of the world (most popular in games based on isolated matches, e.g. FPS)
- sharding – dividing all players into larger groups, where each group is assigned to a given server (each MMO that has a world choice uses this technique, e.g. World of Warcraft)
- scalable fixed world – everyone plays in the same world which should scale to their number, e.g. EVE Online
How does it look like in VA? It depends on which version we are talking about.
The old version from years ago used sharding – everyone had to choose the world when logging in. This approach had some problems – it was impossible to scale the world up or down. Additionally, no one could interact with anyone from other worlds in any way. Luckily, we were able to diversify the gameplay back then by changing some of the rules of the game between worlds. Thanks to this, they were similar, but ultimately different, and you did not feel any artificial division.
In this day and age, such a system is ultimately too cumbersome and too restrictive for players to apply.
In the current version, we decided on one dynamic world. All players will play against each other and the game will scale to their number. This required significant changes to the backend architecture itself and a departure from the typical server = world approach.
The whole game consists of many services running in parallel in the cloud, which themselves can run multiple instances. This approach is similar to typical microservices, but the word “micro” is quite unconventional here – due to the nature of the application, some of them are quite large. Some services are responsible for e.g. calculating the current state of a player, others for sending messages, and others for trading. This approach eliminates bottlenecks in the game. For example, if sending messages slows down the game, just increase the number of running instances responsible for sending and everything should be back to normal. At the same time, the rest of the game will continue to function without any performance degradation. Thanks to this, everyone benefits – players have smoother gameplay, and we have more precise control over the game world.
Of course, everything must communicate with each other and there must be a place for data storage. At VA, Apache Kafka, Cassandra and Elasticsearch are responsible for this.
Cassandra as a database offers high performance and dynamic scalability. Same with Kafka as a system for exchanging messages between services. Elasticsearch, in turn, is responsible for quickly searching for anything – from other players by username fragments, to market offers. Everything is hidden in the internal network of the cloud, and communication with clients takes place through a special proxy, which is also responsible for security.
OK, but what does it mean for me?
The benefits of this approach are not only visible to us. Thanks to very detailed control over every aspect of the game, the whole system should be more stable and allow (in theory) the ability to scale infinitely. And that means a more enjoyable gameplay for everyone, without the artificial limitations of the world. MMO games are inherently very complex internally, and such architecture complicates them even more. The end result should, however, reward all the work invested.