Game specialisation

[DecDuck]

Adds 3 types of game "specialisation":

• Game: to be played
• Executor: emulators
• Redistributable: to be install

Under the hood, games are all the same object with the same schema. We enforce specialisation-specific options currently during import, so we may get corrupted state if changes are made without the necessary checks.

I think there is significant enough overlap in the required APIs and interfaces that it's worth it to just tag games rather than make them separate models, despite the relative unsafety with no type-safety when it comes to valid database objects.

Current specialisation differences:

• Executor: launch configurations can have "executorSuggestions", which are file extensions to auto-guess valid commands for "Game"s
• Game: launch configurations can have executors

[DecDuck]

Would love your guys' thoughts on different models vs one model w/ type for this. @Huskydog9988 @Pacodastre @quexeky

[Huskydog9988]

I have a few questions.

1. What is the goal in specializing? I assume it's mostly a ux thing?
2. For an emulator specialization, it implies the emulator cannot be installed via Drop. So does that mean it's a wrapper around another specialization?
3. Why is the 'installer' state applied to the game as a whole? I feel like everything (except emulator) is more applicable to the version instead.

[DecDuck]

1. Yep
2. I'm not sure what you mean, all specialisations can be installed.
3. What do you mean by the installer state?

[Huskydog9988]

My understanding was that this specialization effected how a version is imported and installed by a client. For example with 'Redistributeable' it would only present options to setup the game, not run it.

[Pacodastre]

To answer your question about 1 schema vs multiple ones, I think having multiple schemas would be more flexible if new features get added to those schemas. Having everything on one could end up creating a big schema with a lot of properties. That's not necessarily a bad thing, but having one schema per specialisation is definitely going to be easier to manager, though if queries will get more complex with a lot of joins (and every time a new specialisation is added, it's one more table to join).

[DecDuck]

My understanding was that this specialization effected how a version is imported and installed by a client. For example with 'Redistributeable' it would only present options to setup the game, not run it.
Being forced into "setup-only mode" would be enforce server-side in both the UI and at the API. The client treats all of them the same

[DecDuck]

To answer your question about 1 schema vs multiple ones, I think having multiple schemas would be more flexible if new features get added to those schemas. Having everything on one could end up creating a big schema with a lot of properties. That's not necessarily a bad thing, but having one schema per specialisation is definitely going to be easier to manager, though if queries will get more complex with a lot of joins (and every time a new specialisation is added, it's one more table to join).

Maybe we can refactor when the maintenance load becomes too much. I think, for now, having one model is fine because there's only slight differences.

[Huskydog9988]

I think I'm mostly just struggling to understand the end goal is all. Once I get that I think I can tell you my opinion.

[DecDuck]

Basically you shouldn't be able to launch "Skyrim" with "Minecraft", or set "Call of Duty" as a redistributable for "Hollow Knight". It's designed to help the user mentally categorize the stuff in their library, and reinforce that category in the suggestions in UI/available options.

[Huskydog9988]

Ok, based on what your saying then, I think I was just confused by the naming. I don't have any issues with the current model then, other than the naming.