Characters Database

Read identity separately from relationship data

Official development material can establish a resident's name, portrait, or connection to a family without documenting every role they have in the released game. A character record marked partial preserves that useful identity while leaving schedules, gifts, romanceability, birthdays, and story conditions unknown. Do not read an empty field as a negative answer. It means the field has not been confirmed for this database.

Family labels require the same care. Moonlight Peaks officially centers seven supernatural families, but a name appearing near one family in promotional material does not automatically establish every biological, social, or household relationship. The category shown on a record should reflect the source narrowly, and later evidence can add context without rewriting the original source as more complete than it was.

Make a reliable character lookup

Search the exact displayed name first, then compare the summary, category, and tags with the resident you met. If you arrived from a gift, romance, quest, or map question, use the character record to confirm identity before following the linked topic. Similar supernatural themes, nearby homes, or shared dialogue scenes are not enough to merge two profiles.

For schedules, record the location, time, story stage, platform, and version where the resident was observed. One sighting proves only that context. A public schedule needs repeated observations across the relevant conditions and should state known exceptions. Until then, a route note belongs in personal research rather than a verified database field.

• Confirm the exact resident name before adding gifts or relationship notes.
• Keep official profile facts separate from live-game observations.
• Attach story and version context to schedules or scene triggers.
• Use partial status when the person is known but key fields remain open.

Keep gifts and romance as independent claims

The official Steam description says the town includes roughly two dozen romanceable characters, but it does not turn every named resident into a confirmed candidate. Romanceability should be supported by the current game or a direct official source. The same rule applies to dates, marriage, exclusivity, and long-term outcomes. A portrait or detailed backstory cannot fill those fields by implication.

Gift preferences need an exact item and an unambiguous reaction. A resident's visual theme, species, occupation, or family is not a gift category. Use the gift finder for published reactions and keep rare items out of speculative tests. When you observe a response, record the item label and version before classifying it as loved, liked, neutral, or disliked.

Submit character evidence with context

A useful correction identifies the character, affected field, platform, version, story stage, and source or repeatable step. For a family link, include the dialogue, profile, or official material that states the relationship. For a schedule, include multiple observations instead of one location. For romance or gifts, preserve the menu option or reaction rather than only the conclusion.

Corrections are applied to the narrow field they prove. Confirming Brook's location on one night does not verify every schedule entry, and confirming a gift reaction does not verify romanceability. This field-level approach keeps small records honest while the broader character database grows.