Character Module Bonus Systems in Games: Data-Driven Design Practice

Background and Problem Definition

In games built around character progression, a “module bonus” is a secondary modifier applied to a character’s base attributes. It usually does not change the character’s initial stat sheet. Instead, it adds extra attributes, talents, or skill effects, and these effects can produce significant numerical changes under specific combat conditions.

A common characteristic of such systems is that the same character can perform differently under different modules. Values such as HP, attack, defense, attack speed, and damage reduction may vary, which changes the character’s role in a stage or encounter.

From an engineering perspective, the core difficulty of a module bonus system is not simply “how much is added.” It lies in three areas:

• Diversity of modifier sources: fixed-value bonuses, percentage bonuses, and conditionally triggered bonuses.
• Determinism of stacking rules: whether modifiers stack additively or multiplicatively, and whether they override or coexist.
• Verifiability of numerical balance: any configuration change must not break the overall combat curve.

A healthy module system is therefore a combination of data modeling, a calculation engine, and balance validation.

Core Modeling of the Module Bonus System

The first modeling step is to abstract a “module” as a pure data description rather than scattering its logic across the codebase. A module configuration usually contains three parts:

• Stat modifiers: fixed-value or percentage modifiers applied to base attributes such as HP, attack, and defense.
• Talents or passives: effects triggered under specific conditions, for example, “ignore a portion of defense when attacking a marked target.”
• Skill or cost modifiers: adjustments related to combat resources, such as deployment cost, cooldown time, or energy.

{
  "moduleId": "M_001",
  "level": 3,
  "statModifiers": [
    { "stat": "hp",      "op": "add", "value": 160 },
    { "stat": "attack",  "op": "add", "value": 69 },
    { "stat": "attack",  "op": "mul", "value": 0.08 }
  ],
  "talents": [
    { "type": "cost_refund", "value": 0.80, "trigger": "on_retreat" },
    { "type": "attack_speed", "value": 17, "trigger": "before_first_kill" },
    { "type": "damage_reduce", "value": 0.35, "trigger": "before_first_kill" }
  ]
}

The benefit of configuration-driven design is clear: designers and numerical specialists can tune parameters without touching code, while engineers only need to implement a generic “interpret and execute” engine. In principle, adding a new character or module no longer requires new business logic code. A new configuration file can be released instead.

Layered Design for Stat Calculation

Much of the confusion in stat calculation comes from mixing flat additions and percentage multiplications without a clear order. A standard implementation should follow a fixed calculation order. The commonly used layered model is as follows:

1. Base layer: the character’s initial attributes.
2. Flat modifier layer: the accumulation of all fixed-value modifiers.
3. Percentage modifier layer: percentage modifiers are aggregated and applied as a single multiplier.
4. Conditional trigger layer: temporary modifiers calculated dynamically based on combat state.

def calc_final_stats(base, modifiers, context):
    # Layer 1: Base values
    hp = base['hp']; attack = base['attack']; defense = base['defense']
    # Layer 2: Accumulate flat modifiers
    flat = {'hp': 0, 'attack': 0, 'defense': 0}
    mul  = {'hp': 0, 'attack': 0, 'defense': 0}
    for m in modifiers:
        if m['op'] == 'add':
            flat[m['stat']] += m['value']
        elif m['op'] == 'mul':
            mul[m['stat']] += m['value']
    # Layer 3: Add flat values first, then apply percentage modifiers
    # to avoid operation-order ambiguity
    final = {}
    for s in ('hp', 'attack', 'defense'):
        final[s] = (base[s] + flat[s]) * (1 + mul[s])
    # Layer 4: Conditional modifiers, such as damage reduction
    # or penetration when the target is marked
    if context.get('target_marked'):
        final = apply_conditional(final, context)
    return final

The key design principle is: apply additions first, then multiplications. Percentage modifiers should be accumulated additively rather than multiplied one by one. The first rule ensures that results are unique and reproducible. The second rule prevents balance disasters where multiple percentage modifiers are chained together and cause exponential power growth.

Abstracting Conditional Triggers and State Machines

In the original design, many effects are conditional. Examples include:

• Increase attack speed before killing an enemy.
• Restart timing after losing a barrier.
• Reduce damage taken from the character’s own blocking units.

If these effects are implemented with many if-else branches, the system quickly becomes hard to maintain. A better approach is to abstract conditions into composable state machines and listeners.

• Model combat states as a set of subscribable events, such as entering attack, hitting, being hit, killing, and gaining or losing a shield.
• Register each talent effect as a response function for a specific event type.
• Parse condition expressions with a unified rule engine. For example: “35% damage reduction when kill count is 0.”

# Event subscription example: The attack speed buff is active
# before the first kill and is removed after the kill
@on_event('before_kill')
def atk_speed_boost(entity):
    entity.add_buff('attack_speed', value=17)
@on_event('after_kill')
def clear_pre_kill_buff(entity):
    entity.remove_buff('attack_speed')

With event-driven design, tangled conditional logic is broken into independent, individually testable units. When a new conditional talent is added, only a new listener needs to be registered.

Verifiable Numerical Balance

After a module system is released, the biggest risk is loss of numerical control. A seemingly harmless change may be amplified by percentage stacking into fatal power creep. To maintain balance, a quantifiable validation process is required:

1. Damage expectation model: use analytical formulas or Monte Carlo simulations for attack, attack speed, penetration, and damage reduction to estimate expected damage and survival duration in a specific stage.
2. Regression baselines: define baseline metrics for each character or module, such as damage per second or effective HP. Automatically compare them after each configuration change and trigger an alert when thresholds are exceeded.
3. Edge cases: construct extreme scenarios, such as maximum damage reduction or maximum penetration, to ensure there are no anomalies such as negative damage after damage reduction stacking or frame overflow after attack speed stacking.

def validate_balance(config, baseline):
    metrics = simulate(config, rounds=10000)
    for key, expected in baseline.items():
        deviation = abs(metrics[key] - expected) / expected
        assert deviation < 0.05, f"{key} deviates from baseline by {deviation:.1%}; please review the configuration"

Automating balance validation and integrating it into continuous integration can catch problems before configuration changes are merged, instead of waiting for player feedback that a module is too strong and then rolling it back.

Engineering Implementation and Maintainability Recommendations

To build a high-quality module bonus system, the following engineering practices are recommended:

• Strictly separate configuration from logic: manage all numerical values as data tables and keep only a generic calculation engine on the program side.
• Define explicit calculation order and stacking rules: apply flat values first and percentage modifiers later, and document these rules to avoid ambiguity during collaboration.
• Abstract effects into composable units: use events, buffs, and listeners instead of hard-coded conditional branches.
• Shift balance validation left: establish metric baselines and run automatic regression checks in CI.
• Make tuning traceable and hot-update friendly: keep version records for each parameter adjustment and support updating configurations without a full release through configuration delivery or hot-loading mechanisms.

Conclusion

A module bonus system may look like it only “adds a few points to a character’s stats,” but it is actually a complete engineering system involving data modeling, calculation engines, state machines, and numerical validation. The real technical value lies in turning “how much is added” into “how to calculate deterministically, how to extend maintainably, and how to validate balance verifiably.” With layered calculation, event-driven design, and automated validation, a character progression system can remain both flexible and controllable over the long term.