U DON'T GET IT
Guide & walkthrough

Chapter 01

Start and setup

U DON'T GET IT is a psychological visual novel by Vhan || 반. Its premise puts you at a university where the person expected to guide you treats you with striking indifference. The gap between a promised welcome and an actual cold reception drives the early mystery. The current public release is a demo, so approach it as an introduction to a developing story. The official game listing offers downloads for Windows, macOS, Linux, and Android. This site also provides a hosted browser player. Open the player on the home page, let the game finish loading, and choose the game's Start option when its menu appears.

At the beginning, read the game's own notices and setup screens before clicking forward. The creator lists customizable pronouns as a feature. Choose the option you want for this run and record it only if you intend to compare the wording on another playthrough. Pronoun selection is a way to tailor your reading experience; the official listing does not state that it is a secret ending switch. Treat it as presentation unless the game itself shows otherwise. If you are coming back to a saved run, use the game's Load option when available. A new run and a loaded run serve different purposes: Start lets you test a fresh path; Load helps you revisit a decision without rereading every scene.

Browser play depends on the hosted game loading inside an embedded frame. The cover on the home page starts the download only after you press Play in browser. A large visual novel build may take a moment to display its own progress. If the frame remains blank or does not respond, use the direct game tab. You can also use the creator's official download page for a platform build. Avoid treating a loading delay as a narrative feature. If the game interface has not appeared, no story choice has been made.

Before you begin, decide what you want from the run. A blind first reading is best if you care most about suspense. A documented run is better if you want to map how choices affect the protagonist. Those goals can coexist, but they call for different habits. For a blind run, write nothing until you reach an ending or the demo's stopping point. For a documented run, make a simple note of each choice, your reason for selecting it, and the next scene that seemed to change. The note should distinguish a visible difference from an interpretation. “The reply changed” is an observation. “This raised a hidden trust score” is a theory until verified.

Visual novels often invite rapid clicking because the interface is simple. Here, the creator explicitly asks players to pay attention to dialogue. Let each line settle before advancing. Read the character's wording, then look at the protagonist's response options. If a choice seems small, it may still reveal how the protagonist understands a situation. If a choice seems dramatic, it may be more about tone than an immediate plot fork. The safest starting principle is to take the text seriously while avoiding assumptions about unseen code.

Chapter 02

A first playthrough that preserves the mystery

The first run gives you a baseline. It shows what the story feels like when you respond naturally rather than optimizing for an imagined ending. Start at the title screen, complete the setup, and choose the dialogue that makes sense to you in the moment. Resist the urge to reload every time the tone becomes uncomfortable. Psychological stories use uncertainty, and a response that produces unease may still be the response you wanted to make. A first run is most informative when it has a coherent point of view.

Notice the starting relationship. The protagonist enters university expecting some form of guidance, yet the assigned guide seems to ignore them. Ask what the game has actually shown. Has the guide refused a direct request? Has the protagonist interpreted silence? Has another character explained the situation? These are different kinds of evidence. A character's statement can be sincere, evasive, mistaken, or incomplete. A scene may show an event directly, or it may show the protagonist's reaction to an event. Keeping those levels separate helps you follow the mystery without accidentally turning your first guess into a “fact.”

When a dialogue choice appears, read every option before choosing one. Some options may differ in directness, curiosity, patience, or defensiveness. You do not need to turn those differences into a numerical system. Simply ask which response fits the person you are playing. Then observe what happens. Does the other character answer the question? Does the protagonist's internal narration change? Does the scene transition quickly? Does a later line seem to remember the earlier exchange? Record the difference only after it appears on screen.

Save at sensible pauses if the interface offers saving. A good first checkpoint is before a choice you already suspect you might revisit; a second is after a substantial scene change. Avoid overwriting the only save you have just before a major decision. Multiple slots let you preserve the emotional continuity of your original run while still exploring alternatives later. If you prefer a fully blind experience, play to the demo's end first and make your first save only when you naturally stop. The game is designed to be read; there is no need to transform every minute into a test.

After your first conclusion, summarize the run in five plain sentences: what the protagonist expected, how the guide behaved, what you chose when you felt uncertain, what the game showed at the end, and what question remained. This is more useful than writing “good ending” or “bad ending” without evidence. The creator confirms multiple endings, but the official listing does not give a definitive route table. Your own ending screen, if the version you play presents one, is the strongest evidence for the result of your particular run.

One reason to take a first run slowly is that dramatic genre labels can bias interpretation. The official listing tags the game as psychological horror and romance, among other categories, and describes obsession and uncovered truths. A tag sets expectations; it does not tell you which individual line is honest or what a future chapter will reveal. Let the demo establish its own pace. Hold a question open if the scene has not answered it. The feeling of not knowing is part of the reading experience.

Chapter 03

How to read a choice without guessing hidden mechanics

A dialogue option can do several things at once. It can express the protagonist's immediate mood, invite a reply, change the next line, alter a later scene, or contribute to a larger pattern that affects an ending. The creator confirms that decisions shape the protagonist's mindset and how the truth unravels. That statement is broad. It does not identify a particular option as a guaranteed ending trigger. Read choices first as language, then investigate their mechanical effect through comparison.

Begin by comparing the verbs. One option might ask, another might accuse, and a third might withdraw. Even if all three eventually reach the same location, they can create very different readings of the relationship. Pay attention to who has the initiative. Does the protagonist invite the guide to explain, demand an answer, or avoid the subject? A game about expectations can make these differences meaningful without announcing a visible meter. The point is not to reward one tone universally. It is to notice the tone you selected and the response it made possible.

Next compare the assumptions inside each option. “Why did you ignore me?” assumes intent. “Did you hear me?” leaves more possibilities open. If a game offers options with this sort of contrast, the wording itself tells you something about the protagonist's available interpretations. You can use this as a reading method even when the exact phrases differ from these examples. The examples here illustrate the method; they are not quoted choices from the demo. Do not look for them as exact menu text.

After selecting an option, look for evidence at three distances. The immediate response may change in the next line. A local consequence may appear later in the same scene. A wider consequence may be visible only after another decision or at the conclusion. Write down the earliest observable effect. If you reload and choose an alternative, compare the same stretch of text under similar conditions. A change in background music, portrait, or pacing may matter to the atmosphere, but distinguish that from a confirmed route change. Some differences are expressive; others are structural.

A useful comparison note has four fields: the scene, the question you were answering, the option you picked, and the next difference you observed. Add a fifth field for uncertainty. For example: “Outdoor dialogue; I wanted a direct answer; chose the more confrontational option; the next response sounded guarded; unknown whether this affects an ending.” This keeps the record readable. It also prevents the common error of publishing a precise walkthrough from one untested playthrough.

Do not infer a numerical “affection,” “sanity,” or “trust” score merely because other visual novels use them. The official description speaks of a protagonist's mindset, not a named stat with public thresholds. A route chart becomes trustworthy when it is supported by the game's own script, a developer explanation, or repeated controlled play. Until then, describe patterns in ordinary language. “These choices consistently produced a more guarded exchange in my runs” is better than “pick option two for +2 trust” if you have not verified a value.

Chapter 04

A replay plan that actually teaches you something

Once you have a baseline run, change one question at a time. Replaying every scene with a completely different personality may reach a different ending, but it rarely tells you which decision mattered. Start from a save before a meaningful choice. Keep the rest of the route the same as far as possible. Select the alternative response, then follow the game until the paths either diverge visibly or reconnect. A reconnection does not prove the earlier choice was irrelevant; it may still affect later narration. It tells you only that the immediate scene converged.

Keep a short route label for each experiment. “First run: curious and patient.” “Second run: same choices except the outdoor question.” “Third run: same opening, more guarded replies.” Labels help you remember what changed without claiming that the game has formal route names. If you reach an ending screen, record its actual text exactly in a private note. If the screen uses an image rather than words, describe what is visibly there. You can then compare the result with another run without retroactively rewriting your memory.

Save before branch points, after a scene you have tested, and near the latest point you can safely return to. Use different slots for these roles. A “before” save supports controlled comparisons. An “after” save lets you continue a successful run. A “late” save reduces repetitive reading when you are exploring the end of the demo. If the game offers a history or backlog, it can help you reread wording you missed, but a backlog does not replace a save because it does not necessarily change a decision already made.

When you compare two runs, hold the starting conditions steady. Use the same version of the game. Load from the same save if possible. Pick the same pronouns if you are checking line-level differences, so presentation changes do not distract from the dialogue you are studying. Do not clear browser storage or reinstall between comparison runs unless troubleshooting requires it. These simple controls make your notes more reliable.

If the result does not change, try a cluster of related choices rather than randomly toggling everything. The story centers on the guide's distance and the protagonist's attempts to understand it. A cluster might reflect how directly you ask for an explanation, how much you accept silence, or how you respond when a scene feels ambiguous. These are reading categories for your own experiments, not verified game variables. Run one cluster consistently, then compare it with your baseline. If a branch appears, narrow the cluster to identify the decisive point.

Be patient with delayed effects. Some visual novels let two choices produce the same next scene while changing the protagonist's internal voice later. Others use a choice solely to make the player's interpretation explicit. If you stop comparing after one line, you may miss the meaningful change. At the same time, do not assume every option must have a delayed consequence. A choice can enrich the reading even if it does not change the ending. Record what you see and leave the rest open.

Chapter 05

Exploring the demo's endings responsibly

The creator lists multiple endings as a feature, and the game is still in development. That combination matters. The current demo may let you see more than one conclusion while future chapters and endings remain unfinished. Avoid importing a total ending count from an older comment or another build. Check the Endings menu, if the version you play has one, and compare it with what you have actually unlocked. A visible slot is evidence about the build in front of you. It is not a promise about the final game.

For a clean ending hunt, finish one route before trying to force another. Note the choices that seemed most consequential, then replay from the earliest relevant save. Change one cluster of responses, complete the route, and compare the conclusion. If the ending is unchanged, consider whether the changed responses were cosmetic, whether a later decision overrode them, or whether the difference appears in text rather than in the final label. None of those explanations should be treated as certain until tested.

A compact ending log can include the date, game version if displayed, platform or browser, route label, key choices, final screen, and any issue that might have affected the result. Date matters because an active demo can be updated. Platform matters when troubleshooting saves, although the story should be checked rather than assumed identical across builds. Key choices are the ones you can point to, not a guess about hidden flags. If a branch was reached from an old save after an update, note that too.

When you think you have discovered a route, attempt to reproduce it. A reproducible route begins from a known point and reaches the same conclusion twice. If the game has an ending gallery, check whether the same slot is unlocked. If it does not, compare the final scene itself. The second run helps catch accidental choices you did not record during the first. This is particularly important if you plan to share a route online. A helpful guide should tell another player what was actually tested.

