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.

Standalone game delivery: automatic vendor-SDK installation is disabled and no provider SDK is bundled. Shipping defaults are Ads Dummy (0) and IAP Disabled (3). To enable real AdMob ads, separately install the official Google Mobile Ads SDK using the vendor documentation, configure your own Android App ID, placement IDs, consent and provider settings, then perform device testing. Do not mix legacy unitypackage and UPM copies.

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