spaceship/ChaserEnemyDefinition.tres

[gd_resource type="Resource" script_class="EnemyDefinition" load_steps=3 format=3]

[ext_resource type="Script" path="res://EnemyDefinition.gd" id="1"]
[ext_resource type="PackedScene" path="res://EnemyPursuitComponent.tscn" id="2"]

[resource]
script = ExtResource("1")
enemy_id = "chaser"
display_name = "Chaser"
max_hp = 3
speed = 140.0
acceleration = 260.0
rotation_speed = 6.0
hull_points = PackedVector2Array(0, -16, 12, 0, 0, 16, -12, 0)
glow_color = Color(1, 0.15, 0.2, 1)
dies_on_contact = true
component_scenes = Array[PackedScene]([ExtResource("2")])
Add enemy foundation: definitions, components, ranged damage (#44) 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. 2026-08-15 14:43:29 +02:00			`[gd_resource type="Resource" script_class="EnemyDefinition" load_steps=3 format=3]`

			`[ext_resource type="Script" path="res://EnemyDefinition.gd" id="1"]`
			`[ext_resource type="PackedScene" path="res://EnemyPursuitComponent.tscn" id="2"]`

			`[resource]`
			`script = ExtResource("1")`
			`enemy_id = "chaser"`
			`display_name = "Chaser"`
			`max_hp = 3`
			`speed = 140.0`
			`acceleration = 260.0`
			`rotation_speed = 6.0`
			`hull_points = PackedVector2Array(0, -16, 12, 0, 0, 16, -12, 0)`
			`glow_color = Color(1, 0.15, 0.2, 1)`
Implement #80, #81, #82 and #83 #80 - desktop combat. The mouse aims, the left button fires, and the number keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin sticks are built for thumbs; on a desktop they mean dragging a virtual stick with a pointer that could simply BE the crosshair. The pointer path hands its heading to FireStickController rather than driving weapons itself, so exactly one thing in the scene aims a gun, and a held stick wins - a finger on it is a deliberate act, a mouse resting somewhere is not. Abilities gained fire_at(), which aims and fires in one call instead of pretending to be a press-drag-release touch. It is gated on the absence of a touchscreen, because Godot emulates a mouse button from every touch and without that a tap on a phone would fire the guns. The gate has an explicit override, and not for tidiness: headless reports a touchscreen, so with the automatic answer alone the aiming could never be exercised by a test and the only covered behaviour would be the guard. #81 - the bottom-left control hint is gone, from both scenes and from GameController. #82 - a chaser is destroyed by the impact when it reaches a vessel. It used to pass through the wreck untouched and line up another pass, which made a ramming enemy strictly better than any other. Data-driven per enemy (dies_on_contact), because a sniper that happens to drift into a ship has not spent itself doing it - and routed through take_damage, so it dies exactly as it dies to gunfire. The enemy is told about the impact BEFORE the ship resolves its own damage, since resolving it can free the ship. #83 - the research tree's buy button is gone; tapping a node twice buys it. Deliberately "the same node twice" rather than a timed double-tap: no window to miss on a slow phone, no accidental purchase while browsing, and the first tap always does something visible, so the second is never a blind commitment. The status line now says "Tap again to research" - with the button gone it is the only thing distinguishing an affordable node from an unaffordable one. test_enemy_collision asserted the exact behaviour #82 reversed, and now checks the ram costs both. Suite 117/117. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-08-21 18:49:47 +02:00			`dies_on_contact = true`
Add enemy foundation: definitions, components, ranged damage (#44) 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. 2026-08-15 14:43:29 +02:00			`component_scenes = Array[PackedScene]([ExtResource("2")])`