Forge

Game data authoring — define characters, items, abilities, narrative and world systems as structured DataItems.

If Oracle is where you write, Forge is where you define.

A character isn't a paragraph in Forge — it's a row with fields, validators and references. A weapon isn't a description — it's a record with damage, costs, tags and animation hooks. The result is a machine-readable description of your game that any consumer (UE plugin, exporter, generator) can read.

The principle

GameDevBuddy describes the game. Unreal Engine implements it.

Forge is the authoring side of that principle. UE — and any future GDB framework — is a consumer of what Forge produces, not the owner of the data.

It should remain valid to use GameDevBuddy to plan and define a game without using the GDB UE layer at all.

DataItems

The unit of authoring in Forge is the DataItem. A DataItem belongs to a domain (Characters, Items, Abilities, Narrative, World, Systems) and is described by a schema.

Domains ship as starter packs — opinionated schemas for common game types. You can use them as-is, fork them, or write your own.

Domain	What it covers
Characters	NPCs, player classes, factions, relationships
Items	Inventory, equipment, consumables, loot tables
Abilities	Skills, spells, perks, GAS-style attribute mods
Narrative	Quests, dialogue, branching, world events
World	Locations, biomes, points of interest
Systems	Progression, crafting, interaction rules

Where Forge fits

Vision → Oracle (planning & narrative thinking)
       → Forge (structured DataItem definition)
              ↓
     Exporters / Adapters / Generators
              ↓
     UE plugin / GDB Framework / Third-party plugins

Forge sits in the middle: vision is captured in Oracle, refined into structure in Forge, then projected into whatever runtime you need.

Pricing: Premium.

Next steps

• Concepts — DataItems, domains, schemas, references
• Domain starter packs — what ships, what you can fork
• The UE bridge — how Forge data lands in your project