Beyond where. Beyond when.
Otherreach is an in-development single-player open-world fantasy/science-fantasy RPG focused on exploration, long-term progression, systemic NPCs, deep crafting, persistent world change, and a world that does not exist merely to wait for the player.
The repository is still named UNNAMED, its original development codename.
The project draws inspiration from the feel of classic persistent-world MMORPGs — learning a dangerous world, discovering places without being led everywhere by markers, developing a character over hundreds of hours, crafting meaningful equipment, finding rare long-form objectives, and becoming known through what you actually do — while remaining an entirely original game and setting.
Otherreach is being designed primarily as a single-player RPG, with reasonable architectural seams preserved for possible future LAN/co-op/community-server experimentation rather than attempting to build an MMO now.
Start with almost nothing. Explore a world that does not revolve around you. Learn, fight, craft, build, recruit allies, uncover ancient secrets, acquire legendary equipment, establish a home or settlement, make friends and enemies, and eventually become someone the world remembers.
The player begins as an insignificant newcomer with:
- poor equipment;
- limited knowledge;
- little money;
- few developed abilities;
- no major reputation;
- no guaranteed importance to the world.
What the character becomes is primarily the result of play rather than prophecy.
Settlements, wilderness, ruins, roads, caves, mines, dungeons, factions, travelers, creatures, economies, and world events exist for reasons beyond containing player objectives.
Opportunities can change while the player is elsewhere.
NPCs can act independently.
Failure can create consequences instead of merely demanding a reload.
The map is intended to represent what the character knows, not an omniscient database.
Information can come from:
- physical exploration;
- directions;
- purchased maps;
- cartographers;
- books;
- rumors;
- tracking;
- faction intelligence;
- divination;
- discovered routes.
Some places should be found simply because the player saw something interesting and decided to investigate it.
Otherreach does not use universal enemy scaling.
Entering the wrong valley, ruin, cave, or territory too early can be a very bad idea.
Returning later with better knowledge, equipment, skill, allies, and preparation should feel like real progression.
Important content is designed around a solo player rather than mandatory human parties.
Preparation can include:
- companions;
- hirelings;
- pets;
- summoned entities;
- specialized gear;
- crafted consumables;
- tactics;
- environmental advantages.
NPC allies are intended to be people with goals, relationships, opinions, equipment, money, and lives beyond following the player.
The current camera direction is a full-body third-person / over-the-shoulder RPG with continuous player-controlled zoom into first person.
The full character remains the primary world representation.
Players should be able to move naturally between:
- first person;
- close shoulder view;
- normal third person;
- more distant classic-RPG/MMO-style third person.
Perspective changes presentation, not authoritative combat or world rules.
Character level influences capability, but does not replace physics.
Combat is being designed around:
- weapon reach;
- armor coverage;
- anatomy;
- position;
- timing;
- stamina;
- injury;
- knowledge;
- preparation.
A powerful enemy should be difficult because of real advantages — skill, armor, senses, wards, biology, equipment, numbers, or tactics — rather than simply having an enormous health bar.
NPCs react to what they can plausibly:
- see;
- hear;
- smell;
- track;
- infer;
- learn from another character.
An enemy does not know something merely because the simulation knows it.
This supports old-school pulling, investigation, body discovery, last-known positions, disguise, and information propagation without psychic faction aggro.
A long-term goal is a compositional item system built from:
- form/chassis;
- materials;
- structural components;
- functional components;
- mechanisms;
- magical or technical channels;
- tuning;
- enchantment;
- appearance.
If a combination is physically and systemically plausible, the preferred answer is:
Yes — but it has costs and tradeoffs.
Examples include transforming implements, hybrid weapons, modular armor, unusual mechanisms, and cross-cultural technology/magic.
Otherreach is not being designed around a generic universal mana bar.
Resonance describes a practitioner's ability to interface with Pacha phenomena.
Strain describes the accumulated cost and instability of forcing reality to behave differently.
Magic is planned as a compositional system with domains, delivery, shape, duration, anchors, triggers, safeguards, and strain profile.
Established spells can exist, but advanced practitioners may eventually tune or construct their own formulas.
Souls are real phenomena in Otherreach, although their ultimate nature remains open to interpretation.
A major long-term design concept is that the player's Soul may persist across multiple incarnations within a world.
The Soul can eventually have its own history, attunements, memories/echoes, scars, divine relationships, and rare soul-bound objects.
Character progression asks:
Who am I becoming in this life?
Soul progression asks:
What has persisted through all of my lives?
Beings or intelligences exist whose capabilities mortals reasonably call divine.
A god to a mortal civilization may not be a god to another god.
Religion, science, magic, advanced technology, constructed realities, and the Other may overlap without the game reducing every mystery to a single final explanation.
Otherreach uses the concept of Pachas: complete realities with their own space, time, matter, history, and physical law.
Related working terminology includes:
- The Other — the broader unknown beyond or among ordinary realities;
- The Veil — a perceived boundary;
- Otherways — traversable routes that may lead elsewhere or elsewhen;
- Othergates — stabilized entrances;
- Otherwhere — beyond ordinary geography;
- Otherwhen — beyond ordinary chronology;
- Otherwake — disturbance left by passage;
- Othermarked — those changed by exposure;
- Otherwrought — objects made using Other-derived forces, matter, or knowledge.
No one knows where the Otherways lead. Some go elsewhere. Some go elsewhen.
Eight original playable peoples are currently designed for eventual development:
- Veth — adaptable, fast-learning descendants of a lineage touched by reality transition;
- Kal — compact, dense builders and material thinkers with large folding dorsal wings;
- Siann — extremely long-lived scholars and magical practitioners with slow, deep mastery;
- Orenth — walkers capable of innate Pacha-crossing at permanent personal cost;
- Mor — bodiless survivors of a reality that no longer exists, closely tied to Soulcraft;
- Constructed — people native to an engineered reality who see physics and magic as systems;
- Vaskaal — tall void-farers with advanced technology but no native ability to cast magic;
- Ondrek — living geology capable of reading material history.
Biology, aptitude, and culture are deliberately separate.
A civilization's knowledge is learned. It is not automatically encoded into every member of a race.
Long-term systems include:
- autonomous NPC adventurers;
- companions and hirelings;
- factions and layered reputation;
- jurisdiction-specific law and crime;
- witness/evidence systems;
- bounty hunting;
- persistent dungeons with changing occupants;
- settlements that can be threatened, destroyed, occupied, and rebuilt;
- regional economies and contracts;
- property ownership and wilderness building;
- weather, seasons, survival, and environmental hazards;
- cartography and information as progression;
- pets with actual utility;
- world events from personal scale to cosmological scale.
These systems are being staged incrementally. Their presence in the design does not mean all are already implemented.
- Engine: Godot 4.x
- Primary language: C#
- Content: human-readable YAML
- Testing: xUnit / headless .NET tests
- 3D interchange: GLB/glTF + standard PBR workflows
- Asset normalization: Blender
- Architecture: engine-independent authoritative C# domain with command/event-based mutation
- Persistence: deterministic world baselines + sparse persistent deltas + versioned migration
Godot handles:
- presentation;
- rendering;
- scene composition;
- physics integration;
- input/view binding.
Authoritative gameplay state lives outside the engine-facing presentation layer and is testable without launching Godot.
Conceptually:
Godot Presentation
↓
Commands / Application
↓
Authoritative Systems + Domain
↓
World State / Persistence
↓
Events
↓
Presentation
Presentation does not directly own authoritative game state.
Persistence is treated as foundation rather than an afterthought.
The current architecture uses:
- stable Definition IDs for authored content;
- ULID-based runtime instance identity;
- deterministic world baselines;
- sparse deltas for world divergence;
- checksummed save folders;
- crash-safe atomic commit behavior;
- rotating backups/autosaves;
- corruption detection/reporting;
- explicit migration rather than silent guessing.
M2 established the baseline persistence implementation.
M2b added historical save migration and separated exact content identity from world-generation compatibility, so unrelated balance/content edits do not reshuffle procedural baselines.
The project is being developed with extensive AI-assisted engineering and asset production.
AI coding agents are treated as implementation collaborators, not substitutes for:
- architecture;
- automated tests;
- source control;
- milestone exit criteria;
- human review;
- playtesting.
Runtime AI/LLM features are optional future systems.
A foundational rule is:
Generated prose may describe or propose. Deterministic systems remain authoritative.
A runtime language model will not be allowed to arbitrarily award items, XP, reputation, kills, or world-state changes.
The game must remain playable with runtime AI disabled.
The project is experimenting with tools including:
- ComfyUI;
- TRELLIS-family 3D generation;
- image-generation workflows;
- procedural/generative PBR workflows;
- Blender;
- GLB/glTF;
- AI/video motion-capture workflows;
- animation retargeting and reusable skeleton families.
The production direction is:
concept/reference
↓
raw generated asset
↓
canonical Blender source
↓
normalized production GLB
↓
Godot import + validation
Animation is intended to use:
- canonical skeleton families;
- reusable animation libraries;
- retargeting;
- IK;
- additive layers;
- procedural correction;
- animation-only GLBs where appropriate.
Generated intermediate assets are intentionally kept outside normal Git history.
Otherreach is currently in Phase 1 — Playable Prototype, at its owner-playtest gate.
Completed milestones:
- Phase 0 — game/system architecture and adversarial review
- M0 — repository and architecture bootstrap
- M1 / M1b — domain skeleton, command/event flow, headless tests; data-driven content loading and validation
- M2 / M2b — entity identity, deterministic baselines, sparse persistence, crash-safe saves; save migration and baseline compatibility
- M2c — progression spine
- M3 – M3f — player, movement and world cells; items, inventory and equipment; combat; creatures and AI; basic magic; gathering and one profession
- M4 — the waystation's people: NPCs, structured dialogue, relationships, trade
- M5 — quests as objective graphs, and the quest debugger
- M6 — Ashen Hollow's four cells, its second quest, and the first companion (at the owner-playtest gate)
The Phase-1 prototype is playable end to end in a small greybox region. The project is not yet a generally playable game.
You need the .NET 8 SDK, and for the game itself Godot 4.7 (the .NET / Mono build).
- Headless tests: from
src/, rundotnet build, thendotnet test --no-build. No engine is needed. - Content validation:
dotnet build src/Content -c Release, thendotnet exec src/Content/bin/Release/net8.0/UNNAMED.Content.dll lint --content-root content. A broken definition is named by file and line, and the game refuses to start on one. - Play:
dotnet build src/Presentation, then rungodot --path src/Presentation(or opensrc/Presentationin the Godot editor and press Play). - Controls: WASD to move, Shift to sprint, Ctrl to walk, Space to jump, X to crouch or stand, mouse to look, wheel to zoom in to first person (V toggles, Q swaps shoulder); left click attacks, right click guards (or aims the bow), C dodges; E opens, takes, talks, works and helps up, R takes all from an open container; Tab is the inventory, J the journal, K the character, 4-6 the formulas, H a salve, G tells a companion to follow or wait; F1 lists the controls; F5 quicksaves, F9 quickloads; F3 is the debug overlay, F4 the quest debugger; Esc frees the mouse.
- Checks without playing:
godot --headless --path src/Presentation -- --smokeboots, plays a little and round-trips a save.godot --path src/Presentation -- --playthrough <dir>plays the content bible's acceptance route and saves and quits;-- --playthrough-verify <dir>relaunches, loads that save and compares the state field by field.
A representative public-facing vertical slice is targeted by M9, after factions/building and a dungeon/boss/multi-stage quest are integrated.
No release date is currently promised.
The current critical path is approximately:
M2b Save migration
M2c Progression spine
↓
M3 Player + movement + world cells
M3b Items / inventory / equipment
M3c Combat core
M3d Creatures / AI / loot
M3e Basic magic
M3f Skills / gathering / one profession
M4 Settlement + NPC persistence + dialogue
M5 Quest framework + debugger
M6 Companion v1
── Phase-1 playable prototype ──
M7 Factions + reputation + building v1
M8 Dungeon + boss + multi-stage quest
M9 Vertical-slice gate
Large-scale content expansion comes after the core loop has proven itself.
Otherreach is built vertically and incrementally.
One small system that actually works is more valuable than a large system that merely exists on paper.
Prefer:
- three working weapons over architecture for 500 hypothetical weapons;
- five excellent creatures over a spreadsheet of 200;
- one functioning dungeon over plans for fifty;
- one tested region over a huge empty map.
Every major milestone should:
- inspect existing implementation;
- implement the smallest coherent feature set;
- build;
- run automated tests;
- perform runtime validation where appropriate;
- fix regressions;
- update documentation;
- provide evidence against exit criteria.
Do not claim a system works without evidence.
docs/ Architecture, decisions, design, roadmap, risks, status
src/ C# runtime implementation
tests/ Headless automated tests and probes
content/ Data-driven content definitions
tools/ Development/content/asset tooling
assets/ Asset pipeline structure and manifests
The documentation is intentionally extensive so another engineering session or model can continue without reconstructing project history from memory.
Important project documents include:
docs/ARCHITECTURE.mddocs/DECISIONS.mddocs/DATA_MODEL.mddocs/SYSTEMS.mddocs/PERSISTENCE.mddocs/WORLD_ARCHITECTURE.mddocs/PROGRESSION.mddocs/PROTOTYPE.mddocs/VERTICAL_SLICE.mddocs/ROADMAP.mddocs/RISK_REGISTER.md
Additional gameplay/design documents cover areas such as:
- races and cosmology;
- combat and stealth;
- crafting/itemization;
- economy and NPC simulation;
- property/building;
- travel;
- maps/cartography;
- companions;
- crime/law;
- quests/world events;
- magic;
- Souls;
- animation/asset production.
Normative architecture documents take precedence over unreconciled future-design notes when implementation conflicts exist.
This is currently a personal experimental development project with foundational systems still under active construction.
Issues, discussion, technical observations, and constructive feedback are welcome.
Large unsolicited architectural rewrites or major feature pull requests may not be accepted while foundational milestones are still being completed.
Source code is licensed under the MIT License. See LICENSE.
Game artwork, 3D models, textures, audio, music, characters, lore, world designs, narrative material, and other non-code creative assets are not automatically licensed under MIT unless explicitly stated otherwise.
Every road leads somewhere. The Otherways do not.