Renderer-independent
Use React Three Fiber, vanilla Three.js, another renderer, or no renderer at all.
Modular RPG systems · TypeScript · MIT
Overworld Engine gives React Three Fiber and Three.js games the systems around the scene: quests, dialogue, inventory, AI, multiplayer, UI, persistence, and platform adapters. Keep rendering in R3F. Keep game rules portable and testable.
A renderer solves cameras, materials, meshes, and frames. An RPG also needs long-lived state, content schemas, objectives, rewards, saves, input arbitration, networking, and UI projections. Putting all of that inside React components or scene objects makes those rules difficult to test and impossible to reuse on a server.
Overworld separates serializable content, headless state machines, and rendering adapters. Your application remains the composition root. There is no global engine object that has to own the render loop, routing, or product-specific game rules.
Use React Three Fiber, vanilla Three.js, another renderer, or no renderer at all.
Typed facts connect quests, achievements, audio, analytics, and UI without imports.
Install one system for the slice you are building instead of taking a full stack.
Keep domain logic shared while bridges isolate Web, desktop, mobile, and mini-game APIs.
Scene code emits a typed fact. The quest engine advances matching objectives, runs a registered reward, and emits completion. React UI subscribes to stores or events. No system needs to import the others.
import { gameEvents } from '@overworld-engine/core'
import { createQuestEngine } from '@overworld-engine/quest'
const quests = createQuestEngine({
quests: QUESTS,
conditions,
effects,
events: gameEvents,
})
// Called from an R3F controller, Three.js system, or server simulation:
gameEvents.emit('player:moved', { position, distance: 1.4 })
// quest objective → reward effect → quest:completed → React UIThis boundary also makes automated tests cheap: inject an event bus, storage adapter, clock, and random source; drive the system with events; assert against plain state.
Data-driven quest chains, dialogue sessions, conditions, effects, tutorials, and achievements.
Scene entities, environment simulation, minimaps, loading boundaries, AI, and navigation.
Headless server execution, transport-neutral networking, relay support, and shared schemas.
Shared game rules with explicit adapters for save files, Steam, WeChat, Tauri, and Capacitor.
If rendering and game state are becoming entangled, begin with the React Three Fiber RPG architecture guide. If quest logic imports the wallet, inventory, combat, and UI directly, use the headless TypeScript quest system guide.
Each guide follows a real vertical slice from serializable content or validated input through runtime state, events, UI, persistence, and server boundaries.
Event-driven objectives, conditions, rewards, chains, persistence, and testing.
Serializable trees, conditional choices, declarative effects, localization, and React UI.
Item definitions, stacking, capacity, overflow, effects, events, and save state.
Validated inputs, deterministic simulation, prediction, reconciliation, and snapshots.
Run movement, dialogue, quests, inventory, rewards, HUD, AI, and tests.
Share domain rules across Web, desktop, mobile, mini apps, and Node.
Compare renderers, RPG systems, integrated frameworks, engines, and backends.
Install only the Overworld packages needed by the first gameplay slice.
No. React Three Fiber and Three.js own rendering. Overworld supplies renderer-independent RPG systems and the contracts that connect them to your scene and React UI.
Yes. Packages are independently published and most domain packages depend only on the small core package. You can begin with one vertical slice instead of migrating an entire game.
Yes. Headless domain systems can run in Node.js without a DOM or WebGL context. That makes authoritative simulation, deterministic tests, and shared validation practical.