Goal

Torchbound started as (and it still is, as I write this) an implementation of Five Torches Deep. I still believe that it was the right choice: implementing a real game gave me concrete rules, contracts, tests, persistence requirements, dungeon interactions, combat, progression, and UI behavior instead of designing an abstract RPG engine upfront.

As Torchbound grows, however, I am wondering if it could be possible to preserve an important architectural option (which is a new idea, it just crossed my mind, so I'm letting my uncontrollable ramblings flow here):

Torchbound Core should not assume that Five Torches Deep is the definition of an RPG.

The long-term goal is not to turn Torchbound into a universal RPG framework. It would rather be to make the ruleset an explicit boundary, so that another system could eventually replace 5TD without requiring Torchbound itself to be rewritten.

Possible future rulesets include Nimble and an adapted 2D6 Dungeon ruleset.

---

Torchbound today

The current architecture already contains a large amount of reusable infrastructure:

• campaign and session management
• SQLite persistence
• commands and events
• dungeon import from Delveforge
• dungeon identity, provenance and spatial state
• save/reload
• navigation and UI
• player-facing projections
• world-state management

However, the Engine also directly knows about many concepts belong specifically to 5TD.

Examples include checks, combat rules, proficiency, Supply, death and stabilization, resting, progression, spells, treasure rules and other game-specific mechanics.

Conceptually, the architecture still looks roughly like this:

                         TORCHBOUND TODAY

                         ╭─────────────╮
                         │     UI      │
                         ╰──────┬──────╯
                                │
                                ▼
                    ╭──────────────────────╮
                    │  Campaign / Session  │
                    ╰──────────┬───────────╯
                               │
                               ▼
                    ╭──────────────────────╮
                    │        ENGINE        │
                    ╰──────────┬───────────╯
                               │
                ┌──────────────┼──────────────┐
                │              │              │
                ▼              ▼              ▼
          ╭───────────╮  ╭───────────╮  ╭─────────────╮
          │  Dungeon  │  │   State   │  │ Persistence │
          ╰───────────╯  ╰───────────╯  ╰─────────────╯
                               │
                               ▼
               ╭──────────────────────────────╮
               │       5TD assumptions        │
               │                              │
               │  checks       combat         │
               │  Supply       death          │
               │  rest         progression    │
               │  spells       treasure       │
               ╰──────────────┬───────────────╯
                              │
                              ▼
                   ╭────────────────────╮
                   │ Five Torches Deep  │
                   ╰────────────────────╯

This does not mean Torchbound would have to be rewritten from scratch to use another system.

It does mean that changing rulesets today would still require invasive surgery because infrastructure, orchestration and rules responsibilities are not yet consistently separated.

---

The architectural constraint from now on

The new rule is deliberately simpler than "build a multi-ruleset engine":

New Torchbound Core code must not introduce an implicit dependency on a Five Torches Deep rule.

For every new feature, from now I want to distinguish four responsibilities:

Core: Torchbound infrastructure and orchestration.

Rules: Mechanics belonging to the selected game system.

Content: Authored Torchbound adventures, encounters, profiles and configuration that may intentionally use a particular ruleset.

External contracts: Delveforge and other external representations that describe things to Torchbound without defining its game rules.

Existing mixed code does not need to be rewritten immediately. I will first audit it and then separate responsibilities where there is a demonstrated architectural benefit.

---

Target architecture

The desired direction is approximately:

                          TORCHBOUND

                    ╭────────────────────╮
                    │         UI         │
                    ╰─────────┬──────────╯
                              │
                              ▼
             ╭────────────────────────────────╮
             │        Campaign / Core         │
             │                                │
             │   state          identity      │
             │   commands       events        │
             │   persistence    projections   │
             │   dungeon        orchestration │
             ╰───────────────┬────────────────╯
                             │
                             ▼
                 ╭──────────────────────╮
                 │ Explicit Rules API   │
                 ╰──────────┬───────────╯
                            │
               ┌────────────┼────────────┐
               │            │            │
               ▼            ▼            ▼
        ╭────────────╮ ╭────────────╮ ╭────────────╮
        │    5TD     │ │   Nimble   │ │   2D6D*    │
        │ Rules Pack │ │ Rules Pack │ │ Rules Pack │
        ╰────────────╯ ╰────────────╯ ╰────────────╯

                 Interchangeable Rules Packs

            * adapted to use DF-provided dungeons

The Core should therefore know primarily about concepts such as:

• identities
• state
• commands
• events
• spaces and positions
• persistence
• transitions
• sessions
• projections

It should avoid assuming that every RPG necessarily has:

• STR / DEX / CON / INT / WIS / CHA
• d20 checks and DCs
• AC
• Supply
• spell slots
• 5TD death mechanics
• 5TD progression
• 5TD treasure tables

Those concepts can exist in Torchbound — but their owner is the Rules Pack, not necessarily Torchbound Core.

---

Delveforge remains a separate responsibility

This distinction is particularly important for dungeon generation.

Torchbound should not become a procedural dungeon generator merely because one supported ruleset normally includes dungeon generation.

The intended responsibility split is:

                       ╭────────────────╮
                       │   DELVEFORGE   │
                       ╰───────┬────────╯
                               │
                      describes / generates
                               │
                               ▼
                       ╭────────────────╮
                       │    DUNGEON     │
                       ╰───────┬────────╯
                               │
                               ▼
                 ╭──────────────────────────╮
                 │     TORCHBOUND CORE      │
                 │                          │
                 │  identity                │
                 │  spatial state           │
                 │  persistence             │
                 │  world state             │
                 │  orchestration           │
                 ╰────────────┬─────────────╯
                              │
                     interprets / resolves
                              │
                              ▼
                       ╭──────────────╮
                       │  RULES PACK  │
                       ╰──────────────╯

In other words:

Delveforge says what the dungeon is.
Torchbound says what exists and what happens in it.
The Rules Pack says how actions and consequences are resolved.

This remains true even for an adapted 2D6 Dungeon Rules Pack.

2D6 Dungeon normally includes procedural dungeon generation as part of its gameplay loop. In Torchbound, I would deliberately remove that responsibility from the Rules Pack and replace it with Delveforge.

Torchbound itself should not gain procedural dungeon generation merely to reproduce that part of 2D6 Dungeon.

---

Three architectural tests

I can use three rulesets as conceptual tests without implementing any of them yet.

Five Torches Deep - baseline

5TD is the existing implementation.

The question is:

Can I identify and eventually remove the 5TD rules without removing Torchbound infrastructure with them?

This reveals the current Core/Rules coupling.

Nimble - substitution test

Nimble is another fantasy RPG, so it will share some concepts with 5TD while implementing them differently.

The question becomes:

Could I replace 5TD with Nimble without changing code that genuinely belongs to Torchbound Core?

This is important because otherwise I could accidentally create abstractions that are merely the common denominator of 5TD and Nimble and mistake them for generic Torchbound concepts.

2D6 Dungeon - partial-ruleset / DF-substitution test

2D6 Dungeon is structurally more different.

For Torchbound, I would deliberately remove its procedural dungeon-generation responsibility and replace it with Delveforge.

The question becomes:

Can a Rules Pack surrender a responsibility already owned by another Torchbound component while retaining its coherent resolution, combat, treasure and progression mechanics?

This prevents me from solving the opposite problem by making Torchbound Core absurdly broad.

---

What I am deliberately NOT doing

I am not building a generic RPG framework today and trying to predict every RPG mechanic I may encounter in the future.

Instead, I can use the existing 5TD implementation to discover the first real boundary.

Later, an actual Nimble implementation can challenge that boundary.

If Nimble exposes incorrect assumptions, I can adjust it.

A substantially different system such as adapted 2D6 Dungeon can challenge it again.

The abstraction therefore emerges from real implementations and failing assumptions, rather than speculative generalization.

---

Desired end state

Eventually, changing the game system should conceptually approach:

                    ╭────────────────────╮
                    │  Torchbound Core   │
                    ╰─────────┬──────────╯
                              │
              ┌───────────────┼────────────────┐
              │               │                │
              ▼               ▼                ▼
       ╭─────────────╮ ╭───────────────╮ ╭──────────────╮
       │ Delveforge  │ │ Campaign / UI │ │  Rules Pack  │
       │   Dungeon   │ │ Saves / State │ ╰──────┬───────╯
       ╰─────────────╯ ╰───────────────╯        │
                                                ▼
                                     ╭────────────────────╮
                                     │ Five Torches Deep  │
                                     ╰────────────────────╯
                                                │
                                           swap rules
                                                │
                                                ▼
                                         ╭────────────╮
                                         │   Nimble   │
                                         ╰────────────╯

rather than:

                     ╭────────────────╮
                     │ Change ruleset │
                     ╰───────┬────────╯
                             │
                             ▼
                     rewrite engine.lua
                             │
                             ▼
                 rewrite campaign_session
                             │
                             ▼
                    rewrite dungeon logic
                             │
                             ▼
                    rewrite persistence
                             │
                             ▼
                        rewrite UI
                             │
                             ▼
                    rewrite everything
                             │
                             ▼
                            :(

That being said, I am far from being close to that yet.

But Torchbound is still early enough that adopting this constraint now is cheap compared with extracting 5TD assumptions after several more major gameplay systems have been built.

The immediate strategy is therefore:

Audit the existing coupling. Do not over-engineer it. Stop introducing new coupling today. Extract Rules boundaries only where real dependencies demonstrate that they are needed.

That keeps Five Torches Deep as Torchbound's first fully supported ruleset while leaving the door open for Torchbound to become, later, a game capable of running the same underlying campaign/dungeon infrastructure through genuinely different Rules Packs.

Yes, I know why you smile.

As if... this challenge wasn't already out of proportion to my technical abilities and my long-term commitment :)

Peace. Out.

And... (drumroll) here's the first version of TorchBound, showing a player at the start of a DelveForge dungeon! This is a god mode view, the dark squares are unknown to the player.
And the player can’t go any further because… the next square contains a pit and… the “obstacle” handling isn’t implemented yet, so the player is stuck :)
(Yes, starting with a pit right behind the dungeon entrance is pretty mean, but that’s how DelveForge generated the map, and I left it as is)
(Life is hard, especially for dungeon explorers.)

That said, it’s nice to “see” something after hours (and hours) of implementing rules and automated tests (1,723 and still counting).

Peace. Out.

DelveForge & Torchbound — where are the boundaries?

The relationship between DelveForge and Torchbound became clear:
DelveForge creates places.
Torchbound makes stories happen inside these places.

They share a world, but they do not have the same responsibility.

---

DelveForge: the world builder

DelveForge answers one question:

What does this place look like?

DelveForge is an architect and decorator of an unexplored place. It generates:

DelveForge
|
├── Spatial generation
|     ├── levels
|     ├── rooms
|     ├── corridors
|     └── connections
|
├── Dungeon structure
|     ├── topology
|     ├── accessibility
|     └── constraints
|
└── Static features
      ├── doors
      ├── chests
      ├── skeletons (relics / remains)
      ├── pits
      ├── stairs
      └── other points of interest

A DelveForge dungeon is a coherent location.

Example generated by DelveForge:

Forgotten Chamber

• ancient walls
• locked door
• forgotten chest
• skeleton remains
• dangerous pit
• staircase leading deeper

DelveForge does not decide what happens there, it only says:

Here is a place with a history.

---

Who can experience a DelveForge world?

The generated world is not tied to a single consumer. The same dungeon can become:

A classic TTRPG adventure

Using:

• printed PNG map
• human imagination
• a Game Master

A VTTRPG adventure

Using:

• map export
• structured dungeon data
• virtual tabletop features

Torchbound

Using:

• the modeled dungeon representation
• game rules
• persistence
• gameplay systems

---

Torchbound: the world storyteller

Torchbound answers another question:

What happens here?

Torchbound gives life to the place. It adds:

Torchbound
|
├── Characters
├── Creatures
├── Events
├── Encounters
├── Decisions
├── Consequences
└── Progression

DelveForge creates:

There is a chest in this forgotten room.

Torchbound decides:

What is this chest?

It could contain:

• a potion
• a trap
• a key
• nothing

---

DelveForge creates:

A skeleton lies here.

Torchbound decides:

What does this mean?

It could be:

• simple scenery
• a fallen adventurer
• a clue
• part of a larger story

---

Same world, different experiences

The same dungeon can therefore live several lives. DelveForge exports a description:

{
  "room": 42,
  "features": [
    "chest",
    "skeleton"
  ]
}

A consumer interprets it according to its purpose:

• a GM invents a story
• a VTTRPG provides interaction
• Torchbound creates an adventure

---

The simple rule

DelveForge creates the stage. Torchbound directs the play.

Or even shorter:

DelveForge builds worlds. Torchbound tells stories inside them.

Peace. Out.