NPC Types (Advanced)

{
  "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."
  }
}

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

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.

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):

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.