System Overview

Architecture

Rising Kingdoms is a multi-server Rising World cluster with one central backend. Five repos today, each its own git repo under wildtimesgaming/<RepoName>.

Repo	What it is
`RKClient`	The core Rising World plugin every game server runs. Framework hub — other plugins hook into it, not into each other.
`RKServer`	The standalone backend process (`RKBackend`). One instance, all game servers connect to it.
`RKUpdater`	Low-`loadorder` (`-10`) plugin that gates connections until every registered plugin is ready, and auto-updates jars by hash comparison. Loads before `RKClient`.
`RKPackets`	The core wire-protocol packets (handshake, cluster sync, transfer, playerdata, admin/wrong-server) — used regardless of which feature plugins are installed.
`RKUpdatePackets`	A separate, tiny packet library just for the update/claim protocol. Kept apart from `RKPackets` so a breaking change there can't strand the updater.

Why three separate "core" pieces instead of one big plugin: RKUpdater has to work before RKClient even exists — it's the thing that installs/updates RKClient in the first place — so it can't depend on anything RKClient provides. RKServer is a completely separate JVM process, not part of Rising World's plugin loader at all.

RKClient — the framework core

A Rising World plugin (extends Plugin implements Listener, UpdateAware). Owns:

The one persistent socket connection to the backend (BackendClient) — every plugin's packets flow over this same connection, there's no way to open your own.
Player lifecycle: connect → wrong-server check → verified (or kicked/redirected) → disconnect. The single owner of the raw, cancelable PlayerConnectEvent/PlayerDisconnectEvent — see events.
Cluster state (grid position, sector borders, home-server designation, weather/time sync).
The packet registry and event pipeline other plugins hook into.

A plugin gets the running instance via:

Plugin core = getPluginByName("RKClient");
if (core instanceof RKClient rkClient) { ... }

Full reference: RKClient page.

RKServer — the backend

One process (RKBackend, launched via java -jar RKServer.jar), holds:

ServerSocket accepting connections from every game server (ClientHandler, one per connection, dispatches through the shared PacketRegistry).
SQLite database (Data/rkbackend.db) — server registry, player data cache. The only thing with DB credentials; no plugin or remote server ever gets a connection string.
UpdateSocketServer / UpdateHttpServer — serves the Updates/ tree to RKUpdater instances, and runs the claim-code exchange for new server registration.
/admin dashboard, and this /documentation documentation site.
The BackendModule list — where a feature's backend-side manager registers itself.

Full reference: RKServer page.

RKUpdater — install / update / boot-gate

Runs first (loadorder: -10), does three jobs before any real plugin logic runs:

Claim exchange (only on a fresh, unclaimed server) — writes this server's identity into RKClient's Settings/Server.json.
Update check — SHA-256 hash comparison against the backend's manifest, no version numbers anywhere. If anything changed, applies it and restarts.
Boot-gate — every registered plugin implements UpdateAware and calls registerPlugin(this). RKUpdater calls onUpdatesFinished() once no update is needed, waits for each to call reportReady(), then opens the connection gate. No admin bypass.

Why this matters for your plugin: if you want to be part of the "wait until everything's actually ready" guarantee and get auto-updated the way RKClient does, your plugin needs to participate in this same handshake — see Building a Plugin.

Full reference: RKUpdater page.