Do not promise an ending based on a vague trait such as “be nice to Zhenya.” The phrase may describe a mood, but it is not a route. A reliable route guide needs exact choices or a verified condition. The current official listing does not provide those details. If you are stuck, the practical next step is to work from your own save, change one group of replies, and observe what happens. The replay plan above gives you a method that works even while published route data is incomplete.

There is value in an incomplete ending notebook. You may find that two playthroughs end the same way but produce different conversations on the journey. That is still a meaningful discovery for a story about perception. You may also discover that a seemingly minor choice opens a distinct scene. Write the result carefully, and keep the emotional reading separate from the structural result. “This run felt colder” and “this run unlocked a new ending” are different conclusions.

Chapter 06

Reading the story: expectation, silence, and uncertainty

The official premise is unusually focused: a new university beginning is disrupted when the assigned guide appears to ignore the protagonist. That gives the story two layers from the start. There is an external question about what the guide is doing, and an internal question about how the protagonist understands it. The creator's description emphasizes obsession, expectations, and uncovered truths. You can follow those themes without deciding too early which interpretation is correct.

Start with expectation. The protagonist expects someone to help them navigate a new place. The guide's apparent indifference therefore carries more weight than the same behavior from a stranger. A reader can ask what was promised, what was assumed, and how much of the disappointment comes from the contrast between those two things. The game may offer later information that changes your answer. Until then, keep the expectation visible. It explains why an ordinary silence can feel personal.

Next consider isolation. A university setting can be crowded, yet a newcomer may feel alone when the one designated point of contact does not respond. The creator's description highlights uncertainty and isolation. Watch how the background, colors, and pacing support that feeling. The cool blue city image, the outdoor choice screen, and the interior scenes shown in the official artwork establish a visual mood. An image can heighten a question without answering it. Do not convert atmosphere into plot evidence.

Notice the protagonist's language around the guide. Is a conclusion framed as knowledge or as suspicion? Is the guide's behavior described through direct observation or through the protagonist's fear? A psychological visual novel can place the player close to a character's mind, making interpretation feel like fact. This closeness is part of the form. Read the words with sympathy while still asking what the scene itself has shown. This approach lets you care about the protagonist without needing an immediate verdict on every other character.

Zhenya appears in the game's art and is central to player discussion of the demo. The page's gallery shows him in several contexts, including a close character image. A portrait offers clues about tone and presentation, not a complete account of motive. It may invite you to feel wary, curious, attracted, or conflicted. Those responses are valid reactions. They are not confirmations of a future plot twist. The most interesting reading may come from comparing how your first impression changes after the same line is delivered in a new context.

Psychological tension often works through mismatched information. A character may know more than the protagonist; the protagonist may know more than the player; the player may notice a visual detail neither character discusses. When this happens, annotate the source of each belief. You might write, “The protagonist thinks he is avoiding them,” “He says he did not see them,” and “The scene shows a pause before his reply.” The exact content will depend on your playthrough, but the method prevents a single interpretation from swallowing the scene.

There is no need to solve the entire mystery within a demo. The official page says more chapters are planned. A good reading of an unfinished chapter can identify its central questions and the evidence currently available. Ask what the demo tells you about the university setting, what it tells you about the relationship, and what it deliberately leaves unresolved. A gap is not automatically a plot hole. It may be the reason to return when the creator releases more of the story.

On a replay, look for moments that changed meaning after you knew the outcome of your first run. An early pause might seem awkward the first time and ominous the second. A line that sounded dismissive might become ambiguous. Write down the two readings separately. Avoid claiming that the later reading is automatically the “real” one. In a story built around interpretation, the friction between readings can be the point.

Finally, remember that a guide can support a literary reading without spoiling it. Use the route sections when you want to test an ending. Use this story section when you want to think through why a scene affected you. Both kinds of reading are valuable. The former asks what your choices changed; the latter asks what those changes meant to you. Neither requires pretending that the demo has revealed more than it has.

Chapter 07

Six original game images

The images below are from the game's original art and scenes already used by this site. Five show game screens; the sixth is original character artwork. They are presented as visual reference, not as evidence of a specific ending. Captions describe what is visible and avoid invented plot claims.

Original game art by Vhan || 반. See the creator's page for the game and current release notes.

Chapter 08

Technical help for browser and downloaded play

If the embedded player does not start, first confirm that you pressed its Play button. The site delays loading the game until you ask for it. Then wait for the game's own progress display. If it remains blank, open the direct hosted tab from beneath the player. This separates an iframe problem from a problem with the game build itself. If the direct tab also fails, try the platform download on the creator's itch.io page. The official listing currently offers Windows, macOS, Linux, and Android files; always check the listing for the latest version.

If text or buttons are difficult to read in the embedded frame, use the Fullscreen button below it. Escape usually returns you to the page. If fullscreen is blocked by your browser, the direct game tab may give the interface more room. On a phone, rotating to landscape can help when the visual novel interface was designed for a wider display. A cramped interface is not a story branch; change the display before making a choice you cannot read fully.

For save trouble, start with the simple distinction between local browser data and downloaded game files. A save made in one browser or on one device should not be assumed to appear in another. A private browsing session may also behave differently from a regular one. If you plan to hunt endings over several days, use a stable browser profile and avoid clearing site data until you have finished. For the downloadable build, use the game's own save and load interface rather than moving files unless the creator provides platform-specific instructions.

If you think a scene has frozen, check whether the game is waiting for a dialogue click, a choice, or a loading step. Try one ordinary click or tap on the game area. Avoid rapidly clicking through a delayed response: doing so can skip text as soon as the interface becomes active. If the issue persists, note the device, browser or platform, where the freeze occurred, and whether it happens again from the same save. That information is more useful to a developer than “the game is broken.” The official page links to the creator's contact page for reports.

Chapter 09

Frequently asked questions

Chapter 10

Sources, version notes, and what is still unknown

The main source is Vhan's official U DON'T GET IT page. It supports the premise, creator credit, demo and development status, available downloads, dialogue choices, multiple endings, and pronoun selection. The six images are existing local assets from the original game and creator artwork. Browser-player details come from this site's own current implementation. The replay methods are editorial advice, not claims about hidden code.

We have not verified an exact route chart, ending names, a complete number of future endings, or hidden numerical choice thresholds from the game script. We will not fill those gaps with guesses. If you have a reproducible route, keep the game version, starting save, exact decisions, and ending screen together. That evidence makes a future update useful to other players.

Last editorial review: November 4, 2026. This is an unofficial fan guide. U DON'T GET IT and its artwork belong to Vhan || 반.

Chapter 11

A scene-by-scene reading field guide

Before the first decision

The opening of a visual novel does more than set a location. It teaches you how the story expects to be read. Before the first interactive option, look at the relationship between the text and the image. Does the narration describe the setting as welcoming, indifferent, or threatening? Does the color palette support that description or complicate it? Does the music settle into a steady loop or create an uneasy interruption? These questions are useful because the game's central premise involves a difference between what was expected and what is experienced. You do not need to solve anything yet. You are building a baseline against which later scenes can be compared.

One way to keep this baseline is to write a single phrase in your own words. “New campus, uncertain welcome” is enough. Do not write a page of predictions before the game has shown its first exchange. Predictions can be enjoyable, but they can also make you search only for evidence that supports them. A phrase that describes the present moment will be easier to revisit after you have seen another scene. If you later discover that your first impression was mistaken, the original note will show how the story produced that mistake.

When the assigned guide appears

The premise says the assigned guide seems to ignore the protagonist. Treat “seems” as an important word. A player's first task is to identify what is visible. Did the guide look toward the protagonist? Was there a direct introduction? Was the protagonist waiting for an explanation? What did the environment make it possible for either character to notice? The official description frames the guide's behavior as a source of uncertainty. It does not tell you the hidden cause. A guide that supplies a cause at this stage would replace the game's question with speculation.

Pay close attention to sequence. In one scene, the protagonist may think something before another character speaks. In another, a spoken line may prompt a private reaction. These are different orders of information. If you want to analyze the exchange later, write “thought before reply” or “reply before thought.” This small distinction helps you see whether the protagonist is responding to a fact or preparing an interpretation in advance. It also helps you locate the exact moment when a choice changes the emotional direction of the conversation.

At the first dialogue menu

Pause before clicking. Read each option as a complete sentence. If two options are short, imagine the implied tone: is one asking for information while the other seeks acknowledgment? If one option is longer, check whether it includes an assumption that the shorter option avoids. Choose the one you want, not the one you think a walkthrough would reward. This first choice sets the tone of your run even if it does not permanently separate two branches. The creator says choices shape the protagonist's mindset, so the meaning of a reply matters apart from its eventual ending label.

After choosing, avoid immediately reloading. Let the response play out until the next clear pause. Sometimes the important consequence is the character's first line. Sometimes it is the protagonist's description of that line. Sometimes there is no visible difference until a later scene. For the first run, you only need to notice the immediate reaction. For the second run, compare the alternative. If you have a backlog or history screen, use it to reread exact wording. A remembered paraphrase often exaggerates a character's certainty or softens a refusal, so checking the text can change your interpretation.

At a change of location

A location change is a natural checkpoint. Save if the game allows it, then ask what changed besides the background. Is the protagonist alone now? Has a question been answered or merely postponed? Did the conversation move from public space to a private setting? The answer may shape how you read the next scene. A city view can make a personal problem feel small against a larger world; an interior can make the same problem feel inescapable. This is an interpretive possibility, not a statement that every image has a coded symbolic meaning. Let the actual scene guide the reading.

Notice whether the game presents a transition as an event or as a jump in time. If a jump occurs, do not invent what happened in the gap. Write down the gap itself. “The scene moves to a computer without showing the walk there” is useful. “The protagonist must have followed Zhenya” is only justified if the text says so. In a mystery, omitted movement can be ordinary compression or a deliberate absence. Keeping both possibilities open is more productive than choosing one too early.

At a visually striking image

The camera image and the dark computer scene are striking examples from the site's gallery. Study what is actually visible: a character's position, the object in the frame, the lighting, and the surrounding space. Then ask what the scene's text adds. The object may be part of an action, a memory, or simply the composition. A screenshot alone does not establish which. If you saw the image outside the game before playing, be aware that promotional imagery can change your expectations. Return to the in-game context and let the adjacent dialogue determine its role.

It can help to separate description from reaction in two columns. In one column, write “the screen shows a computer in a dark room.” In the other, write “this made me expect a secret.” The first is evidence; the second is your response. Neither is disposable. The response tells you how the game affected you. The description tells you what another player could independently check. When a later scene changes your mind, you can preserve both records instead of pretending the earlier reaction never happened.

When an answer sounds incomplete

