Creatures and Vehicles
creature and vehicle are the project's odd ones out: instead of the many small typed fields you'd see on character or equipment, both compress their entire crunch into one big statBlock field. That's not an unfinished schema — it's the right call for content whose shape varies more than a fixed grid of properties can comfortably hold.
Why one text field instead of many
A character's Characteristics and Attributes are the same seven-plus-eight numbers for every human. A creature's stat block is not: a Dragon has wings, a breath attack, and eight named hit locations; a Horse has none of that; a Skeleton is Undead and has no Fatigue track at all. Trying to force all of that into shared numeric fields means either a schema bloated with mostly-empty properties (most creatures have no breathAttackDamage) or endless one-off fields nobody else uses. Compare <@Dragon.creature> and <@Horse.creature> if you want to see the range this has to cover in one project.
Instead, creature.statBlock and vehicle.statBlock hold the whole thing as formatted markdown text, and creature.description / vehicle.description carry the narrative half. This trades queryability (you can't ask "list all creatures with AP > 8" with a schema query) for expressiveness (any creature, however exotic, fits). If your project needs the queryable version — say, a bestiary you want to sort by threat level — that's a deliberate schema change; see Extending the System for how to add structured fields alongside or instead of statBlock without breaking the existing entries that only have prose.
Writing a creature
Follow the shape already established across the bestiary — <@Dragon.creature>, <@Goblin-Orc.creature>, <@Horse.creature>:
- Vitals line — SIZ, Action Points, Damage Modifier, Magic/Power Points if any, Initiative Bonus, Move (note flying/swimming rates separately, e.g.
12m/18m Flying). - Abilities — a comma-separated list of named Creature Abilities drawn from <@Creature Abilities.rule>. Keep to about three abilities per creature "as a general rule of thumb" (the rule file's own words) — reach for more only for genuinely exceptional creatures like the Dragon. Don't invent a new ability name inline; add it to <@Creature Abilities.rule> first so a Games Master can look it up, the same way you'd add a new Magic Trait before using it in a spell.
- Skills / Magic / Combat Style — percentages in the same skill vocabulary as
/Skills/, so a Games Master can run the creature with the same roll-under logic as a PC. - Named attacks — Size, damage formula, and any special handling (Sweep, Trample) inline with the attack.
- Hit Locations table — 1d20 ranges mapped to named locations with AP/HP, when the creature doesn't use the standard seven-location human table. Skip this table entirely for creatures simple enough to use standard human locations.
megLink is optional and points at the creature's entry on the Mythras Encounter Generator (MEG) when one exists — leave it blank rather than guessing a URL.
Writing a vehicle
vehicle.statBlock follows the abstract sheet from <@Vehicles Overview.rule> and the Player's Handbook Vehicles chapter: Hull (armor class + AP), Structure (HP), Speed (band, not a number), Systems (count), Traits, Weapons. <@Sedan Car.vehicle> is the template to copy — bold the labeled stats, leave Weapons: None explicit rather than omitting the line, and use category for the vehicle's broad class (Ground Vehicles, Aircraft, Watercraft, Starships, and so on) so the sample fleet stays browsable by kind. designationNote is free text for anything that doesn't fit the standard sheet — a unique quirk, a licensing/setting note — and is hidden entirely when blank, so don't fill it just to have something in every field.
When to add real schema fields instead
Reach for a structured field only when every entry in the type will actually have a comparable value and something needs to compute or sort on it — for example, if you wanted every vehicle to show a numeric top Speed for cross-vehicle comparison, that's worth promoting out of statBlock into its own field. Do it as a genuine schema change (see Extending the System) rather than starting to write two versions of the same stat — one structured, one in the text block — for new entries only; that just makes older and newer files inconsistent with each other.