Active development

Game Save
Manager.

A .NET 8 desktop application for discovering Steam games and profiles, resolving known save locations, and moving save data through workflows designed to be previewable, reversible and auditable.

View repository Explore the dataset

My role: Independent developer
Current phase: Provider expansion
Platform today: Windows
Stack: .NET 8 · Avalonia · SQLite

Application gallery

The safety workflow in practice

Eight views from the current Avalonia application, from discovery and review through transfer, backup, sync and audit history.

Game Save Manager dashboard showing Steam discovery and save-mapping statistics — Dashboard
The Avalonia dashboard summarises the detected environment, installed games, Steam profiles and mapping review state without exposing personal filesystem information.

Game Save Manager installed-games view with detected titles and mapping states — Installed games
Each detected title shows its mapping state, discovered save files and readiness before a workflow begins.

Steam profiles

Source and target profiles are selected explicitly before the application builds a transfer plan.

Game Save Manager transfer-preview screen listing proposed save-file mappings — Transfer preview
A dry-run plan exposes the files, destinations, blocked items and copy-safety controls before confirmation.

Manual backup

Profile, game, source and destination choices remain visible throughout the preview-first backup workflow.

Game Save Manager backup-and-restore screen with backup run details — Backup and restore
Manifest-backed backup runs expose restore targets, integrity details and explicit overwrite gates.

Game Save Manager SFTP and SSH synchronisation settings and plan — SFTP/SSH sync
Capability-driven connection settings lead into a selectable, previewable backup-run synchronisation plan.

Game Save Manager operation-history view with recorded workflow results — Operation history
A durable audit trail records the outcome of transfer, backup, restore and synchronisation runs.

01 / 08

The problem

Save files are valuable and inconsistent

PC games store saves across Steam userdata, documents, AppData, installation directories and custom locations. Players often only discover that complexity when moving between profiles or recovering from data loss.

Game Save Manager turns those inconsistent locations into a reviewed mapping system and a set of guarded workflows. The goal is not simply to automate file copying, but to make every action understandable before it runs and recoverable if something goes wrong.

Implemented application

A complete local safety workflow

The first two roadmap phases are complete. Phase 03 now includes working local-folder and SFTP/SSH providers, with Google Drive still ahead.

Steam discovery

Finds the Steam installation, additional libraries, installed games and local Steam profiles by reading registry and VDF data.

Safe profile transfer

Previews files before copying between Steam profiles, validates path containment, skips existing files by default and requires explicit confirmation.

Backup & restore

Creates manual and automatic backups with SHA-256 manifests, supports dry-run restore, presets, retention and self-contained ZIP export/import.

Provider-backed sync

Synchronises backup runs through local-folder and SFTP/SSH providers, with connection checks, selectable plans, live progress and conflicts that are reported rather than silently resolved.

Living save-path dataset

Turning public data into trusted mappings

The dataset is built continuously by fetching Steam AppIDs and harvesting save-location candidates primarily from PCGamingWiki, while manually researched paths can be added alongside them.

21k / 170k

Steam AppIDs processed so far

5,140

Games with collected mappings

2,698

Mappings reviewed and approved

Current development snapshot. Approximately 12% of the target Steam AppID catalog has been processed; 5,140 of those entries currently have mapping data, and 2,698 mappings are approved for trusted application use.

≈ 2,000 / day

Daily catalog mining

Automated harvesting processes roughly two thousand new catalog entries each day and records candidate paths with their provenance.

Manual + mined

Two ways to grow

Mappings can also be added or corrected manually, so new titles are not limited to what an automated source can extract.

Continued support

Review can broaden later

The project will keep supporting new releases. A future direction is letting additional trusted reviewers help approve the growing candidate queue.

From public clue to trusted path

Why the application needs a reviewed catalog

Steam identifies games, but it does not provide one dependable catalogue of where every title stores its save files. Public sources can suggest locations, yet those suggestions may be outdated, incomplete or written for a different operating system.

