Plans & Ideas

Everything from a rough idea to an in-progress build. Each entry gets a synopsis and a status: Idea → Planned → In Progress → Done, or Paused at any point along the way.

RKDev

Status: Planned. A dev/test plugin built through the real UpdateAware/registerPlugin lifecycle from the start — deployed via Updates/Plugins/RKDev/... so RKUpdater's own hash-check/apply/restart cycle handles staleness automatically, instead of manual jar copying. References all global libraries so it can test cross-plugin scenarios broadly. Replaces the retired RKFramworkTest throwaway, which was hand-deployed and directly caused two real bugs (see Bugs) from exactly the class of mistake real lifecycle participation prevents. First step of the RKClient Core Systems build order.

Framework Rework

Status: Done. RKClient became a "core" other feature plugins hook into instead of every system living directly in it: a packet registry both directions (registerPacketHandler / BackendModule), a generic event pipeline (registerEventHandler, one-owner-per-cancelable-event principle), and a shared settings merge/migration mechanism. All confirmed working on real Sandbox traffic, both repos pushed. Full detail on the Architecture and Building a Plugin pages.

Documentation Site

Status: Done. This site. Served live off disk from each repo's own Web/ folder (admin stays firewalled, docs and update downloads are each exposable on their own terms) — no recompile needed to edit a page, including this planning section. Per-plugin pages auto-discovered from Web/Plugins/<Name>/doc.html, no code change needed to add one. Reorganized 2026-08-17 under Web/Backend/ — see the entry below.

Reverse Proxy & Settings Reorg

Status: Done. An embedded Host-header subdomain reverse proxy (rk.backend.webservices.reverseproxy) fronting RKServer's HTTP servers — e.g. Documentation.<domain> resolves cleanly with no port shown, purely by inspecting the request's Host header on one shared port (80). Internal targets dispatch in-process (no network hop, same JVM); a per-route access setting keeps admin local-only even with the proxy publicly reachable. Fully optional — disabled by default, and every server's own port keeps working directly either way. Full field-by-field reference on the new Settings page.

