Skip to main content
FORGE is meant to be forked. You keep the framework packages, tune them through config, and put your world in your own content package. You rarely edit framework internals, and when you do, you’re forking, so it’s yours to change.

​
The workflow

1

Fork the framework

Start from FORGE-FRAMEWORK. The packages under Scripts/ are now yours.
2

Decide on the neutral defaults

Keep them while prototyping, edit the shared/data/*.lua files to taste, or set ShipDefaults = false per package to start blank. See the content model.
3

Create your content package

Add a package (a good pattern: Scripts/forge-examples/<your-server> while prototyping, or a flat package for a real server) that registers your items, abilities, quests, and world through the framework’s public APIs.
4

Tune the framework via config

Adjust Config in the packages you use (XP curve, HP defaults, container caps, currency caps) without touching framework logic.
5

Remove what you don't need

Disable a package in config.json (or its Config.Enabled) if your server doesn’t use it.

​
What goes where

Framework packages

Mechanisms. Fork and tune via config; edit internals only if you must.

`shared/data/*.lua`

The framework’s editable neutral defaults. Trim or reskin in place.

Your content package

Your world, registered through public APIs. This is where most of your work lives.

`config.json` + `Config`

Which packages load, in what order, tuned how.

​
Reference: the example content

forge-examples/forge-example-content is a complete worked example of a tier-2 content package, a magic-academy slice (wand, firebolt, an instructor who gives a lesson quest, training dummies, a player HUD). Read it as the canonical “how a creator builds on FORGE,” then replace it with your own.
Keep your content in its own package rather than editing framework packages. It makes pulling framework updates into your fork far easier, and keeps the removability guarantees intact.

​
Learn by doing

Add an item

Add an effect

Add a recipe