Is character control a real advertised feature?
Creature control appears in the official main-game description and the original demo's feature material. The official material establishes the documented feature, while the dated gameplay examples help show how that feature appeared in a particular build. Keeping those two evidence types together makes it easier to separate a confirmed mechanic from an assumption based on another game. That supports describing it as part of the advertised game concept.
A difference between those versions can explain apparently conflicting instructions without proving that one source is universally correct. If a step or value is not demonstrated in the collected sources, treat it as unverified and check a current developer update before relying on it. It does not establish a complete, tested sequence for entering and leaving control in the current main-game build. This distinction matters because feature descriptions and gameplay instructions answer different questions.
A store page can confirm that a feature is intended without documenting every input or every condition required to use it. The collected material does not close that gap with a successful, independently reproduced current walkthrough. This keeps unrelated editor choices from obscuring what changed. It also gives you a clearer basis for describing a reproducible result to other players, without turning one observation into a guaranteed rule for every save or build.
What does clicking a resident confirm?
The October 27 preview shows a resident being selected and inspected. The official material establishes the documented feature, while the dated gameplay examples help show how that feature appeared in a particular build. Keeping those two evidence types together makes it easier to separate a confirmed mechanic from an assumption based on another game. Information about the inhabitant is displayed, demonstrating an inspection interaction.
A difference between those versions can explain apparently conflicting instructions without proving that one source is universally correct. If a step or value is not demonstrated in the collected sources, treat it as unverified and check a current developer update before relying on it. That observation does not establish that the player has taken direct control of the character's movement or actions. Use inspection when your goal is to understand the resident already present in the simulation.
A character's existence and visible statistics are separate from the ability to possess that character. Do not interpret every selection panel as proof that a control mode is active. This keeps unrelated editor choices from obscuring what changed. It also gives you a clearer basis for describing a reproducible result to other players, without turning one observation into a guaranteed rule for every save or build.
Are divine powers the same as possession?
The prelaunch footage also shows a resident being moved through a divine-power interaction. The official material establishes the documented feature, while the dated gameplay examples help show how that feature appeared in a particular build. Keeping those two evidence types together makes it easier to separate a confirmed mechanic from an assumption based on another game. This demonstrates an action performed on the world or one of its inhabitants.
A difference between those versions can explain apparently conflicting instructions without proving that one source is universally correct. If a step or value is not demonstrated in the collected sources, treat it as unverified and check a current developer update before relying on it. It does not demonstrate the same thing as steering that inhabitant through direct character controls. The difference is practical when you are trying to reproduce a video.
Relocation, selection and direct control can all involve the same visible resident while representing different systems. A guide needs evidence for the particular system being explained rather than transferring inputs from one to another. This keeps unrelated editor choices from obscuring what changed. It also gives you a clearer basis for describing a reproducible result to other players, without turning one observation into a guaranteed rule for every save or build.
What happened in the older demo attempt?
A June 20 demo recording includes an attempted control interaction that does not succeed. The official material establishes the documented feature, while the dated gameplay examples help show how that feature appeared in a particular build. Keeping those two evidence types together makes it easier to separate a confirmed mechanic from an assumption based on another game. The recording reports a missing linked simulation hero in that historical context.
A difference between those versions can explain apparently conflicting instructions without proving that one source is universally correct. If a step or value is not demonstrated in the collected sources, treat it as unverified and check a current developer update before relying on it. It is evidence of that attempt and its result, not a universal diagnosis for every later build or every controllable creature. The material does not establish a verified fix for the observed failure.
It would therefore be misleading to promise that assigning an arbitrary class, recreating a resident or changing a particular setting always resolves it. A failed historical attempt should remain a dated observation until stronger evidence explains the required conditions. This keeps unrelated editor choices from obscuring what changed. It also gives you a clearer basis for describing a reproducible result to other players, without turning one observation into a guaranteed rule for every save or build.
Why not use a generic control-key guide?
The collected sources do not verify WASD movement, a right-click possession command, attack inputs or an exit key for a successful current session. The official material establishes the documented feature, while the dated gameplay examples help show how that feature appeared in a particular build. Keeping those two evidence types together makes it easier to separate a confirmed mechanic from an assumption based on another game. Those details cannot be supplied merely because other games use familiar control schemes.
A difference between those versions can explain apparently conflicting instructions without proving that one source is universally correct. If a step or value is not demonstrated in the collected sources, treat it as unverified and check a current developer update before relying on it. Doing so would turn an advertised concept into an invented tutorial. The same limit applies to class requirements and eligibility rules.
The main game advertises classes, but that does not establish which resident or hero must be selected for direct control to work. Treat population creation, character inspection and class configuration as related topics rather than an unverified guaranteed route into possession. This keeps unrelated editor choices from obscuring what changed. It also gives you a clearer basis for describing a reproducible result to other players, without turning one observation into a guaranteed rule for every save or build.
What can you check without guessing?
First identify what the demonstrated interaction actually does: inspection displays information, while a divine action changes something in the world. The official material establishes the documented feature, while the dated gameplay examples help show how that feature appeared in a particular build. Keeping those two evidence types together makes it easier to separate a confirmed mechanic from an assumption based on another game. Then compare the recording's build and date with your own session before applying its behavior to the main release.
A difference between those versions can explain apparently conflicting instructions without proving that one source is universally correct. If a step or value is not demonstrated in the collected sources, treat it as unverified and check a current developer update before relying on it. This avoids treating a June demo failure as proof that a later advertised feature is either fully working or permanently broken. For a reproducible report, describe the selected inhabitant, the action attempted and the exact result you observed.
Official discussions and the game's community are appropriate places to seek build-specific clarification. Until a successful workflow is confirmed, the most accurate answer remains that creature control is advertised while its reliable current input sequence is not established by the collected evidence. This keeps unrelated editor choices from obscuring what changed. It also gives you a clearer basis for describing a reproducible result to other players, without turning one observation into a guaranteed rule for every save or build.
Sources and verification
This answer cross-checks developer and Steam material against independent reporting or gameplay footage. Details from older demos are identified as historical because interfaces and availability can change between builds.