Managing Versions with Online Gaming
Proper version management is often something that is overlooked by developers during the course of the game development, because the issue does not appear during QA. However it always strikes back with a vengeance once the game is in players’ hands and can lead to disasters and lots of angry users!
What is the problem?
Say you are going to publish a new version of your game that fixes some important bugs in the Rules Engine. For example, your game uses cards and some of the cards were not implemented correctly so you fixed them. QA validated your build and you pushed your game to the Stores, thinking you did a great job and patting yourself on the back.
However, once the update reaches players, you get tons of angry comments, like “online gaming is broken in the update”, “the update is worse than the previous version”, etc. What went wrong?
In fact, you just ran into two problems:
- Compatibility between apps playing together on-line
- Compatibility between updated apps and older (on-going) games
Compatibility between apps playing together on-line
Do all users update automatically and right away? Definitively no and no.
On iOS, you can turn off the automatic update of your apps. On Steam, you can postpone downloads for later in the night. Some users have learned the hard way that updating is always risky and prefer to wait and see. Etc.
So you are going to end up with users playing together online with different versions of the app. Which means different implementations of the cards. If you implemented your Rules Engine properly, i.e. by using Event Sourcing and checking all the actions when loading a Game State, one of the apps is going to reject the game data.
One solution is to implement backward compatibility and forward compatibility in the Rules Engine and your Game State data model. For minor changes, it is usually possible and remains the recommended approach, to provide the best experience to players. But it can become quickly quite complicated and sometimes simply impossible, for example when the game rules change too much.
So the “brute force” solution is to force all users to update when they enter the critical area of online gaming. A simple technique is to store some configuration file on Amazon S3 and read it (we can provide you with a S3 Bucket on request). It can be a JSON file, a YAML file or even a plain text file with just a number - whatever you prefer. This file represents the minimal version that apps should have to be able to play online. The app should compare this number with the one it stored internally and show a stopping dialog to the user if the app is deemed too old: “Please update your game to the latest version to be able to play online”.
Compatibility between updated apps and older (on-going) games
So now we have a system that ensures that all apps playing online are from the right version, but you are still getting angry reports from customers. What’s going on?
The problem is that these players are trying to play asynchronous games that were started before the update. These games may contain actions that were valid with the old Rules Engine but that are not valid anymore. So these games data will be rejected when replayed by the Rules Engine - just like in the previous case.
The solution is to store the app version number at the beginning of your Game State when a new game is created. When loading the Game State, this number is compared to the app’s version number, and the game is rejected if the game data version is lower that the app’s one. The app should show a message like “Sorry, this game is too old and cannot be played with the new update. It will be terminated.”
After that, a nice touch is to hide this game from the list of games that can be resumed. This will prevent the user from trying to load it again.
Depending on the type of game that you do, the problem may be more or less serious. Games that are played quickly and synchronously most of the time, such as Ticket to Ride, are usually not much of a problem. But games that have long turns and a long Player Clock will definitively run into this issue (we did).
Therefore it is a good idea to warn your community when you are about to publish an update with a “breaking change” in the Rules Engine. Tell players to finish their ongoing online games before the cut-off date, and to wait for the update before playing online again.
One last word
It is important that you implement this system right from the start. And make sure that you test it properly in QA and during the Beta testing period. Too often developers do it in their 1.0.2 version after they realize the problem with their 1.0.1 update. Which is too late because of all the 1.0 and 1.0.1 apps that are still out there - which are going to last even more since from the players’ perspective, it is: “don’t upgrade, it breaks online gaming!” and make you want to go cry in a corner…