## Example

```json
{
  "character": {
    "name": "character",
    "vulnerabilities": [],
    "resistances": [],
    "immunities": [],
    "description": "A mortal being - human, elf, dwarf, or other standard species. No damage modifiers; standard combat, social, and effect rules apply."
  },
  "humanoid_enemy": {
    "name": "humanoid_enemy",
    "vulnerabilities": [],
    "resistances": [],
    "immunities": [],
    "description": "Mortal adversaries - bandits, rogue soldiers, corrupt officials. No special damage profile. Fully subject to social pressure: can be talked down, bribed, or scared off. Standard combat tactics apply."
  },
  "undead_shambling": {
    "name": "undead_shambling",
    "vulnerabilities": ["fire", "light"],
    "resistances": ["slashing", "bludgeoning", "piercing"],
    "immunities": ["poisoning", "dark"],
    "description": "Mindless undead - skeletons, zombies, revenants without will. Take extra damage from fire and holy light, shrug off physical blows, and are unharmed by poison or dark magic. Immune to fear and social pressure; cannot be reasoned with or bargained with."
  },
  "construct_golem": {
    "name": "construct_golem",
    "vulnerabilities": ["lightning"],
    "resistances": ["slashing", "bludgeoning", "piercing"],
    "immunities": ["poisoning", "psychic"],
    "description": "Animated guardians of stone or metal. Conductive cores take extra lightning damage, dense bodies resist physical attacks, and they are unaffected by poison or psychic effects. Follow their last instruction literally; cannot be persuaded or intimidated."
  }
}
```

## Fields

### name

Display name of the NPC type, and **must be byte-identical to the outer map key** — the engine matches entries by key, so the key and `name` have to be exactly equal (same case, same spaces). A mismatch is a validation error. Build the map as `{ npcType["name"]: npcType }`.

### description

`description` - baseline behavior summary: how this creature type behaves socially and in combat, what motivates it, and how it perceives the player. This is the template the narrator applies to every NPC of this type before the individual NPC's `basicInfo` supplements it.

> **📋 Note (`npcType.description` as a `generateNPCDetails` instruction channel):** Because `npcType.description` is read by the narrator during `generateNPCDetails`, it functions as an instruction channel for that task across every NPC of the type. Directives embedded in the description -- such as formatting rules, required detail categories, or generation constraints -- apply consistently to all NPCs of that type without repeating them in each individual NPC's `basicInfo`. This is additive to the behavioral template role: the same field can describe how the type behaves and instruct how its detail generation should be structured.

## Behaviour

### When to create a type

**Create an NPC type only when:**

- Multiple NPCs share the same damage profile (vulnerabilities / resistances / immunities), or
- The type represents a species, creature category, or profession that more than one NPC will inhabit

No baseline type is required. A world where every NPC is a unique individual (no shared damage profiles) is fine with zero `npcTypes` entries and `type: ""` on every NPC. The section is optional.

### Damage multipliers

| Category | Multiplier | Effect |
|----------|------------|--------|
| `vulnerabilities` | 1.5x | +50% damage taken |
| `resistances` | 0.5x | -50% damage taken |
| `immunities` | 0x | No damage taken |

### Damage type inheritance

An NPC with `type: "goblin"` looks up `npcTypes.goblin` and receives the **union** of the type's damage arrays plus its own:

- effective vulnerabilities = `npcType.vulnerabilities ∪ npc.vulnerabilities`
- effective resistances = `npcType.resistances ∪ npc.resistances`
- effective immunities = `npcType.immunities ∪ npc.immunities`

NPCs with `type: ""` use only their own arrays -- no inheritance happens. Use a typed NPC for shared damage profiles, and a typeless NPC when a one-off character needs a unique profile.

### Resistance stacking

Multiple resistances against the same damage type **multiply** rather than add. A 0.5x resistance from the npcType combined with a 0.5x resistance on the NPC itself equals `0.5 × 0.5 = 0.25x` total damage taken (75% reduction). The same multiplicative rule applies to vulnerabilities and immunities.

> **🐛 Common mistake:** Values in `vulnerabilities`, `resistances`, and `immunities` must match strings verbatim from `combatSettings.damageTypes`. Approximate matches do not work -- `"poison"` is not valid if `"poisoning"` is in the list; `"frost"` is not valid if only `"ice"` is defined. Always copy the exact strings from your `damageTypes` list. Entries that don't match are silently ignored.

### Species ability inheritance

When you define a creature species as both an `npcType` (so NPCs can be assigned to it via `type`) and a `trait` (so players can choose it at character creation), the species trait should include 3 abilities representing that species' innate capabilities. NPCs assigned that `type` should also have those same 3 abilities in their `abilities` array. This keeps species mechanics consistent between player and NPC versions of the same species - a player Elf and an NPC Elf both have access to the same innate abilities.

> For guidance on populating vulnerabilities/resistances/immunities see [Authoring Guide > NPC Types](/world/npcTypes#npc-types-vulnerabilities-resistances-immunities).

## Authoring tips

### NPC Types - Vulnerabilities, Resistances, Immunities

The `vulnerabilities`, `resistances`, and `immunities` arrays on `npcTypes` are matched by the engine against a single vocabulary: the **damage type** strings listed in `combatSettings.damageTypes` (or the engine defaults when you define none). They are damage multipliers and nothing else.

The matching is literal, not semantic. A value like `"blade combat"` will not match anything unless that exact string is a defined damage type. **Populate these arrays only with values that exist in your `combatSettings.damageTypes`, or the entries have no mechanical effect** (they are silently ignored).

These arrays do **not** govern social or skill outcomes. To make a type immune to fear, resistant to persuasion, or hard to deceive, write that into the type's `description` as narration guidance -- the narrator reads `description` and portrays the behavior. Do not put skill names like `persuasion` or `intimidation` in the damage arrays; they are not damage types and are ignored.

Your damage type vocabulary is a world-design choice that varies by genre. A high-fantasy set will differ from a modern or sci-fi one. Define `combatSettings.damageTypes` for your scenario first, then design type profiles around it.

**Example: a fantasy damage profile** (illustrative -- one workable configuration among many; uses the default damage types):

| Type | Vulnerable to | Resistant to | Immune to |
|---|---|---|---|
| character | - | - | - |
| beast | - | - | - |
| undead | fire, light | slashing, bludgeoning, piercing | poisoning, dark |
| construct | lightning | slashing, bludgeoning, piercing | poisoning, psychic |
| elemental | (opposing element) | (own element) | poisoning |
| spirit | light, arcane | slashing, bludgeoning, piercing | poisoning |

A modern or slice-of-life world where combat is rare may leave these arrays empty entirely. A combat-heavy sci-fi world would define damage types like `kinetic`, `plasma`, or `emp` in `combatSettings.damageTypes` and build profiles from those. The pattern is the same; the damage vocabulary changes with the genre.