Subtypes

A subtype is a way to split one entity type into a few useful sub-categories. All your characters share the Character template, but a Player Character is filled in differently from an Innkeeper. Subtypes let you express that difference without making three separate types.

You’ll see subtypes when you create or edit an entity: a small picker at the top of the form labelled “Subtype”. Pick one, and the form can show different fields depending on what you chose.

When to use a subtype (and when not to)

Subtypes are great when you have one entity type that comes in a few flavours, where the flavours mostly overlap but each has a few unique details.

Scenario	Subtype or new type?
Protagonist vs Antagonist vs NPC vs Historical Figure	Subtypes of Character — they share most fields, just differ in emphasis.
Player Character vs Non-Player Character	Subtypes of Character — the player-character one might add fields like “player name”.
City vs Village vs Wilderness Area	Subtypes of Location — same fields mostly, but a wilderness might skip “population”.
Spell vs Vehicle	Different types — these are unrelated things; nothing about a spell carries over to a vehicle.
Character vs Faction	Different types — also unrelated.

A simple test: if you’d want to link to these things differently, they’re separate types. If they’re all interchangeable in your relationships and content, they’re subtypes.

Adding subtypes to a type

1. Open Management → Entity Types, click the type you want to edit.
2. Switch to the Subtypes tab.
3. Click Add Subtype.
4. Fill in:
   • Name — what users see in the picker (e.g. “Protagonist”).
   • Description — one line of context (e.g. “A main viewpoint character”). Shown under the picker.
   • Icon (optional) — a small icon to make the picker scannable.
5. Save. The new subtype appears in the picker the next time someone creates or edits an entity of this type.

You can mark one subtype as default. The picker will start on it for new entities.

Showing fields for one subtype only

The big payoff of subtypes is being able to ask different questions for different kinds of entity, without splitting the whole template. You do that with a visibility rule on the field, conditioned on the subtype.

A worked example for a Character type:

Subtype	Extra fields you might want
Protagonist	Goal, internal conflict, character arc
NPC	Role, default attitude, services offered
Historical Figure	Years active, legacy, primary source

To set this up:

1. Add all those fields to the Character type.
2. For each, add a visibility rule that hides the field unless the entity’s subtype matches. For “Goal”, the rule reads: Show this field when subtype is Protagonist.

The result: when someone creates a Protagonist, they see Goal, Internal Conflict, and Character Arc. When they create an NPC, they see Role, Default Attitude, and Services Offered. The form adapts to what you’re describing.

See Visibility Rules for the full setup.

Filtering and finding by subtype

Subtypes also help you find things later:

• The entities list has a subtype filter alongside the entity-type filter.
• The graph view can colour or shape nodes by subtype.
• The chatbot uses subtype information when it answers questions about your world.

If you find yourself wanting to filter for a sub-category and there’s no good way to do it, that’s usually a sign that sub-category should become a subtype.

What happens if you change subtypes later

• Adding a subtype — appears in the picker immediately. Existing entities keep their current subtype (or none).
• Renaming a subtype — entities already using it keep the new name automatically.
• Removing a subtype — entities using it lose their subtype assignment. They don’t get deleted, but any fields tied to that subtype via visibility rules will hide. You’ll be asked to confirm.

Where to go next

Visibility Rules The mechanism that turns a subtype into a different form layout.

Layouts Group fields into tabs and sections — works hand-in-hand with subtype-driven visibility.