Landed alongside two settings-file reorganizations, done the same day for the same reason (a file's name should match what's actually in it): Network.json split into Connection.json (raw socket/throttle only) and Http.json (every HTTP port + the reverse proxy config), and Debug.json renamed to Logging.json with every category upgraded from a plain on/off boolean to a 4-way destination (OFF/CONSOLE/FILE/BOTH), plus a proper override_logging master switch (same 4 values) that was designed originally but never actually wired up under the old boolean scheme. The documentation site itself was reorganized in the same pass: architecture.html/plugin-guide.html and this whole Planning section moved under Web/Backend/, and a new Settings page documents every field across all 7 Settings/*.json files.

Known cosmetic issue, deliberately not fixed yet: the sidebar's logo/Overview links are hardcoded to the absolute /documentation path (correct for direct-port access, where that's the server's actual registered context). Clicked while already on Documentation.<domain>, this makes the address bar show a redundant /documentation segment after the subdomain — content still resolves correctly (handleProxied() strips it), purely a URL-prettiness issue. Left alone since the planned landing-page redesign (see Feature Ideas — public website overhaul) will likely touch these same links anyway.

RKClient Core Systems

Status: Idea. The next layer of RKClient itself — input, per-entity state, assets, and UI — as opposed to feature plugins that consume them. Build order: RKDev → RKInput (keys/mouse) → asset loader → base UI dock → toast, though not rigid. Covers a decision rule for framework-vs-plugin placement (verified against the real Plugin API for input and UI), a mirrored PlayerController/NpcController per-entity attachment point, a per-player settings/theme flow, prior art scanned from four old projects (icon-dock UI pattern, theme system, NPC role dispatch), and a declined embedded-FTP idea for update downloads. Full detail on the RKClient Core Systems reference page.

Character, Stats & Skills

Status: Idea. Three separate plugins, deliberately independent (own repo, own deploy cycle) rather than one combined system — Character (custom avatar system, name capture/change via chat events, race, optional backstory), Stats (max stamina, max health, health recovery rate, walk/move/sprint speed, cold/heat resistance), and Skills (harvesting/gathering, farming, felling, mining). Progression is pooled EXP → character level → each level-up grants separate stat points and skill points to spend, not per-skill practice-leveling. Race (Character) affects base stats (Stats) — the one confirmed cross-plugin dependency, everything else stays independent.

Uses a ranked node mechanic for the skill tree: each node holds multiple ranks, needs rank ≥1 in the node before it to unlock, and can never exceed that prior node's current rank — forces balanced investment rather than rushing one powerful node. Professions ("miner," "carpenter") are just descriptive labels for a skill combination, not their own tracked system. Each plugin gets its own packet(s) through the existing shared PacketRegistry/BackendModule pattern, not one monolithic sync blob — consistent with how the framework was built for independent feature plugins. Full node-by-node detail for all 12 skills and the remaining build order lives on the Character & Skills reference page.

Equipment — Backpack & Saddle Systems

Status: Idea. Two systems, both synced cross-server through the existing player-data pattern: a modular backpack (World.createStorage()-based, slot count driven by a "Carrying capacity" Stats-plugin point), and saddles & saddle bags with hide-socketed stats — 4 stat slots on saddles (health/speed/whistle distance/whistle cooldown), 2 capacity slots on saddle bags, encoded directly into Item.setValue() so stats travel with the item through trades for free. Includes a rare unicorn variant (horsehide texture variant 4, ~0.1% drop) and a whistle-to-mount teleport mechanic. Full hide-stat tables and implementation detail on the Character & Skills reference page.

Cities & Portal Hubs

Status: Idea. Each server gets a main city with a portal hub linking to every other server's city. Entering a hub sets a per-player "discovered" flag (synced as part of their player data). Portals require prior discovery; edge-sailing (the existing cross-server transfer mechanism — see Framework Rework) always works regardless of discovery status, giving every player a guaranteed way into any server even before finding its city. Not yet started — no city/portal/discovery concept exists anywhere in the current codebase as of 2026-08-17.

Feature Ideas

Status: Idea (all of the below) — unscoped, not committed to. Long-term direction: RK should evolve into a general framework to keep adding modules to, not a fixed set of one-off systems.

• Currency system — cross-server currency for players, synced through RKBackend similar to player data. Used as the running example throughout the framework rework design, never actually committed to being built first. A first concrete design (multiple backend-defined currencies, physical exchange markets per city) exists on the Character & Skills reference page.
• Chat broadcasting — broadcasting chat messages across servers in the cluster.
• Auction house — cross-server player marketplace.
• Email system — in-game player-to-player mail, presumably synced cross-server through RKBackend.
• Permission syncing — syncing player/rank permissions to all servers in the cluster.
• UI system — now substantially scoped as the base UI dock in RKClient Core Systems (real API confirmed, prior-art patterns from four old projects), plus toast notifications on the Character & Skills reference page.
• Cluster scalability — extend the grid (add more server cells) as needed rather than a fixed size at creation.
• Biome override system — force a server's biome/terrain generation based on grid position (northern cold, central temperate, southern desert).
• Public website overhaul — a public-facing site showing the cluster grid + server info to players, building on the existing /admin grid UI (admin side stays separate, this adds a player-facing view alongside it).

RPG progression and saddle enchantments used to be one-liners here — both are now fully scoped, see Character, Stats & Skills and Equipment below.

MySQL Migration

Status: Paused. Migrate RKServer's backend DB from SQLite to MySQL/MariaDB4j with a connection pool (HikariCP) — driven by future systems (currency, auction house) needing a large, heavily-synced database at a target scale of ~20 servers, including other people's servers linking in via portal travel, well past SQLite's comfortable single-writer range. MariaDB4j evaluated as the embedded-style option (auto-manages a real mariadbd subprocess, no manual install, genuine MySQL-wire compatibility — not a shim). Leaning toward MySQL/MariaDB4j-only rather than a dual-backend abstraction, not finalized. Still open: pool sizing, concrete schema migration plan/tooling.

Player Offline Cache

Status: Paused. Each game server keeps a local SQLite cache tracking which player IDs are allowed on it. If RKBackend is unreachable on connect: check the local cache instead of blocking the player out entirely; anyone who connects during the outage gets cached locally and resynced once the backend comes back. Same "backend down shouldn't take the server down" philosophy RKUpdater's own failure-handling already follows for updates. Still open: how the cache's allowed-list stays fresh during normal operation, conflict resolution if backend-side data changed while a server was running off-cache.

Plugin Auto-Doc Registration

Status: Idea. Plugins connected through RKClient auto-register their documentation with this site on connect, instead of the current manual "author Web/doc.html, copy it to the backend" step. The natural version (send the file's bytes as a packet) was rejected — it would bundle docs into the plugin jar, breaking the recompile-free editing this site was built around, and mixes runtime code (scanned by UpdateManifestBuilder) with documentation (deliberately excluded from that scan). If revisited: send only a path/pull-URL on connect, backend fetches from there — keeps doc.html a plain, freely-editable file while still getting auto-discovery on first connect.

Architecture Docs Split

Status: Idea. Whether Web/Backend/architecture.html should split into multiple pages under its own folder (mirroring how Planning/ is 5 separate pages), once there's enough subsystem content to justify it — one page per subsystem (packets, events, settings, the webservices/reverse-proxy layer). Not decided, no folder created yet.

Embedded FTP for Updates

Status: Idea. An embedded FTP server inside RKServer to feed Updates/ downloads, as an alternative or addition to UpdateHttpServer's HTTP byte-range downloads. Not scoped — routing model, whether it replaces or supplements the HTTP path, auth, and port are all still open.

RKClient Logging

Status: Idea. Bring proper destination-based logging to RKClient, mirroring the Logger/LoggingConfig system just built for RKServer — and potentially offer it as a feature other plugins connected through RKClient can use too, not just RKClient's own internal logging. Not scoped — whether RKClient gets an independent logger or something shared given Rising World's shared plugin classloader, and what "offer as a feature" concretely means, are both still open.