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.
Picking the right kind of field
Section titled “Picking the right kind of field”Don’t try to memorise all the field kinds. Reach for them as you need them, using the table below as a menu.
For words
Section titled “For words”| Field kind | Use it when… | Example |
|---|---|---|
| Short text | The answer fits on one line. | A character’s epithet, a city’s motto |
| Long text | The answer is a paragraph or two of plain notes. | Quick backstory jot, GM notes |
| Rich text | You 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.
For numbers
Section titled “For numbers”| Field kind | Use it when… | Example |
|---|---|---|
| Whole number | The value is always a clean integer. | Age, level, population, character count |
| Decimal number | The 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).
For yes/no questions
Section titled “For yes/no questions”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.
For dates and times
Section titled “For dates and times”Every date field you add to an entity type is a calendar date: a date in your world’s own calendar, such as a birth, a founding or a coronation. It shows in the format your calendar uses, can carry a time of day if your calendar has hours, and moves with the Viewing as of selector. See Calendars for how dates work across the rest of the app.
Real-world dates, the kind on a session’s Session Date, are kept for the app’s own records and for container types. New entity fields can’t be real-world dates (an older schema may still carry one, which you can rename). A new field asked to be a real-world date, whether through the API or by the chat assistant, is refused with a pointer to a calendar date instead, because an entity’s date box takes a date in your world’s calendar and a real-world field could never be saved.
For choices from a list
Section titled “For choices from a list”| Field kind | Use it when… | Example |
|---|---|---|
| Single choice | The user picks one option from a fixed set. | Alignment (good/neutral/evil), gender, status |
| Multiple choice | The user picks several options from a fixed set. | Languages spoken, abilities, allergies |
| Tags | The 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.
For links to other things
Section titled “For links to other things”| Field kind | Use it when… | Example |
|---|---|---|
| Single entity link | This entity points to one other entity. | Homeland, current ruler, parent organisation |
| Multiple entity links | This entity points to several others. | Allies, members, weapons of choice |
| Location link | The 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.
Every entity link needs a relationship type. This is the part people skip. When you create the field you also choose what kind of connection it makes — “Homeland” creates an Inhabits relationship, “Captain” creates an Operates one. That choice is what turns a name in a picker into a real edge in your graph.
You can’t save an entity link field without one. If nothing in the list fits, create a relationship type first — see Relationship types.
For media
Section titled “For media”| Field kind | Use it when… | Example |
|---|---|---|
| Image | One image — portrait, icon, banner. | Character portrait, location overview |
| Image gallery | Several related images. | Outfit reference sheet, location at different times |
| Audio | A sound clip. | Theme music, ambient sound |
| Voice | A 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.
Specialised fields
Section titled “Specialised fields”| Field kind | Use it when… | Example |
|---|---|---|
| Colour | A single colour swatch with a picker. | Faction colour, magic aura, banner colour |
| Coordinate | An X/Y position on a map. | Location placement on a regional map |
Setting up a field
Section titled “Setting up a field”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. The quick-create dialog (the one that opens from an entity link or a scene) shows only a handful of fields; if a required field isn’t among them, the dialog names it and you’ll need the full New entity page to fill it in.
- 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 — the relationship type the link creates (required), which entity types are allowed as targets, whether the link is to one entity or many, and, when the relationship type has kinds, the kind of link the field records (in a field that links to many, each link can still pick its own kind in its details).
A few rules of thumb
Section titled “A few rules of thumb”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.