Skip to content

Fields & Data

A field is one piece of information about an entity. A character’s name, age, alignment, faction, portrait — each of those is a field. When someone creates an entity of your type, every field you’ve defined turns into an input on the form.

Pick fields the way you’d pick the columns of a spreadsheet you’d actually use. If a column would be empty for most rows, it probably shouldn’t be a field — make it part of a description instead. If a column is the same value for every row, it’s not a field, it’s a fact about the type itself.

Don’t try to memorise all the field kinds. Reach for them as you need them, using the table below as a menu.

Field kindUse it when…Example
Short textThe answer fits on one line.A character’s epithet, a city’s motto
Long textThe answer is a paragraph or two of plain notes.Quick backstory jot, GM notes
Rich textYou want headings, bold, lists, or links to other entities.Full backstory, detailed history, lore dumps

If in doubt, rich text is the most flexible. Pick short text only when you’ll never want formatting.

Field kindUse it when…Example
Whole numberThe value is always a clean integer.Age, level, population, character count
Decimal numberThe value can have a fraction.Tax rate, speed, coordinates, ratings

Both kinds let you set a minimum and maximum so users can’t enter something nonsensical (e.g. age between 0 and 1000).

Toggle — a single on/off switch. Use it for things like is the character alive, is this the capital city, is this magic system rare. If you have more than two states, use a single-choice field instead.

Field kindUse it when…Example
Calendar dateA date in your world’s calendar.Birth, founding, coronation
Real-world dateA real calendar date (e.g. when a real-world event happened).A photo’s capture date
Real-world date & timeReal date with a clock time.Session start time

Most worldbuilding dates should use calendar date so they show in the format your calendar uses. See Calendars for how dates work across the rest of the app.

Field kindUse it when…Example
Single choiceThe user picks one option from a fixed set.Alignment (good/neutral/evil), gender, status
Multiple choiceThe user picks several options from a fixed set.Languages spoken, abilities, allergies
TagsThe user types in their own labels, freely.Themes, motifs, rough categories

Single choice and multiple choice both ask you to define the available options when you make the field. Tags don’t — users can write in whatever they want.

Field kindUse it when…Example
Single entity linkThis entity points to one other entity.Homeland, current ruler, parent organisation
Multiple entity linksThis entity points to several others.Allies, members, weapons of choice
Location linkThe link must be to a Location specifically.Birthplace, capital, headquarters

When someone fills in one of these, they get a search-as-you-type picker that looks across the entities in your world. You can restrict the picker to specific entity types — for example, “Homeland” might only allow Locations.

Field kindUse it when…Example
ImageOne image — portrait, icon, banner.Character portrait, location overview
Image gallerySeveral related images.Outfit reference sheet, location at different times
AudioA sound clip.Theme music, ambient sound
VoiceA voice sample for an AI voice profile.Character voice acting reference

Media fields upload to your world’s media library and can be reused across entities.

Field kindUse it when…Example
ColourA single colour swatch with a picker.Faction colour, magic aura, banner colour
CoordinateAn X/Y position on a map.Location placement on a regional map

When you add a field, you’ll be asked a few questions besides “what kind”:

  • Name — what users see on the form (e.g. “Date of Birth”).
  • Internal ID — a short, lowercase identifier the system uses behind the scenes (e.g. date_of_birth). Auto-generated from the name; only change it if you’re matching an existing field on another type.
  • Description — short help text shown under the field. Use this to clarify what to put in, not to repeat the field name. (“Use the era abbreviation, e.g. 412 AC.”)
  • Required — if on, users can’t save the entity without filling it in. Use sparingly; the more required fields, the more friction creating entities.
  • Default value — pre-filled when creating a new entity. Useful for fields like “status” where most entities start the same way.

Some field kinds have extra options:

  • Numbers — minimum, maximum, and step (e.g. integers only, or 0.5 increments).
  • Text — maximum length, and a pattern (a small set of characters the value must match).
  • Single/multiple choice — the list of allowed options.
  • Entity links — which entity types are allowed as targets, and whether the link is to one entity or many.

Start small and grow. A type with 4 well-chosen fields you actually fill in is worth more than 20 fields most users skip.

One field per question. “Origin and status” is two fields, not one. Splitting them lets you filter and link more cleanly.

Don’t put data in field names. A field called level_1_spells is harder to evolve than a spells field linking to Spell entities with a level of their own.

Required fields are a tax. Every required field is one more thing the user must answer to save anything at all. Make a field required only if the entity genuinely makes no sense without it (usually just name).

Reach for entity links early. If a field’s value is itself a thing you might want to track (a faction, a city, another character), make it an entity link. You can always upgrade a text field to an entity link later, but it’s harder than getting it right the first time.