Database Migration for Unity Game

Job: Replace Firebase Authentication & Data Storage with Mirror + Persistent Storage

We are looking for an experienced Unity + Mirror developer to completely replace our current Firebase-based user authentication and data storage with a custom solution that works inside our Mirror networking setup. Using C#. 

Our game is currently using:
Firebase Authentication for login/registration.
Firestore for storing user profile data, card collections, and deck lists.
Firebase methods for saving, loading, and assigning cards/decks.
We want to remove Firebase entirely and have all of this handled by our Mirror server.


1. Authentication
Replace Firebase login & registration with Mirror-based authentication messages.
Registration requires email and password.
Email must be verified via a one-time code:
Server generates a random code, stores a hash + timestamp, and sends the code to the email address.
The client presents a “verification code” input.
Client sends code to server; server validates and finalizes registration.
Resend codes allowed but rate-limited; codes expire after a set time.
Passwords must be hashed (bcrypt, scrypt, or argon2 — no plain SHA-only hashing).
Handle login failures, duplicate accounts, and security checks.
All authentication messages must be Mirror messages only (no Cmd/Rpc).



2. Persistent User Storage
Save all user data to a persistent storage system on the server (local JSON, SQLite, or other DB — to be discussed).
Implement load/save routines for:
User profile (email, username, level, experience).
Card collections (List).
Deck lists (List).
Storage must be easy to expand/version over time.



3. Card & Deck Handling
Replace Firebase card assignment and saving with server-side logic.
Ensure cards and decks load immediately after login.
Allow decks to be created, renamed, updated, and deleted — all changes saved persistently.



4. Mirror Integration
All client–server communication must be via Mirror messages.
Authentication must complete before the player joins the game world.
Server remains the source of truth for all data.



5. Logging & Debugging
All methods must log entry, exit, and key state changes using our LogHelper.TraceMirrorAuth flag.
Catch and log all exceptions without breaking gameplay.



Deliverables
Full replacement of Firebase authentication & Firestore persistence with Mirror + server-side storage.
Working registration, login, card loading, and deck loading.
Functional deck/card save, update, and delete.
Password hashing and email verification.
Clean, maintainable code with comments where needed.
Variable names should be human readable and descriptive.
Short written documentation summarizing:
Storage format.
Message types.
Authentication flow.
Deck/card management flow.



Email Verification Details
For development, you may use Gmail SMTP with an app password.
Server sends verification codes only — never from the client.
Code is random, cryptographically secure, and stored only as a hash.
Expire codes after a short time (e.g., 10–15 minutes).
Enforce limits on resend attempts and total verification attempts.
Email sending must be implemented in a way that can later be swapped to a transactional provider (Postmark, Mailgun, SendGrid, SES) without client changes.



Nice to Have
Token/session management for persistent logins.
SQLite or relational DB integration for larger-scale storage.
Experience with multiplayer card games or similar inventory/deck systems.
Experience with transactional email services.



Additionally: I am also looking to hire a part-time coder on an hourly basis for various ongoing tasks on this project beyond this job. If you’re interested in a longer-term, flexible arrangement in addition to completing the above work, please mention this in your application.

 ... Show more