Skip to main content

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.

This roadmap is the durable handoff document for the MMO Project modernization effort. Its purpose is to make the project resumable at any point without relying on conversation history or informal notes. Before beginning a modernization session, read the current checkpoint and immediate next work package. Before stopping, update the task checkboxes, checkpoint summary, and change log. This is not a feature wishlist — every item here is grounded in what the preserved legacy system actually does.

​
Current status

Phase 2 — Architecture and Migration Prototype — is active. Phase 1 (Legacy System Specification) is complete for prototype-planning purposes. The specification documents covering the startup and session flow, gameplay rules and formulas, security findings, decisions, and feature parity matrix all exist under docs/modernization/.
The current verified prototype baseline is:login → character load → enter world → world snapshot → authoritative movement → inventory/equipment → reconnect → logoutThis sequence has been confirmed locally against a seeded PostgreSQL database with a Godot desktop client, authoritative click-to-move, reconnect restoration within the 10-second grace window, DB-backed inventory and equipment snapshots, authoritative equip/unequip and food consumption, and local and remote equipped-item visuals on player composites.

​
Phase overview

Objective: Produce trustworthy, repeatable evidence from the legacy client and server.Key work items:
  • Create a machine-readable manifest of every original and extracted file, including size and checksum.
  • Compare ProjectorRays and Director Cast Ripper Lingo outputs and explain meaningful differences.
  • Identify the active client entry scripts, frame markers, linked casts, and Xtras.
  • Separate clean extraction output from earlier mixed or duplicate export directories.
  • Record any extraction warnings and unsupported cast-member types.
  • Capture representative legacy behavior in an isolated runtime where feasible.
Exit criteria:
  • Every legacy input and extraction result is reproducible and checksummed.
  • Active source and generated or stale Director chunks can be distinguished.
  • Unknown or failed extraction areas are explicitly documented.
Estimated effort: 2–3 person-months total, including work already completed.
Objective: Convert the extracted implementation into a behavioral specification for the rewrite.Key deliverables: LEGACY_SYSTEM_INVENTORY.md, FEATURE_PARITY_MATRIX.md, PROTOCOL_CATALOG.md, DATA_FORMAT_CATALOG.md, SECURITY_FINDINGS.md, DECISIONS.md, GAMEPLAY_RULES_AND_FORMULAS.md.Key work items:
  • Catalog client startup, login, character creation, and session flows.
  • Map client message subjects to server handlers and classify unmatched subjects.
  • Document map, character, inventory, NPC, monster, quest, bank, guild, house, and settings formats.
  • Document combat, stat, skill, spell, loot, economy, and progression formulas.
  • Inventory core and secondary gameplay systems.
  • Mark each feature as required, optional, obsolete, unsafe, or not yet understood.
  • Identify behavior implemented in frames, casts, Xtras, or assets rather than Lingo.
Exit criteria:
  • A developer can explain the complete login-to-gameplay lifecycle without reopening the Director movie.
  • Every known feature has a parity classification and evidence reference.
  • Data formats needed by the vertical slice have documented schemas.
Estimated effort: 3–5 person-months, now substantially completed in the preserved specification set.
Objective: Prove the proposed client, server, network, and content-import approach.Key work items:
  • Write and maintain PHASE_2_PROTOTYPE_SCOPE.md as the prototype boundary document.
  • Create and maintain an interface-first scaffold under prototype/ before runtime implementation starts.
  • Prototype map rendering, sprite animation, input, and UI scaling.
  • Create a representative 20×20 world of 17×9 chunks centered on x1000y992.
  • Prototype authenticated client/server connectivity and server-authoritative movement.
  • Define versioned transport messages for login, account-character load, world entry, world snapshots, movement, reconnect, logout, NPC updates, and remote-player updates.
  • Define initial PostgreSQL schemas for account/session/character/map/presence/status/inventory/item-definition state.
  • Prototype one legacy data importer with validation reporting.
  • Benchmark rendering and network behavior on representative hardware.
Exit criteria:
  • One legacy or representative map renders accurately enough to validate the rendering stack.
  • Two clients can authenticate, enter the map, and observe authoritative movement.
  • The prototype demonstrates that the selected stack is viable or records why it must change.
Estimated effort: 2–3 person-months.
Objective: Deliver the first complete modern gameplay loop.Required flow: account login → load account character → enter map → move → chat → fight one monster → receive loot → save → disconnect → reconnectKey work items:
  • Implement secure accounts, password hashing, sessions, and character ownership.
  • Implement map instances, spawning, movement, collision, and transitions.
  • Implement chat with validation and rate limits.
  • Implement a minimal authoritative combat and stat model.
  • Implement one monster, one NPC, inventory, equipment, loot, death, and persistence.
  • Import enough original content to validate visual and behavioral fidelity.
  • Add automated unit, integration, migration, and reconnect tests.
  • Add structured logging, health checks, and a deployable test environment.
