Is it worth it to take care of the possibility of supporting previous versions of a multiplayer online mobile game? And How?

Question

Game development

Hello,
Problem: While maintaining a game, the client/server communication protocol or something else may change, after which previous versions of the game will no longer be supported.
Questions:How critical is this for multiplayer mobile online games? Are there any statistics on the impact of mandatory game updates on user engagement? Is it realistic to create a game in such a way that the changes made would not affect previous versions and the life of each version would remain maximum? And how to do it? Can the task of maintaining previous versions greatly affect the architecture of the software, the speed and development process? Or most people do not pay attention to the need to update the game and just do it? Interested in the opinion and experience of both the developers and the players themselves.
Thank you.

Answer 1

During maintenance of the game, the client/server interaction protocol or something else may change, after which previous versions of the game will no longer be supported.

To be honest, changing and updating the protocol between product versions is the norm. Just don't confuse it with releasing content updates, that's a different matter.
We can say this: it is useful to change the network protocol completely from time to time. This is a good prevention against all sorts of parasites in your project. A sort of hygiene measure.
During the protocol upgrade process, we usually end up with one of two options:
In the first case, there are no particular problems. The second case really leads to a violation of compatibility.
In order to achieve compatibility between client and server versions in the first case, the developer usually uses serialization libraries that support backward (or/and forward) compatibility.
Examples of such libraries are Google Protobuf , Google Flatbuffers and Cap'N Proto . (yes, there is no C++ tag, but it does not interfere with the case)
I also came across independently developed solutions that, to varying degrees, have the advantages of the above libraries.
There are statistics on the impact of the obligation on the user's desire to play - a very big impact. Literally, this translates into a sequence: launched - asked to update the client - deleted, because. I want to play, not update.
This is what a lot of users do in countries where mobile Internet is very expensive and one 10Mb update literally means a hole in the wallet.
Therefore, it is very important to provide the user, if possible, with access to an already updated server from a still old client. Disable new features for the player, cancel sending packets, there were error texts like: "This new feature will be available after updating your client." Anything, but the player should be able to use what is available to him now.
If we are running a project for mobile platforms, then the situation with updates is even more interesting there. No one will ever tell you when your version of the client will be updated in a particular market. Laying out a version is a long process, it is impossible to synchronize it between different markets. If you only have GooglePlay and AppStore coverage, then this is half the problem. Usually there are dozens of markets, which necessarily include Ya.Stor for Android, markets from Samsung, mobile operators, small shopkeepers and the like. And if we go to China, then the number of markets starts to reach hundreds. And each of them will update your application only when it wants to.
All this suggests that updating the server and mobile clients is not a synchronized matter. The server should immediately be ready to accept updated clients, so it must be updated at the same time as versions are uploaded to the markets. And at the same time, this new server must be able to let in old clients, because the new ones have not yet been tested and uploaded for users to download.
Yes, really, examples of such games have been plying the Appstore and GP for more than 8 years. I won’t give names, I don’t do advertising, I’m not used to peering.
I use Cap'N Proto and Flatbuffers in my work. These two libraries cover backward compatibility issues for the protocol and binary resources. The use of these libraries is enough for the freedom to change data without fear of losing clients.
In general, backward and forward compatibility tools are needed to solve this problem.
It is important to understand that compatibility must be ensured not only for the protocol, but also for the resources of the client.
Resources can be uploaded to the user's provider's local CDN and delivered over a discounted rate, but the user may not be able to go to the Appstore and update the client application itself.
Therefore, the old client must be able to start with the new resources in compatibility mode.
This is exactly the task that the Flatbuffers library solves. It makes it possible to update the binary data format forward and retain very efficient access to them through the old version of the format.
Serious things like encryption/compression upgrades rarely happen. This is exactly the moment when compatibility breaks down completely. Such stages are planned in advance, releases are released in advance, news is fasted, the community is fully prepared for the inevitable and mandatory update. The day before the update, everyone who enters the game is greeted with a notification about the upcoming update. If only there was no panic among users.
If you offload part of the work (the part where you need to directly deal with ensuring compatibility) to the guys from the OpenSource community (and be sure to become part of it, by the way), then the maintenance task becomes easy.
The most important thing to understand is that backward compatibility is an extremely temporary measure. It is very necessary to enter it, but only during the migration of clients between versions. It is better to drive the most backward clients with a push stick so that they can be updated as soon as possible.
Maintaining 10 past versions is unwise and creates fertile ground for parasites.
If you say in general. Yes, interoperability is hard. This is a series of architectural decisions that must be made correctly. But if the skills already exist, if there is experience, if there is a vision of the project, then ensuring compatibility is a feasible thing.

Answer 2

The question can be divided into two:
- how to update the interaction protocol?
- how to update the game logic?
The protocol is simple. There are many options, I prefer this approach:
- For each API method, a version is entered that is explicitly specified by the client.
- Multiple versions of the same method can be supported.
- There are destructive API changes (increase the version) and non-destructive ones (do not increase the version).
- Non-destructive - this is the addition of new parameters to the response or optional to the request, without changing the logic of the server's reaction to receiving old parameters.
- Destructive: deletion, renaming, changing the semantics or data format in the response, changing the logic of the server reaction.
- When a destructive change needs to be made, the old method is kept in support until all clients (or the desired percentage of them) are updated.
Logic is more difficult. But there are also options:
- The simplest is a forced update. They rolled out a new server, everyone should update the client. It is the easiest to support, if a top product is not being made, then it is better to do so - it will save a huge amount of resources. But there are some nuances, for example, it is difficult to achieve the simultaneous release of mobile clients on different platforms (Google Play, App Store) due to the peculiarities of reviews, agreements on featuring, etc.
- Run multiple server versions: old and new. If a player has updated the client and played on the new version, he will no longer connect with the old client. Here it is necessary to correctly distribute clients across servers and take care of the non-intersection of different versions of the game. For example, it is not possible for clients with different versions to play together (PvP, tournaments, etc).

Answer 3

Separate the server interaction component from the main application.
When there is an update, update it in a "transparent" mode for the user.

Answer 4

In most games I saw only one option - they are not allowed to play until you update. If the update is released during the game, then they show a message in the interface, they say now there will be work on the server. Nobody supports older versions, it only fragments the user base.