Feature flags 2nd attempt

[NQNStudios]

Here's a 2nd attempt at the feature flags system.

• Scenarios contain a string map of feature flags. The flag names are the keys, and flag versions are the values, so a typical value might be "fixed" for bug fixes or for evolving features, "V1", "V2", etc.
• The game has a map of flags to lists of supported versions. The game can therefore signal that it supports a legacy behavior for a given feature flag. The last version in the list is considered to be this build version's default behavior.
• When launching a scenario, we check to make sure the game supports the scenario's required versions of its feature flags.
• When launching a replay, we make sure the game supports the feature flags that the version of the game that made the recording did.

[CelticMinstrel]

Okay… this still feels like something is missing, though that might be inevitable since currently no feature flags exist.

With this system, can the existing "legacy" flag be replaced by one or more feature flags? We don't have to actually replace it, but it seems like a good test of whether the feature flag system does what it needs to do.

[NQNStudios]

There's something I still need to fix here....

[NQNStudios]

Ok I had realized I made get_feature_version() less than useful.

I have clarified its purpose: The game will call get_feature_version() to find out which version of a feature should be active. So if a scenario requests an outdated feature, the game will be able to check and find that out easily. For flags that have nothing to do with scenarios, such as bugfixes, this function returns the behavior that the replay used.

[CelticMinstrel]

Did you miss my previous comment in this thread? You commented at the exact same time, so maybe it slipped through your notice…

[NQNStudios]

I saw it. Yeah, I'm planning to write up a little example -- just also working on other issues and PRs.