I wrote recently about migrating from LayaAir to Cocos Creator. This post is the follow-up: what I actually built with Cocos after the migration settled.

The game is Cosmic Summon, a gacha merge tower defense. Players summon heroes randomly, place them on a grid, and combine duplicates to evolve them through seven rarity tiers. Enemies spawn in 50 waves themed around real constellations. Bosses appear every five waves.

This post walks through the technical decisions behind three of the core systems: the merge mechanic, the wave progression, and the enemy variety system.

The Merge Mechanic

The merge mechanic is the heart of the gameplay loop. When a player places two heroes of the same type on adjacent grid cells, they combine into a higher-tier version of that hero.

Implementing this cleanly in Cocos Creator came down to three decisions.

First, the grid is a logical structure, not a visual one. Heroes are rendered at pixel-perfect positions but their merge eligibility is determined by grid coordinates stored on the hero component itself:

@ccclass('HeroUnit')
export class HeroUnit extends Component {
  @property
  heroType: string = '';

  @property
  tier: number = 1;

  @property
  gridX: number = 0;

  @property
  gridY: number = 0;

  canMergeWith(other: HeroUnit): boolean {
    if (this.heroType !== other.heroType) return false;
    if (this.tier !== other.tier) return false;
    if (this.tier >= 7) return false;
    return this.isAdjacent(other);
  }

  isAdjacent(other: HeroUnit): boolean {
    const dx = Math.abs(this.gridX - other.gridX);
    const dy = Math.abs(this.gridY - other.gridY);
    return (dx + dy) === 1;
  }
}

Second, the merge animation is handled by the Cocos Animation component, not by manually tweening properties. The animation plays on a temporary placeholder node while the old heroes are destroyed and the new hero is instantiated underneath. This lets the visual feel smooth even when the game logic is doing three things at once.

Third, the merge trigger is evaluated on placement, not continuously. The old approach ran merge checks every frame, which was fine for small boards but slowed down on mobile with 20+ units on screen. Evaluating only on placement cut the CPU overhead substantially.

The Wave Progression System

50 waves is enough that designing them manually would be tedious and error-prone. I built a wave configuration system based on JSON data, evaluated at runtime:

interface WaveConfig {
  waveNumber: number;
  constellation: string;
  spawns: EnemySpawn[];
  isBossWave: boolean;
  durationSeconds: number;
}

interface EnemySpawn {
  enemyType: string;
  count: number;
  delayMs: number;
  spawnPattern: 'single' | 'cluster' | 'stream';
}

The wave data lives in a JSON file shipped with the game. At runtime, the wave manager reads the config for the current wave, schedules enemy spawns through Cocos's scheduler, and triggers the wave completion event when all enemies are defeated or reach the base.

This separation of wave configuration from wave logic made iteration vastly faster. When playtesting revealed that wave 23 was too easy, I adjusted the JSON file, not the code.

One useful pattern: rather than spawning enemies instantly, each spawn is scheduled with a delay. This gives waves a sense of rhythm rather than a wall of enemies arriving simultaneously. For the 5-wave boss cadence, the boss spawn is preceded by a 2-second pause and a visual warning effect.

The Enemy Variety System

28 enemy types sounds like a lot, but the complexity comes from how they interact with each other and with the player's hero composition, not from the types being mechanically unique.

Each enemy is a composition of behaviors rather than a monolithic class:

@ccclass('Enemy')
export class Enemy extends Component {
  @property([Component])
  behaviors: Component[] = [];

  @property
  hp: number = 100;

  @property
  speed: number = 50;

  takeDamage(amount: number) {
    const reflect = this.getBehavior(ReflectBehavior);
    if (reflect && reflect.shouldReflect()) {
      reflect.reflectDamage(amount);
      return;
    }
    this.hp -= amount;
    if (this.hp <= 0) this.onDeath();
  }

  onDeath() {
    const split = this.getBehavior(SplitBehavior);
    if (split) split.spawnSplitUnits();
    this.node.destroy();
  }

  getBehavior<T extends Component>(type: new () => T): T | null {
    return this.behaviors.find(b => b instanceof type) as T || null;
  }
}

Behaviors are reusable: StealthBehavior vanishes for N seconds, SplitBehavior spawns smaller enemies on death, ReflectBehavior bounces damage, SummonBehavior spawns minions during lifetime, ShieldBehavior absorbs a fixed amount before taking hit damage.

A Reflector Splitter enemy is simply an enemy with both ReflectBehavior and SplitBehavior attached. This compositional approach made adding new enemy types trivial, usually just a new config entry referencing existing behaviors.

Performance Considerations

With up to 40 active enemies plus 15 heroes plus projectiles plus UI, the scene can hit several hundred nodes during peak combat. A few patterns that helped.

Object pooling for projectiles and hit effects. These are spawned frequently and destroyed frequently. Pooling eliminates the allocation cost:

const pool = new NodePool('Projectile', 50);
const projectile = pool.get() ?? instantiate(projectilePrefab);
pool.put(projectile);

Avoid per-frame array allocations in update loops. Reusing a single array reference across frames rather than creating new arrays each update saved measurable frame time on lower-end phones.

Batching sprite draws. Cocos Creator supports auto-batching for sprites in the same atlas. Grouping projectile sprites and enemy sprites into their respective atlases meant the whole scene rendered in a handful of draw calls rather than dozens.

What I'd Do Differently Next Time

Two things.

First, I'd design the merge system's edge cases earlier. The current implementation handles the common cases well but had weird behavior when players rapidly placed and removed units in the same frame. Fixing it required refactoring the placement event queue late in development.

Second, I'd build a dev-mode wave editor from the start. I eventually built one to accelerate balance testing, but the first 30 waves were designed with manual JSON editing, which was slow and error-prone. An in-editor tool would have paid for itself many times over.

Playable

Cosmic Summon runs in any modern browser at phyfun.com with no download or account required. The iOS version is currently in App Store review.

If you're building anything in Cocos Creator and want to see a working example of these patterns, the game is a decent reference for gacha systems, merge mechanics, and wave-based progression in a single project.

This article was written with AI assistance.