Moonlit BeaconPlayer Care

Privacy Policy — Moonlit Beacon

This policy explains what Moonlit Beacon by Hyo Dev collects and how it is handled.

Updated for version 4.0.0.

Ways to sign in

  • Entry offers a guest door plus Google and Apple sign-in where the build configures them.
  • Guest entry creates an anonymous sign-in identity where the device supports it.
  • Google and Apple are separate sign-in identities. The Play Games gaming profile is a separate Android-only option and is not offered in this build.

What sign-in handles

  • Firebase and the Google or Apple provider you choose process identifiers, sign-in and session credentials, and the profile fields your consent and provider settings make available, to authenticate and recover the account.
  • The game keeps its own records: your public player ID, the private link between your signed-in account and that ID, and your checkpoint saves.
  • Only the game's on-device account list stores the server account reference in hashed form. Account and save records held by the backend carry the raw account reference and stay private to your account.
  • The game itself holds sign-in tokens in memory while it reaches your records. Gameplay save files contain no sign-in tokens, and tokens are never placed in public ranking. Staying signed in across launches is handled separately by the Firebase and provider SDKs, which keep their own session data under SDK and OS storage.
  • Email and profile information is not shown in public Hall rows. Provider-side profile handling follows that provider's own policy: Firebase, Google, Apple.

Your player ID

  • Each install mints a durable public player ID of the form MB- plus 32 hexadecimal characters before first play.
  • It names your saved gate and your Hall rows, and it survives linking: connecting Google to the original guest keeps the same ID and the same checkpoint ownership.
  • Signing out starts a fresh guest ID on the device while the previous ID and its saves stay kept. Signing back in with the same provider returns to that account's ID and kept saves. One install can therefore hold more than one ID over time.
  • Include your player ID, shown in the game's account panel, when you contact support.

Cloud saves

  • A signed-in account owns one private versioned save holding its progress (cycle, hero, relics, growth, scores).
  • Saves land on the device first; uploads follow in the background.
  • Saves never carry purchase or balance records.
  • Downloads are fully checked before install, and a differing cloud copy waits for you to choose which side to keep.

Hall board

  • The Hall keeps one best entry per player ID: player ID, hero, score, progress, app version, and update time.
  • Board reads are public; only the owning account may write its entry. Scores only increase, and standing is derived from scores so equal scores share one rank.
  • No name, email, account reference, token, or save appears in a Hall entry.

Deletion

  • Delete your cloud account from the game's account settings. Deletion first removes its Hall entry, cloud save, reservation, and profile together in one verified step; only after that confirmation is the sign-in itself deleted.
  • On iOS, deleting an Apple-linked account may ask you to confirm again through the Apple sign-in sheet.
  • Signing out ends the sign-in session and switches to a fresh guest ID; it deletes nothing on the device or in the cloud.
  • Deleting your cloud account removes your cloud records and sign-in, but files already on this device — local saves and the on-device account list — stay until you reinstall the game or clear its storage.
  • Account, checkpoint, and Hall records have no configured automatic expiry: they remain until the account is deleted.
  • You can also request access, correction, or deletion of your data by email at hyo@hyo.dev. Include your player ID.
  • Support requests are matched to your records through your player ID; deletion requests that concern purchase records are forwarded to the purchase-verification processor.

Guests and offline play

  • Guest play works offline as a device-only guest and is never shown as a registered cloud account.
  • If background sign-up fails, or the build has no sign-in setup, play continues anyway. Builds without sign-in setup make no registration attempt and show no error.
  • Sign-in, cloud saves, the Hall, the store, and purchase verification need an internet connection.

Analytics

Optional gameplay analytics stays off unless two switches agree: the shipped build's export configuration and your explicit consent in Settings, which defaults to off.

Purchases

  • Store receipts are verified through the IAPKit purchase-verification service. Store and product plus the receipt or token (Apple's signed JWS or Google's purchase token) are sent for verification.
  • Its validation record may retain transaction and order identifiers, store responses, request IP, verification result, and processing duration. Processing serves entitlement grants, restores and revocations, refunds, fraud and duplicate prevention, diagnosis, and service statistics.
  • For service statistics, IAPKit may send a project-first-valid-receipt event and the store kind to Mixpanel; that event excludes the purchase token, transaction ID, and IP. Convex provides IAPKit's infrastructure. Their policies: IAPKit, Convex, Mixpanel. These third-party service statistics are separate from the game's optional gameplay analytics, which stays off unless you enable it in Settings.
  • Neither the app nor the developer receives your payment-card information or store-account password. Keys, signatures, and purchase tokens are kept out of logs and error messages.
  • Store-side purchase processing follows each store's own policy: Apple, Google.

Support requests

  • Emailing support processes your email address, message, and any attachments you choose to send, together with the email service provider, to resolve your request.
  • Support keeps your request only while needed to resolve it and to meet legal duties.
  • When a purchase is involved, support asks only for the minimum order detail needed to locate the record — never a full receipt, password, or verification code.
  • Providers retain validation records as necessary for restoration, refunds, fraud prevention, statistics, accounting, and legal obligations; no uniform expiry is promised.
  • Records the law requires to keep can remain, and requests about processor-held records can be relayed to the processor.
  • Your support request and the verification above may be processed outside your country.

Changes to this policy

When the game changes how it handles data, this page is updated with the new version. This edition covers version 4.0.0.