Exit criteria:
  • The required flow works entirely on the modern stack.
  • Disconnects and retries cannot duplicate items or currency.
  • The slice is deployable from a clean checkout using documented commands.
Estimated effort: 13–20 person-months across foundations and vertical-slice work.
Objective: Restore the main MMORPG systems needed for sustained play.Key work areas:
  • Character stats, classes, experience, leveling, and death.
  • Items, equipment, durability, inventory, storage, and drops.
  • Combat, spells, effects, skills, crafting, gathering, and hunger.
  • Monsters, NPC behavior, shops, quests, portals, and treasures.
  • Banking, mail, message boards, and world-state timers.
  • Map transitions, environmental behavior, boats, and airships.
Exit criteria:
  • Required core features in the parity matrix are implemented and tested.
  • Economy and progression operations are authoritative and transactional.
  • Imported content passes referential-integrity and gameplay smoke tests.
Estimated effort: 10–16 person-months.
Objective: Restore the systems that give the original game its broader identity.Key work areas:
  • Guilds, factions, friends, direct messages, and secure trading.
  • Houses, guild halls, player shops, keys, and construction.
  • Assassin events, blackjack, slots, checkers, and high scores.
  • Newspapers, paintings, photos, story systems, and remaining specialty content.
  • Moderation roles, bans, audit history, and player support workflows.
Exit criteria:
  • Every required secondary feature is implemented or explicitly deferred.
  • Player-to-player and economy operations are abuse-tested and auditable.
Estimated effort: 6–10 person-months.
Objective: Replace privileged in-client editing and unsafe file-transfer commands.Key work areas:
  • Authenticated map editor.
  • NPC, monster, item, quest, drop, and configuration editors.
  • Content validation, preview, publishing, versioning, and rollback.
  • Moderation dashboard and immutable administrative audit trail.
  • Backup, restore, and data-repair tooling.
Exit criteria:
  • Routine world administration requires no direct filesystem or database editing.
  • Content changes can be reviewed, validated, published, and rolled back safely.
Estimated effort: 4–7 person-months.
Objective: Prepare the modern game for real players and ongoing operation.Key work areas:
  • Rehearse content and account migration using repeatable snapshots.
  • Run load, soak, reconnect, abuse, and transaction-concurrency testing.
  • Add TLS, rate limiting, monitoring, alerting, backups, and restore drills.
  • Create staging and production deployment pipelines.
  • Run closed alpha, rollback rehearsal, open beta, and release readiness review.
Exit criteria:
  • Migration is repeatable and reconciles source and destination counts.
  • Restore and rollback procedures have been tested rather than merely documented.
  • Release-blocking security and data-integrity findings are resolved.
Estimated effort: 5–8 person-months.

​
Estimated scale

The current rough-order estimate is 42–62 person-months for faithful feature parity. This assumes that existing content can be reused at high rates, substantial new art is not required, the currently recommended stack choices remain viable through Phase 2, and early releases prioritize the required parity set before every secondary or admin surface is fully polished.
Team sizeApproximate calendar range
4 experienced contributors12–20 months
2 experienced contributors2–3.5 years
1 full-time contributor3.5–5+ years
4-person playable vertical slice only~5–8 months
The remaining unknowns that push toward the upper end of the range include importer complexity across flat files and packed fields, administration and editor tooling replacement, abuse-resistant transactional handling for inventory, banking, trade, and shops, and any decision to ship most secondary systems in the first major release rather than staging them.

​
Known risks

RiskConsequenceMitigation
Repeated or internal Director container dataStale scripts may be mistaken for active behaviorCompare Director-aware exports and identify active cast and script references
Behavior outside LingoImportant rules may be missedInspect frame markers, score data, cast metadata, Xtras, and runtime behavior
Client-authoritative legacy logicDirect ports would preserve exploitsRe-specify commands as server-validated player intent
Flat-file and DBF inconsistenciesMigration may silently corrupt or omit dataUse schema validation, reconciliation reports, and immutable source snapshots
Missing automated legacy testsBehavior comparisons may be subjectiveCapture golden fixtures and representative runtime recordings
Scope expansion during parity workThe rewrite may never reach a playable stateEnforce the vertical-slice gate and parity classifications
Asset or distribution rights uncertaintyPublic release could be blockedConfirm ownership and redistribution rights before release planning

​
Modernization principles

  1. Treat the legacy system as evidence, not as an architecture template.
  2. Preserve behavior intentionally; do not preserve vulnerabilities accidentally.
  3. Keep gameplay rules independent from rendering, transport, and persistence.
  4. Validate every migrated data format with repeatable import tests.
  5. Make all economy-changing operations transactional and auditable.
  6. Prefer one playable end-to-end path over many disconnected partial systems.
  7. Keep generated extraction output separate from handwritten modernization code.
  8. Do not place secrets, passwords, private keys, or production credentials in the repository.

Build docs developers (and LLMs) love

Get started for freeTalk to us