Shopee Games: Engine Selection, Optimization, and Engineering Practices for H5 Game Development

Shopee Games team aims to enrich the e‑commerce platform with interactive and entertaining lightweight games that can be rapidly iterated without significantly increasing the app size. To achieve this, they needed a suitable game engine and a matching toolchain.

The team evaluated candidate engines based on several factors: 2D vs 3D focus, developer friendliness (TypeScript support, documentation quality, dev‑led workflow), performance and compatibility, completeness of the official toolchain, open‑source nature, presence of successful game cases, availability of official support, and commitment to continuous updates.

After narrowing the field to 2D engines, they excluded 3D‑oriented options (Unity3D, LayaBox, Three.js, Babylon.js) and older or insufficiently featured engines such as lufylegend.js, Cocos2d‑JS, and CreateJS. The final comparison focused on Egret, Cocos Creator, and Phaser (which uses Pixi). All three support TypeScript and WebGL with comparable performance. Egret was chosen because its canvas mode runs well on low‑end Southeast Asian devices, its developer‑centric philosophy aligns with the team’s strengths, and it provides a mature toolchain including DragonBones animation and an editor.

Having selected Egret as the core engine, Shopee Games built a customized toolchain on top of it. Work on the engine included performance reporting (FPS, DrawCall, First Paint, GPU Size), performance optimizations such as static texture atlases, dynamic texture atlases (which merge textures at render time to reduce DrawCall, especially for user‑generated outfits), node‑ordering adjustments (e.g., transforming img1>text>img1 into img1>img1>text to lower DrawCall), and enabling DrawCall optimization via Benchmark.init(null,null,true) or setting Benchmark.optimizeDc to true. Engine trimming removed unused modules (Native code, Runtime, WX/minigame compatibility, KTX texture, ETC Loader), cutting the frontend JavaScript load by about 16 KB (~7%). Bug fixes addressed iOS 14/15 rendering stalls, DragonBone rendering issues, and network/audio problems; the team even contributed a fix for the iOS stutter back to the official Egret repository. API enhancements added convenient wrappers for common operations like setting node dimensions. A public utility library (SoundUtil, DragonUtil, ResUtil, SmartEvent) was created, saving roughly two weeks of development effort per project, and extended base UI components with lifecycle hooks to reduce boilerplate and prevent memory leaks.

To keep the customized engine in sync with the official upstream, the team adopted a double‑remote Git workflow: the custom repository (B) tracks the upstream (A) as a remote, fetches updates, and merges specific tags (e.g., v5.4.0) using git merge v5.4.0 --allow-unrelated-histories . Guidelines to minimize merge conflicts include avoiding renames or deletions of original files, extending functionality via prototype chains, defining internal utility classes without name clashes, making changes additive, and reducing channel‑specific code that would otherwise cause repeated diffs.

The raw Egret project lacked several modern frontend engineering features: no module system (global scope leading to variable pollution), no support for npm or package.json, absence of engineering practices like code review or unit testing, and a complex deployment process that relied on the official GUI build tool without a CLI. To solve these, the team modified the build script to recognize a custom field in package.json instead of merely checking for its presence, thereby allowing a root‑level package.json . They then published the customized engine as an npm package ( @egret-engine/egret-core ) containing a build folder for engine libraries and a tools folder for compile‑time utilities. Integrating Webpack enabled module‑based compilation and server‑side deployment, while reusing the official tools for processing .exml and resource files. The resulting Webpack build produces artifacts identical to the official build, ensuring compatibility.

After these changes, the Egret project resembles a standard web frontend project, allowing the use of linting (ESLint), testing (Jest), and other quality‑gate tools. The team further developed Egret-Webpack-CLI , a scaffolding utility split into a CLI and template repository (base, standard, Shopee, native). Running egret-cli prompts for project details, downloads the appropriate template, and renders a ready‑to‑use Egret project, eliminating manual cloning and configuration.

The final workflow now treats Egret game development like any other frontend project: code is authored in TypeScript, built with Webpack, tested, linted, and deployed via CI/CD pipelines. This shift has enabled advanced patterns such as dynamic code loading, multi‑page applications, and even hybrid Egret+React pages, while markedly improving code quality, development speed, and onboarding experience for new engineers. Beyond engine optimization and engineering, the team has also resolved iOS review challenges, with a forthcoming article detailing the Egret Native integration and its coupling with the Shopee App.