jmarya/gamenix
jmarya/gamenix
Watch
1
0
Fork
You've already forked gamenix
 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

feat: declaratively discover and manage game save data #1

New issue
Open
opened 2026-08-22 05:38:10 +00:00 by jmarya · 0 comments
jmarya commented 2026-08-22 05:38:10 +00:00
Owner
Copy link

Goal

Expose the save-related locations for each declared game so Gamenix can support inspection, backups, snapshots, migration, and eventually cross-machine synchronization.

Proposed model

  • Keep catalog game identity separate from emulator-specific IDs needed to resolve save directories.
  • Let runners define save-path conventions and classify locations as save, save-state, config, shader-cache, or firmware.
  • Resolve those paths per user in the Home Manager module, then expose them through config.gamenix.resolvedGames and the user runtime manifest.
  • Keep a machine-level inventory suitable for system tooling where appropriate.
  • Support explicit user overrides for non-standard runner layouts.

Sync and backup direction

Start with exported path metadata and backup/snapshot consumers. Add backend integrations (for example Syncthing, restic, or btrfs snapshots) separately. Normal save files should be syncable by default; save states must be opt-in because they are emulator/version-specific and can be unsafe to copy while the emulator is writing them.

Backend credentials, peer/device IDs, and remote endpoints must not be written to the generated public manifest.

Open design questions

  • Which platform-specific identifiers belong in catalog metadata versus user configuration?
  • How should runner templates model title/profile/slot-specific save layouts?
  • How should active-emulator locking and sync conflict handling work?
  • What is the exact split between /etc/gamenix.toml and per-user manifests?
## Goal Expose the save-related locations for each declared game so Gamenix can support inspection, backups, snapshots, migration, and eventually cross-machine synchronization. ## Proposed model - Keep catalog game identity separate from emulator-specific IDs needed to resolve save directories. - Let runners define save-path conventions and classify locations as `save`, `save-state`, `config`, `shader-cache`, or `firmware`. - Resolve those paths per user in the Home Manager module, then expose them through `config.gamenix.resolvedGames` and the user runtime manifest. - Keep a machine-level inventory suitable for system tooling where appropriate. - Support explicit user overrides for non-standard runner layouts. ## Sync and backup direction Start with exported path metadata and backup/snapshot consumers. Add backend integrations (for example Syncthing, restic, or btrfs snapshots) separately. Normal save files should be syncable by default; save states must be opt-in because they are emulator/version-specific and can be unsafe to copy while the emulator is writing them. Backend credentials, peer/device IDs, and remote endpoints must not be written to the generated public manifest. ## Open design questions - Which platform-specific identifiers belong in catalog metadata versus user configuration? - How should runner templates model title/profile/slot-specific save layouts? - How should active-emulator locking and sync conflict handling work? - What is the exact split between `/etc/gamenix.toml` and per-user manifests?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jmarya/gamenix#1
No description provided.