A partial answer can be more informative than a complete one. Ask what was asked, what was answered, and what remained untouched. A reply may be literally true but address only one part of a question. Another reply may offer emotion instead of information. If the protagonist accepts or rejects it, that response tells you something about their current mindset. Avoid calling a character dishonest solely because the answer feels unsatisfying. Discomfort is a signal to examine the exchange more closely, not a verdict.

Try a short transcript method if you are taking detailed notes. Copy only the smallest phrase needed to anchor the exchange in your private notebook, then paraphrase the rest. Write the question's purpose, the reply's substance, and your uncertainty. This keeps your notes focused on decision making and avoids turning the entire game script into a duplicate document. It also makes a later comparison easier: you can see whether a different choice produced new information or only changed the delivery of the same information.

At the end of a scene

Before moving on, ask whether the scene resolved its own immediate question. An early scene may simply establish that the guide is distant. A later scene may ask why. Still another may challenge the protagonist's first explanation. These are different achievements. If the scene leaves you with a new question, note it in one sentence. A good question is specific enough to test later: “Does he respond differently when directly addressed?” is more useful than “What is going on?” The question can guide your replay without becoming a claim about how the game works.

Scene endings are also good places to check emotional continuity. Did your chosen response feel consistent with what you selected earlier? If not, that tension may be an intentional part of the protagonist's development or a sign that your choices are pulling in different directions. You do not need to correct it. A conflicted run can be interesting. If your goal is route discovery, however, note the conflict so you do not later summarize the playthrough as uniformly “patient” or “confrontational” when it was neither.

At the demo's stopping point

A demo can end with an ending, a chapter break, or a preview of what comes next. Identify which the build actually presents. If there is an ending name, record it. If there is a gallery slot, check whether it changed. If there is only a stopping message, describe that instead of assigning a route title yourself. The official creator page promises more development, so some threads may be deliberately unresolved. An open question at the demo boundary is not evidence that you missed a hidden choice.

After closing the game, look at the notes you wrote before the first decision. Which expectations were confirmed? Which were complicated? Which remain untested? This is a better debrief than simply judging whether you “won.” A psychological visual novel may reward attention to a changing interpretation, even when the mechanical outcome is the same. Your first run gives you a personal reading. Your next run can become an experiment.

Chapter 12

Build a branch map from evidence

Begin with a question, not a theory

A branch map is a record of what you can make the game do from a known starting point. It is not a diagram of all the code you imagine might exist. Start with a narrow question such as, “Does this dialogue option change the next exchange?” or “Can I reach a different conclusion while keeping the opening choices fixed?” The narrower question tells you what to compare. It also gives you a stopping point. If the next exchange changes, you have answered the first question even if you do not yet know whether the ending changes.

Define the start of the experiment clearly. A save just before a menu is ideal because it keeps earlier choices constant. If you cannot save there, note the choices required to reach the menu from the beginning. A branch map that lacks a starting state can be misleading. Two players may choose the same visible reply and see different later text because they arrived with different histories. This is a general risk in choice-driven stories; the official page does not disclose whether this demo uses persistent hidden variables at every menu. Your method should remain sound either way.

Give each observation a name

Use plain labels that describe scenes, not conclusions. “Outdoor question A” and “Outdoor question B” are better working names than “true route” and “false route.” If a choice leads to an apparently warm reply, you can call the observation “warm reply,” but keep it separate from the option's identity. A label should help you find a scene later, not announce a theory as fact. When the game supplies an official scene or ending name, use that name exactly. Otherwise, make your own labels visibly provisional.

A map can be drawn as a table. Put the starting save in the first column, the chosen response in the second, the next visible difference in the third, and the final result in the fourth. Add a question mark wherever the result has not been tested. This may look less impressive than a branching tree filled with arrows, but it is more honest. An empty cell tells you what to try next. A tree with invented connections can send you on a long search for a path that was never there.

Distinguish local and global branches

A local branch changes a line or short exchange and then returns to shared material. A global branch produces a longer sequence, a distinct scene, or a different conclusion. Both are worth documenting, but they answer different player questions. If someone asks how to unlock an ending, a local wording change may not help. If someone asks why a character responded coldly, that same local change may be exactly the answer. Keep the two scales visible in your notes.

Do not decide the scale too soon. Two responses can converge after one exchange and diverge much later. Conversely, an elaborate immediate difference can still lead to the same final screen. When you first test a choice, record “local difference observed; later effect unknown.” Then complete a controlled run before upgrading the claim. This wording may feel cautious, but it makes the guide trustworthy. A player can tell what you observed and what remains to be checked.

Revisit the same choice under a different history

Once you understand a choice from one save, ask whether it behaves the same after earlier decisions change. This is a second-stage experiment. It requires more work because you must replay the path to the choice. Change one earlier cluster while keeping the later test option fixed. Compare the immediate reply and final result. If they change, the later choice depends on context or some earlier state. If they do not, you have evidence of stability under the two histories you tested. Neither outcome proves a universal rule across every possible run.

For a game whose creator says choices shape the protagonist's mindset, this contextual test is particularly useful. A line spoken after several guarded responses may read differently from the same line after several curious ones, even if its wording is identical. The difference may live in your understanding rather than in the script. That is why a branch map should include a short reading note alongside mechanical observations. It can preserve the story's texture without confusing subjective interpretation with route conditions.

Use a minimal decision tree

When you have enough tested observations, draw only the branches you can reproduce. Begin at the opening setup, place a node at each choice you tested, and draw an arrow to the next observed state. A state can be a scene, a changed line, or an ending screen. Mark untested arrows with a question mark. If several options converge, draw them together. If you are unsure whether they truly converge, write “same scene reached” instead of “same state.” Hidden changes may remain invisible until later.

A good map can fit on one screen. If yours becomes unreadable, divide it into an opening map, a middle map, and an ending map. Link them through named checkpoints. This makes the guide usable for a player who wants to solve one problem. It also makes updates easier when the demo changes. If a new version alters the middle, you can revise that segment without pretending the old map still applies to every scene.

Handle an apparent contradiction

Suppose you followed what you believed was the same route twice but got different results. Before inventing a random chance system, compare the recorded conditions. Did you load from the same save? Did you choose the same option after the last checkpoint? Did the game update between runs? Did you skip a menu because you remembered it as unimportant? A contradiction often reveals an unrecorded difference. If you cannot explain it, mark the route as unconfirmed and preserve both observations.

The same discipline applies if another player's report conflicts with yours. Ask for their version, platform, starting point, exact choices, and final screen. Do not dismiss the report, and do not merge it into your map without a test. A screenshot of an ending proves that the ending appeared, but not necessarily which preceding choice caused it. Respect both kinds of evidence: the final image and the reproducible path that leads there.

Write a route instruction only after reproduction

Once a path works twice from the same starting state, write instructions in chronological order. Use the exact choice text where you can lawfully and reasonably quote a short option, or describe the option by its meaning if wording varies with pronouns or updates. State which version you tested. Include a fallback checkpoint: “Save before the outdoor conversation” is more useful than “restart the entire game if this fails.” Explain whether the route reached a unique ending or only a distinct scene. That distinction sets the player's expectation correctly.

Do not claim uniqueness without testing alternatives. If you found one reliable path, say “one verified path.” The creator's own official page confirms multiple endings but does not state that every ending has exactly one route. A successful run proves reachability; it does not prove that no other choices work. This is the difference between a helpful walkthrough and a brittle checklist. The former gives players a dependable method while leaving room for the game to be richer than one sequence of clicks.

Keep the map current

When a demo is in active development, a route chart is a snapshot. Put the version and review date near the chart. If the game changes, test the most important path from a clean start before changing the date. A new release may alter writing without changing route logic, or it may add a chapter that changes what counts as an ending. Both matter. A reader should be able to tell whether a guide describes the exact build they opened today.

If a route stops working, retain the old note in a private archive and label it with its old version. Remove or revise the public instruction after verification. Avoid silently rewriting history: an older player may still have that build, and their report can help identify when the behavior changed. The archive does not need to clutter the page; a concise version note is enough. The goal is to make each public instruction actionable in the current release.

Chapter 13

The language of a choice: a close-reading workshop

Many walkthroughs reduce a visual novel to a list of buttons. That can be useful once exact routes are known, but it misses why a choice feels meaningful. In U DON'T GET IT, the creator describes a story driven by uncertainty and by the protagonist's attempts to uncover the truth. The wording of a reply therefore matters before you know its mechanical consequence. This workshop gives you a way to read choices closely without inventing the demo's unseen logic. The example lines below are made-up teaching examples, not dialogue quoted from the game.

Look for the action inside the sentence

Imagine three possible replies to a distant guide: “Can you explain what happened?”, “You owe me an explanation,” and “Forget it.” They all respond to the same silence, yet each performs a different action. The first asks; the second demands; the third withdraws. If you are deciding how your protagonist will respond, identify the action rather than trying to guess which answer has the most favorable outcome. A demand may be appropriate to a player who feels wronged. A question may fit a player who wants information. Withdrawal may express self-protection rather than weakness.

After selecting a reply, see whether the game's next line answers the action you performed. Did the other character explain, resist a demand, or allow the withdrawal? If the answer does not match, that mismatch can be revealing. A character may hear a question as an accusation, or the protagonist may interpret a neutral response as rejection. Record the mismatch as a feature of the exchange. Do not immediately assign it to a hidden affection score.

Identify implied facts

Some choices carry facts that have not been proven. “Why are you lying?” presumes a lie. “Is that the whole story?” leaves room for omission, confusion, or a partial answer. If the game offers such a contrast, choosing one option commits the protagonist to a stronger interpretation. The resulting scene may be interesting even if the accusation is premature. What matters for analysis is that a strong claim can change the social stakes of the conversation. A reply may become defensive because of the accusation, not because the underlying mystery has been solved.

You can mark implied facts in your notes with the word “assumes.” For example, “This option assumes he saw me earlier.” Then write whether the scene had already established that fact. If it had, the option is a direct challenge. If it had not, the option exposes the protagonist's suspicion. The distinction is easy to lose when you are emotionally involved, which is precisely why it is valuable to pause at a dialogue menu.

Notice the scale of the question

A reply can ask about the immediate moment, the relationship, or the whole mystery. “Did you hear me?” concerns the last few seconds. “Why do you avoid me?” asks about a pattern. “What are you hiding?” reaches toward a larger explanation. The three questions might be appropriate at different stages. If you choose a large question early, a partial answer may feel evasive simply because the speaker cannot or will not address everything at once. If you choose a small question late, you may miss an opportunity to challenge a pattern that has become clear.

When replaying, compare options of different scale. Does the small question produce a practical fact? Does the larger one create tension? Does either reveal new context? The answer depends on the game, and you should observe it rather than assume it. The method helps you understand why two choices can both be reasonable while producing different kinds of information.

