[Tech] No longer use GameManagers as singletons #4894
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Invoking a method on one of the game managers was always a little verbose: Every method took not just its own parameters, but also parameters describing the game's state (effectively that's only an AppName right now, but that may change for other store providers). Instead, there's now one
Game
class instance for every distinct game in the user's libraryIn practice, code changes in the following way:
Before:
After:
As I mentioned in #4889, I plan on offloading a lot of
GameInfo
properties into individual methods (so there's not as much a burden on game managers to provide everything ingetGameInfo
all at once). Increasing the amount of method calls quickly leads to our before approach (the current code) becoming unreadable due to there being so much duplicate work.Requires #4889
Use the following Checklist if you have changed something on the Backend or Frontend: