Game Engine Integration Guide

This parent page explains the common MiniGame integration model and provides entry points for engine-specific adaptations such as Cocos Creator, Laya, and Unity.

1. Scope

MiniGame provides unified integration capabilities for mainstream HTML5 and cross-platform game projects. Different engines vary in build artifacts, scripting runtime, resource management, lifecycle, and platform bridge mechanisms. On top of the common SDK capabilities, the platform provides engine-specific adaptations that better match common project workflows.

For engine-specific integration, refer to:

2. Common Integration Model

Regardless of engine, integration usually includes the following steps:

• Create a game project and obtain the platform-assigned game identifier, environment configuration, and required secrets.

• Initialize the SDK or platform bridge layer during game startup.

• Align the game lifecycle with the platform lifecycle, including start, pause, resume, close, and error retry.

• Integrate account, sharing, ads, payments, leaderboards, data reporting, and other capabilities as needed.

• Adjust resource paths, loading strategies, package structure, and compatibility settings during build for the target platform.

• Complete debugging in the test environment before submitting for production review.

3. Engine Adaptation Differences

3.1 Cocos Creator

Cocos Creator projects usually integrate through a plugin SDK or project template. The plugin should handle initialization configuration, platform API wrappers, build configuration injection, and debugging assistance as much as possible, reducing direct dependency on platform details in business code.

Key areas:

• Plugin installation and version compatibility.

• Build templates, resource paths, and screen orientation configuration.

• TypeScript or JavaScript API usage.

• Coordination between platform callbacks and the Cocos lifecycle.

3.2 Laya

Laya projects usually need to focus on script bridging, resource loading paths, asynchronous API calls, and runtime compatibility. During integration, avoid scattering platform checks throughout business logic; use a unified adapter layer to centralize MiniGame capability calls.

Key areas:

• Initialization entry point and loading order.

• Async callback, Promise, or event dispatch model.

• Published resource directory and CDN path handling.

• Separation between debugging and production configuration.

3.3 Unity

Unity projects need to focus on build targets, WebGL runtime, JavaScript bridging, package resources, and platform review requirements. If the game is published to multiple platforms, encapsulate platform differences in a dedicated adapter layer to avoid polluting core gameplay code.

Key areas:

• Unity version, build target, and template configuration.

• Interface bridging between WebGL and the host platform.

• First-screen loading, resource splitting, and memory usage.

• Synchronization between platform capability callbacks and Unity main-thread logic.

4. Recommended Engineering Boundaries

• Core gameplay should not directly depend on platform SDKs; access external capabilities through a platform adapter layer.

• Initialization, login, payment, ads, sharing, and similar capabilities should be idempotent to avoid state corruption from repeated callbacks.

• Separate test and production environment configuration, and do not hardcode sensitive parameters in public artifacts.

• Provide explicit fallback strategies when platform capabilities fail, so baseline playability is not affected.

• Keep build configuration differences between engines minimal to reduce multi-platform publishing maintenance cost.

5. Verification Checklist

• The game starts normally from the standard build artifact of the target engine.

• SDK initialization, environment configuration, and error callbacks are observable.

• Pause, resume, background switching, back, and close lifecycle behavior meets expectations.

• Optional capabilities such as sharing, ads, payments, and leaderboards are integrated only when enabled, and error paths are verified.

• First-screen loading time, package size, resource paths, and cache strategy meet platform requirements.