Read silence as an event, but not as proof

Silence is powerful in a story about an apparently indifferent guide. It can indicate refusal, uncertainty, distraction, fear, or simply a pause before speech. A player may be tempted to treat every delay as evidence of a secret. Slow down. Look for the text and visual framing around the silence. Does the protagonist describe it? Does another character react? Is the pause accompanied by a change in music or image? These details can help you understand how the game wants the silence to feel, though they still may not reveal its cause.

On a replay, test how your response to silence changes the next exchange. A direct question may prompt speech; a softer reply may let the pause continue; withdrawal may end the conversation. If you observe such differences, write them as local effects. You can later ask whether they accumulate into a different route. The first test is about what the scene visibly does.

Separate intent from impact

The protagonist may intend a line as curiosity while another character receives it as pressure. The reverse can happen too: a defensive reply may be heard as honesty. If the next response surprises you, do not immediately conclude that the game's writing is inconsistent. Ask whether the characters have different information, expectations, or emotional stakes. A visual novel can use that mismatch to make a relationship feel unstable. The creator's emphasis on expectations makes this a particularly productive question to keep in mind.

For your route log, record your intention and the observed impact in separate phrases. “I chose this to ask for clarity; the guide reacted as if accused.” That note tells you much more than “bad choice.” It also helps you revisit the scene with a different option later. Perhaps a more direct accusation produces the same reaction; perhaps a gentler question changes it. Either outcome teaches you about the conversation.

Test whether an option is about information or self-expression

Some dialogue choices exist to gather facts. Others let you decide who the protagonist is in that moment. A reply such as “I am frightened” may not ask a question at all. Its purpose can be to expose vulnerability. If the response does not reveal new plot information, that does not make the choice meaningless. It may change the protagonist's self-understanding or the emotional texture of the scene. The official listing says choices shape mindset, so emotional expression belongs in the analysis.

When comparing outcomes, use two questions: “What did I learn about the external situation?” and “What did I learn about the protagonist?” If only the second changes, you have still found a meaningful local difference. A purely mechanical walkthrough would miss it. A strong guide can report both, as long as it does not pretend that a changed feeling automatically means a changed ending.

Beware of false binaries

Two options can look like opposites while sharing an underlying assumption. “Confront him now” and “wait to confront him later” both presume confrontation is necessary. A third option, if offered, may question the premise. Read the full menu before deciding that the first two define the scene. Likewise, a gentle and a harsh reply may both seek the same answer. The choice may be about manner rather than goal. Finding the actual axis of difference is more useful than labeling each button “good” or “bad.”

If you are mapping the menu, write the question each option answers. One might answer “How urgently should I press this?” Another might answer “Do I believe the guide?” A menu with several axes is harder to summarize, but it also offers richer role playing. Do not force it into one moral scale. The demo's story may ask you to live with ambiguity rather than select a universally correct personality.

Use pronouns as part of the reading, not a route superstition

The creator includes customizable pronouns. This choice can make the narration feel closer to you or better fit the character you want to play. It may change grammatical wording in scenes. Unless the game or creator explicitly says pronouns determine an ending, do not put them in a route chart as a required condition. If you compare two runs line by line, hold pronouns constant to avoid confusing grammatical changes with branch changes. If you want to experience the story with a different set, make that a separate reading goal.

This distinction is respectful to both the feature and the player. Pronoun selection is part of how the story addresses you. It deserves attention for that reason alone. Treating it as an unverified secret switch would turn an inclusive presentation choice into a rumor. The better guide tells players where to find the setup and lets them choose freely.

Return to your original intention after an ending

At the conclusion of a run, reread the choices you made in light of your original intention. Did you set out to be curious and become suspicious? Did you plan to be guarded but select an open reply at a crucial moment? The changing pattern can explain why the story felt different from what you expected. It may also reveal a practical route question: perhaps a single late choice contradicted the earlier pattern. Test that choice from a save before deciding it caused the outcome.

This workshop has no magic answer key because the official page does not provide one. Its value is in helping you read precisely. A precise reading can improve both your enjoyment and your experiments. It lets you say what a choice meant to you, what it visibly changed, and what remains unknown. Those three statements are enough to begin a reliable guide.

Chapter 14

Ten controlled experiments for a second playthrough

The experiments in this chapter are methods, not promises that a named route exists. Each begins with a question you can test in the version you are playing. Use your first-run save when possible, and keep a short record of what you observe. If an experiment cannot be performed because your build does not offer the relevant choice or interface, skip it. The point is to give your next run a purpose while protecting the story from unsupported claims.

Experiment 1: Change only the first reply you can control

Load a save just before the first dialogue menu or start a fresh run and repeat the same setup. Choose a different reply, then read until the next decision. Compare the immediate wording, portraits, and narration with your baseline. Does the other character respond differently? Does the protagonist describe the interaction differently? If nothing changes, continue one scene further before deciding that the option is cosmetic. Write the earliest difference, not the most dramatic theory you can imagine. This experiment teaches you the difference between a visible local branch and a possible delayed effect.

Experiment 2: Keep the reply, change the approach to a later question

Choose the same early option as in your first run, then change how you address a later uncertainty. Perhaps you ask more directly, or perhaps you leave a question open if the game offers that option. Do not assume either is more favorable. Compare the next exchange and the protagonist's internal response. The contrast can reveal whether the scene is sensitive to tone, to information seeking, or simply to a fixed story beat. If the later dialogue differs, note whether it references the choice itself or the broader history of your run.

Experiment 3: Follow one consistent emotional stance

For one complete run, choose responses that express the same broad attitude whenever the menu allows it. You might play a curious protagonist who asks rather than assumes, or a guarded protagonist who protects their own boundaries. Do not force a choice into your plan when it clearly means something else; note the exception. At the end, describe the run in your own words and compare it with the first. This experiment tests whether a pattern feels different to read and whether the final result changes. It does not establish a named stat or route threshold.

Experiment 4: Reverse a stance at one turning point

Begin with a consistent stance, then deliberately change it at one later choice. Record why that moment felt like a turning point. Does the game acknowledge the change? Does the protagonist's narration seem to support it, resist it, or ignore it? Complete the run and compare the conclusion with a version where you maintained the original stance. This can reveal whether the story treats a late decision as decisive or whether earlier choices continue to matter. If both runs end alike, the contrast may still change the emotional meaning of the scene.

Experiment 5: Compare asking for facts with seeking reassurance

At a menu where two options seem to differ in purpose, identify one that asks what happened and another that asks how the other person feels. If your build offers such a contrast, test both from the same save. A factual question may produce information without warmth. A request for reassurance may change the relationship without explaining the mystery. Those are possibilities to examine, not predictions about the demo. Write what the scene actually provides in each case. This experiment is particularly useful in a premise where a guide's apparent indifference creates both practical and emotional uncertainty.

Experiment 6: Follow a visual clue without treating it as a code

Choose one image that stayed in your mind: the city, an outdoor choice, the camera, or the computer screen shown in this site's gallery. Revisit the scene and read the text immediately before and after the image appears. Note whether the image introduces an action, emphasizes a mood, or creates a question. Then replay the nearest relevant choice. Does the image change? Does its context change while the image stays the same? An unchanged picture can still feel different when the dialogue around it shifts. This experiment gives you a disciplined way to discuss visual storytelling without claiming that every prop is a secret puzzle.

Experiment 7: Test a suspected branch over a longer span

If two replies appear to converge after a few lines, continue both paths until the next substantial scene transition or the demo's conclusion. Use the same save and keep all subsequent choices equal where possible. Record whether a later line recalls the earlier decision. If it does, you have found delayed recognition. If it does not, you have only shown that no difference appeared in the span you tested. Resist the word “irrelevant” until you know the ending and have checked the parts of the story where that choice might matter.

Experiment 8: Reproduce a result from a clean start

When you reach an ending or a distinctive concluding scene, write down the path as best you can. Then start again without loading a late save and follow the same path. Check whether the same final screen appears. A clean reproduction can reveal an accidental choice that your late save had already fixed. If the result changes, compare the two runs before drawing any conclusion. If it matches, your route note becomes stronger, though it still describes one successful path rather than every possible path to that result.

Experiment 9: Check whether a setting changes only presentation

Pronoun selection is a verified feature. If you are interested in how the story addresses the protagonist, play a short scene with one selection and repeat it with another. Keep dialogue choices equal. Compare grammatical wording and your experience of the scene. Do not automatically treat every textual difference as a route branch. A presentation feature can matter deeply to the reader while leaving the plot structure unchanged. If you find a structural difference, document it carefully, but do not start from the assumption that one must exist.

Experiment 10: Audit your own assumptions

Before a replay, write three claims you believe about the guide, the protagonist, or the story's mystery. Label each as directly shown, said by a character, or inferred by you. Then replay a scene related to one claim. Look for evidence that supports and challenges it. A line you overlooked may complicate your first interpretation. This experiment does not seek a different ending. It seeks a more accurate reading. In a psychological visual novel, changing how you understand an unchanged scene can be as valuable as unlocking a new branch.

How to record the results

Use one small table per experiment. Include the starting save, the changed choice, the same choices you held fixed, the first visible difference, the final result, and your remaining question. “No difference seen” is a valid result if you state how far you played. Do not delete failed experiments. They rule out simple explanations and help you avoid retesting the same idea later. If you share a finding, include enough context for another player to reproduce it without forcing them to read your entire diary.

These ten tests can be done in any order after a first run. You do not need to complete all of them to enjoy the demo. Choose the one that matches a question you genuinely have. A route hunt becomes more satisfying when it grows from curiosity about a specific scene rather than a demand to click every possible combination. The creator's story is still developing, and a careful method will remain useful even if later versions add or alter branches.

Chapter 15

Save planning for a branching demo

A save is more than a way to avoid rereading. It is a controlled starting point for a question about the story. If you want to explore endings, your saves should tell you where you can return and what you already chose. If you want to preserve a first impression, your saves should protect the continuity of that run. Both aims are legitimate. The most useful plan is simple enough that you will actually follow it while reading.

The three-slot pattern

Use one slot for your current uninterrupted run, one for the most recent choice you want to compare, and one for a major earlier checkpoint. The uninterrupted slot is your safety net. The comparison slot saves you from replaying a long section just to test one reply. The earlier checkpoint lets you change a broader pattern of choices if the local experiment does not explain the ending. You can use more slots if the interface offers them, but giving three clear jobs to the first three prevents a page of anonymous saves from becoming its own puzzle.

Name or note each checkpoint outside the game if the save interface does not support labels. A short note such as “before outdoor choice, first run” is enough. Include the version if the game shows it and you expect to return after an update. Screenshots of save thumbnails can help, but write the text too; a similar-looking background can appear in more than one scene. Do not rely on memory for a choice you made several days ago. The point of a checkpoint is to reduce uncertainty, not to preserve it.

