Day 01: The Oath of Gammoridin: One Library, No Noise

Series: "Gammoridin Devlog" tags: - tauri - rust - react - typescript - sqlite - local-first - game-launcher - backlog - igdb

A launcher is a door. We’re forging a Sanctum that remembers what you own—and makes starting to play feel effortless.

GAMMORIDIN.COM

What we set out to build

Gammoridin is a Windows 10/11 desktop app that acts as a local-first, all-in-one PC game launcher + codex.

If you’ve ever thought:

• “I know I own something good… somewhere.”
• “Why do I have to open three launchers to find the game I want?”
• “My backlog is a graveyard because it’s scattered.”
• “I just want one clean library that doesn’t spy on me.”

…that’s the exact pain Gammoridin is designed to solve.

The problems we’re solving (in plain user terms)

• Fragmented libraries
  Steam, Epic, standalone installs, and the rest all live in different places—so your “library” becomes a scavenger hunt.

• Backlog chaos
  Without a single place to track intention, your backlog isn’t a system—it’s a vibe. Gammoridin makes backlog status a first-class feature with a simple, canonical lifecycle:
  none, wishlist, backlog, in_progress, completed, abandoned.

• Momentum loss (the hidden tax)
  The friction isn’t just annoying—it steals your playtime. When starting a session feels like work, you stop playing or you waste your energy getting to the start line.

• Local data should stay local
  A lot of “helpful” game apps drift into telemetry and cloud dependencies. Gammoridin is intentionally offline-capable and local-first: library, settings, metadata cache, and play history live on your machine.

What Gammoridin is (the “what”)

At the center is the Codex: a local SQLite database that stores:

• Your detected games (name, paths, launcher type, installed state)
• Your backlog status and favorites
• Your play sessions (start/end/duration)
• Optional IGDB metadata cached locally (summary, storyline, genres, platforms, website links, hero/cover paths)

And wrapped around the Codex is the Sanctum UI:

• A Library Grid you can search/filter
• A Chronicle panel (game details) that feels like a “home” for each title
• A Backlog Board (Kanban) for moving games between statuses with drag & drop

What shipped today

Day 01 is about planting the banner: what Gammoridin is, and what it refuses to be.

This Chronicle series will be one post per day, documenting the build as it actually exists in the canon docs (Changelog, Task List, Specs, Architecture Notes) and what we choose next.

In terms of real, current capabilities (already present in the project’s canon as of the latest docs):

• Unified library foundation

  • Game detection via local sources (Steam manifests/library folders, Epic install locations, and standalone folder scanning)
  • Results normalized into the local Codex

• One-click launching

  • Steam launches via steam://rungameid/<id>
  • Non-Steam launches via direct .exe execution (with launch args support)

• Local playtime tracking

  • Sessions recorded with started_at, ended_at, and duration_seconds
  • Totals and “last played” used throughout the UI

• Backlog organization

  • Canonical six-status lifecycle
  • Status selectors on cards and in the Chronicle
  • Filtering by status and quick views like Favorites / Recently Played

• IGDB enrichment

  • Metadata fetching + caching (summary, storyline, genres, platforms, websites)
  • Cover/hero art cached to local app data
  • “Refresh from IGDB” support
  • Website links labeled intelligently (Steam, Discord, Wiki, etc. instead of “Other” spam)

• Backlog Board (Kanban)

  • Drag & drop between canonical columns
  • Stable ordering within a column via persisted sort_index

Behind the curtain

The choice

We chose a stack that matches the oath: lightweight, secure, and local-first.

• Tauri v2 for a fast native shell without dragging in a heavyweight runtime
• Rust for scanner/launcher/tracker logic (filesystem, registry, process lifecycle)
• React + Vite + TypeScript for a responsive UI and clean state management
• SQLite as the Codex (structured, offline, durable, perfect for this job)

Just as important as the stack is the rulebook:

• No private or undocumented launcher APIs
• No scraping
• No cloud dependency required to function
• No credential leakage (IGDB keys stay in the backend and never show up in the UI)

The cut

There are shiny features we’re not prioritizing on purpose—because the foundation has to be trustworthy first:

• Deals / affiliate integrations
  We want it, but it comes after the library, backlog workflow, and reliability feel rock-solid.

• Cloud sync / accounts
  Useful later, but it’s easy to violate the “local-first” trust contract if added too early.

• AI recommendations (“What should I play next?”)
  Also later—after we’re confident the Codex is clean, statuses are consistent, and user intent is represented well.

Rough edges / dragons

These are known areas that need sharpening:

• Scanner cleanup

  • Reduce false positives and junk entries
  • Harden install heuristics (still local-only, still TOS-safe)

• Chronicle polish

  • Better loading/error states
  • Fallback imagery that looks intentional, not broken

• IGDB validation sweep

  • Test across a representative library
  • Confirm metadata + artwork caching stays stable and safe

• Settings page

  • Theme toggle
  • Scan roots management
  • Data path transparency (where the Codex lives, where covers are stored)

Next on the path

Tomorrow (Day 02), we’ll define the MVP boundary in a way users can feel:

• What the MVP includes (and why)
• What’s intentionally postponed (and what must be true before we add it)
• The “trust contract” of the Sanctum: local-first, clean UX, and no creepy behavior

— Filed into the Chronicle. The Sanctum stands; the Codex begins to remember.