Properly support gameplay forks, including a fix for the fake deathbomb quirk

[nmlgc]

The gameplay community is very interested in fixing the "fake deathbomb" quirk introduced in version 1.005: Visually, it might seem as if Shuusou Gyoku had deathbombs, but bombing shortly after getting hit won't in fact prevent losing a life, as such a bomb will be counted as a regular one on the next life. Version 1.0 did not have this issue, as it simply blocked bombing during invincibility periods.

However, since the issue fulfills the definition of a quirk, fixing it would create a replay-incompatible fork of the game, together with a new competition tier. But since we have source code, it's actually viable to introduce such a new tier by handling it as transparently as possible: A player should always know whether they're playing the original variant or our fork, and replays should come with a built-in indicator of the gameplay variant they were recorded on.
Since we're already distinguishing, we might as well provide both behaviors in the form of a switchable option. This will allow players to continue competing in the 1.005-compatible "fake deathbomb" tier while still getting all the technical improvements of our fork. And since we're already designing a new replay format, it also makes sense to directly build it in a way that can support mods. Heck, we might even use this to add a full-on "1.0" mode, in order to both preserve the difference between 1.0 and 1.005 and allow players to compete in this easier variant of the game.

• Implement the deathbomb fix behind a quirk toggle
• Add the deathbomb quirk toggle to the Config menu (requires Introduce a version system for 秋霜CFG.DAT #34)
• Display the state of the quirk toggle in one of the in-game side bars (got enough space there)
• Output non-1.005 replays with a different filename to signal incompatibility with the original release
• Add a hash of all ECL files to the replay header
• Add a further "gameplay core version" tag. This is also some kind of hash that identifies the entire C++ gameplay code. C++-level mods would change this to identify themselves, which allows another way of distinguishing modded replays even if the ECL scripts stay identical. Calculating this hash from the C++ source file text is probably overkill as it would turn mere refactors into entirely new games as far as the replay system is concerned. Then again, can we really be sure, even if we had a test suite with lots of replays? 🤔 Hashing C++ source code might still be the right thing to do, and we can always curate a list of known "refactor" hashes and treat those as identical to the original game. Or we could merely show a warning for replays that were recorded on a different gameplay core version.
  • If we do, it makes sense to isolate gameplay code as much as possible. Goes hand in hand with Turn the core game update code into a headless library #37.
• Show ECL / gameplay core version in the replay menu… which we might want to enhance in general, see Implement better replay support #36.

[nmlgc]

If you just care about the fix and don't mind breaking replay compatibility, check out Tasos500's fork.