Stack Concepts

call it a foundation roadmap, not a scaling plan yet. For the first build, keep it as one PHP application and one SQLite database in Docker Compose.

An Eden Realm should initially be a logical hosted world inside the app, not a separate deployed server/container per Server Master. Every realm-scoped record simply belongs to a realm_id. That keeps development simple while preserving the correct boundary for future scaling.

Recommended implementation order:

1. Foundation / Frontend shell

   • Responsive HTML/CSS/JavaScript
   • JSON API conventions and DOM-rendered screens
   • Docker Compose, SQLite persistence, migrations, changelog, basic audit logging
   • No need to optimize for scale yet

2. Authentication and authorization

   • Account registration/login/logout
   • Secure sessions, password hashing, CSRF protection
   • Roles: player, Server Master, platform administrator
   • Permissions must be scoped: a Server Master manages only their own realms

3. Player Chronicle

   • Persistent player profile - if client goes offline, modal stating reconnecting.
   • Realm directory: active, archived, invited, and past realms
   • Character and campaign history
   • Personal journal and archive links
   • This is the default post-login lobby

4. Hosted Realms

   • Server Master creates a realm, sets its name/status/rules
   • Invites players and assigns roles
   • Active / archived state
   • Realm membership and strict data isolation
   • Archive mode becomes read-only, remains discoverable through Chronicle

5. First game vertical slice

   • One map, one starter region, four player keeps
   • Settler work timers, rations/resources, hero recruitment
   • One mission type and a logged outcome
   • This proves the actual Eden Realms loop before we build deep systems

The most important data boundary is:

Chronicle = account-wide, cross-realm history
Realm = Server Master-owned world and its current game state

So a player can belong to many realms, but their profile and archived history follow them. Realm content, permissions, posts, characters, map state, and resources remain isolated within that realm.

Later, if growth requires it, we can move from SQLite to PostgreSQL and run multiple application workers or realm-processing services. But we should not build for that now—the correct realm_id boundaries, API shape, migrations, backups, and audit records will make that future transition manageable.