If the Emberville class menu is not opening, first distinguish a class that has not been discovered from a menu that refuses to respond after the discovery tutorial. Public demo gameplay shows the first class tutorial directing keyboard players to press P and activate Wanderer. If you changed bindings, follow the current assignment instead of assuming P still applies.
For gamepad problems, check the installed demo version before relying on an old workaround. Demo Alpha 0.20.18.x includes shoulder-button and UI navigation fixes, but it does not establish a universal fix for every class-menu symptom. Start with a controlled input comparison and preserve your existing character.
Identify which part of access is failing
Opening the class menu, finding a class inside it, activating a known class, and using a class skill are separate actions. A page or discussion that says classes are broken may refer to any of those stages. Identify the exact stage on your own screen before deciding what to change.
If the menu opens but the class you expected is missing, that is not a failure to open the menu. Likewise, a skill that is unavailable after the menu appears should be checked as a skill or progression issue. This guide focuses on reaching the menu and selecting the known class state, not on inventing unlock requirements for every future class.
If nothing happens when you press the expected control, note whether you are in normal play, dialogue, inventory, or another interface. Input context can change how a control is interpreted. A single unsuccessful press during a conversation is different from a reproducible failure while standing in an ordinary playable area.
Write down whether other menus still open. If inventory and other interface controls also fail, describe the broader problem rather than assuming the class system alone is responsible. If only class access fails, that narrower symptom is useful when you compare inputs or report it.

This identifies the Classes interface and a visible entry; it does not show a menu-opening failure or its repair.
Check whether the discovery tutorial has appeared
Demo gameplay shows the first playable class being discovered and a tutorial instructing the player to activate Wanderer. The tutorial then describes the class menu as the place to learn and activate known classes. That sequence is useful for recognizing the expected progression state.
It does not provide a universal character level, hidden requirement, or exact route for every class. Do not grind an invented number of levels or defeat an unrelated enemy merely because someone assumed it opens the menu. Use the prompts your current demo actually provides.
If you have not reached a class discovery message, continue the current objectives rather than treating the absence of an activated class as proof of a broken interface. If you have reached it, note the tutorial text and the control it names. That gives you a concrete action to test.
The first class shown in the recorded public-demo sequence is Wanderer. This does not mean that a menu failure can be repaired by finding a second class, changing weapons repeatedly, or creating another character. Those actions do not establish why the discovery prompt's menu control is failing.
Test the current keyboard assignment
Keyboard footage reads the class-menu prompt as P. Treat that as the default shown in those demo sessions, then compare it with your current setup. A custom binding, another input layout, or a reset of configuration can change what you should press.
- Return to an ordinary playable state outside dialogue and other menus.
- Check whether the class discovery tutorial has already appeared.
- Read the current class-menu prompt or relevant binding if available.
- Press the assigned control once and wait for the interface response.
- If the menu appears, confirm that the known class is visible before selecting it.
- Close the menu normally and repeat the same action once to check consistency.
Do not press several shortcuts in quick succession while trying to identify the correct one. That can open a different interface and obscure whether the class control worked. A single deliberate input gives you a clearer result.
If the class menu opens with the current keyboard assignment but not with the controller route, the comparison points toward input or navigation rather than proving that class progression is missing. If neither route works, keep that result as a symptom rather than assuming a particular file is corrupt.
Check the gamepad navigation state
The public demo has received targeted controller fixes. Alpha 0.20.18.x addressed shoulder buttons not working properly in some menus, some UI navigation issues, the controller failing in the main menu after character creation, and a radial menu opening at unwanted moments.
Those fixes make the current build worth checking before you copy advice from an earlier demo session. They also show why a general statement that controller menus never work is too broad. At the same time, a fixed shoulder-button issue does not guarantee that every possible class-menu access problem has been resolved.
Compare the active controller prompts with your layout. Use the action indicated by the running game rather than guessing a physical button from another controller type. No universal pad mapping is established for every layout in this guide.
If you can reach the menu but cannot switch tabs or select Wanderer, describe that narrower navigation failure. It is more useful than saying the menu will not open when the screen is already visible. A screenshot can help show which part of the interface is accessible and where selection stops.

Compare whether this separate menu responds before diagnosing a class-specific input fault.
Use a fallback as a test rather than a permanent diagnosis
A mouse or keyboard comparison can help you reach a menu that a gamepad route fails to open. That is a diagnostic fallback, not proof that controllers are unsupported or that a particular mapping fixes every player. Test the exact action that failed and record the result.
Keyboard-only menu navigation was added experimentally in the current demo line and may contain bugs. Do not assume that switching entirely to keyboard navigation guarantees every screen works. A mouse comparison may still be useful when a particular keyboard or gamepad navigation path is unreliable.
If the fallback works, finish the immediate menu action carefully and return to normal play. Check whether the controller can then operate the character as expected. A menu-specific limitation and general gameplay control should be evaluated separately.
Avoid making many binding changes at once. Change only what you need for the failed action, then retest. If a new binding creates another conflict, you will have a clearer idea of which adjustment to undo.
| Observation | Useful interpretation | Next check |
|---|---|---|
| No class discovery tutorial yet | The expected progression state may not have been reached | Follow current objectives and watch for the tutorial |
| Tutorial appeared but assigned input does nothing | Menu access needs an input check | Test in normal play with the current binding |
| Keyboard opens the menu but gamepad does not | Input routes behave differently | Check gamepad prompts and demo version |
| Menu opens but a tab or selection fails | The problem is navigation inside the menu | Record the affected control and screen state |
| Menu opens and class appears but skill does not work | Access succeeded; skill use is a separate issue | Inspect the current class and skill state |
Keep bindings and character data separate
Earlier Alpha Demo 0.20.17.x fixed some rebinding issues and the reset-all-bindings button. If you use a custom layout, check the actual assignment rather than relying on memory of a setting made before an update.
A configuration reset may affect input preferences, but that does not make deleting character data a sensible menu test. Do not clear the Saves folder or remove your character just because the menu shortcut fails. Character deletion is not a documented class-menu solution.
The options-file workaround documented for language selection is a separate procedure. It is not a verified universal repair for class access. Applying it without a language problem can also reset preferences and make your input comparison less clear.
If you want to return a binding to a default, use the controls exposed by your current interface and check the resulting assignment. Do not infer success solely because you clicked a reset button; verify that the class action is now mapped and that the intended input reaches the menu.
Report a persistent menu failure with the right detail
If the current binding fails in normal play after the discovery tutorial, record the demo version and the exact sequence. Include whether you are using keyboard, gamepad, or a custom layout, and whether another input method opens the same menu.
State whether the failure occurs before the menu appears or inside it. If the menu opens, describe the tab, selection, or activation step that stops responding. If it never appears, say whether other menus still work and whether the character continues moving normally.
Do not keep creating new characters merely to repeat an unchanged test. A fresh character can alter progression state and make comparisons harder. Preserve the existing character and the observed tutorial state while seeking guidance about the specific failure.
As of October 28, 2026, the latest verified public demo line is Alpha 0.20.18.x; Early Access remains planned for January 7, 2027. Recheck access after a relevant update. The success condition is concrete: the assigned input opens the class menu, the expected known class is visible, and you can make the intended selection without losing ordinary control of the character.
