Enemy.gd now resolves stats/hull/color from EnemyDefinition resources and composes behaviour from capability components (EnemyPursuitComponent holds today's chase-the-nearest-ship logic), the same shape Ship.gd already uses for vessels. Fleet lookups go through a "player_fleet" group instead of a hardcoded ../Fleet sibling path, so an enemy parented anywhere (e.g. under a planet surface's SurfaceFeatures) still finds it. Also closes a real gap: enemies previously had no way to damage the fleet at range at all (Ship only reacted to physical contact, Projectile.gd was player-only). Ship.take_damage() is now a proper entry point - contact damage routes through it unchanged - and EnemyProjectile lets an enemy component fire at player_ships. Both ranged enemy archetypes in #45/#46 build on this. Part of the #40 conquest-mechanic breakdown.
19 lines
789 B
GDScript
19 lines
789 B
GDScript
class_name EnemyDefinition
|
|
extends Resource
|
|
|
|
# Data-driven enemy stats and appearance, mirroring VesselDefinition's role
|
|
# for player ships. Enemy.gd instantiates component_scenes exactly like
|
|
# Ship.gd does, so behaviour (pursuit, ranged fire, ...) lives in capability
|
|
# components rather than in a type switch here.
|
|
|
|
@export var enemy_id: String = "chaser"
|
|
@export var display_name: String = "Chaser"
|
|
@export var max_hp: int = 3
|
|
@export var speed: float = 140.0
|
|
@export var acceleration: float = 260.0
|
|
@export var rotation_speed: float = 6.0
|
|
@export var hull_points: PackedVector2Array = PackedVector2Array([
|
|
Vector2(0, -16), Vector2(12, 0), Vector2(0, 16), Vector2(-12, 0),
|
|
])
|
|
@export var glow_color: Color = Color(1.0, 0.15, 0.2)
|
|
@export var component_scenes: Array[PackedScene] = []
|