When to save

Save before a choice that changes the purpose or tone of a conversation. Save after you have completed a comparison and want to continue that branch. Save before ending the session if you have not reached a natural conclusion. Avoid saving over your only clean checkpoint immediately after selecting a new option; you may want to test the other one. If a menu appears after a long sequence, a fresh “before” save is especially valuable because it gives you a quick way back to the exact question you care about.

Not every dialogue menu requires a permanent slot. If you save at every line, the slot list may become harder to navigate than the story. Favor decisions you can describe in a sentence: the first direct question, a notable response to the guide's distance, a scene where the protagonist's attitude seems to turn, or a menu just before a conclusion. These are examples of useful categories, not a claim that the demo has precisely four fixed branch points.

How to test from a save

Load the checkpoint and confirm you are at the expected scene. Pick one option and play until the next stable point. Record the result. Load the same checkpoint again, pick the alternative, and compare the same span. If later choices appear on only one path, note that the paths have diverged rather than forcing them into a line-by-line comparison. If the paths reconnect, continue a little further to see whether the earlier choice is acknowledged. The checkpoint makes this method efficient because every comparison starts from the same known history.

Do not confuse a save thumbnail with proof of route state. A thumbnail shows what was on screen when the save was made; it may not reveal prior choices. Your written label supplies the missing context. A late save can be useful for quickly replaying an ending, but it may be poor evidence for which early choice caused that ending. When writing a public route, begin from an earlier checkpoint or from a fresh run and record the whole path.

Browser and download saves

The browser player on this site runs from a hosted game address, while the creator also distributes downloadable builds. These are different environments. A browser save may depend on local browser storage for the hosted address. A download may use the game's own local save location. Do not assume that a slot in one environment automatically appears in the other. If continuity matters to you, choose one environment for your ending hunt and keep using it until you finish. If you later switch, treat the new environment as a new playthrough unless the creator provides an official transfer method.

Within browser play, keep the same browser profile and avoid clearing the hosted game's site data while relying on its saves. A private window can have different storage behavior. Browser extensions and privacy settings may also affect what persists. We have not verified an export feature for this specific hosted build, so do not promise an automatic backup. The safest user-facing advice is to make notes of important choices and treat local saves as convenient but not guaranteed portable. If you need a durable record of an ending, record the ending text and route separately from the save slot.

Recovering from a mistaken overwrite

If you overwrite a checkpoint, first check whether another slot or an auto save exists in the game's interface. Do not assume it does; simply inspect what the version you are playing offers. If you can return to a recent point, reconstruct the missing path from your route notes. If you cannot, decide whether a fresh run is worth the time. For a short demo, replaying may be faster than trying to manipulate files or browser storage without knowing the build's save format.

An overwrite can also teach you to simplify the plan. Perhaps the “current run” slot and the “before choice” slot had similar names. Rename your external notes or assign fixed slot numbers. The goal is to make the next action obvious when you are immersed in the story. A route system that requires a separate map just to understand your save menu will not help you read attentively.

Version changes and old checkpoints

A developing game may receive updates. An old save might load, fail, or produce a path that no longer matches the revised story. The official page reports the release as in development, so check its update notes before interpreting a surprising result. If a route behaves differently after an update, test from a new start before declaring that the choice logic changed. Old saves can carry earlier state or skip newly added setup. Keep your old notes with a date; they may be accurate for the version you played at the time.

When writing about a result, say “observed in the version I played” if you do not know the build number. That phrase is more useful than presenting the result as eternal. If you can identify a build number or update date from the menu or download, include it. A reader with another build can then judge how directly your route applies. Version notes are especially important for exact ending instructions, while the broader reading methods in this guide remain useful across revisions.

Respect the emotional value of a first run

It is easy to treat the original save as a disposable baseline once you become interested in route testing. Consider keeping it. It records the choices you made before you knew what any option might lead to. That run may be the most honest record of how the story met you. Even if you later discover a route you prefer, the first save lets you revisit a scene without reconstructing your initial expectations. The practical and emotional reasons to save can support each other.

A good save plan should disappear into the background while you read. Save at deliberate moments, add a short label, then return to the dialogue. When you are ready for an experiment, the checkpoint is there. When you are ready to follow the story without analysis, the checkpoint can wait. The game remains a story first, and the plan exists to help you explore it on your own terms.

Chapter 16

Image atlas: what the six pictures can and cannot tell you

Images are often the first part of a visual novel a player sees. A screenshot can suggest mood, setting, and character design before the accompanying dialogue provides context. The six original game images in this guide are useful landmarks, but they are not a substitute for playing their scenes. This atlas explains how to use each image while keeping observation separate from interpretation. It does not assign an ending to an image or claim a screenshot proves a secret route.

The title screen

The title image introduces the game's cool color palette and a close view of Zhenya. A title screen has a special job: it creates an expectation before the story asks you to make a choice. Notice where the character looks, how much space the composition gives him, and how the title sits beside the figure. Then start the game and compare the person you meet in dialogue with the person the menu led you to expect. The difference between promotional framing and in-story behavior can be part of your experience without being a hidden clue.

If the title screen changes after a run or an update, document the visible change and the version. Do not assume it unlocks a route unless the game explicitly connects them. A menu can change for artistic or technical reasons. Conversely, an unchanged menu can acquire a different emotional meaning after you have played. Your interpretation can evolve even when the asset does not.

The blue city scene

The city image places dialogue against an expansive background. It may make the protagonist's personal concern feel exposed within a larger environment, or it may simply establish location and atmosphere. Look at how the text box sits against the skyline. Does the image make the scene feel open, distant, lonely, or calm to you? These are reading responses rather than plot facts. Write your response, then ask which details in the image produced it. A specific description gives another reader something to compare.

During play, read the lines before and after the city image appears. Does it begin a new scene or continue a conversation? Is the protagonist moving, remembering, or waiting? The screenshot by itself cannot answer those questions. If you are building a walkthrough, note the image as a landmark: “after the city view, the next choice appears.” But check the sequence in your build before publishing it. Asset order in a gallery is not guaranteed to match every route's scene order.

The outdoor choice image

This screenshot is especially useful because it visibly shows the interactive form: a scene with selectable dialogue. It reminds you that a choice happens within a visual and emotional context. Before clicking, read the background and the preceding line. A response that sounds reasonable in isolation may sound more defensive after a tense exchange. The game is not a quiz whose choices can always be judged from one sentence. Context is part of the answer you give.

For route experiments, the image can help you recognize the correct checkpoint. If your save thumbnail resembles the outdoor scene, verify the exact dialogue before comparing choices. Similar backgrounds may recur. Record the prompt or preceding line in your private notes, along with the chosen response. A screenshot of the menu can document that an option existed in one version, but it does not by itself document what happened after the click. Pair visual evidence with an outcome note.

The camera scene

A character holding a camera invites questions about watching, recording, memory, or simply the activity at hand. Do not leap from the presence of an object to a hidden plot explanation. The image tells you that the camera appears in the game's art. The dialogue around it tells you why it matters in that moment. Your reaction to it may be shaped by the game's psychological tone and by what you already suspect. A second playthrough can reveal whether that reaction changes once you know more.

Notice the direction of attention in the composition. Is the character attending to the camera, the protagonist, or something outside the frame? The answer may be ambiguous, and that ambiguity can be interesting. When writing about the image, use language such as “the composition suggests” or “I read this as” unless the text confirms an action. Those phrases do not weaken your analysis; they make its basis clear. A reader can appreciate your interpretation without mistaking it for a developer statement.

The dark computer scene

A computer in a dim room creates a different visual rhythm from an outdoor conversation. It can focus attention on information, isolation, or the contrast between the lit screen and the surrounding darkness. Again, these are interpretive possibilities. Ask what the game text actually places on the screen, who is using it, and what happens next. If the screenshot does not make the contents readable, do not claim to know them from the image alone. Revisit the scene in the game if a detail seems important.

This image is a good test of hindsight. On a first run, you may feel that a computer scene promises an answer. On a later run, you may notice a question the scene leaves open. Record both readings. A visual novel can use a familiar object to create a sense of evidence without immediately explaining what that evidence means. Your guide should help readers observe the distinction rather than supplying an unsupported solution.

The original character artwork

The sixth image is creator artwork rather than a scene screenshot. It gives a closer view of character design, including color, clothing, pose, and expression. It is valuable because visual design shapes how a player approaches the character. It should be captioned accurately, which is why the gallery calls it character artwork. Do not use it as proof that a particular pose or background occurs at a specific point in the playable demo.

Look at how design choices prepare an emotional response. A close portrait can create intimacy while a shadowed or sharply angled composition can create unease. Both responses may be present at once. That mixture fits a psychological romance premise, but the picture alone does not settle the relationship or the ending. Comparing the portrait with in-game expressions can be more useful than trying to decode it as a spoiler. Ask what remains consistent across images and what changes with context.

How to cite an image in a route note

Use an image as a landmark paired with a line of text or a decision. For example, “At the outdoor dialogue screen, after the preceding question about the guide, I chose the more direct response.” The landmark helps a player locate the moment; the text identifies the actual choice. Avoid saying “choose the blue picture” unless the game itself presents pictures as choices. The gallery images are not buttons in the story. Their purpose here is to make the guide recognizable and to support careful visual reading.

Credit matters too. These pictures belong to Vhan || 반, who is credited for writing, art, and programming on the official listing. The site is an unofficial fan page. Keep creator credit near the images and link to the official release. A player who likes the art should be able to find the person who made it and check the latest version directly.

Chapter 17

An ending log that other players can reproduce

An ending log is the bridge between a private playthrough and a public walkthrough. A private note can say “I chose what felt right and reached this scene.” A public route needs enough detail that another player can follow it from a known start. The creator confirms multiple endings, but the official page does not offer exact routes. That makes careful documentation especially valuable. It also means a guide should be honest about what has not yet been tested.

Record the build first

Before describing a route, note when and where you played. Was it the hosted browser build linked on this site, or a download from the creator's page? Which platform or browser did you use? Did the menu show a version number? If not, the date of your play is still useful. The project is in development, and a later build may contain new scenes or altered choices. A result without a version context can become confusing even if it was completely accurate on the day you found it.

Do not assume all builds are identical merely because they share a title. The official listing currently provides several platform downloads. The hosted browser edition may be updated on a different schedule. The story may be the same, but a route guide should test that rather than promise it. If you use a browser save made before a hosted update, mention that history. A clean run in the current build gives the strongest public evidence.

Describe the start state

Write whether you began from the title screen, a specific save, or an ending gallery option. If you loaded a save, explain the earlier choices that led to it. A late checkpoint can make a route easy for you to reproduce while leaving another player unable to reach the same state. For publication, the safest path is to start from a new game and list every decision that might matter. If the sequence is long, group choices by scene but keep their order. Do not replace several exact decisions with “be nice” unless you have verified that any kind response works.

