星火 2.0 开发文档

主题

Game Environments ​

Use this skill when the task is about Spark Editor / WasiCore environment terms, deployment vs runtime environment differences, project internal testing, formal launch, CloudData separation, alpha-to-production migration, release timing, or custom resources missing after moving to online.

Read the full guide before giving detailed advice:

  • SDK repo: docs/guides/DeploymentAndRuntimeEnvironments.md
  • Game project with copied SDK docs: docs/sdk/guides/DeploymentAndRuntimeEnvironments.md

Terms ​

Deployment environment describes the official platform/editor/runtime release channel:

  • alpha: external public test deployment. It receives the week's editor, SDK, server, and client runtime capabilities before production. Use it only when validating capabilities that are not yet available in production, when official staff request external verification, or for an alpha-to-production migration check.
  • production: online production deployment. This is the default deployment environment for new projects and for formal online users. It receives each capability batch after alpha; timing follows the current release plan, not a fixed lag.
  • master: reserved deployment-channel value. Do not treat it as a project release, testing, or migration target.
  • Headless publishing follows the host's own installation environment: an online installation publishes to pd, and the historical production manifest value is normalized to pd. See Headless Editor publish environment.

Runtime environment describes the project's own game-session data and availability lane:

  • debug: debugging runtime environment for editor debug, remote debug, and development validation.
  • test: project internal test runtime environment. This is the author's own test lane, not the editor alpha deployment.
  • formal: project formal runtime environment. production + formal means the game is formally published, passed platform review, listed on TapTap, and publicly discoverable/playable through TapTap App and the Spark battle platform.

Always keep these axes separate. alpha is not project internal testing, and test is not the editor public test deployment.

Data Isolation ​

Deployment and runtime environments combine into independent data spaces. Treat all combinations as separated. For project development, testing, release, and migration decisions, default to production, add alpha only on demand, and keep the debug/test/formal runtime choice separate; master is only a reserved deployment-channel value.

Practical consequences:

  • test and formal CloudData are separate.
  • alpha + test, alpha + formal, production + test, and production + formal do not share CloudData automatically.
  • Project internal test data does not disappear when the project later enters formal release; the test lane continues to exist.
  • Payment boundary follows the runtime environment: test can only spend existing Spark currency and cannot recharge, while a game running in formal can recharge through the Spark battle platform. Do not state that the platform itself cannot recharge, and do not treat test-lane balance consumption as recharge verification.
  • Do not casually promise no-wipe internal tests. If payment or equivalent paid behavior happens during internal testing, the usual approach is to record purchases and compensate players in formal with equivalent primary paid currency or project-owned compensation. Exporting test data and restoring it into formal is possible in principle but uncommon and higher risk.
  • Server-side environment-aware systems such as ServerChannel should stay isolated by runtime environment.

API Advice ​

Use:

  • Game.DeploymentEnvironment
  • Game.RuntimeEnvironment
  • Game.IsAlphaDeploymentEnvironment
  • Game.IsProductionDeploymentEnvironment
  • Game.IsDebugRuntimeEnvironment
  • Game.IsTestRuntimeEnvironment
  • Game.IsFormalRuntimeEnvironment

Good uses:

  • logging, diagnostics, and backend messages;
  • feature flags or operating notices that differ between internal test and formal release;
  • confirming launch readiness for production + formal;
  • avoiding accidental reads/writes that mix debug, test, and formal assumptions.

Do not use environment APIs to bypass review, payment compliance, player communication, or migration planning.

Release Cadence ​

New projects start in production: use the online editor and develop, debug, and publish there. Use alpha only for the cases listed under Terms: validating capabilities that are not yet online, official verification requests, or an alpha-to-production migration check.

Do not plan around a fixed lag. Alpha capabilities reach production according to the current release plan; the interval varies with the batch and with platform/client version coverage, and client-binary capabilities can take longer. Use docs/sdk/CHANGELOG.md, official notices, and editor prompts for the current timing; treat any specific number of days as an estimate, not a standing promise.

A feature available in alpha is available for public test, not necessarily for production. A new API is practically usable online only when the production editor, SDK/API docs, official dependency libraries, and runtime/client capability are all available.

Users can check the latest release notes in the game project at docs/sdk/CHANGELOG.md. In the SDK repo, the source file is docs/CHANGELOG.md. Tell users to use the changelog cycle for planning, then confirm with official notices, editor prompts, or the current release plan.

Online Bug Fix Expectations ​

When users hit a production online bug:

  • Official dependency-library bugs can usually be hotfixed after official confirmation.
  • Server bugs can usually be hotfixed, but users should verify persistence, settlement, matchmaking, CloudData, and other online state impact.
  • Client bugs may require a client release and full platform rollout. Tell users to expect at least about two weeks, up to about three weeks for full coverage, and recommend workarounds during that window.

Useful workaround advice: disable the affected feature, avoid the trigger path, keep using an older API, add compatibility branches, or lower/remove the resource or presentation setting that triggers the client bug.

Resource Migration ​

Custom cloud resources are deployment-environment-specific:

  • User-uploaded custom cloud assets in alpha and production are independent.
  • Official resources are synchronized between alpha and production.
  • Cloud resources are useful for cross-project sharing and download-cache reuse inside the same deployment environment.
  • Project resources travel with the project and are more self-contained across environments, but repeated assets in multiple projects are downloaded per project.

If many custom cloud resources are used in alpha and the project is moving to production, advise the user to contact official staff to synchronize custom resources between environments. For a small number of resources, re-uploading in production may be enough. For project-private resources where self-containment matters, prefer project resources and follow ResourcePathGuide.md.

  • docs/guides/DeploymentAndRuntimeEnvironments.md
  • docs/guides/ResourcePathGuide.md
  • docs/guides/ResourceManifestTroubleshooting.md
  • docs/systems/CloudDataSystem.md
  • docs/systems/ShopAndPaymentSystem.md