Your privacy.
Clearly explained.

1. Operator and scope

Fineform Studios LLC operates Orbit Theory, a mobile game currently in development / pre-release. For support and privacy requests, email [email protected].

This policy is a draft based on a review of the Orbit Theory repository and owner-provided release information. It distinguishes code implemented in the reviewed build from disabled production features. It is not a verification of live service settings or native device behavior, and has no effective date yet.

2. What is implemented, and what is not active

These statements describe the source revision reviewed for this draft. An SDK integration, configured identifier, or database migration does not by itself establish that a production feature is active.

3. Supabase anonymous authentication and economy

The game uses Supabase to create or reuse an anonymous authenticated session without requiring an email address or password. The session is persisted locally and refreshed as needed. An anonymous account has a unique player identifier; this is pseudonymous data, not a guarantee that all associated information is unidentifiable.

The backend connection runs when the game is active and online. It reads wallet connection information and can submit a legacy-balance migration request containing a snapshot hash and claimed balance. The schema includes player profiles, wallets, migration records, transaction ledgers, and reward receipts, with identifiers and relevant timestamps. Deployment and actual records retained must be confirmed by the owner.

The reviewed code leaves the server-authoritative wallet disabled: backend balances are not imported into local gameplay, and local coins and rewards remain in use. Ad-verification and purchase tables are foundations for disabled features, not evidence of current production ad or purchase collection.

Network requests to Supabase necessarily provide connection information such as an IP address to the service. The owner must verify provider logging, hosting regions, and retention. Loss of a locally stored anonymous session may affect the ability to locate the same account; cross-device account recovery is not promised.

4. Local saves, gameplay progress, and backups

The game stores progress in local storage, including completed and unlocked levels and chapters, best moves and stars, archived scores, coin balance and reward history, assistance and tutorial state, daily/retention gameplay state, gameplay statistics, and sound, music, and haptic preferences. “Retention” here refers to gameplay engagement state, not a documented data-retention period.

Telemetry preferences are saved separately. Authentication sessions and backend migration status also use local persistence. The game includes progress export/import and native sharing support; a progress backup contains game-save information and can be disclosed to a destination you choose when sharing it.

The progress-reset function resets the game save while retaining game settings. It is not a backend-account deletion function and does not establish deletion of provider records. Clearing local storage or uninstalling may remove local information, depending on platform and backup behavior, but should not be assumed to delete server information.

5. Firebase Analytics, Crashlytics, and your choices

Firebase Analytics and Crashlytics are integrated for native builds, with collection configured off by default. The ordinary browser game does not initialize this Firebase integration. Native runtime behavior remains pending device verification.

On eligible native devices, players without a prior privacy choice are offered an optional prompt after Level 1 onboarding, before a subsequent puzzle. “Allow” enables analytics and crash reporting; “Not Now” records both as off. Settings provides independent switches for analytics and crash reporting. The code keeps collection off if preferences cannot be saved.

When analytics is enabled, allowlisted events cover session starts, level starts/completions/failures, chapter progression, hints, path previews, power-cell depletion, and daily-challenge participation. Event parameters are limited to level/chapter numbers, mode, outcome, and hint type. The integration does not send wallet balances, purchase receipts, Supabase player IDs, authentication tokens, or complete saves as analytics parameters.

Firebase creates app-instance or installation identifiers and may process SDK device/app metadata. Crashlytics can collect native crash stacks and diagnostic/device information. The JavaScript error integration sends fixed sanitized exception descriptions rather than arbitrary error messages, URLs, or saves. Provider-collected metadata still needs review against the final SDK configuration.

Turning analytics off invokes the SDK’s analytics reset; turning crash reporting off deletes unsent crash reports. JavaScript reporting is gated by the preference. Some SDK collection changes may require an app restart. These controls do not promise deletion of data already received by Firebase.

Advertising storage, advertising user data, and ad personalization consent remain denied in this telemetry integration. The reviewed native configuration disables analytics advertising-ID collection; no App Tracking Transparency prompt is added. Confirm these behaviors on devices before release. See Firebase’s privacy and security information.

6. Google AdMob and advertising consent

Production AdMob playback and rewarded-ad fulfillment are not enabled in the reviewed runtime. Native app/ad identifiers and integration foundations exist, but their presence does not mean players currently receive production ads. Browser play uses an unavailable native-ad provider.