Pronoun selection should be recorded if it changes the wording you quote, but it should not be presented as an ending condition without evidence. Note it as part of setup. If another player uses a different selection, they can then understand why a line in your guide is phrased differently. The same applies to language settings if a later version adds them. Setup context helps a reader follow the guide; it does not automatically become route logic.

Record choices in order

A list of choice meanings is easier to read when paired with scene landmarks. Write “at the outdoor dialogue, choose the reply that asks for clarification” rather than “choose option two,” because menu order may be forgotten or altered. If the exact wording is brief and stable, record it in your personal notes. When sharing, quote only what is needed to identify the option and avoid reproducing large portions of the game script. The aim is to guide another player through decisions, not to replace the creator's story.

Include choices you made even when you suspect they are irrelevant. Mark them as “not yet tested” if you have not compared alternatives. This helps another player reproduce the path exactly. After you run controlled comparisons, you can simplify the published instructions by removing confirmed nonessential steps. Until then, a full chronological record is safer than a short route built on assumptions.

Describe the outcome precisely

If the game names an ending, write that name. If a gallery slot unlocks, identify the slot as it appears in your build. If the demo stops without an explicit ending label, describe the final scene and avoid inventing a title. Record whether the game returned to a menu, showed a credit screen, or presented a continuation notice. These details help distinguish a real ending from a chapter boundary or an interrupted session. A screenshot can support the description, but it does not explain the choices that produced it.

Pay attention to near matches. Two runs may share a final image but differ in the preceding dialogue. That can be a variant of one ending, or it can be a separate ending that uses shared art. Check the game's own label or gallery before deciding. If no label exists, describe the observable difference without imposing a classification. “Same final image, different last exchange” is useful even when the taxonomy remains uncertain.

Reproduce before publishing

Try the route again from the stated start. Follow your notes exactly. If it works, mark it as reproduced once. If it fails, stop and compare the two runs before posting a confident guide. Perhaps you forgot an earlier choice, a setting changed, or the build updated. A failure is not embarrassing; it is the reason to test. It prevents other players from spending time on a path that works only in your memory.

A third run can be useful when the first two results conflict, but do not repeat endlessly without changing the quality of your notes. If you cannot isolate the cause, publish the observation as uncertain or hold it back. A route chart does not need to be complete on day one. It needs to be dependable where it makes a promise. The rest can be labeled as open questions for future testing.

Test whether each step is necessary

Once a path is reproducible, change one choice while holding the others fixed. If the ending remains, that choice may not be required for this route. Test at least one alternative history before generalizing further. A choice can be unnecessary in the path you tested yet necessary under another combination. The precise conclusion is “this alternate choice also reached the ending from the same starting state.” That is enough to improve the guide without claiming a complete truth table.

When you discover two successful paths, list both or describe their common condition if you have strong evidence for one. Avoid compressing them into a vague personality rule too early. “Ask directly in the outdoor scene, then keep the later response unchanged” gives a player a clear action. “Be assertive” may cover too much and leave the player guessing which menu counts. Specificity is especially important when the game has subtle dialogue rather than obvious puzzle items.

Share a route respectfully

Put a spoiler warning before an exact ending path. State the version and source of the result. Credit the creator and link to the official game page. Keep your own interpretation separate from the route instructions: the former explains what the ending meant to you; the latter explains how to reach it. Both are welcome, but a player looking for a solution should be able to find the required choices quickly, while a player avoiding spoilers should be able to stop before the reveal.

Be open to corrections. If another player reports a different outcome, ask for their build and route details. Update a public note when you can reproduce the correction. Do not quietly add unsupported claims merely to make a guide appear complete. The strength of a fan walkthrough lies in its traceable observations. A short, verified route can be more helpful than a sprawling list of confident guesses.

A model log entry

Here is a format you can copy into your own notes: “Played on [date] in [browser or platform], build [version if visible]. Started a new game. Chose [setup]. At [scene landmark], selected [short option description]. At [next landmark], selected [description]. Continued without loading another save. Final screen: [exact visible title or careful description]. Gallery result: [slot if shown]. Repeated from a new game on [date] with the same result. Uncertainty: [choice not yet tested].” This is a template, not a route for the demo.

That one paragraph contains the information another player needs to judge your finding. It also exposes gaps for your next experiment. If you cannot fill a field, leave it blank rather than inventing it. Over time, several such entries can become a route map. They can also document how the game changes as new chapters arrive. Good notes let a fan community build knowledge without turning speculation into misinformation.

Chapter 18

Browser play: diagnose the problem you actually have

The home page provides a browser player for the demo. It uses a cover screen, an embedded game frame, and a direct link to the hosted build. That setup gives you several ways to play, but it also means “the game does not work” can describe different problems. The following checks start with the visible symptom. They avoid assuming that every failure comes from the game itself. If a downloadable official build is easier on your device, the creator's page remains the source for current platform files.

The cover remains visible

Press the Play in browser button on the cover. The page is designed to delay loading the large game until you choose to start. If the button does nothing, check whether the browser blocked scripts on this site. Reload the page and try once more. If the cover changes to a loading state, the click worked and the game is beginning to load. Do not keep pressing the button repeatedly; give the frame a chance to initialize. If nothing changes after a normal reload, try the direct hosted tab linked below the player.

The distinction matters because the game's own menu is inside the frame. Seeing only the site's poster means the game has not loaded. Seeing a game progress display means the hosted build is active but may still be downloading data. Seeing the game's title screen means you can begin. Each state calls for a different next step. A guide that simply says “wait longer” for every symptom can waste a player's time.

The frame is blank

Open the game in a new tab using the direct link. If the game loads there, the issue is likely specific to embedding, browser policy, or the way the frame interacts with your device. You can play in the direct tab without losing the story. If the direct tab is also blank, try another browser or the creator's downloadable version. Record whether you saw an error message, a spinner, or an entirely empty page. Those details help identify the layer that failed.

A blank frame can also result from a network interruption while game data loads. Check that other pages open normally, then retry the direct tab once. Avoid clearing all browser storage as a first step if you have saves you care about. Clearing data may remove local progress, and it may not fix the underlying loading issue. Use the least disruptive test that distinguishes the cause.

Loading takes a long time

A browser visual novel can require a substantial initial download. The game may display its own progress after the site's cover disappears. Let that complete before deciding the page is frozen. If progress stops for an unusually long time, reload the direct tab and compare. A faster second load suggests caching is helping. A repeated stop at the same point may indicate a failed asset request or compatibility issue. If you report it, include the device, browser, approximate point where progress stopped, and whether the direct tab behaved differently.

Do not make route decisions while the interface is still catching up. Rapid clicking after a slow load can advance several lines once the game becomes responsive. Wait for the text to appear and then use one deliberate click or tap. If you accidentally skip dialogue, check for the game's history or backlog control if available in your build. The exact menu can change, so use what the game itself shows rather than relying on a keyboard shortcut remembered from another Ren'Py title.

Controls feel unresponsive

Click inside the game area once to give the frame focus, then try an on-screen button. Keyboard input may go to the outer page if the frame is not focused. On a touch device, tap the visible choice rather than swiping across the frame. If the game responds in the direct tab but not in the embed, continue there. If neither responds, check whether an overlay, menu, or loading indicator is still active. A choice screen may require selecting one option before ordinary dialogue advancement resumes.

Fullscreen can improve focus and readability, but it is not required for the story. The site's Fullscreen button expands the game stage when the browser allows it. Press Escape to leave fullscreen on most desktop browsers. If it does not work, the direct tab provides more space. On a small screen, try landscape orientation. Before choosing, make sure the full option text is visible. A truncated line can make a response seem harsher or gentler than it is.

Sound is missing

Browsers often require a user gesture before allowing sound. Press the game's start or play control, check the game's settings if present, and confirm that the browser tab and system are not muted. A delayed first sound does not imply a broken route. If the direct tab has audio while the embed does not, use the direct tab. If a downloadable build also lacks audio, check the game's own volume settings and the creator's issue notes. The official page credits music and sound effects, so audio is part of the intended presentation, but your browser may control when it begins.

Saves appear missing

Confirm that you opened the same environment where you saved. The embedded frame and the direct link point to the same hosted address in this site's current implementation, but a downloaded build is a separate installation. A different browser, browser profile, or device may not have the same local data. Private browsing can discard storage at the end of a session. Before trying to recover files, check the game's Load menu and any visible save pages carefully. A save can be in another slot or page.

If your progress is genuinely gone, your written route notes can still help you reproduce it. This is why the guide recommends recording important decisions outside the game. Do not assume that a browser save automatically syncs through an account. The hosted player does not present such a promise on this site. Treat local progress as local unless the game's interface or creator documentation says otherwise.

Report a problem clearly

A useful report states the platform, browser or operating system, game version if visible, the step that failed, the expected result, and the actual result. Add whether the direct hosted tab worked and whether the problem repeats after a reload. If the issue occurs after a story choice, describe the scene without posting major spoilers in a public subject line. The creator's official game page points players to a contact channel for problems and questions. A focused report helps the creator distinguish a site embed issue from a game issue.

Keep the test simple and reversible. Start with the direct tab, then a normal reload, then another supported browser or official platform build. Preserve your saves before clearing storage or reinstalling. A technical problem can be frustrating, but it should not force you to gamble with progress you want to keep. The goal of troubleshooting is to find the next playable path while retaining enough evidence to explain what failed.

Chapter 19

Use spoilers deliberately

A guide can help you enjoy a story or accidentally flatten its surprises. The difference often lies in when you consult it. U DON'T GET IT builds tension through uncertainty about a guide's apparent indifference and the protagonist's attempts to understand it. If you read an ending theory before your first scene, you may start filtering every line through that theory. If you wait until after one run, the same information can help you explore a question you formed yourself. Neither approach is morally superior; the important thing is to choose it knowingly.

Choose a spoiler level before opening a route page

Think of three levels. A light hint tells you how to approach a problem without revealing the answer: save before a meaningful choice, read all options, and compare outcomes. A structural hint tells you which scene or kind of decision matters. A full route gives exact choices and an ending result. This guide stays mostly at the first level because exact routes have not been independently verified here. If you later use a community walkthrough, look for a spoiler label that tells you which level it contains. If there is none, assume the page may reveal the conclusion immediately.

You can write your own question before searching. “I want to know whether I missed a choice in the outdoor scene” is narrower than “tell me everything about the ending.” Search for the narrow question and stop reading when you have enough to continue. This habit preserves more of the story while still solving the problem that brought you to a guide. It also prevents a common loop in which one spoiler creates another question and soon the entire demo is summarized before you return to it.

