Refactoring of GameSource, Game, FS, DB

[tkashkin]

This is a discussion of refactoring of the main interfaces.

[tkashkin]

FS - new directory structure (#387)

I'm currently thinking about something like this:

Global:

${CACHE} = ${XDG_CACHE_HOME}/${PROJECT}/

• sources/${source.id}/, providers/${provider.id}/
  • graphics/${game.id}/ - graphics cache
    • icons/, images/, achievements/
  • metadata.db - metadata cache database

${DATA} = ${XDG_DATA_HOME}/${PROJECT}/

• sources/${source.id}/
  • games.db - games database (probably just install paths and metadata customizations like custom names and tags, maybe also some basic metadata to show if there's no cached data)
• compat/shared/${tool.type}/${tool.id}/ - shared compat prefixes

${RUNTIME} = ${XDG_RUNTIME_DIR}/${PROJECT}/

• overlays/${overlay.id}/ - mounted overlays

---

Game: ${DATA}/games/${source.id}/${game.id}/

• compat/${tool.type}/${tool.id}/ - game-specific compat prefixes
• graphics/
  • icon.png, grid.png, vgrid.png
• overlays/
  • all overlays except base (base is the game directory itself)
• game.json - game settings, overlays, compat options, version, etc.

[Lucki]

The place for mounted overlays seems to be questionable:

Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.

---

I'm personally not a fan of using $XDG_DATA_HOME for prefixes or larger game data but I don't have a better solution either and Steam is already doing that too for the default library.

[tkashkin]

@Lucki

The place for mounted overlays seems to be questionable

It should be fine if only mountpoint and workdir are in $XDG_RUNTIME_DIR. Actual game files and overlays would not be there.

I have also experimented with mounting overlays on top of the game installation directory and it works, this even allows to implement overlays for Steam games.

---

I'm personally not a fan of using $XDG_DATA_HOME for prefixes or larger game data

Another idea I had is to store game data near the game installation directory:

~/Games/GOG/
    .gamehub/
    Game1/
    Game2/
    ...

This may be better, but there are some cases where this wouldn't work (imported game outside of all libraries, a binary somewhere in /usr/bin, emulated ROM, etc.).

I think it would be better to not overcomplicate things and use one path for all games.
Maybe it should be configurable, but I think it should just be $XDG_DATA_HOME. Users can override or symlink it if they want.

[tkashkin]

GameSource

This is what I currently think about a minimal interface to support game sources with and without a client.
This will most likely need to be expanded.

public abstract class GameSource: BaseObject
{
	public string id { get; construct; }
	public string name { get; construct; }
	public string icon { get; construct; }

	public ArrayList<Account>? accounts { get; protected set; }

	public ArrayList<File>? game_dirs { get; protected set; }
	public File? default_game_dir { get; protected set; }

	public abstract Gpseq.Future<Seq<Game>> get_games();

	public abstract class Account: BaseObject
	{
		public string id { get; protected construct set; }
		public string? name { get; protected construct set; }
		public string? url { get; protected construct set; }
		public string? image { get; protected construct set; }
	}

	// traits

	public interface NeedsAuthentication: GameSource
	{
		public abstract bool has_saved_credentials { get; }
		public abstract async bool authenticate();
		public abstract async bool authenticate_with_saved_credentials();
	}

	public interface HasClientAccounts: GameSource
	{
		public abstract async bool detect_client_accounts();
	}
}

---

Also GameSource may be a weird name for this concept, maybe it should be renamed to something else, at least in UI, but maybe in code as well. Let me know if you have any suggestions about renaming things and making them less weird.