Different classes, brighter builds
Emberville Skill Inheritance Guide
Understand how confirmed active and passive skill inheritance can shape an Emberville build.
Pre-Early Access · Core mechanics only · Updated Sep 19, 2026
How skill inheritance shapes a build
Learn another class, inherit confirmed active or passive skills, and use those options to shape a build direction. Slot limits, costs, and compatibility rules remain under review.
Active and passive inheritance are separate planning layers
Emberville officially describes combat classes that can inherit both passive and active skills from other learned classes. Active and passive are therefore useful categories in the planner, but the current sources do not establish slot counts, costs, transfer limits, or every compatibility rule.
An active inherited skill represents an action the player may be able to add to a setup. A passive inherited skill represents a lasting modifier or condition. Those descriptions explain the planning distinction only; individual effects will stay unavailable until their game records can be verified.
From a learned class to a final build
The planning flow begins with a base class, expands when another class is learned, and then considers which confirmed active or passive options can be inherited. Weapon-bound combos and the player’s preferred combat direction remain part of the final setup, so inheritance should be evaluated in context instead of as an isolated list of powerful skills.
BuildForgeTools will preserve that relationship when data arrives: a skill will retain its source class, type, verification state, and known compatibility evidence. This makes it possible to update a rule without silently rewriting every build that uses it.
Future compatibility matrix
The compatibility matrix is currently in review. Its purpose will be to show a base class on one axis and learned-class skills on the other, with each intersection marked confirmed, unavailable, or still unverified. Empty cells will remain unknown rather than being interpreted as compatible.
- Source class and skill type must be known before a row appears.
- A compatible state requires direct game data or consistent testing evidence.
- Restrictions and costs will be stored separately from skill descriptions.
- Every matrix update will carry a source and data-version label.