Keep a blind-run record

If you care about your first impression, write it down before looking at other people's route charts or theories. What did you think the guide wanted? Which scene felt most uncertain? What did you expect the ending to resolve? A few sentences are enough. Later, you can compare those impressions with the creator's future chapters or with another route. Without a record, hindsight can make your first interpretation seem obvious or foolish. In a story about expectations, preserving that initial uncertainty is especially revealing.

The record does not need to be public. In fact, a private note can be more candid. You may have guessed wrong, felt sympathy for a character you later distrusted, or missed an image detail. Those are normal parts of reading. A good guide supports exploration; it does not grade the reader's first reaction. The point is to see how the game moved your understanding over time.

Separate route spoilers from story spoilers

Knowing that a certain choice leads to a different screen is a mechanical spoiler. Knowing what the screen reveals is a story spoiler. A player may want one without the other. If you share a route, place the exact choice list before a clearly marked description of the ending scene, or provide separate collapsible sections. This lets someone reach a result while still experiencing the scene's content firsthand. Conversely, a player who wants interpretation can read the story discussion without necessarily following every click.

The distinction also improves accuracy. A route instruction is tested by whether it reaches a result. An interpretation is argued from what the result shows. If you mingle them, a theory about a character's motive may sound like part of the game's official ending name. Keep the observable result and your reading in separate sentences. This matters most when the work is a demo and later chapters may change the meaning of an early conclusion.

Use a hint ladder when you are stuck

Give yourself the smallest next piece of help. First, check whether you are actually at a choice or merely waiting for the game to finish loading. Second, revisit the last decision you remember and compare the alternative. Third, inspect your ending log for a pattern you have not tested. Fourth, seek a structural hint about which scene to replay. Only then use a full route if your goal is completion rather than discovery. This ladder is not a rule; it is a way to avoid consuming more information than you wanted.

A hint ladder can also be used by someone helping a friend. Ask what they have already seen and what level of detail they want. Offer a question to think about before offering an answer. For example, “What changes if you respond more directly in that conversation?” is lighter than naming the ending. Do not give a vague hint that sends them to replay hours of irrelevant material; a good hint is specific enough to reduce frustration while leaving the key moment to the player.

Protect others in shared spaces

When posting about an ending, keep the title neutral and put revelations behind the community's spoiler tools. A screenshot can spoil as much as a sentence, so treat ending images the same way. State the build and route context without placing a twist in the first line. If someone asks a technical question about browser loading, answer the technical question rather than adding a story detail they did not request. The game is new to many players, and the demo's uncertainty is part of what they may want to experience.

Creator credit belongs beside shared images and route discussions. Link to the official page so readers can find the current release and support the developer directly. An unofficial fan guide should make the game easier to enjoy, not become a replacement for the game or a source of copied script text. Short option identifiers may be necessary for a route; long passages of dialogue are usually not.

Revisit a spoiler after playing

Once you have seen a result yourself, read the route note again. Did it accurately describe the choices? Did it overstate an interpretation? Did your emotional reaction differ from the writer's? A walkthrough can be technically correct and still frame the story in a way you do not share. That difference is worth noticing. The game belongs to its creator, but the experience of reading it belongs to each player. A guide can report a path while leaving room for multiple thoughtful responses.

The same principle applies to this page. Its methods are suggestions for observing and replaying, not the only way to enjoy the demo. Some players prefer to map every branch; others prefer a single run and a lingering question. Use the level of guidance that helps you stay engaged. If a section starts to feel like work, return to the game and follow the story. A long guide is a reference you can consult in pieces, not a prerequisite for pressing Start.

Chapter 20

How to return when the demo changes

Vhan describes the current release as a demo and lists additional chapters and endings among future plans. That makes any present guide a snapshot. The story you play today may have new text, art, or routes when you return. You can enjoy each release without needing to erase your earlier experience. Keep a small version journal: the date you played, the platform, the ending or stopping point you reached, and the questions you hoped a later chapter would answer. When an update arrives, the journal will help you notice what changed rather than relying on a blurred memory.

Check the official release first

The creator's itch.io page is the primary source for the current release, downloads, and development notes. Before following an old route, read the latest update information there. Check whether the version you plan to play is the same as the one described in a guide. If the listing provides a new platform build, choose the one that matches your device. If you use this site's browser player, remember that a hosted build may have its own update timing. A route that worked in an older download should be retested in the current browser edition before you present it as current advice.

Do not infer that every update changes endings. Some updates fix bugs, adjust writing, or replace art without altering a route. Others may add content that changes the meaning of an earlier scene. Read the creator's notes for what is actually announced, then verify the parts you care about in the game. This two-step habit respects both the official information and your own playthrough. It also prevents a guide from treating every minor patch as a completely new story.

Preserve old and new readings

If a line is revised, you may prefer the older version or the newer one. Record the difference without deciding that one reading was invalid. An early demo is part of a work in progress. A revision can clarify an intended meaning, shift a character's tone, or make a scene flow better. It can also change how you interpret earlier choices. Your old notes show how the story affected you at the time. Your new notes show what the updated version now communicates. Both are useful evidence about the game's development.

When sharing the comparison, identify the versions and avoid quoting large blocks of script. Describe the change in your own words: a response became more guarded, a transition gained an extra beat, or an image now appears at a different moment. If a specific short phrase is essential to explain the difference, use only what is needed. A fan guide can track revisions while still sending readers to the game itself for the full experience.

Test a route after an update

Choose one route you documented well in the earlier build. Start a new game in the updated version and follow the old decisions. Record the first point where the path differs. If the same ending appears, note that the route still worked in your test. If a menu changed, do not automatically choose the option in the same screen position; read the new wording and decide which option matches the old intent. If no option matches, mark the route as requiring revision. A route is more than a sequence of button positions.

After the first test, compare a second route if you have one. A new chapter may leave early choices intact while changing later outcomes. Testing the entire path matters because an unchanged opening does not guarantee an unchanged ending. If you cannot complete the retest, label the old route with its last verified version. Readers can then decide whether to try it as an experiment rather than a promise.

Retest the browser experience separately

A content update and a hosting update are different. The game may run well as a download while the browser edition encounters a loading problem. After a hosted update, check that the cover opens, the game reaches its menu, the first choice is readable, and the direct-tab link works. If you have an old browser save, inspect it carefully before continuing. Starting a new run can be a useful test of the current build, but it should not require overwriting the only save you value.

On mobile, test that dialogue and options fit within the frame and that the direct tab remains usable. A visual novel is primarily read, so legibility is functional, not cosmetic. If the update adds more text to a choice, an interface that worked before may now feel cramped. The same applies to a longer content notice or a new settings screen. The site can provide a larger frame, but the game's own layout also affects the experience.

Update a guide with evidence

A responsible guide revision starts with a list of claims that could be affected: current demo status, platform availability, visible ending count, route steps, screenshots, and troubleshooting advice. Check each against the official page or current build. Change only what the evidence supports. If a future version reveals an exact route, add it with a version label and a spoiler warning. If a creator publishes an official ending guide, cite it and distinguish their statement from fan-tested alternatives. This keeps the page useful as the game grows.

Do not update the date on an article merely because you touched its stylesheet. An editorial review date should mean that the factual claims were checked. If you checked only the browser player, say so. If you checked only the official listing, do not claim that every ending route was retested. Precise notes let readers trust the part of the guide that applies to their question.

Keep unresolved questions visible

A new chapter can answer one mystery and open another. Make a list of questions that remain after each release. Separate what the game has answered, what a character claims, and what you still infer. If you once assumed the guide's silence had a simple cause, a later scene may complicate it. That is a reason to revise your interpretation, not to hide the old question. Good serial storytelling rewards readers who can let a theory change.

The same applies to route mechanics. A newly visible ending slot does not tell you which choices unlock it. A new choice does not prove it changes an ending. Put a question mark beside untested connections in your branch map. That visible uncertainty invites a productive experiment. Filling the map with guesses might make it look complete, but it gives players less reliable help.

Return for the story, not only completion

An update can offer a reason to revisit the opening even if you already found every ending in the previous build. Read how the protagonist's first impressions feel now. Watch whether the creator has changed pacing, art, or sound. Consider whether your own interpretation has changed since the last playthrough. A psychological visual novel can gain depth through rereading because the questions you bring to it are different. Completion is one way to engage; a fresh reading is another.

If you are waiting for a future chapter, avoid turning the wait into a certainty about what the story must do. The official page lists plans, not a fixed final plot available to players today. Enjoy theories as theories. Credit the creator for confirmed information. When the next release arrives, let it surprise you. The best long-term guide is one that helps you notice what the work actually becomes.

A return checklist

Before your next session, check the official release, note your build, protect any saves you want to keep, and decide whether you will start fresh or continue. During the session, read revised scenes rather than skipping automatically to new material. Afterward, update your ending log with what you observed, mark old route claims that need a retest, and save one question for your next run. This short loop keeps a developing game manageable without reducing it to an endless checklist.

Most of all, keep the source of each statement clear. The creator's listing confirms the premise and current features. The game itself shows the scene and the result of your choices. Your notes record your particular run. Your interpretation gives those observations meaning. A guide becomes durable when it respects all four levels. It can then grow with the demo without pretending to know what has not yet been released.

Chapter 21

Choose the guide path that fits your goal

This is a long reference because different players come to a developing visual novel with different questions. You do not need to read it from beginning to end before playing. Use the path that matches your goal, then return to the story. The sections below connect the practical chapters into shorter journeys. They also help you avoid reading more spoilers or technical detail than you need.

If this is your first run

Read Start and setup, then the first few paragraphs of A first playthrough. Open the game and choose naturally. You do not need a branch map, an ending log, or a theory about Zhenya before the title screen. The creator's premise is enough: a new university beginning and a guide whose apparent indifference raises questions. Let the first run show you which part of that premise matters most to you. When you reach a stopping point, write down what you saw and what you still wonder.

If you have limited time, use a single save before a choice you suspect you may revisit. If you prefer complete immersion, skip the notes until the end. The story should have room to work on you. The more analytical chapters will still be here afterward. Reading them after a first run may be more useful because their examples will connect to a scene you actually experienced rather than a hypothetical branch.

If you are returning after one ending

Begin with A replay plan and choose one of the controlled experiments. Start from a save before a menu that stayed in your mind. Change one option, then compare the same stretch of story. If the result differs, note the first visible difference. If it does not, continue far enough to see whether the choice is remembered. You are not trying to prove the entire game at once. One reliable comparison is a useful achievement.

Use the close-reading workshop if two replies seem almost identical. It will help you identify whether they differ in tone, assumption, or purpose. Use the scene-by-scene prompts if you remember a moment but cannot explain why it felt important. The aim is to turn a vague impression into a question you can test. A second run becomes more rewarding when it has a clear reason to exist.