The pipeline therefore treats collected paths as candidates, not facts. Rule-based checks expand reusable path templates and flag repeatable problems, while human review handles ambiguity and decides which mappings are safe enough to approve. The application uses only those approved mappings when it prepares a backup or transfer preview, reducing the risk of selecting the wrong files or folders.

Collect game IDs

Steam AppIDs create the catalog queue and tell the pipeline which games still need save-location research.

Find possible paths

PCGamingWiki and manual research provide candidate save locations together with their source and context.

Review each candidate

Templates are expanded, ambiguous or unsafe paths are flagged, and every candidate receives a visible review state.

Use approved mappings

Approved paths let the app build clearer previews and target the intended save data during backup and transfer.

Why the review state matters

Scraped locations can be outdated, incomplete, platform-specific or simply wrong. Candidate data remains visible as Pending or NeedsFix, but the application does not automatically trust it. This keeps dataset growth separate from save-file safety.

Design principles

Safety is an architectural requirement

Save files can represent hundreds or thousands of hours. Guardrails are part of the product, not warnings added at the end.

Copy, never move

Source saves are not deleted or modified during transfer or restore.

Preview first

Transfers, restores, sync and cleanup expose a dry run before execution.

Overwrite is opt-in

Existing files are skipped unless the user explicitly enables replacement.

Backup before overwrite

Safe Mode refuses an overwrite when its automatic backup cannot be completed.

Verify integrity

SHA-256 manifests identify missing or modified backup files before restore.

Keep an audit trail

SQLite history, manifests and per-file results record what every workflow did.

Architecture

A thin UI over explicit services

The shared core stays independent of Avalonia, SQLite, registry access, VDF parsing and filesystem details. Views bind to view models, while preview generation, containment checks, hashing, persistence and provider behavior live behind testable contracts.

GameSaves.Core

Platform-neutral models, contracts, sync plans and transfer rules. It defines what a safe operation means without knowing about Avalonia, SQLite or a particular filesystem.

Infrastructure

Concrete adapters for Steam discovery, registry and VDF parsing, SQLite, path expansion, backup, restore, history, local-folder sync and SFTP/SSH.

Avalonia App

A thin MVVM interface that coordinates explicit services, presents previews and confirmations, and keeps provider-specific controls driven by declared capabilities.

CLI & Reviewer

Separate developer tools for catalog fetching, PCGamingWiki harvesting, verification and deliberate human approval of candidate mappings before the desktop app trusts them.

Phase 03 right now

Past SFTP/SSH, before Google Drive

The provider abstraction is already exercised by two real implementations: local or mounted folders and SFTP over SSH. Both use the same preview-and-execute contract, copy-only conflict rules, named remote profiles, connection checks and auditable results. The current work is hardening that shared design for the next provider rather than presenting Google Drive as complete.

Implemented

Local-folder and SFTP/SSH providers, including host-key trust and session-only credentials.

Shared foundation

Capability catalog, provider factory, remote-profile persistence, selectable plans and conflict reporting.

Next boundary

Google Drive needs interactive OAuth, durable token storage, quota awareness and resumable transfers.

Roadmap

Delivered in deliberate phases

Remote providers are intentionally paused while the provider design is reviewed. Planned functionality is not presented as implemented.

01Local GUI manager & transferComplete
02Backup and restore systemComplete
03Sync-provider abstractionIn progress
04Cross-platform supportPlanned
05Advanced featuresFuture

Engineering lessons

What this project is teaching me

01Separating domain rules from infrastructure and UI makes safety-critical workflows easier to reason about and test.
02External data is not automatically trustworthy: scraped save paths need provenance, review states and verification before use.
03Destructive-adjacent operations need visible plans, explicit confirmation, containment checks and auditable outcomes.
04Backup design is more than copying files; manifests, hashes, history, retention and reversible restore all matter.
05Provider abstractions help introduce sync incrementally without coupling the core application to one cloud service.
06A growing dataset needs repeatable harvesting, deduplication and review workflows—not a one-time import script.