Minigame docs

English

简体中文

English

简体中文

Engine Adaptation Overview ​

1. Relationship Between the Platform and Engines ​

The platform is an engine-agnostic runtime environment. The platform itself is not tied to any specific game engine; instead, it provides low-level foundational capabilities such as rendering (WebGL/WebGL2/Metal), audio (WebAudio/InnerAudio), networking (HTTP/WebSocket/TCP/UDP), and file systems. Game engines connect to these low-level capabilities through an adaptation layer, so that game artifacts compiled or exported by an engine can run in the minigame environment.

This means that no matter which game engine is used, as long as the corresponding platform adaptation is completed, the game can run in OpenPaaS.

2. Why Engine Adaptation Is Needed ​

Different game engines have their own forms of compiled artifacts and runtime dependencies:

  • HTML5 engines (such as Cocos Creator, Laya, Egret): The compiled artifacts are JavaScript code, and at runtime they usually depend on the browser's BOM and DOM APIs. However, the minigame environment is not a browser and has no global objects such as document or window, so these APIs need to be simulated through an adaptation layer (Adapter), or the engine's official team must complete native adaptation for the minigame platform.

  • Native engines (such as Unity, Tuanjie Engine, Cocos2d-x, etc.): The compiled artifacts are machine code or intermediate code. Through WebAssembly (Wasm) technology, the engine and game logic are compiled into Wasm modules, which then interact with the platform layer via JavaScript glue code, enabling them to run in the minigame environment.

The core goal of engine adaptation is: to adapt based on the engine's compiled artifacts, so that games can run in OpenPaaS in a low-cost, high-performance manner.

3. Adaptation Approaches ​

Depending on the engine type, there are two main adaptation approaches:

3.1 JavaScript Engine Adaptation ​

For JavaScript/TypeScript-based HTML5 game engines, the adaptation approaches are mainly:

  • Official engine adaptation: The engine's official team builds a minigame export option into the build tool, and developers can simply select the export platform directly in the engine IDE without manually handling the underlying adaptation. Engines such as Cocos Creator, LayaAir, and Egret have completed this type of adaptation.

  • Adapter adaptation layer: For engines that have not yet been officially adapted, an Adapter layer can be introduced between the engine and game code. It uses the OpenPaaS API to simulate browser objects such as window and document, allowing the engine to run transparently in the minigame environment.

3.2 WebAssembly Engine Adaptation ​

For game engines targeting native platforms (such as Unity, Tuanjie Engine, Cocos2d-x, and Unreal Engine (UE)), the adaptation approach is based on WebAssembly technology:

  • Compilation and conversion: Use the Emscripten toolchain to compile the engine and game logic written in C/C++/C# into WebAssembly modules.
  • Platform integration: Use conversion plugins and the SDK to connect the engine's rendering, audio, input, network, and other modules to the minigame's low-level capabilities.
  • Performance optimization: Provide dedicated performance optimization solutions tailored to the characteristics of the minigame environment (high startup speed requirements, limited memory, the need to load resources on demand, etc.).

The advantage of this approach is that it keeps the original engine toolchain and technology stack unchanged. Developers do not need to rewrite the core game logic; they can complete the minigame adaptation using conversion tools.