[Context: It's about game compressors that downgrade the version of Ren'py when they release their compressed version]
Ren'Py engine is backward-compatible with the save files (saves from an older version of Ren'Py can be opened by newer versions of Ren'Py), but it's not forward-compatible (saves from a newer version of Ren'Py highly likely can not be opened by older versions of Ren'Py).
The problem isn't just on the save compatibility side, but also on the side of the code itself.
By example, take the improved
renpy.input()
which, since the 7.3.3, accept a screen name as parameter ; you can now have personalized screens according to the actual input, it's useful. If the game compressor decide to downgrade to a version prior to 7.3.3, the error will be seen only when the line using this function will be triggered ; therefore the said game compressor will just broke a game that was perfectly working, and not even know it.
And there's tons of example like that. When it's pure statement changes, the error will be triggered when the compressor will try to launch the game, but when it's Python equivalent, screen actions, or things like that, it will appear only when the game will reach the now incorrect line. And if this line come from a previous update, the said game compressor will never be able to know it, even if he play the full update before realizing his version ; only new players will see that the game is broke.
Sometimes it can even be more subtle, when it's just a change on the behavior of a statement or a Python equivalent. The game will be broke, because it will not react as expected, but the error will stay unseen from the player. It's the same kind of subtle error than when the dev type to fast and write something like :
Code:
$ var =+ 1
[...]
if var > 15:
[...]
The game is broke, since
var
is forced to 1, and so will never be superior to 15. But no one will ever see that there's a problem, except by looking at the code, or tracking the variable in real time.
S
ide note as example: Long time ago, I pointed this kind of error to a dev. It was just a two characters inversion, but it removed around half of the content of the update...
All people who would play a compressed version inducing such subtle bug would be deprived of part of the update ; and also potentially part of the future content, if the behavior change also impact the value of some variables. And they would never know it. Even if, by chance, they discover it, by seeing others talk about scenes they haven't seen, they would never understand why it happen to them.
They play the game following the optimal path, and still can't have its full content. This just because a game compressor decided that his version the game should use a previous version of Ren'py, and this change silently broke the game.
So, perhaps that the word I used is a little too rude, it's totally possible. But yes it can totally ruin a game that, otherwise, would have been good ; and therefore also ruin its author reputation.
It would probably be a good idea to add this to the game compression rules in the compression request thread - that in the process of simple compression the game engine should not be upgraded or modified. Upgrade or replacement (i.e. porting) of the engine should be categorized as a game modification that is incompatible with the original game.
I totally second you on this ; including both upgrade (that can lead to save incompatibility, like you said, if the player decide to use the regular version for the next update), and downgrade (that can lead to errors as I said above).
This especially since there's absolutely no reason to touch the
lib and
renpy folders. Why rebuild the distribution, when you just need to compress a folder ?
bas , sorry to bother you, but since you're both the author of the compression tool and a staff member, I port this to your attention.