Start Here: From Import to a Validated Game

This is the shortest reliable route through HyperCasual LiveOps Kit V2. Start with Tools > HLK > Start Here in Unity. The Toolset Overview mirrors the five steps below and keeps every action one click away.

1. Shape the game-facing sample

Open Tools > HLK > Game Setup Assistant. Use it for the parts a game designer expects first: menu/gameplay scenes, levels, rewards, goals, minigames, offers, battle pass, economy data, and the portrait Starter Menu.

The Feature Dashboard and Starter Menu serve different purposes:

Both are listed as samples in package.json and both remain sample code/data. Do not treat sample identifiers, products, rewards, or simulated provider results as release configuration.

2. Create editable starter data

Use Generate Missing Starter Assets from Start Here or Tools > HLK > Generate Starter Config Assets. The generator fills missing references; review and rename the resulting catalogs and replace placeholder values before release.

Keep the package presets as references. Put game-owned variants in a project-owned folder when you expect to update or replace the asset later.

3. Choose and configure modules

Use Complete V2 as a searchable module map, then open a module's current tab when one exists. The categories mean:

Category What belongs there
Monetization Ads, IAP, offers, receipt/promotion authority
Engagement Goals, quests, gifts, battle pass, energy, rate prompts
Platform Identity-facing services, cloud, links, push, updates, game services
UI & Feedback Audio, haptics, localization, native UI, sharing, web surfaces
Data & Setup Analytics, consent, permissions, crash reporting, app identity
Complete V2 Contract/domain inventory, dependencies, authority, and support evidence

Configure only what the game needs. Dummy, Test, Simulated, and LocalPrototype paths are development tools. Explicit Production/provider paths do not silently turn into successful simulation when a required SDK or authority is absent.

For AdMob, open the Ads tab, expand Google AdMob — direct, and select Install AdMob SDK. After confirmation, HLK adds the official OpenUPM registry and its tested Google Mobile Ads UPM dependency; no OpenUPM CLI or manual scoped- registry entry is required. The installer refuses to mix a legacy .unitypackage copy with UPM and keeps a backup of the previous manifest under Library.

4. Clear local blockers

For the Remote Config tutorial, keep Fetch automatically on init enabled, publish a parameter, then restart the app / Play Mode and inspect active values. Startup attempts a fetch and activation; offline/failure retains cached/default data. Restarting is not a guarantee of fresh server values. Existing opt-out settings are respected. There is no automatic session polling.

The Remote Config panel is ordered **Source > Lifecycle > Active keys > key input

Typed reads**. Lifecycle provides Register defaults and one Pull config and apply (Force) action. Force requires confirmation and, in a player build, HLK_REMOTE_CONFIG_QA. Remove that define before publishing; no Development Build is needed. Force leaves Firebase's global settings and shared app intact. An active server throttle is displayed as a countdown and blocks retries until expiry. Success hides irrelevant failure details; unset timestamps are omitted. The panel refreshes its active-value display automatically. Recovery of an interrupted override from an older kit is retained for safe upgrades.

Same-session Firebase hot updates remain unverified. Use diagnostics and a minimal Firebase sample on the same SDK/platform to investigate further, rather than lowering production settings. RemoteValue can be cached; activation false does not prove throttling. Keep a nonzero release cache window.

There are three different validators; they are not interchangeable:

Tool Audience What it proves
Game Setup validation Game developer/designer Scenes and game-facing asset references are coherent
Toolset static preflight / Build Doctor Game developer/release engineer Locally inspectable settings, compile markers, required files, and release-policy gates
Distributable package validation Asset maintainer The package being exported has clean metadata, paths, GUIDs, secrets policy, and export inventory

Customer projects normally use the first two. Package validation/export, dependency repair, and generated-artifact cleanup are grouped under Tools > HLK > Maintainer because they maintain this distributable rather than configure a game. Reproducible sample showcase builders remain under Tools > HLK > V2 and reject Unity Development builds.

5. Prove external behavior

A green editor result is not production certification. Before release, separately:

  1. Deploy and authenticate customer-owned backend authority.
  2. Verify purchases and promotion redemption with idempotent server fulfillment.
  3. Configure provider dashboards, app identifiers, credentials, products, and callbacks.
  4. Exercise store sandboxes/internal tracks with test accounts.
  5. Validate consent, permissions, notifications, links, native UI, sharing, and failure/offline behavior on every supported device family.
  6. Record the provider/device/build evidence required by your release process.

Updating an existing installation

Before importing a new major version, run Tools > HLK > Migration > Pre-Upgrade Backup and Scan... and choose a user-owned destination outside the package. Use the dry run first if you only want an inventory/report. Migration never replaces provider-console exports, store records, or normal source control backups.

Where to go next