Emberville's inheritance design lets you bring eligible skills from a leveled class into a different active class. The important requirements are distinct: you need the source class and its skill, access to a destination class, and an unlocked inheritance slot that accepts the skill. Learning a class ability and switching class do not, by themselves, prove that you can inherit the ability immediately.
For the public Demo Alpha 0.20.18.x snapshot on October 28, 2026, a completed cross-class transfer with a second playable class is not verified here. Wanderer and its skill tree are demonstrated, while inheritance is described as a broader progression system. Use the explanation below to understand the intended route and recognize the checks in a current interface; do not treat it as proof that every step can already be completed in the public Demo.
Separate the source class from the active class
The source class is the class that owns the skill you want to carry over. The active class is the class you currently use and develop in combat. Inheritance connects them without making their progression the same track.
A class has its own levels, points, perks, and skills. Developing Wanderer gives you access to Wanderer options; it does not mean every other class has gained those levels or points. Likewise, activating a different known class changes your class context, but does not automatically demonstrate that a Wanderer ability has followed you.
This identifies Wanderer. It does not show a skill tree, an inheritance submenu or a completed cross-class transfer.
This distinction should guide every check. First identify the source skill and its state in the source tree. Then identify which class is active. Finally inspect an inheritance slot, if the running build actually gives you access to one. If you skip the source check, a visible ability name can be mistaken for an already learned and eligible skill.
Learn the source skill before planning a transfer
The intended system draws from skills developed in a source class. Begin by activating the class whose skill you want and progressing that class. In the Demo tutorial, the active Wanderer gains its own class progress through combat, and its points are spent in its own skill tree.
A tree can display abilities that you have not yet learned. Check the selected skill's current state instead of treating every visible icon as owned. A description of an ability is not the same as a usable skill, and a future branch can be visible before it becomes available to your character.
The same caution applies to inheritance eligibility. The broader design says some skills can cross between classes; it does not establish that every skill, every branch bonus, or every class-specific benefit can be transferred. Choose a specific learned skill and look for the running build's eligibility information rather than trying to carry an entire tree across.
Confirm that a destination class is actually available
A second class must be known and usable before a meaningful cross-class combination can be verified. The public Demo tutorial confirms Wanderer, but other visible class tiles do not establish current access. A locked entry may preview a class without providing a complete discovery and activation route in that build.
If Wanderer is your only known class, you can inspect and develop it, but you cannot demonstrate a transfer into a second playable class simply by highlighting a locked name. Continue following the game's real discovery prompts and class requirements. Do not search for a fabricated level threshold or spend an item because a speculative build description assumes another class is already available.
This is where the Demo boundary changes the answer. Understanding what inheritance is meant to do is possible now; verifying the full loop requires actual access to the source, destination, and slot in the same running version. Keep those milestones separate when deciding what you can test during this playthrough.
Inspect inheritance slots instead of assuming their unlock levels
Inheritance slots are a separate gate from learning the source ability. Developer explanations describe slots opening as progression develops, but a stable current Demo table for slot levels, active versus passive capacity, and every eligibility condition is not established here.
Read the lock text and available actions in your current build. Do not apply a remembered level from an earlier preview as a universal requirement, especially when the interface is still being developed. A displayed lock tells you what your installation currently expects; an unlabelled slot is not permission to invent its requirement.
If a slot appears unlocked, inspect what skill choices it actually offers. An open destination space does not imply that every ability you own can be placed there. The slot's type, the skill's availability, and the source class's progress are separate things to check. If one of those checks fails, record the specific state rather than combining them into a single “inheritance is broken” claim.
Follow the intended inheritance sequence when the build supports it
The following sequence describes the design and the interface checks needed to verify it. Complete a step only when the current game provides that action:
- Identify the ability you want to carry across and the class that owns it.
- Activate that source class and develop its own class progression.
- Learn the skill and confirm that it is available in the source class rather than merely displayed in a locked branch.
- Confirm that another class is already known and can be activated.
- Activate the destination class and verify that its class state is now current.
- Inspect the inheritance area only if your build exposes it. Read any slot lock, skill restriction, or eligibility message it shows.
- Select the eligible source skill through the displayed inheritance action, if that action is available.
- Check the resulting assignment before returning to combat. A highlighted icon alone is not a demonstrated transfer.
- Verify the inherited skill's availability while the destination class remains active, using the behavior and costs described by the current interface.
No exact controller button or universal transfer shortcut is confirmed for this workflow. The Demo keyboard tutorial uses P to open the class menu, but that does not identify every control inside an inheritance interface. Follow the action prompts shown by your own layout when the feature is usable.
Understand the Swift Foot example correctly
Wanderer's Swift Foot is a useful example because the Demo explanation shows it as a movement-speed ability and describes carrying it into a different class after an inheritance slot becomes available. That illustrates the purpose of the system: keep a chosen benefit while using another class as your main class.
It does not verify a completed two-class transfer in the public Demo. It also does not mean equipping a different weapon activates inheritance, or that the movement-speed effect should appear on every character as soon as Wanderer is discovered.
In the demonstrated Wanderer context, activating Swift Foot reserves part of the Kymia bar. That matters when assessing the ability in its source class. Do not assume an inherited version has identical slot rules, costs, or interactions until the destination interface actually describes them. A useful example explains the intended combination; it does not replace a current skill description.
Keep class inheritance separate from weapon mastery
Weapons and classes develop on different tracks. Weapon mastery can unlock weapon combos and related benefits, while class progression develops a class's tree. A newly unlocked weapon combo is not proof that an inheritance slot opened, and a weapon change is not proof that your combat class changed.
Weapon mastery is a separate track from class skill inheritance.
Use the interface labels to keep your progress readable. If you are looking at a weapon proficiency and its combo entries, you are checking mastery. If you are looking at Wanderer's tree and class-specific points, you are checking class progression. If a current inheritance assignment is shown, check that separate state directly instead of inferring it from a new attack animation.
Equipment values are another separate layer. A different item may change the stats displayed on your character, but that does not establish that a class ability was inherited. Check equipment when comparing an ability's result so that a simultaneous gear change is not mistaken for the benefit of inheritance.
Gear changes can affect displayed statistics; this equipment view does not demonstrate inheritance.
Check each prerequisite before calling a transfer complete
| Check | A useful confirmation | What does not complete the check |
|---|---|---|
| Source ownership | The source class is known and activatable. | A class name appears in a locked tile. |
| Skill availability | The intended skill is learned and available in its source class. | Its icon or description is visible in a future branch. |
| Destination access | Another known class can be made active. | A preview describes how that class may work later. |
| Slot access | The running build exposes an unlocked, usable inheritance slot. | A screenshot from an older build shows an empty slot. |
| Skill eligibility | The current inheritance action accepts the chosen skill. | The skill seems useful with the destination class. |
| Completed assignment | The chosen skill remains available with the destination class active. | You highlighted an option without confirming or checking the result. |
These checks also help when only part of the system is accessible. If the source skill is available but every destination class remains locked, your next milestone is destination access. If a destination exists but the slot remains locked, the unresolved step is slot access. Neither situation justifies inventing an additional material cost or claiming that a particular boss must be defeated.
Choose a useful combination once transfer is possible
Start with one concrete goal, such as keeping a movement benefit while developing another class. Pick a skill that addresses that goal and compare its current description with the destination class's own abilities. Do not assume that overlapping effects stack or that every familiar source-class benefit carries across automatically.
After making a supported assignment, keep the rest of the setup stable for a short comparison. Confirm which class is active, which skill is inherited, and what equipment is unchanged. Observe the particular benefit you selected rather than using a general impression of stronger combat as proof that every part of the combination works.
Early Access remains unreleased in this October 28 snapshot, with January 7, 2027 scheduled as the new launch date. Until a build gives you a known second class and usable inheritance controls, the honest completion point in the public Demo is understanding and developing the source class. A full inheritance result needs the complete source-to-destination sequence visible in the game, not a future-facing class tile or an assumed unlock level.