Game Development 24 min read

Optimizing Game Interaction Scenarios with AnnieX: Engine Preheat, Asset Offline Library, and Resource Compression

This article details the 2024 Douyin Spring Festival game interaction optimizations using the AnnieX cross‑platform container, covering engine preheat, a shared offline asset library, and advanced 3D resource compression techniques such as quantization, sparse accessors, and meshopt, along with performance results and future plans.

TikTok Frontend Technology Team
TikTok Frontend Technology Team
TikTok Frontend Technology Team
Optimizing Game Interaction Scenarios with AnnieX: Engine Preheat, Asset Offline Library, and Resource Compression

Business Background

The article is based on the 2024 Douyin Spring Festival activity and introduces the exploration of ByteDance's cross‑platform container AnnieX in the game interaction suite, aiming to improve container optimization capabilities for game interaction scenarios.

AnnieX serves as ByteDance's unified game container for internal e‑commerce, live‑streaming, and user‑generated content across multiple platforms. Many internal games have specific requirements for traffic, device capabilities, and game‑level optimizations, so we continuously deepen our understanding of interactive game characteristics to provide comprehensive engine capabilities, traffic‑operation abilities, and extreme optimization for interactive scenes.

Interactive Suite Introduction

Based on the 2024 Spring Festival activity, we proposed an Interactive Suite on the container side to provide optimization solutions for game interaction scenes. In 2024 we completed engine warm‑up and a public offline asset library, achieving notable optimization results; we also explored game resource (de)compression and more efficient physics engine solutions, aiming to land compression and physics engine support in the 2025 Spring Festival.

Public Offline Asset Library is a resource management tool that centralizes engine resources needed by interactive games. By unpacking the main game package and unifying engine resources, the library reduces game package size and improves runtime efficiency, while reusing engine versions to further cut download time and bandwidth costs.

Engine Warm‑up pre‑heats the game engine during startup, allowing faster loading of the engine package and improving overall game launch speed, thereby enhancing player experience.

Resource Compression & Decompression greatly improves resource utilization, reducing package size and network loading time. Compression is performed during the engine editor's build phase, while decompression occurs in the interactive container at runtime.

Physics Engine – Front‑end game developers typically rely on JS or WASM physics engines, which leave room for performance improvements. We explore providing a more efficient physics engine on the container side to enrich interactive gameplay.

Glossary

(Glossary image omitted for brevity)

Business Pain Points

Engine Dependency: Creating and running interactive scenes requires loading and initializing the game engine, which consumes about 200‑300 ms and can affect performance.

Loading Time vs. User Drop‑off: Game launch time is directly proportional to abnormal user churn; after 1.5 s of loading, each additional 0.5 s results in roughly a 4 % increase in abnormal exits.

To address these issues, we implemented an engine warm‑up solution that delivered significant loading improvements during the 2024 Spring Festival.

Overall Approach

Before optimization, the container only started rendering the first screen after the main game package was fully loaded, causing additional waiting for engine resources. Our solution pre‑loads the engine during the route‑opening phase, uses idle JS thread time for warm‑up, and mounts the warmed‑up instance on a global object for immediate access when the game logic runs.

Technical Details

Toolchain Refactoring

We integrated the speedy-split-chunks plugin into the build tool to split the engine package from the main game bundle and publish it to a static resource distribution platform as a public offline library. A split-engine-adapter component injects warm‑up code and provides fallback logic to ensure stability. Engine packages and their meta files are deployed to the public offline library, allowing multiple games to share the same engine version and reduce bandwidth consumption.

The adapter also hooks the requireModule function; if the global engine instance is missing, it requests the split engine package as a fallback, improving system reliability.

Engine Warm‑up

Clients use the meta file to manage offline library versions. When a page schema enables engine warm‑up, the client pre‑loads the appropriate engine version during routing. The offline library is stored locally, and engine resources are signed to prevent JS injection attacks. During container creation, the engine files are warmed‑up on the JS thread and the instance is attached to a global object.

