search

BlindMindStudios / StarRuler2-Source

4X Space Strategy game Star Ruler 2's open source distribution.
http://starruler2.com
Other
1.46k stars 244 forks source link

[Admin/Maintenance] Breaking Steam/GOG Compatibility #27

Open DaloLorn opened 6 years ago

DaloLorn commented 6 years ago

I've already mentioned it in Discord, but I feel like it might be more visible here.

It's reasonable to assume that it will take some time for us (all the people forking the repository) to change the client in a way that breaks multiplayer compatibility. It also seems unlikely that we'll need to do so in the near future, unless we want to turn it into something that isn't actually SR2 in the first place.

As such, we should be able to retain backwards compatibility with the commercial version of the game for a while, so long as we don't make compatibility-breaking changes to the game's data and script files. Any such changes should be relegated to the realm of mods, which also allows them to be installed through tools such as the Steam Workshop or the SR2 Mod Manager.

This brings me to the point I'd like to raise: We should not be putting data changes into this repository. There are other places we can put those: A new mod with its own repository, the Community Patch...

There are exceptions to this rule, of course - Lucas disabling the patcher is one of them - but in principle, we should continue to respect the mod/engine divide, especially in the official repo. (On that note, compatibility has already been broken by Jon's new shipsets. Someone needs to either pull those shipsets out or change MP_VERSION.)

EngineOfDarkness commented 6 years ago

As such, we should be able to retain backwards compatibility with the commercial version of the game for a while, so long as we don't make compatibility-breaking changes to the game's data and script files.

Good point - I was thinking about making a PR for a fix of mine which requires changing of a save/load function in the game, thus breaking MP compat (I think, but not sure to be honest).

On the other hand, if said community patch has enough fixes such that a majority of the community regards it as "mandatory" you get the same issue ultimatively - by most online games having at least the community patch in it and thus breaking compat to the commercial version.

It would also depend if the original Developers will want to keep the old commercial version as is or release some of the community work as patches - that probably depends if they can release patches

a) without incurring any costs money wise (not sure it costs money on steam / gog to release patches - I've watched the Development of another game and on consoles patching costs money due to certification and stuff)
b) if they can/want to invest their free time to do so

A quite specific point about not keeping it compatible is exploits. You may be able to fix an exploit and keep the game compatible so people without the fix can join a MP game with the fix.

The question is if you would actually want that.

A good Example is this exploit which I reproduced but not tracked down yet: https://steamcommunity.com/app/282590/discussions/0/1290691937710672216/

Currently in MP you have to thrust all people to not exploit this - which might work in a tight knit MP community where you kind of know / thrust the other players, but probably not in a larger one with more random public games (if we assume the MP community grows larger and stays that way due to the open-sourcing of the game).

DaloLorn commented 6 years ago

Good point - I was thinking about making a PR for a fix of mine which requires changing of a save/load function in the game, thus breaking MP compat (I think, but not sure to be honest).

If you're only changing the save/load functions (as opposed to, say, the read/write functions used for inter-engine and network communication), you'll only break savegame compatibility. Saving/loading occurs strictly on the server, so fixes for this can theoretically be added directly to the base game without too many risks.

The same can be said of the shader fix Reaper merged in, but that shader fix will still need to be duplicated in another format (most likely the Community Patch) in order for the commercial builds to get it.

On the other hand, if said community patch has enough fixes such that a majority of the community regards it as "mandatory" you get the same issue ultimatively - by most online games having at least the community patch in it and thus breaking compat to the commercial version.

The thing is, the Community Patch is a mod, and can be released/installed as any other mod would be. The changes being made to the OS client repository cannot be backported to the commercial versions of the game without either requiring extra effort from the user (manually installing a new copy of the game, possibly even building the game client from scratch, as opposed to simply pushing a few buttons to download and install a mod) or breaking OS compatibility in a completely different way by making a 'patch' mod for it.

It seems highly probable that the community will perceive something as a must-have; I neither can nor want to prevent that. It's just a question of how that something will be distributed.

Edit: Another thing that occurred to me, regarding patching: Steam and GOG have update mechanisms. The devs probably could release new patches to the commercial client if they felt like it. The OS build has no such mechanism right now, which further reinforces the need for updating to be as easy and effortless as possible.

EngineOfDarkness commented 6 years ago

Edit: Another thing that occurred to me, regarding patching: Steam and GOG have update mechanisms. The devs probably could release new patches to the commercial client if they felt like it. The OS build has no such mechanism right now, which further reinforces the need for updating to be as easy and effortless as possible.

Yeah good point - I was actually focussing on the commercial versions because of the backward compatability you mentioned - I just assumed the OS client would be updated by someone who distributes the binaries. I suppose people who compile the game themselves won't mind compiling it again when patched.

Off course that implies one would need to know the OS version was patched - so I get that's one of the core "issue" at hand probably.

In that case a community patch might actually be a better Idea like you proposed (for thinks like data / scripts - this probably cannot applied to Bugs in the Engine itself because they really should be fixed on an engine level).

One Issue I see with the mod approach is that mods might end up locking themselves to certain versions of the patch if they simply "copy" and paste their changes over or use the community patch as base and then modify the files.

What I want to get at is:

If possible, the patch would supply a "simple" Event System - say the community patch modifies script file "x" it should attach Event Dispatchers to all functions in that file so that mod developers can register Event Listeners to modify the functionality without touching / copying / overwriting the community code.

That makes it somewhat possible to "update" the community patch for end users - say if the file "x" is changed again (an additional fix is introduced) the mod authors don't need to push out an release to make it compatible with the new patch version in the best case (fix introduces no need to modify MP Version).

I know this won't fix all possible edge cases (like adding file "y" in a later version of the community patch, which mod "FooBar" overwrites already which leads to a mod conflict naturally, or if the community patches MP Version changes), but maybe it is worth to think about.

DaloLorn commented 6 years ago

One Issue I see with the mod approach is that mods might end up locking themselves to certain versions of the patch if they simply "copy" and paste their changes over or use the community patch as base and then modify the files.

This will happen either way. Whether you're overriding the implied "base" mod or something else, you will need to update your mod whenever the overridden files are changed. The thing is that, as far as we know, a lot of these files won't be changing once the CP is done with them. (They probably won't change a lot either way, really.)

The point of the CP is to take things that are objective improvements to the game - like fixing bugs, or opening up more options in game configuration - and put them into a "base+" package which can then be used as a foundation for mods trying to make subjective improvements such as balance changes. (As such, it's likely to be reasonably static and tolerant of outdated overrides.) This also appears to be the policy used to manage this repository; what I'm arguing here is that there's a better way to implement that policy.

If possible, the patch would supply a "simple" Event System - say the community patch modifies script file "x" it should attach Event Dispatchers to all functions in that file so that mod developers can register Event Listeners to modify the functionality without touching / copying / overwriting the community code.

This sounds nice in theory, but... well, for starters, we don't have anywhere near enough resources for that one.

There's also the fact that most mods don't simply attach to a script - they either ignore it outright, or change the script.