Designing Your First Framework in The Forge

You know that house rule your table loves? The one where a clutch save earns a point of Grit, and three points let a hero shrug off a killing blow. Right now you track it on a sticky note, and half the time you forget. A framework is how you hand that job to the game itself.

In The Forge you build one by snapping visual blocks together instead of writing code. Your first framework can take about ten minutes, and once it clicks you will start seeing rules everywhere you could hand off to it.

What a framework actually is

Think of a framework as your rulebook, except it runs. It is made of a few simple pieces that add up to real mechanics.

• A resource is a number a character carries: health, mana, or that homebrew Grit.
• A condition is a state a character is in, like Poisoned, Inspired, or Rattled.
• A trigger is the when-this-then-that glue: when a hero hits zero Grit, apply Rattled.

A framework is just a rulebook that runs itself.

That is the whole idea. You describe what happens and when, and the system does the bookkeeping every session, without anyone remembering to.

Build a small one first

Do not start with your grand initiative overhaul. Start with one number and one rule. Here is a full micro-system you can build in a single sitting.

1. Create a resource. Name it Grit, start it at 0, cap it at 3.
2. Add a trigger: when a player rolls a natural 20, grant 1 Grit.
3. Add a spend option: let a player burn 3 Grit to auto-succeed on a saving throw.
4. Add a condition called Rattled that drops a hero's Grit to 0 when they take a critical hit.

That is a complete, working system. No plugin, no spreadsheet, no nudging anyone to update their sheet. The moment someone rolls that 20, the point lands. The moment they get clobbered, it drains away.

Why no-code beats fiddly macros

Macros are powerful, and also brittle. One stray bracket and the whole thing silently stops working. Six months later, nobody at the table remembers what the formula was supposed to do, least of all the person who wrote it. Visual frameworks trade that fragility for something you can actually read.

• You see the whole logic laid out, not buried inside a formula string.
• When a rule misfires, you follow the blocks to the break instead of hunting a typo.
• Your co-GM, or future you, can read it without a decoder ring.
• Changing a number is just changing a number, not rewriting a script.

The point is not that code is bad. It is that your Tuesday-night group should not need a programmer on call to tweak how Grit works.

Then let the table break it

No rule is right on the first session. Maybe 3 Grit feels too stingy, so you bump the cap to 5. Maybe Rattled should linger for a round instead of vanishing. Because every piece is visible, adjusting it is a matter of seconds, not a debugging session. Playtest, tweak, run it back.

That loop is the real reward: your game stops being a static PDF and starts behaving like something you designed, all the way down to the house rules only your table knows about.

Pick your first rule

Your first framework does not need to be clever. It needs to be one small thing your players already love, made automatic. Pick the sticky note you are tired of losing, open The Forge, and give the game something to remember for you.