How a Modular Gameplay Engine Transforms Marketing Activity Development

Background

As HuoLaLa’s business grows, the marketing team continuously explores fine‑grained activity strategies such as acquisition, activation, conversion and retention. The original activity implementation became highly coupled, making new features, code changes, and regression testing labor‑intensive, while misuse of ThreadLocal and redundant cache/DB queries degraded service performance.

1. Activity Gameplay Introduction

To address these problems, a "gameplay engine" was designed. The engine provides a development contract that isolates code development and runtime, a mechanism that prevents code decay, and an abstracted capability orchestration layer that supports workflow composition for activity gameplay.

2. Gameplay Engine Overview

2.1 Why Design a Gameplay Engine?

The existing architecture could not support rapid iteration of new activity types, required extensive regression testing for any shared code changes, and suffered from performance issues caused by ThreadLocal misuse and unnecessary cache/DB lookups.

2.2 Engine Design

The engine is organized into three layers:

Activity Layer : contains the concrete activity implementations.

Capability Orchestration Layer : defines reusable capabilities and their composition.

Process Node Layer : represents the low‑level workflow nodes.

This three‑tier design enables clear separation of concerns and facilitates reuse across different business scenarios.

2.3 Engine Orchestration

Orchestration is defined by dimensions such as capability interfaces (typically two methods to separate success and failure paths) and the sequencing of capabilities. The engine currently does not support cyclic calls (e.g., A→B→A), but future extensions will handle more complex flow parsing.

2.4 Engine Execution Flow

Execution is driven by a JSON‑like configuration file that maps process nodes to capabilities. Example configuration files are shown below.

{
  "start":"load.model",
  "load.model":{
    "成功":"risk.access#lottery"
  },
  "risk.access#lottery":{
    "准入":"activity.access",
    "不准入":"page.error"
  },
  "activity.access":{
    "准入":"activity.page#lottery",
    "不准入":"page.error"
  }
}

3. Configuration Examples

3.1 Lottery Activity Sample

The lottery activity uses capabilities such as "risk access", "activity page", and visual rendering. Diagrams illustrate the page composition and capability flow.

3.2 Invite‑Friends Activity Sample

A similar configuration is provided for an invite‑friends activity, demonstrating how different capabilities are wired together to achieve the desired workflow.

{
  "start":"load.model#inviteFriends",
  "load.model#inviteFriends":{
    "成功":"activty.access#inviteFriends"
  },
  "activty.access#inviteFriends":{
    "准入":"risk.access#inviteFriends",
    "不准入":"page.error"
  },
  "risk.access#inviteFriends":{
    "准入":"activity.page#inviteFriends",
    "不准入":"page.error"
  }
}

4. Future Planning

The engine roadmap includes:

Rich visualisation features for capabilities and workflow diagrams.

Dynamic creation, loading, and activation of configuration files for one‑click activity rollout.

Support for repeated capability calls in orchestration (e.g., A→B→A) and additional flow‑file parsers.

These enhancements aim to further reduce development friction and increase flexibility for marketing activity engineering.