The implemented ad foundation gates initialization and ad requests on Google User Messaging Platform consent handling. Published UMP messages, regional and age settings, trusted reward verification, and native testing remain launch prerequisites. A required in-game privacy-options entry for reopening advertising choices is not yet implemented. Firebase’s optional telemetry prompt is not advertising consent.

If advertising is enabled later, this policy must be updated to identify active partners, data categories, ad personalization, and the exact consent/withdrawal controls. Ad services may process IP addresses, device or advertising identifiers, ad interactions, and fraud-prevention data; non-personalized ads can still involve processing. These are future disclosures to validate, not claims of current production collection.

See Google’s Privacy Policy and Google’s information about partner apps.

7. Optional in-app purchases

Optional in-app purchases are not enabled for production. The source contains native Apple/Google billing integration and a local pending-receipt journal, but trusted fulfillment is not configured and normal payment initiation remains unavailable. This draft does not claim purchases or purchase restoration are available to players.

If activated in a future build, the app store would handle checkout, and the game/backend could process product identifiers, transaction identifiers, purchase tokens or signed proofs, entitlement/fulfillment status, and related transaction records. The owner must verify the final validation flow, actual fields, store policies, and retention before activation. No payment processing is performed by this studio website.

8. Purposes and service providers

Local data supports progress, preferences, and game economy. Supabase identity and backend records support account/session continuity, wallet connection, and migration review. Optional native analytics supports understanding game usage; optional crash reporting supports diagnosing failures.

Supabase and Google Firebase are relevant providers for the implemented features. AdMob, advertising partners, and app stores apply to disabled or future features as described above. Review Supabase’s Privacy Policy for provider context. Fineform Studios also receives the information you choose to send when contacting support, such as your email address and message.

The owner must confirm provider contractual roles, production logs, additional processors, lawful disclosure practices, and whether any future advertising activity qualifies as sale, sharing, or targeted advertising under applicable laws. No blanket non-sale or legal-compliance assurance is made by this draft.

9. Data retention, security, and deletion

No verified retention periods have been supplied for backend accounts, wallet/migration records, analytics, crash data, support correspondence, provider logs, or backups. The final policy must specify actual retention periods or criteria, including provider-controlled retention.

Contact the studio to request access to or deletion of relevant data. No self-service server-account deletion flow was identified in the reviewed client implementation. The owner must establish how anonymous accounts can be identified, what can be deleted, how provider requests are handled, and which legal or operational exceptions apply. Do not send passwords, session tokens, receipts, or sensitive identity documents unsolicited.

Local reset, telemetry opt-out, and app removal are distinct from server-side deletion. Unsent crash deletion and analytics reset do not erase all uploaded records. A request is not a guarantee that all information can be located or removed.

The source includes authenticated access and database access-control foundations. Their live deployment and broader security practices require owner verification; no absolute security guarantee is made.

10. International processing and privacy rights

Service providers may process data outside your country. Supabase/Firebase hosting regions, transfer arrangements, and applicable safeguards must be verified before finalization.

Depending on your location and applicable law, you may have rights to access, correct, delete, or receive a copy of personal data, restrict or object to processing, withdraw consent, or opt out of certain advertising disclosures. You may also have a right to complain to a regulator. Rights and exceptions vary by jurisdiction.

Email the studio for a privacy request. The owner must confirm applicable legal bases, proportionate identity-verification procedures, response obligations, and any required appeal process. This draft does not certify compliance or promise an unsupported response deadline.

11. Children’s privacy

The intended age audience, store age ratings, child-directed status, and age-screening behavior require owner confirmation. No parental-consent procedure was verified during this review.

Before release, the owner must assess applicable children’s privacy obligations and configure telemetry, advertising, and purchases appropriately. Do not assume the optional analytics prompt is parental consent. A parent or guardian concerned about a child’s data can contact the studio; the process for locating and deleting relevant records requires verification.

12. Contact and updates

Contact Fineform Studios LLC at [email protected] for general support, game questions, or privacy requests. Include “Orbit Theory” and a brief description of the request without sensitive credentials.

The final policy must have an owner-approved effective date and explain how material changes will be communicated. Review this draft against the native builds and production service configuration before publication as a finalized policy.