Use this page for a named or recurring encounter whose function is distinct from the general Mellow guide. Clocky and similar search terms should be documented through observable dialogue, location, item response and route consequence. A fan nickname can help discovery, but it must be identified as community language if the game does not use it.
Build an encounter timeline
Record the first sighting, the room, the available conversation and the state after leaving. When the figure returns, compare what changed rather than writing a biography from memory. A timeline can show that a character moved, repeated a line, accepted an object or opened a route without guessing the motive behind the behavior.
If the encounter is required for a puzzle, link the clue article and state the exact evidence that connects them. If it is optional, mark the spoiler level. If it affects an ending, keep the choice and consequence in Endings so a reader can avoid a story reveal while looking up a character name.
Separate names from roles
Use official labels when a name appears in the game. If a guide, forum or video supplies a nickname, write “community label” and keep the in-game wording in the evidence note. Do not turn an unnamed background figure into a confirmed quest giver because a third-party page gives it a dramatic title.
The same rule applies to objects that behave like characters. A speaking object can belong here when its interaction is the player’s direct question; a silent lamp, clock or screen belongs in Puzzles or Secrets unless a verified character intent exists.
Test a changed conversation
Read the initial line, complete the suspected trigger, and return once. Record the changed words, new action and any visible result. If the line does not change, do not publish the trigger as confirmed. A community route can remain a lead with its date, build context and missing test.
The official Steam description establishes the game’s strange-individual interaction loop. Detailed Clocky steps require current in-game evidence. The article is scoped to Steam base game AppID 2684630, public label 1.08, Windows native.
Avoid overreading a recurring figure
A repeated appearance can signal a puzzle state, a story beat, a joke or a change in the player’s route. Describe the evidence before interpreting it. If Clocky appears beside a new object, record both the appearance and the object response; do not claim that the character caused the change until the route is tested.
For a final article, put the spoiler label above the first reveal, then give the shortest useful sequence. A player who only needs to know whether the encounter is safe should not have to read its ending consequence. If a community source disagrees with the current game, keep the report as a lead and show the public version checked.
Connect the encounter to a player question
Use a location question for the first appearance, a dialogue question for changed lines, and a route question for a door or item affected by the encounter. Do not make the reader search a biography to find a single interaction. If the answer is not confirmed, show the observed state and the next test rather than a fictional motive.
When the character disappears, record the last confirmed room and the event before the disappearance. A later guide can then distinguish a normal route transition from a missed conversation. This evidence also helps the Updates editor decide whether an old report needs retesting.
Use the encounter’s exact visual or dialogue cue as the page anchor. A reader may search the fan name, but the verified article should lead with the location and observed action. That makes the result discoverable without extending a community nickname into unsupported lore.
If the encounter can be revisited, record the return condition and the line that proves the state. If it cannot, identify the closing event and link the save-planning page. This keeps the character article useful without claiming more story detail than the route demonstrates.