How Oasis Engine Created a Multi‑User Metaverse‑Style Fortune Park

Background and Challenges

In its eighth year, the "Five Blessings" (五福) project made huge breakthroughs in both business model and technical innovation. The goal was to open the platform to third‑party merchants, creating a metaverse‑like "Fortune Park" where each building represents a merchant. Over 30,000 mini‑programs from merchants participated, 30× the previous year, marking the start of full digital service openness.

The park is a real‑time, third‑person roaming project with many buildings and digital humans. Challenges included massive resource loading, high scene complexity with many effects, tight art‑development schedule (≈2 months), and uncertainty from opening to external merchants.

Ensuring smooth loading for large resources.

Maintaining performance and memory with many scene elements and effects.

Coordinating art and development under a tight timeline.

Handling business uncertainties from full merchant openness.

Architecture Design

The front‑end is divided into three layers:

Game layer: built with Oasis Engine and its physics, effect, and custom material libraries.

Communication layer: the

game

object provides event communication between business and game layers.

Business layer: handles generic logic such as fortune value display, settings, music, and networking.

For the network layer, both RPC and RTS were used. RPC offers robust load balancing and reliability, while RTS provides higher real‑time performance for position synchronization and player interactions.

Scene Construction and Rendering

To accelerate progress, art and development worked in parallel: artists built scenes in the Oasis editor, while developers added collision boxes for game logic.

Building layout and building IDs were defined early, allowing developers to implement logic before art assets were finished.

Collision boxes are placed in separate nodes named by ID, and all code references these boxes, decoupling business logic from art. Additional boxes prevent digital humans from leaving the closed park space.

Scene Splitting Strategy

Initial loading on Android devices exceeded 20 seconds. The team split the scene into four parts: the entrance shop, game entry, wish tree and central buildings as the first screen; the outer ring buildings into two sub‑scenes; and low‑priority ambience animations as the last sub‑scene.

First‑screen: entrance shop, game entry, wish tree, central buildings, and floor.

Outer ring: split into two sub‑scenes.

Ambient animations: loaded last.

After splitting, the first‑screen load time dropped by over 20 MB, and with pre‑fetching most devices load the park in under 10 seconds; typical online load time is around 3 seconds.

Placeholder models with minimal geometry replace unseen buildings during the first screen, making the loading feel instantaneous.

On‑demand Prefab loading uses script paths; the same script works even after art updates.

const [box, animatorController] = await engine.resourceManager.load([
  {
    url: "/Assets/MS_BX/MS_BX.fbx",
    type: AssetType.Prefab
  },
  { url: "/Assets/MS_BX/ANI_BX", type: AssetType.AnimatorController }
]);

Scene Rendering

All buildings use a custom BakePBRMaterial that pre‑bakes light reflections into a texture, eliminating runtime dynamic lighting.

The environment uses IBL; the .env file is uploaded in the editor and selected for use.

Real‑time shadows are added for digital humans, while static gray planes simulate shadows for NPCs and treasure chests, with scaling animations to enhance visual feedback.

Lottie animations (fireworks, shop entrance, etc.) are added via the @oasis-engine/lottie package.

Digital Human

When users first enter the park, a popup offers a skin related to their participation year. Users can switch skins via the digital‑human settings.

Animation and Outfit Change

Both male and female avatars have a base skeleton and six skin variants (one default, five year‑related). After modeling, parts are imported into the editor, materials are adjusted, and the ARK SDK loads, swaps, and animates them at runtime.

Anchors are placed at the foot center to keep positioning stable when scaling. Adding an

Animator

component and setting animation states drives actions.

Skinning works by sharing the same skeleton between body and hair; the hair model is bound to the skeleton so it moves correctly.

Virtual asset paths are mapped to HTTP URLs, simplifying asset management.

"data":{
  "hair":"/assets/hair01",
  "cloth":"assets/cloth02",
  ...
}

Joystick Control

The joystick offset calculates an instantaneous speed, which determines the animation to play and updates the character position.

Multiplayer

Both state sync and frame sync are combined: clients sample and send their pose to the server (upstream), and the server periodically broadcasts all users' poses back (downstream). Frequency is tuned (≈100 ms up, 500 ms down) and prediction logic smooths movement.

Upstream: client‑side logic, periodic sampling.

Downstream: server restores other users' poses.

Higher upstream frequency reduces distortion; prediction logic further improves smoothness.

Behavior Management

Interactions (e.g., wishing, card exchange) are triggered when avatars approach; a button appears above the other avatar. A dirty flag system updates distances only when movement occurs.

Behaviors are processed in

onUpdate

, adjusting speed and animation based on the current state.

Performance Optimization

During launch the park achieved an average frame rate of 46 fps (with half‑VSync), crash rate of 0.24 ‰, and T2 latency of ~3000 ms, running smoothly at 60 fps on iPhone 5s.

Loading Optimization

Original assets exceeded 100 MB (≈70 MB gzipped). Scene splitting reduced first‑screen load by >20 MB, and overall load time dropped ~5 %.

glTF KHR_mesh_quantization compression cut file size and memory by ~45 %.

Frame Rate Optimization

Peak triangle count reached 600 k+. Animator culling stops updates for invisible renderers, reducing CPU load.

Hiding Lottie components reduced draw calls from 93 to 52.

Memory Optimization

GPU texture compression (ASTC, PVRTC) cut texture memory by ~75 %. Reducing texture sizes (256 px for reflection maps, 512 px for base maps) further lowered per‑building memory usage.

Conclusion

The Fortune Park project demonstrated the robustness of Oasis Engine’s physics, shadows, digital humans, 2D, and input systems in a complex business scenario, while highlighting areas for toolchain improvement such as texture compression integration.