3debcd7edd
Every enemy component used to ask the same question - which player SHIP is nearest - so a structure was scenery they flew straight through. A Building is also a plain Node2D, so there was nothing to collide with even if one had tried. EnemyTargets answers the question once, for pursuit, standoff, the lancer's lunge and the ranged weapon together, so they cannot drift into disagreeing about it. It keeps one thumb on the scale: a vessel inside 520px always wins, even against a nearer building, or the fleet could not defend anything by interposing itself and an enemy would fly past the ships shooting it. Buildings get a hitbox - an Area2D in a group, the same shape as a Ship or an asteroid, so EnemyProjectile needed one extra branch rather than a new concept. It applies damage on a tick rather than on area_entered: entry fires once, which is right for a rammer that dies on the first strike, but would let a sniper that drifted inside sit there scratch-free for ever. On a tick, an enemy parked on a structure is besieging it. What one strike costs is data on the enemy definition, for the same reason dies_on_contact is - a lancer arriving at 950px/s is not a sniper drifting into a wall. Also clears the asteroids in test_enemy_projectile_damage. set_process(false) only stops NEW asteroids; the ones already placed keep drifting, and one wandering into the shield vessel parked at (2000, 0) spent its single charge so the projectile fired next killed it. That failed about one parallel suite run in thirty and never in isolation. Clearing them is what the other combat tests already do. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
39 lines
2.1 KiB
GDScript
39 lines
2.1 KiB
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)
|
|
# Interior detail drawn on top of the hull, as consecutive PAIRS of points
|
|
# (a, b, c, d -> segments a-b and c-d). Every enemy used to be a single flat
|
|
# outline, which left the artillery and the turret spawner as the same
|
|
# octagon at two sizes - the silhouette carried no information about what a
|
|
# thing did. Kept as DATA rather than a per-type draw branch, for the same
|
|
# reason hull_points is: adding an enemy must not mean editing Enemy.gd.
|
|
@export var detail_lines: PackedVector2Array = PackedVector2Array()
|
|
# Rings, as triples of (centre x, centre y, radius). Sensor domes, muzzles
|
|
# and bay openings all read better as circles than as polygon chords.
|
|
@export var detail_rings: PackedVector2Array = PackedVector2Array()
|
|
# #82: this enemy is destroyed by the impact when it reaches a player vessel,
|
|
# rather than shrugging it off and lining up another pass. Data, not a type
|
|
# check: the chaser rams because ramming is its whole behaviour, while a
|
|
# sniper that happens to drift into a ship has not spent itself doing it.
|
|
@export var dies_on_contact: bool = false
|
|
# #101: what one strike against a player structure takes off it. A rammer
|
|
# spends itself on the hit and so hits hardest; a stand-off enemy that drifts
|
|
# into a wall barely scratches it, its real threat being its weapon.
|
|
@export var contact_damage: int = 6
|
|
@export var core_color: Color = Color(0.06, 0.02, 0.03)
|
|
@export var component_scenes: Array[PackedScene] = []
|