If you want every ending available in your build

Start with Ending exploration and Save planning. Finish one route and record the visible result. Keep checkpoints before important decisions. Then use the branch map method to compare paths. If your build shows an ending gallery, use it to track which results you have actually unlocked. Do not turn its current number of slots into a claim about the finished game. The creator's plans include more content, so the gallery is a snapshot of the build you opened.

When you find a new result, use the ending log to document it. Reproduce the path once before relying on it. If a route works, share it with a version label and a spoiler warning. If it does not, keep both observations and investigate the difference. Completion is more satisfying when you know how you reached a screen, not only that it appeared once.

If you mainly want to understand the story

Read the story chapter and the image atlas. Pay attention to the contrast between expectation and experience, and to the gap between a character's statement and what the scene directly shows. Keep your own response to an image separate from what the image proves. This approach leaves space for ambiguity. It does not ask you to distrust every line or to solve a future chapter in advance.

After playing, revisit one image you remember: the city, outdoor dialogue, camera, computer scene, or character portrait. Ask whether its meaning changed for you after the ending. If it did, identify what new information or feeling caused the change. If it did not, ask why the first impression remained strong. Both answers can deepen your reading without requiring a new mechanical branch.

If the game will not open

Go straight to Browser play diagnosis. Identify whether the cover is still visible, the frame is blank, the game is loading, or the game has opened but input fails. Use the direct hosted tab to distinguish an embed problem from a game problem. If necessary, use the creator's official platform download. Protect saves before clearing browser storage. There is no reason to read ending advice while the interface itself is unavailable.

Once the game works, return to the first-run path. A technical interruption can make you eager to click quickly through the opening, but the dialogue is the center of this work. Confirm that the full text is readable on your screen. Fullscreen or a direct tab can help. If you are on a phone, try an orientation that gives the choices enough room. Then begin at a pace that lets you notice the story.

If you are writing your own guide

Read Build a branch map, An ending log, and How to return after updates. State the source for each claim. The official listing supports broad features and premise; the current game supports observed scenes; your controlled runs support route instructions; your interpretation supports analysis. Do not borrow the authority of one level for another. “The creator says there are multiple endings” and “I reached this ending by choosing these replies” are different statements, and both can be valuable when labeled correctly.

Give readers a short route instruction before a long interpretation. Include the build context and an exact starting point. Put major story revelations behind a spoiler warning. Credit Vhan || 반 and link to the official game page. If a path has only worked once, say so. If a later update changes the route, revise the guide after testing rather than merely changing the publication date. Your readers can tolerate uncertainty; what misleads them is certainty without evidence.

If you are returning after an update

Read the official release notes, then use the version chapter. Preserve your earlier notes and check whether an old route still works from a fresh start. Notice revised wording, art, and pacing as well as new choices. A new chapter may answer a question you carried from the demo, but it may also change how you understand the old material. Let the updated work speak for itself before treating an old theory as confirmed.

A practical return session can be short. Check the build, play the opening carefully, test one saved route, and record one new question. You can explore more later. A developing visual novel rewards patient rereading, and there is no need to complete every branch on release day. Your guide should grow at the same pace as your evidence.

If you only have ten minutes

Open the browser player, press Play, and wait for the game's menu. Read the opening notices and setup choices. Begin the story and follow it until your first meaningful dialogue option. Before selecting, read every response and ask which one fits your current understanding of the protagonist. Choose, then watch the next exchange without reloading. If you must stop, save at the next natural pause. That short session will give you a better foundation than skimming a page of unverified ending rumors.

If the player does not load within your available time, use the direct tab or bookmark the creator's download page for later. Do not spend the whole session clearing settings without a diagnosis. The technical chapter can help when you return. A brief, attentive opening is enough to begin forming your own questions about the guide, the campus, and the protagonist's expectations.

One final principle

Every path through this guide ends at the same place: the game. The site can help you start, replay, compare, and troubleshoot, but the story's actual words and images are the source of your experience. The official page confirms that Vhan created the writing, art, and programming. This fan guide can point to the work and explain methods for exploring it. It should never make up a route merely to sound complete.

Choose a question worth following. Maybe it is how a single reply changes a conversation. Maybe it is why the guide's silence feels so unsettling. Maybe it is whether a conclusion can be reproduced from a clean start. The question gives your next session direction. The answer should come from what the current demo actually shows, from a creator statement, or from a route you can test again. That discipline makes exploration more satisfying, and it leaves room for the unfinished story to surprise you.

Chapter 22

A short glossary for route notes

Build. The particular release of the demo you are playing. A browser copy and a downloaded copy may be updated at different times. Record the date or version when making an exact route claim, because a later release can change text, choices, or endings.

Branch. A point where one choice produces an observable difference from another. The difference may be a single line, a full scene, or a final result. Do not use “branch” to imply a separate ending unless you followed both paths far enough to verify that outcome.

Checkpoint. A save made before a question you want to test. A good checkpoint has a clear label and a known history. It lets you compare two replies from the same starting conditions instead of relying on memory after a full replay.

Convergence. A point where two visible paths return to the same scene or text. Convergence tells you the immediate presentation has come together. It does not prove that the game forgot the earlier choice, since a later line or ending could still differ.

Demo boundary. The point where the current public release stops. It might include an ending, a chapter break, or a notice about future content. Describe the screen you actually see. Do not assume every unresolved question means you missed a hidden route.

Ending gallery. A menu that records endings in a particular build, if the build you play includes one. A gallery can help you track your own progress. Its current slots do not establish how many endings the completed game will eventually have.

Interpretation. Your reading of what a scene means. An interpretation can be thoughtful and well supported without being an official explanation. Mark it as your reading when discussing a character's motives or the meaning of a visual detail.

Local effect. A change visible soon after a choice, such as a different reply or internal line. Local effects are worth noting even if the final ending remains the same. They are part of the experience of shaping the protagonist's response.

Observation. Something shown by the current game or stated on the creator's official page. “The menu offered this reply” is an observation. “This reply adds a hidden point” is not an observation unless you have direct evidence of that rule.

Route. A sequence of decisions that leads from a stated starting point to a stated result. One reproducible route is useful. It does not prove there are no other routes to the same result, so describe it as one verified path unless you have tested the alternatives.

Run. One playthrough or one controlled continuation from a save. Give a run a simple label, such as “first blind reading” or “outdoor choice comparison.” The label helps you keep observations from different experiments separate.

Source. The evidence behind a claim. For this guide, the creator's official page supports the premise and broad features; the site's code supports browser-player instructions; the game's scenes support observations made during play. A clear source makes a guide easier to trust and update.

Spoiler level. How much a guide reveals. A light hint suggests a method, a structural hint points to a relevant scene, and a full route states exact choices and outcomes. Choose the level you want before reading, especially if you have not finished your first run.

Unverified. A claim that has not yet been reproduced or supported by the creator. Unverified does not mean false. It means the evidence is not strong enough to promise another player the same result. Keep the claim as a question or a test plan.

These terms keep a long guide precise. They also make your own notes shorter. “Local effect observed; ending effect unverified” says a great deal in seven words. You can use that language to share a discovery without overstating what the demo has shown. As the story develops, the glossary remains a tool for careful reading rather than a list of supposed hidden mechanics.

When a route note feels confusing, return to the smallest claim you can check. Identify the build, find the checkpoint, repeat the choice, and describe the next visible event. Then ask a new question. This sequence is slow enough to avoid rumor and quick enough to guide a practical replay. It respects the creator's unfinished work while giving players useful steps today.

Chapter 23

Common mistakes during a route hunt

Guessing an ending from a screenshot. A promotional or gallery image shows artwork, not the conditions that unlock a result. Return to the playable scene, record the preceding choice, and follow the path to its actual conclusion before naming an ending.

Calling a choice irrelevant after one line. Two replies may rejoin immediately and still be remembered later. Write “no immediate difference” and continue the comparison through a later scene or final screen. This keeps your observation accurate without claiming more than you tested.

Changing several decisions at once. A different result is exciting, but it does not tell you which change mattered. Keep a baseline run, alter one choice or one clearly defined cluster, and record the first visible divergence. Narrow the cluster in a later run.

Using “nice” and “mean” as exact instructions. Those labels hide the wording and purpose of a reply. A gentle question and a gentle withdrawal may affect a conversation differently. Describe what the option asks or does, then provide a scene landmark so another player can identify it.

Forgetting the start state. A route from a late save may carry earlier decisions that your note omits. Record the prior path or reproduce the ending from a new game before publishing the route. A checkpoint is useful only when you know how you reached it.

Assuming a demo is the finished story. The creator marks the project in development and plans more chapters. Treat current conclusions and gallery slots as properties of the version you played. Future content may add context without making your earlier experience meaningless.

Confusing a technical failure with a story event. A blank frame, frozen loader, or muted tab does not reveal a secret ending. Test the direct hosted tab, check the interface, and use the creator's download if needed. Once the game is running, return to the actual dialogue.

Overwriting the only useful checkpoint. Keep a clean save before a choice you intend to test. Use another slot for the route you continue. If you accidentally overwrite, check the game's available saves and reconstruct the path from your notes rather than guessing what an old thumbnail represents.

Treating a character's claim as objective narration. A character can speak from limited knowledge or emotion. Record who said a line and what the scene directly showed. This does not require distrusting every character. It simply preserves the mystery until stronger evidence appears.

Reading a future theory as a confirmed route. Fan discussions can be inventive and perceptive, but a theory about motives is not the same as a tested sequence of decisions. Label theories as interpretations. Label route instructions with a build and reproduction record. Readers can enjoy both without confusing them.

Ignoring the version. The exact words of a menu, the position of an option, and the available ending slots may change during development. Note the date and build when possible. After an update, test an old path before telling someone it still works.

Turning every choice into a score. The official listing says decisions shape the protagonist's mindset; it does not publish a named numerical system. Avoid inventing points or thresholds. Describe visible changes and use controlled replays to identify patterns. A good route note can be precise without pretending to know unseen code.

Skipping the line after a choice. In a dialogue-driven game, the immediate reply may be the most revealing consequence. Pause after choosing. Read the whole exchange before loading an alternative. A rapid route hunt can miss the very difference it set out to find.

Publishing a result you cannot reproduce. A single surprising screen is worth noting, but it is not yet a dependable instruction. Follow your written path again from the stated start. If the result changes, investigate and mark the claim as unverified. Readers benefit from your uncertainty more than from a confident error.

Forgetting why you began playing. A checklist can be satisfying, yet the demo's atmosphere, art, and uncertain relationship are part of its appeal. When route testing becomes tiring, return to a natural reading. You can keep the map for later. The guide is a tool for curiosity, not a requirement to optimize every line.