Crafting immersive experiences that bridges players and game worlds.
Gameplay and Engine Dev
Wingstrike
“WingStrike” is a mobile top-down shootem up game featuring large-scale enemy waves, squad-building mechanics, and progression-driven gameplay.
Players recruit and upgrade aircraft units while fighting through increasingly dense combat encounters and multi-phase boss battles. The game focuses on responsive combat pacing, scalable enemy encounters, and fast mobile gameplay sessions.
The title has accumulated 100k+ downloads on Google Play.
Buff System:
I designed and implemented a modular data-driven Buff System integrated into our ECS-style gameplay framework. The system was built around extensibility, deterministic execution order, and runtime decoupling, allowing gameplay designers to author and tune buffs through data while still supporting highly specialized gameplay behaviors through runtime operations.
The framework separates buff definitions, runtime state, and executable behavior into independent layers. Buff data is authored through configurable presets, runtime state is stored inside ECS-compatible containers, and gameplay behavior is implemented through isolated BuffOps registered through a centralized factory pipeline.
Data-Driven Gameplay Architecture
One of the main design goals was enabling gameplay iteration without requiring direct changes to gameplay code. Instead of hardcoding logic into combat systems, buffs are represented as configurable gameplay presets containing stack behavior, trigger conditions, stat modifiers, gameplay tags, operation types, and runtime parameters.
For more specialized behaviors that could not be represented through simple stat modifiers, the system supports modular runtime operations called BuffOps. Each BuffOp encapsulates a single gameplay behavior such as lifesteal, shielding, aura propagation, or conditional buff application.
All BuffOps are registered through a factory/registry layer, allowing new gameplay mechanics to be added without modifying the core BuffSystem itself. This architecture keeps the core framework stable while allowing gameplay behaviors to scale cleanly throughout development.
Event-Driven Runtime Pipeline
The BuffSystem operates on top of a centralized gameplay event pipeline rather than directly coupling buffs to combat logic. Runtime gameplay events such as damage, hit, death, healing, and periodic updates are collected from the simulation world and dispatched to matching BuffOps through typed runtime triggers.
This event-driven model significantly reduced dependencies between gameplay systems while allowing complex combat interactions and chained gameplay effects to remain modular and maintainable.
The runtime pipeline also processes gameplay events in a deterministic order, helping maintain combat consistency across reactive gameplay interactions, stacking effects, and event-triggered abilities.
Runtime Performance and ECS Integration
To reduce runtime overhead, active buffs are stored inside ECS-compatible BuffContainerComponents rather than allocated as independent runtime objects. Each entity owns a lightweight runtime container holding active BuffInstances and minimal runtime state required for execution.
The system also implements dirty-state stat aggregation. Runtime stats are only recalculated when buff state changes occur, avoiding unnecessary per-frame stat recomputation during combat-heavy gameplay scenarios.
Technical Design Highlights
-
Data-driven buff authoring pipeline
-
Factory/registry-based BuffOp architecture
-
Event-driven gameplay effect dispatching
-
ECS-compatible runtime storage
-
Deterministic gameplay processing order
-
Dirty-state stat recomputation
-
Stack-aware and source-aware buff tracking
-
Modular lifecycle callbacks (OnApply / OnRemove / OnStackChange)
-
Gameplay tag propagation system
-
Extensible trigger pipeline for combat interactions
MMO-Style Combat Framework：
Combat was designed as an event-driven pipeline rather than a single hardcoded damage function. The goal was to support MMO-style combat interactions where hit detection, damage calculation, mitigation, shields, healing, death handling, buffs, and modifiers can all interact through clear runtime stages.
The system processes combat through centralized simulation events such as HitEvent, DamageEvent, DamageResolvedEvent, HealEvent, HealResolvedEvent, and DeathEvent. This keeps combat logic decoupled from projectiles, buffs, shields, and gameplay modifiers while still allowing each system to react to combat results in a predictable order.
MMO-Style Combat Pipeline
Instead of applying damage immediately when a projectile hits, the system separates combat into multiple stages:
This structure makes the combat system easier to extend. For example, dodge, projectile pierce, critical hits, penetration, defense, resistance, shields, and death triggers are handled as separate steps instead of being mixed into one large damage function.
This is closer to an MMO-style combat model, where damage is not just “collision equals HP loss,” but a sequence of gameplay rules that can be modified by stats, buffs, equipment, and special effects.
Modular Validation and Formula Layers
The system includes a modular pre-hit gate pipeline through IPreHitGate, allowing new hit-blocking rules to be added with priority ordering. This can support mechanics such as dodge, immunity, shield block, invulnerability windows, or special combat rules without rewriting the main combat flow.
Damage calculation is also split into outgoing and incoming formula contexts. The outgoing stage handles attacker-side logic such as critical hits, damage multipliers, penetration, and offensive modifiers. The incoming stage handles target-side logic such as defense, resistance, mitigation, and defensive modifiers.
This separation makes the system easier to reason about and closer to scalable RPG/MMO combat architecture.
Shield, Healing, and Death Resolution
Damage is resolved through a layered health model. Non-true damage first interacts with shields, then applies remaining damage to health. The system publishes a DamageResolvedEvent before applying final state changes, allowing other gameplay systems such as buffs, lifesteal, reactive shields, or UI feedback to respond to the resolved combat result.
Healing follows the same event-driven approach. Heal requests are processed into resolved heal events, including applied healing and overflow healing. This enables mechanics such as overheal-to-shield conversion or healing-triggered buffs.
Death is also published as an explicit event instead of being handled inline, allowing kill effects, death triggers, rewards, and presentation systems to respond cleanly.
Projectile and Stat Snapshot Support
The combat system supports projectile-based combat by resolving damage from projectile entities while preserving the original source entity. If the original source stats are unavailable, the system can fall back to a projectile stat snapshot.
This is important for MMO-style projectile behavior because projectiles may need to preserve the attacker’s stats at fire time. It prevents already-fired projectiles from being incorrectly affected by later stat changes, while still allowing projectile-specific damage profiles and weapon IDs to participate in combat resolution.
Technical Design Highlights
-
Event-driven combat resolution pipeline
-
MMO-style staged damage processing
-
Hit validation separated from damage calculation
-
Modular pre-hit gate system
-
Outgoing and incoming formula contexts
-
Critical hit, penetration, defense, and resistance handling
-
Shield-before-health damage resolution
-
Heal overflow support
-
Projectile source stat snapshotting
-
Explicit resolved damage, healing, and death events
-
Designed to integrate cleanly with BuffSystem and projectile systems