If warm‑up fails, the front‑end falls back to loading the engine directly, ensuring overall stability.

Business Benefits

Through engine warm‑up and the shared offline asset library, AnnieX reduced the main game package size by 28.05 % and saved tens of thousands of yuan in network bandwidth costs. Loading time improvements ranged from 200 ms to 500 ms across games, with Android PCT90 improving by 32.12 % (PCT50 +20.75 %) and iOS PCT90 improving by 47.24 % (PCT50 +33.89 %).

Resource Compression

Business Pain Points

3D resources are typically large; compressing them reduces loading time and network traffic.

Common 3D formats (glTF, FBX, OBJ) contain geometry, skeletons, animations, materials, etc. We explored compression and decompression techniques for these assets during the 2024 Spring Festival.

Overall Approach

AnnieX applies three main compression methods to geometry and animation data: Quantization, Sparse Accessor, and meshopt.

Technical Details

Geometry Compression & Decompression

Geometry data includes Position, UV, Normal, Tangent, Color, Index, Skeleton, and Blend Shape. Different data types use different quantization bit‑widths (e.g., Position 14 bits, UV 12 bits, Normal 10 bits, etc.) to balance precision and compression ratio.

Quantization

Quantization converts 32‑bit floats to 16‑ or 8‑bit integers, achieving 50 %–25 % compression. It is a lossy process with O(n) complexity.

Sparse Accessor

Derived from the glTF sparse accessor, it stores only non‑zero values and their indices, providing lossless compression with O(n) complexity and very low overhead.

Meshopt

Implements the EXT_meshopt_compression extension using WebAssembly (with asm.js fallback). It optimizes vertex/index order and applies filters (octahedral, quaternion, exponential) to achieve 10 %–20 % compression for geometry and 40 % compression for animation data.

Animation Compression & Decompression

Animation data consists of keyframe times and values. We first resample using the keyframe-resample-wasm library (lossless), then compress times (often using attribute mode) and values (quantizing rotations to 16‑bit with quaternion filter, applying exponential filter to translation/scale). Decompression mirrors the compression steps.

Future Plans

While 2024 saw successful deployment of engine warm‑up and the public offline library, engine warm‑up hit‑rate averaged only 81.33 % and the offline library size continues to grow, prompting the need for better version management and ROI‑based pruning.

Resource compression has demonstrated solid size reductions, but low‑end devices and some iOS models struggle with meshopt decompression performance, leading us to consider native C++ implementations for future stability.

We also plan to explore compression for other asset types such as images, videos, fonts, scripts, and editor‑exported assets (Lottie, Spine) to further reduce overall game package size.

Team Introduction

We are the Douyin Front‑End Architecture – Interactive Experience Technology Team, providing interactive technology solutions for ByteDance businesses. Our products include the SAR Creator for interactive/minigame development, the high‑performance Simple Engine, and the AnnieX interactive container.

We collaborate with the Douyin Front‑End Interactive Creation Team, the Cross‑Platform Framework Team, the Open Platform Mini‑Game Team, and the User Growth Incentive Front‑End Team to continuously explore innovative business forms within the ByteDance ecosystem.

Next Issue Preview

The next theme in the series will be Editor Techniques and Practices , focusing on tools that streamline interactive scene creation, debugging, building, and packaging, and enable efficient content production workflows.

Previous Issue Review

2024 Douyin Happy Chinese New Year (Part 1): The Technology Behind the “Recruiting God of Wealth” Interactive Game

resource-compressionengine preheatmeshopt3D assetsAnnieXGame Optimizationinteractive container
TikTok Frontend Technology Team
Written by

TikTok Frontend Technology Team

We are the TikTok Frontend Technology Team, serving TikTok and multiple ByteDance product lines, focused on building frontend infrastructure and exploring community technologies.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.