Building Consistent Content

New content should feel like a natural part of the system before it becomes more detailed. Start from function, then add flavor.

Blueprints

A Blueprint is a reusable offer, not a finished object. Give it a clear category, resource costs, build time, requirements, area status, description, and one primary purpose. Use structured income for production and housing capacity for residents. Use adjacency effects only when the relationship is specific and worth tracking. A unique Blueprint should be truly one-per-settlement; ordinary farms, shelters, storage, and workshops should remain reusable when the fiction allows it.

Research

Research should change the future. Prefer one or two legible outcomes over a long list of vague bonuses. A Blueprint unlock, an effect with a stable key, or a Quest connection gives the research a reason to exist. State requirements in terms the player can pursue: an accessible area, a tool supply, a completed quest, a worker, or a previous discovery.

Guests, Quests, and Factions

A Guest is a temporary person with a need, offer, rumor, reason to stay, and a reason to leave. Do not make the Guest a disguised reward dispenser. A Quest should state its objective, approaches, deadline when relevant, status, reward, and consequences. Approaches are invitations to act, not an exhaustive menu. Faction content should make reputation change because of a confirmed action, not merely an intention.

Races and Classes

Race supplies cultural, visual, historical, and settlement context; it does not dictate personality, morality, profession, or automatic bonuses. Class supplies identity, primary-stat guidance, settlement flavor, and starting equipment. Keep the player free to interpret both. If a mechanical benefit is needed, express it through an explicit supported rule rather than implying it in flavor text.

Skills, Spells, and equipment

Use references instead of copying ability prose into a Character. Distinguish a Skill's origin category from its family grouping. A Spell's category describes its type. Equipment should describe what it is, its category, value, weight, and fiction; do not smuggle an unsupported combat subsystem into notes.

Presentation and examples

Descriptions should show how content enters play: sensory presence, a concrete offer, a visible limitation, and a consequence. Use stable keys for effects, event protection, and logic. Display names remain editable; never make rules depend on a name that a creator may later rename. Example files are teaching tools: keep them coherent, minimal, and marked as examples rather than treating them as required canon.