This document records the current modernization decisions for MMO Project and separates them into three groups: confirmed decisions that are active project constraints, proposed decisions that serve as working defaults pending prototype validation, and deferred decisions that are intentionally left open. Its purpose is to reduce the restart cost between sessions — if a decision changes, this document and the roadmap should be updated together.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/TaylorZaneKirk/MMO-Project/llms.txt
Use this file to discover all available pages before exploring further.
Proposed decisions become confirmed only after documented prototype validation or an explicit project decision. Do not treat a recommended choice as locked in until that threshold is met.
Confirmed decisions
The following decisions are supported strongly enough by preserved evidence and current project direction to treat as active constraints. 1. Rewrite both client and server The modernization effort is a full rewrite of both the game client and the backend. The legacy Director/Shockwave runtime is obsolete and the Shockwave Multiuser Server trust model is unsafe for a public service. The preserved system is best treated as behavioral evidence, not as a production foundation. Evidence:MODERNIZATION_ROADMAP.md, SECURITY_FINDINGS.md.
2. Preserve the legacy files as read-only evidence
The original client source, extracted client artifacts, server scripts, and legacy data remain preserved and unchanged as the primary evidence base. The rewrite depends on these files for parity, migration, and validation, and editing the originals would blur the line between source evidence and rewrite output. Evidence: MODERNIZATION_ROADMAP.md, fso-dir-lab/ preservation workflow.
3. Use a vertical-slice migration strategy
The rewrite delivers a playable end-to-end slice early rather than attempting broad feature reconstruction before anything is playable. The parity surface is too large for a safe big-bang rewrite, and the feature matrix already identifies a strong first playable path. A vertical slice reduces the risk of years of disconnected partial work. Evidence: MODERNIZATION_ROADMAP.md, FEATURE_PARITY_MATRIX.md.
4. The new backend must be authoritative
The rewrite uses a server-authoritative model for character state, inventory, currency, guild state, and all other gameplay-affecting persistence. The legacy system trusts client-supplied save blobs and other mutable gameplay inputs too heavily, and security review confirmed client-authored persistence and other unsafe trust patterns. Evidence: SECURITY_FINDINGS.md, FEATURE_PARITY_MATRIX.md.
5. Reuse legacy content where it remains valid
The rewrite preserves and reuses maps, art, audio, configuration, and other legacy content when legally and technically feasible. Content preservation is central to keeping the game’s recognizable identity, and rebuilding all content from scratch would dramatically increase scope. Evidence: MODERNIZATION_ROADMAP.md, cataloged content under fso-dir-lab/ and docs/modernization/.
Proposed (recommended) decisions
These are the current recommended implementation choices and serve as working defaults for planning and early prototype work. Each becomes confirmed only after the prototype phase validates it.| Decision | Status | Rationale |
|---|---|---|
| Godot desktop client | Proposed | Strong fit for a 2D cross-platform client; good balance of editor support, iteration speed, and rendering flexibility. Must be validated with map rendering and sprite/content import prototypes. |
| C#/.NET backend | Proposed | Good fit for a maintainable, service-oriented authoritative backend. Strong ecosystem for auth, background jobs, admin APIs, migrations, and tooling. Must be validated with prototype session handling and content importer ergonomics. |
| PostgreSQL persistence | Proposed | Strong transactional guarantees for economy and persistence integrity. Good fit for normalized replacements of legacy flat-file formats, and supports auditability, relational integrity, and migration workflows. |
| WebSocket session transport | Proposed | Sufficiently simple for an initial tile-based slice; easier to prototype and inspect than a custom transport. Must be validated with movement cadence, reconnect behavior, and latency tolerance under realistic load. |
| Browser-based admin tools | Proposed | Directly addresses legacy trust-boundary problems. Easier to secure, audit, and permission by role. Better fit for map, NPC, item, quest, moderation, and publishing workflows than embedded client tooling. |
Deferred decisions
The following choices are intentionally left open. More prototype evidence or project-level discussion is required before they can be responsibly resolved.- Final client rendering and asset pipeline details — concrete prototype evidence for map rendering, sprite handling, layering, UI scaling, and asset import ergonomics is still needed.
- Final movement and update model — the protocol catalog shows movement importance, but not enough authoritative sequencing detail to lock timing, tick rate, or reconciliation behavior.
- Final combat simulation details — combat, stat, and progression formulas are not yet documented at the level needed to freeze backend simulation shape.
- Final data model for all secondary systems — guilds, mail, housing, faction state, newspapers, paintings, and side systems are visible but their exact modern schema breakdowns are only partially cataloged.
- Whether all secondary systems ship in the first major release — the parity matrix distinguishes vertical-slice, post-slice core, and post-slice secondary work; final ship scope should follow implementation progress rather than early optimism.