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.

MMO Project is a complete ground-up rewrite of First Star Online, a 2D MMORPG originally built on Macromedia Director 8.5 and served over the Shockwave Multiuser Server. Rather than patching the legacy runtime, the project replaces both the client and the server with a modern, cross-platform stack — Godot 4 for rendering, C#/.NET 8 for the authoritative backend, and PostgreSQL for durable persistence — while preserving the recognizable game world, content, and behavior that made the original worth rebuilding. Development follows a vertical-slice approach: a narrow but fully working end-to-end path is proven first, then expanded system by system.

Quickstart

Run the full local stack — server, database, and Godot client — in minutes.

Architecture

Explore the three-layer design: server, client, and shared protocol.

Protocol Overview

Understand the versioned WebSocket JSON message format used by the prototype.

Modernization Roadmap

Follow the phase-by-phase plan from legacy preservation to public release.

What is being rebuilt

The original game ran a Macromedia Director 8.5 client distributed as a Shockwave plugin, communicating with a Shockwave Multiuser Server over a proprietary multiplayer protocol. That architecture has several problems that make it unsuitable as a foundation for ongoing development. Obsolete runtime. The Shockwave plugin is no longer supported by any modern browser, and the Director 8.5 authoring environment is unavailable for cross-platform development. Players cannot run the original client without legacy hardware or emulation layers. Unsafe trust model. The legacy server accepted client-supplied account names, inventory values, currency amounts, and bank names without server-side validation. Privileged administrative and content-editing messages were protected only by hidden UI or client-side flags, not by server-enforced authentication. Plaintext credentials. Passwords were stored and transmitted without secure hashing, exposing account data to interception and database leaks. The modernization scope covers a new cross-platform client, a new authoritative multiplayer backend, migration of existing maps, art, audio, NPCs, items, and characters, and replacement of all privileged in-client editing with authenticated administration tooling. The legacy source files are preserved read-only as behavioral evidence and content inventory throughout the process.
The legacy source files are preserved read-only as behavioral evidence. They are not modified or shipped.

Technology stack

Godot 4

Cross-platform 2D game client written in GDScript. Handles rendering, input, scene transitions, and WebSocket transport to the backend.

C#/.NET 8

Authoritative multiplayer backend. Owns session lifecycle, movement resolution, inventory and equipment transactions, world snapshots, and all gameplay rule enforcement.

PostgreSQL

Relational persistence layer for accounts, sessions, characters, map presence, character stats, item definitions, inventory, equipment, and ground items.

WebSocket JSON

Full-duplex transport between the Godot client and the .NET backend. All messages are versioned JSON objects under protocol v1.

Protocol v1

The versioned message contract shared between client and server. Defines login, character load, world snapshot, movement, inventory, equipment, reconnect, and logout message shapes.

Vertical-slice model

One end-to-end playable path is proven before broader system work begins, reducing the risk of a long untestable rewrite.

Current phase

The project is currently in Phase 2 — Architecture and Migration Prototype. The goal of this phase is to prove that the selected stack — Godot client, C#/.NET backend, PostgreSQL, WebSocket transport — can deliver a working multiplayer slice before larger implementation work begins. The following baseline has been verified end-to-end against a seeded local PostgreSQL database and a Godot desktop client:
  • Login — valid credentials create a session; invalid credentials are rejected
  • Character load — the account’s character record is fetched and returned with a real character_id
  • Enter world — the character enters map x1000y992 at tile (10, 10) facing south, sourced from the character save
  • World snapshot — the client receives authoritative NPC presence, remote-player presence, character stats, inventory slots, and equipment slots
  • Authoritative movement — the client submits a target tile; the server resolves cardinal A* pathing and commits the result immediately to the database
  • Inventory and equipment — left-click item use, equip, unequip, inventory-full protection, and simple food consumption are all server-authoritative
  • Reconnect — unexpected disconnects preserve map presence for a 10-second grace window; explicit logout revokes access immediately
  • Logout — the session is revoked and map presence is cleaned up

Build docs developers (and LLMs) love