Week 3: Enemy Spawner Implementation & Player Combat Development

Posted byViktor YankulchovskiPosted inUncategorized

Introduction

For the third week of our group game development project, my primary focus was designing and implementing a networked enemy spawner. This system introduces enemies into the game world when a player triggers a specific object (such as a trap). The spawner manages enemy instantiation at set intervals, enforces a maximum enemy limit, and synchronizes these events across all players using Photon Engine and Unity.

Design Rationale

Although my main responsibility is programming, I approached this task with a design-oriented mindset. My goals for the enemy spawner were to:

  • React to player interaction by activating only when triggered.
  • Enforce a maximum enemy count to maintain game balance and performance.
  • Introduce a spawn delay to create tension and pacing.
  • Synchronize enemy spawning across the network so all players share the same experience.

I collaborated with the design team to ensure the spawner’s behavior supports our weekly group objectives and enhances the intended gameplay loop.

Implementation

Below is the core script I developed for the enemy spawner. It leverages Photon Engine for networked object spawning and Unity’s game object system for positioning.

Above is the core implementation of the enemySpawnerActivator script:

Key Features

  • Trigger Activation: The enemySpawnerActivator flag is set by player interaction, ensuring the spawner only activates at the right time.
  • Networked Spawning: Uses Fusion’s Runner.Spawn to ensure all players see the same enemies.
  • Spawn Limiting: Checks the current enemy count before spawning new ones to maintain the maximum limit.
  • Randomized Positioning: Spawns enemies at random points within a defined radius for unpredictability.

Part 1: Melee Attack System

At the design team’s request, I developed a prototype melee combat system for our close-range character. This required:

  • Ensuring network-synchronized attack motions
  • Distinguishing melee/ranged characters via characterType
  • Creating a temporary weapon animation (pending final art assets)
Above is the core implementation of the playerMelee script:

Design Choices

  • Positioned weapon via code (characterTransform()) to support future art iteration
  • Created procedural weapon swing animation (arc rotation)
  • Added attack delay to prevent spamming
  • Used Networked properties to sync attack states

Part 2: Mouse-Driven Player Rotation

To improve combat fluidity, I replaced keyboard-based rotation with mouse-aiming:

Above is the core implementation of the playerRotation script:

Key Features

  • Ground-plane projection for consistent 3D aiming
  • Smooth rotation interpolation (Quaternion.Slerp)
  • Network-synced orientation using Fusion’s [Networked]

Collaborative Process

Documented transform requirements for 3D artists

Design Coordination

  • Worked with designers to balance attack speed/delay
  • Created temporary visual feedback for testing (weapon arc)

Technical Challenges

  • Synchronized animation states across network
  • Resolved camera-raycasting issues in multiplayer
  • Optimized FixedUpdateNetwork for input responsiveness

Art Pipeline Preparation

  • Structured code to easily replace procedural animation with future art assets

Reflection & Iteration

What Worked Well

  • Hybrid approach (code-driven animation + network sync) accelerated prototyping
  • Mouse rotation significantly improved playtest feedback (“More intuitive than keyboard turning”)

Areas for Improvement

  • Current weapon reset uses linear interpolation – could benefit from animation curves
  • Networked rotation occasionally jitters at high latencies

Next Steps

  • Collaborate with artists to replace procedural animation
  • Implement hit detection with enemy spawner system
  • Add visual/audio feedback for attacks

References

Leave a comment

Design a site like this with WordPress.com
Get started