spaceship/tests/test_enemy_mothership.gd

269 lines
11 KiB
GDScript3
Raw Permalink Normal View History

Enemy mothership (#53) A large, slow capital enemy that periodically launches chasers and artillery on their own intervals and fires a heavily telegraphed line beam capable of killing several player vessels at once. Spawning reuses #52's EnemySpawnerComponent as-is via two preset scenes (EnemySpawnerComponentChaser.tscn: 5s/chaser, EnemySpawnerComponentArtillery.tscn: 18s/max 2/artillery) rather than adding multi-type support to the component - two instances of a single-purpose component is the composition this codebase already uses everywhere ("enemy bomber" in the original request is read here as the existing artillery enemy's slow telegraphed AOE, not a new enemy type - flagged as a judgment call in the ticket). New EnemyBigLaserComponent.gd ("big_laser") fires a standalone EnemyBigLaserBeam on a long cooldown - the beam owns its whole charge/ fire/flash sequence once launched, so the mothership dying mid-charge doesn't cancel an already-telegraphed shot, same design as EnemyArtilleryComponent/ArtilleryShell. The aim direction is locked once in launch() and never re-read - nothing in the charging phase touches the fleet's position again, which is what makes it dodgeable. Damage is a line-segment check (projection + perpendicular distance) against every player_ships member; Ship.take_damage() already handles shield absorption per-ship. MothershipEnemyDefinition.tres: max_hp 60, speed 35 (slow), a ~96-unit hull, pursuit + two spawners + big_laser, no type switch anywhere - every stat from the definition, every behaviour from a component. Tests: new tests/test_enemy_mothership.gd, split into beam mechanics (tested directly, not through the component's own cooldown timing, which would make the geometry assertions timing-fragile) and the composed definition (tested through a real Enemy.tscn instance). Screenshot of the charge telegraph mid-countdown. Full suite: 80/80. Found and fixed a real bug along the way, in EnemySpawnerComponent.gd (#52): its `enemy_scene: PackedScene = preload("res://Enemy.tscn")` member-level preload could get permanently baked in as a broken, empty PackedScene when a definition's component_scenes chain led back to Enemy.tscn while it was still mid-load - confirmed empirically via ResourceLoader.has_cached() being true (a good copy existed) while the preloaded reference's own resource_path was empty. This only surfaces when a SINGLE definition composes two instances of a script carrying such a preload (the mothership's chaser/artillery spawner presets; #52's single-spawner turret never hit it). Fixed by resolving enemy_scene lazily via load() on first use instead of at compile time, and additionally made a fresh spawner count down from a full interval before its first spawn rather than firing on tick one, which also happens to keep two sibling spawners with different intervals from ever landing their first attempt on the same frame. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 10:19:02 +02:00
extends SceneTree
# Headless gameplay test: run with
# godot --headless -s res://tests/test_enemy_mothership.gd
# Forgejo #53: a big, slow capital enemy that spawns chasers/artillery on
# their own intervals and fires a heavily telegraphed line beam.
#
# Split into two independent parts, each with its own fleet setup:
# A. EnemyBigLaserBeam mechanics, tested directly (not through the
# component's own tick/cooldown timing, which would make the precise
# geometry assertions below timing-fragile):
# 1. the telegraph holds for the charge - no damage, phase stays
# CHARGING, for most of charge_time
# 2. the locked aim direction never changes even if the fleet moves
# away mid-charge
# 3. three ships in a line all die from one shot; a ship that steps
# outside beam_half_width before the shot lands survives
# 4. a shielded ship in the beam survives, losing exactly one charge
# B. The composed enemy_mothership definition, tested through a real
# Enemy.tscn instance:
# 5. structural composition - pursuit, two DISTINCT spawner presets
# (chaser/artillery), big_laser, no type switch anywhere
# 6. it launches both chaser and artillery spawns on their own
# intervals
# 7. it closes on the fleet without ever exceeding its own defined
# speed - "never reaches ramming speed"
#
# Repo-wide lessons from #52, both apply again here:
# - main.get_node(...).set_process(false) has to happen in _process()'s
# first real tick, not _initialize() - a disable made before the node
# has finished entering the tree doesn't reliably stick.
# - overriding an @export interval on an already-ticking component does
# NOT reset its in-progress countdown - reset the timer variable too.
var game_state: Node
var main: Node
var fleet: Node
var beam_script: Script
var beam: Node2D
var line_a: Node
var line_b: Node
var line_c: Node
var shield_ship: Node
var initial_aim: Vector2
var mothership: Node
var chaser_spawner: Node
var artillery_spawner: Node
var mothership_start_position: Vector2
var closing_elapsed: float = 0.0
var stage: int = 0
var elapsed: float = 0.0
func _initialize() -> void:
game_state = root.get_node("GameState")
#84: move 215 root files into a folder hierarchy Everything lived in one flat directory, so a diff gave no clue what area it touched and finding the file you wanted meant knowing its exact name. Twelve folders now, grouped by what a thing IS rather than what type it is - a vessel's definition, its component scenes and its upgrade resources sit together, because that is the set you read when you change one of them. buildings core controllers enemies logistics planets resources shaders surface ui vessels vfx world 332 files moved and every res:// reference rewritten - 306 files touched, including the autoload and main-scene paths in project.godot. Nothing renamed: this is purely where files sit, so the diff is a pile of pure moves and no behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at the root, where Godot and the export preset expect them. Verified three ways, because a suite alone would not have caught all of it: the full 117 pass, the web export builds clean, and the game renders. The export is why that matters. The FIRST export after the move failed with "Attempt to open script 'res://GameState.gd'" - the old path - while project.godot on disk plainly said res://core/GameState.gd. That is this project's documented Android FUSE mtime trap: Godot served a cached copy of a file whose content had changed. A `touch` fixed it. Nothing in the test suite would have found that, because the suite runs from a copy on a native filesystem - the one place the bug cannot happen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
beam_script = load("res://enemies/EnemyBigLaserBeam.gd")
Rework how a game starts: dev mode, a bare opening, and fleet growth Adds a Dev Mode entry to the main menu and takes the play-testing conveniences out of a normal game, which turn out to be the same change from two directions. DEV MODE. Banks 2000 of every resource, grants 500 research points, and plants one of each planet type in the chunks around the spawn. Built ON TOP of reset_new_game() rather than beside it, so a dev game is a normal game plus a stock rather than a second definition of "fresh game" to keep in sync. Offered only when running from Godot - OS.has_feature("editor"), the tag an export clears - as is the map editor. Hidden AND guarded: pressing either anyway is refused, because visibility is presentation and the rule is the rule. The menu now lays its stack out in code. Hiding two of four entries with scene-authored offsets would leave holes in a shipped build - the same failure the HUD columns had - so it measures the entries that actually exist and centres on them. A NORMAL GAME NOW HANDS OVER NOTHING. No 500 banked ore (removed from both reset_new_game and the autoload's own default, so the two cannot disagree), and no gas giant guaranteed in the origin chunk. Both were play-testing conveniences that had become part of the real world's shape: every player got the same landmark in the same place. Play-testing wanted all four planet types anyway, and a normal game wanted none of them - different needs, now different mechanisms. WorldGen cannot read GameState back (an autoload is not resolvable as a global identifier that early, the hazard PlanetSetups.gd already works around), so GameState.dev_mode's setter PUSHES the flag down. World generation stays static and dependency-free, GameState stays the single source of truth, and dev planting is applied after every rng draw so a dev world and a normal one differ only in those four chunks. FLEET SIZE. BASE_FLEET_SIZE was doing two jobs - how many slots exist AND how many ships you start with - which forced a new game to open with a full fleet, leaving the first ship crafter nothing to do. Split into BASE_FLEET_SIZE (3 slots) and STARTING_SHIP_COUNT (1 vessel), so the opening has two empty slots to fill. A third copy of the old value turned up in PlanetAtmosphereController, hardcoded as spawn_ships(5) and silently degraded into "however many slots exist" once max_fleet_size() clamped it. The doctrine branch now runs 3 -> 10 slots. Wing (30 -> 15) and Squadron (70 -> 35, 2 -> 1 points) are cut hardest: they are no longer a mid-game luxury but the ordinary way out of the opening, and pricing them as a luxury made the early game feel stuck. Armada follows at 90/2. Two new tiers, Battlegroup and Grand Fleet, grant +2 each - seven single-vessel nodes in one lane would be a long monotonous chain for a branch that only ever does one thing. DEFAULT_FORMATION grows to 10 slots, because max_fleet_size() clamps to its length and a doctrine past that would charge real resources for nothing; test_fleet_growth.gd asserts that invariant directly. TEST FALLOUT, all of it from the deliberate change rather than a defect: - Tests that silently inherited the old 5-ship default now ask for the fleet they need. Several had to crew it from their first frame rather than _initialize(), where the engine's deferred tree-entry finalization undoes it - the same hazard those tests already documented for set_process(false). - test_planet_landing_proximity and test_return_position_matches_planet take the FIRST chunk holding a planet and land there. The guaranteed gas giant had been masking that this can now be a black hole, which destroys ships on contact. They exclude it, and clear the asteroids the field already placed. - test_pivot_controls measured rotation with angle_difference, which wraps at +/-pi, so a hold that turned a full circle read as no rotation. Latent flakiness that only ever showed under load; it now reads the controller's unwrapped pivot_hold_amount. - test_research_points was failing on ore, not points: can_unlock() checks the ore price too, and a fresh game banks nothing now. - test_gas_system's "a reachable gas source near the spawn" premise moved to dev mode, which is where that guarantee now lives. Full suite green at 97/97. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 12:10:14 +02:00
# Four vessels are crewed below, past BASE_FLEET_SIZE's 3 slots, so the
# capacity doctrines are granted rather than assumed.
# #219: berths come from Fleet Offices now, not from research. Three of
# them buy the same four-vessel fleet the doctrines used to. Left
# unstocked deliberately - upkeep is not charged for the first
# 25 seconds, and nothing here runs that long.
for _berth in range(3):
game_state.add_building(GameState.BUILDING_FLEET_OFFICE,
Vector2(3000.0 + 400.0 * float(_berth), 3000.0))
#84: move 215 root files into a folder hierarchy Everything lived in one flat directory, so a diff gave no clue what area it touched and finding the file you wanted meant knowing its exact name. Twelve folders now, grouped by what a thing IS rather than what type it is - a vessel's definition, its component scenes and its upgrade resources sit together, because that is the set you read when you change one of them. buildings core controllers enemies logistics planets resources shaders surface ui vessels vfx world 332 files moved and every res:// reference rewritten - 306 files touched, including the autoload and main-scene paths in project.godot. Nothing renamed: this is purely where files sit, so the diff is a pile of pure moves and no behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at the root, where Godot and the export preset expect them. Verified three ways, because a suite alone would not have caught all of it: the full 117 pass, the web export builds clean, and the game renders. The export is why that matters. The FIRST export after the move failed with "Attempt to open script 'res://GameState.gd'" - the old path - while project.godot on disk plainly said res://core/GameState.gd. That is this project's documented Android FUSE mtime trap: Godot served a cached copy of a file whose content had changed. A `touch` fixed it. Nothing in the test suite would have found that, because the suite runs from a copy on a native filesystem - the one place the bug cannot happen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
main = load("res://world/Main.tscn").instantiate()
Enemy mothership (#53) A large, slow capital enemy that periodically launches chasers and artillery on their own intervals and fires a heavily telegraphed line beam capable of killing several player vessels at once. Spawning reuses #52's EnemySpawnerComponent as-is via two preset scenes (EnemySpawnerComponentChaser.tscn: 5s/chaser, EnemySpawnerComponentArtillery.tscn: 18s/max 2/artillery) rather than adding multi-type support to the component - two instances of a single-purpose component is the composition this codebase already uses everywhere ("enemy bomber" in the original request is read here as the existing artillery enemy's slow telegraphed AOE, not a new enemy type - flagged as a judgment call in the ticket). New EnemyBigLaserComponent.gd ("big_laser") fires a standalone EnemyBigLaserBeam on a long cooldown - the beam owns its whole charge/ fire/flash sequence once launched, so the mothership dying mid-charge doesn't cancel an already-telegraphed shot, same design as EnemyArtilleryComponent/ArtilleryShell. The aim direction is locked once in launch() and never re-read - nothing in the charging phase touches the fleet's position again, which is what makes it dodgeable. Damage is a line-segment check (projection + perpendicular distance) against every player_ships member; Ship.take_damage() already handles shield absorption per-ship. MothershipEnemyDefinition.tres: max_hp 60, speed 35 (slow), a ~96-unit hull, pursuit + two spawners + big_laser, no type switch anywhere - every stat from the definition, every behaviour from a component. Tests: new tests/test_enemy_mothership.gd, split into beam mechanics (tested directly, not through the component's own cooldown timing, which would make the geometry assertions timing-fragile) and the composed definition (tested through a real Enemy.tscn instance). Screenshot of the charge telegraph mid-countdown. Full suite: 80/80. Found and fixed a real bug along the way, in EnemySpawnerComponent.gd (#52): its `enemy_scene: PackedScene = preload("res://Enemy.tscn")` member-level preload could get permanently baked in as a broken, empty PackedScene when a definition's component_scenes chain led back to Enemy.tscn while it was still mid-load - confirmed empirically via ResourceLoader.has_cached() being true (a good copy existed) while the preloaded reference's own resource_path was empty. This only surfaces when a SINGLE definition composes two instances of a script carrying such a preload (the mothership's chaser/artillery spawner presets; #52's single-spawner turret never hit it). Fixed by resolving enemy_scene lazily via load() on first use instead of at compile time, and additionally made a fresh spawner count down from a full interval before its first spawn rather than firing on tick one, which also happens to keep two sibling spawners with different intervals from ever landing their first attempt on the same frame. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 10:19:02 +02:00
root.add_child(main)
fleet = main.get_node("Fleet")
func _process(delta: float) -> bool:
elapsed += delta
match stage:
0:
if elapsed < 0.1:
return false
main.get_node("EnemySpawner").set_process(false)
main.get_node("AsteroidField").set_process(false)
main.get_node("BuildController").set_process(false)
for ship in fleet.ships:
if is_instance_valid(ship):
ship.queue_free()
fleet.ships.clear()
# --- A: line-up three ships along +X, one shielded further out ---
fleet.add_ship(game_state.VESSEL_INTERCEPTOR)
line_a = fleet.ships[fleet.ships.size() - 1]
_pin(line_a, Vector2(300, 0))
fleet.add_ship(game_state.VESSEL_INTERCEPTOR)
line_b = fleet.ships[fleet.ships.size() - 1]
_pin(line_b, Vector2(400, 0))
fleet.add_ship(game_state.VESSEL_INTERCEPTOR)
line_c = fleet.ships[fleet.ships.size() - 1]
_pin(line_c, Vector2(500, 0))
fleet.add_ship(game_state.VESSEL_SHIELD)
shield_ship = fleet.ships[fleet.ships.size() - 1]
_pin(shield_ship, Vector2(600, 0))
if not shield_ship.has_shield():
return _fail("shield ship has no shield right after being added")
#84: move 215 root files into a folder hierarchy Everything lived in one flat directory, so a diff gave no clue what area it touched and finding the file you wanted meant knowing its exact name. Twelve folders now, grouped by what a thing IS rather than what type it is - a vessel's definition, its component scenes and its upgrade resources sit together, because that is the set you read when you change one of them. buildings core controllers enemies logistics planets resources shaders surface ui vessels vfx world 332 files moved and every res:// reference rewritten - 306 files touched, including the autoload and main-scene paths in project.godot. Nothing renamed: this is purely where files sit, so the diff is a pile of pure moves and no behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at the root, where Godot and the export preset expect them. Verified three ways, because a suite alone would not have caught all of it: the full 117 pass, the web export builds clean, and the game renders. The export is why that matters. The FIRST export after the move failed with "Attempt to open script 'res://GameState.gd'" - the old path - while project.godot on disk plainly said res://core/GameState.gd. That is this project's documented Android FUSE mtime trap: Godot served a cached copy of a file whose content had changed. A `touch` fixed it. Nothing in the test suite would have found that, because the suite runs from a copy on a native filesystem - the one place the bug cannot happen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
var beam_scene: PackedScene = load("res://enemies/EnemyBigLaserBeam.tscn")
Enemy mothership (#53) A large, slow capital enemy that periodically launches chasers and artillery on their own intervals and fires a heavily telegraphed line beam capable of killing several player vessels at once. Spawning reuses #52's EnemySpawnerComponent as-is via two preset scenes (EnemySpawnerComponentChaser.tscn: 5s/chaser, EnemySpawnerComponentArtillery.tscn: 18s/max 2/artillery) rather than adding multi-type support to the component - two instances of a single-purpose component is the composition this codebase already uses everywhere ("enemy bomber" in the original request is read here as the existing artillery enemy's slow telegraphed AOE, not a new enemy type - flagged as a judgment call in the ticket). New EnemyBigLaserComponent.gd ("big_laser") fires a standalone EnemyBigLaserBeam on a long cooldown - the beam owns its whole charge/ fire/flash sequence once launched, so the mothership dying mid-charge doesn't cancel an already-telegraphed shot, same design as EnemyArtilleryComponent/ArtilleryShell. The aim direction is locked once in launch() and never re-read - nothing in the charging phase touches the fleet's position again, which is what makes it dodgeable. Damage is a line-segment check (projection + perpendicular distance) against every player_ships member; Ship.take_damage() already handles shield absorption per-ship. MothershipEnemyDefinition.tres: max_hp 60, speed 35 (slow), a ~96-unit hull, pursuit + two spawners + big_laser, no type switch anywhere - every stat from the definition, every behaviour from a component. Tests: new tests/test_enemy_mothership.gd, split into beam mechanics (tested directly, not through the component's own cooldown timing, which would make the geometry assertions timing-fragile) and the composed definition (tested through a real Enemy.tscn instance). Screenshot of the charge telegraph mid-countdown. Full suite: 80/80. Found and fixed a real bug along the way, in EnemySpawnerComponent.gd (#52): its `enemy_scene: PackedScene = preload("res://Enemy.tscn")` member-level preload could get permanently baked in as a broken, empty PackedScene when a definition's component_scenes chain led back to Enemy.tscn while it was still mid-load - confirmed empirically via ResourceLoader.has_cached() being true (a good copy existed) while the preloaded reference's own resource_path was empty. This only surfaces when a SINGLE definition composes two instances of a script carrying such a preload (the mothership's chaser/artillery spawner presets; #52's single-spawner turret never hit it). Fixed by resolving enemy_scene lazily via load() on first use instead of at compile time, and additionally made a fresh spawner count down from a full interval before its first spawn rather than firing on tick one, which also happens to keep two sibling spawners with different intervals from ever landing their first attempt on the same frame. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 10:19:02 +02:00
beam = beam_scene.instantiate()
beam.charge_time = 0.5
beam.beam_range = 1000.0
beam.beam_half_width = 35.0
beam.damage = 3
root.add_child(beam)
beam.launch(Vector2.ZERO, Vector2(1, 0))
initial_aim = beam.aim_direction
elapsed = 0.0
stage = 1
return false
1:
# --- 1. telegraph holds, no damage, for most of the charge ---
if elapsed < beam.charge_time * 0.6:
return false
if beam.phase != beam_script.Phase.CHARGING:
return _fail("beam left CHARGING before charge_time elapsed")
for ship in [line_a, line_b, line_c, shield_ship]:
if not is_instance_valid(ship):
return _fail("a ship in the beam's path died before the charge finished")
# Move line_b out of the beam's path - this alone also shifts
# fleet.get_centroid() (line_b is part of the same fleet), which
# is exactly the "the fleet moved mid-charge" event stage 2
# needs to prove the beam does NOT re-track. line_a/line_c/
# shield_ship stay exactly where they were.
_pin(line_b, Vector2(400, 400))
elapsed = 0.0
stage = 2
return false
2:
if elapsed < beam.charge_time * 0.6:
return false
if beam.aim_direction != initial_aim:
return _fail("beam re-tracked the fleet mid-charge - aim_direction changed from %s to %s" % [
initial_aim, beam.aim_direction
])
elapsed = 0.0
stage = 3
return false
3:
# --- 3 + 4. the shot has landed by now ---
if is_instance_valid(line_a):
return _fail("line_a (still in the beam) survived the shot")
if is_instance_valid(line_c):
return _fail("line_c (still in the beam) survived the shot")
if not is_instance_valid(line_b):
return _fail("line_b (moved out of the beam before it fired) was killed anyway")
if not is_instance_valid(shield_ship):
return _fail("the shielded ship died despite having a shield")
if shield_ship.shield_charges != 0:
return _fail("shield charges did not drop to exactly 1 lost (charges=%d)" % shield_ship.shield_charges)
# --- B: reset to a clean single-ship fleet for the mothership ---
for ship in fleet.ships:
if is_instance_valid(ship):
ship.queue_free()
fleet.ships.clear()
fleet.spawn_ships(1, Vector2(3000, 0))
#84: move 215 root files into a folder hierarchy Everything lived in one flat directory, so a diff gave no clue what area it touched and finding the file you wanted meant knowing its exact name. Twelve folders now, grouped by what a thing IS rather than what type it is - a vessel's definition, its component scenes and its upgrade resources sit together, because that is the set you read when you change one of them. buildings core controllers enemies logistics planets resources shaders surface ui vessels vfx world 332 files moved and every res:// reference rewritten - 306 files touched, including the autoload and main-scene paths in project.godot. Nothing renamed: this is purely where files sit, so the diff is a pile of pure moves and no behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at the root, where Godot and the export preset expect them. Verified three ways, because a suite alone would not have caught all of it: the full 117 pass, the web export builds clean, and the game renders. The export is why that matters. The FIRST export after the move failed with "Attempt to open script 'res://GameState.gd'" - the old path - while project.godot on disk plainly said res://core/GameState.gd. That is this project's documented Android FUSE mtime trap: Godot served a cached copy of a file whose content had changed. A `touch` fixed it. Nothing in the test suite would have found that, because the suite runs from a copy on a native filesystem - the one place the bug cannot happen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
mothership = load("res://enemies/Enemy.tscn").instantiate()
Enemy mothership (#53) A large, slow capital enemy that periodically launches chasers and artillery on their own intervals and fires a heavily telegraphed line beam capable of killing several player vessels at once. Spawning reuses #52's EnemySpawnerComponent as-is via two preset scenes (EnemySpawnerComponentChaser.tscn: 5s/chaser, EnemySpawnerComponentArtillery.tscn: 18s/max 2/artillery) rather than adding multi-type support to the component - two instances of a single-purpose component is the composition this codebase already uses everywhere ("enemy bomber" in the original request is read here as the existing artillery enemy's slow telegraphed AOE, not a new enemy type - flagged as a judgment call in the ticket). New EnemyBigLaserComponent.gd ("big_laser") fires a standalone EnemyBigLaserBeam on a long cooldown - the beam owns its whole charge/ fire/flash sequence once launched, so the mothership dying mid-charge doesn't cancel an already-telegraphed shot, same design as EnemyArtilleryComponent/ArtilleryShell. The aim direction is locked once in launch() and never re-read - nothing in the charging phase touches the fleet's position again, which is what makes it dodgeable. Damage is a line-segment check (projection + perpendicular distance) against every player_ships member; Ship.take_damage() already handles shield absorption per-ship. MothershipEnemyDefinition.tres: max_hp 60, speed 35 (slow), a ~96-unit hull, pursuit + two spawners + big_laser, no type switch anywhere - every stat from the definition, every behaviour from a component. Tests: new tests/test_enemy_mothership.gd, split into beam mechanics (tested directly, not through the component's own cooldown timing, which would make the geometry assertions timing-fragile) and the composed definition (tested through a real Enemy.tscn instance). Screenshot of the charge telegraph mid-countdown. Full suite: 80/80. Found and fixed a real bug along the way, in EnemySpawnerComponent.gd (#52): its `enemy_scene: PackedScene = preload("res://Enemy.tscn")` member-level preload could get permanently baked in as a broken, empty PackedScene when a definition's component_scenes chain led back to Enemy.tscn while it was still mid-load - confirmed empirically via ResourceLoader.has_cached() being true (a good copy existed) while the preloaded reference's own resource_path was empty. This only surfaces when a SINGLE definition composes two instances of a script carrying such a preload (the mothership's chaser/artillery spawner presets; #52's single-spawner turret never hit it). Fixed by resolving enemy_scene lazily via load() on first use instead of at compile time, and additionally made a fresh spawner count down from a full interval before its first spawn rather than firing on tick one, which also happens to keep two sibling spawners with different intervals from ever landing their first attempt on the same frame. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 10:19:02 +02:00
mothership.enemy_id = "enemy_mothership"
mothership.position = Vector2.ZERO
main.add_child(mothership)
elapsed = 0.0
stage = 4
return false
4:
if elapsed < 0.15:
return false
# --- 5. structural composition, no type switch ---
if mothership.max_hp != 60:
return _fail("enemy_mothership max_hp is %d, expected 60" % mothership.max_hp)
Implement #85, #86, #87 and #88 #85 - on a computer the sticks and the pivot pair are dead weight: WASD steers, the mouse aims, Q/E pivot. All four go together the first time a keyboard or a mouse is used, and only where there is no touchscreen. A touch device with a keyboard attached keeps everything, because a finger is still a way to play it. #86 - the default gun shoots faster (500 -> 850) and further (320 -> 620). The interesting half is that a bolt now STOPS where the gun's range ends. Projectile lifetime is derived from fire_range at launch rather than set independently, so the distance a shot covers and the distance the aim guide draws are one number. They were two, and they disagreed: the guide promised 320 while a bolt actually flew speed * lifetime = 750, so shots landed on things well past the line saying where they would stop. #87 - the ship that fires throws sparks, so a shot is visibly attached to the vessel it came from; with a whole fleet shooting there was nothing tying the two together, which started mattering once the player had to aim. Enemy deaths gained a shockwave ring and roughly double the debris - a kill used to read as a small red puff that was easy to miss in a fight. #88 - everything moves 1.5x faster: fleet cruise, every vessel's max_speed and acceleration, and every enemy's. Scaling the enemies too keeps it a change of TEMPO rather than a difficulty cut, and scaling acceleration alongside speed keeps the handling from #77's tuning intact. Three tests carried assertions that were really about one balance pass: test_enemy_mothership pinned a literal 35.0 and now compares against the chaser, which is what "never reaches ramming speed" actually means; test_planet_atmosphere_transition flew far enough at the new speed to reach the landed garrison, and now clears it, since that test is about the handoff and not about a fight it never meant to pick. Also repaired real data loss, caught only because test_gas_burner failed: Godot had silently re-serialised GasBurnerBuildingDefinition.tres and dropped collected_outputs, capabilities, map_radius and map_phase, and had recreated a stale copy of it at the pre-#84 root path. Without collected_outputs no transporter ever collects a burner's energy. Both files restored from git. It had also resurrected pre-#84 SNAPSHOTS of Main.tscn, Planet.tscn and lunar_surface.gdshader at their old root paths - the root Main.tscn still carried 27 references to the flat layout. They are dead weight the engine never loads, since project.godot and every preload point into the folders, but they are exactly the kind of thing that wastes an hour later when someone edits the wrong copy. Deleted, and the root is now down to ui_theme.tres, icon.svg, web_shell.html and the two config files. Suite 119/119. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 02:19:14 +02:00
# Compared against the CHASER rather than a hardcoded 35.0. What
# matters is that this thing lumbers - "never reaches ramming
# speed", per the note at the top of this file - and that is a
# statement about the two relative to each other. The literal was
# a hidden dependency on one balance pass: #88 raised every speed
# in the game by 1.5 and this failed while the mothership was
# still exactly as slow, relatively, as it had always been.
var definitions: Script = load("res://enemies/EnemyDefinitions.gd")
var chaser_speed: float = float(definitions.get_definition("chaser").speed)
if mothership.speed >= chaser_speed * 0.5:
return _fail("enemy_mothership moves at %s against a chaser's %s - it is meant to lumber" \
% [mothership.speed, chaser_speed])
Enemy mothership (#53) A large, slow capital enemy that periodically launches chasers and artillery on their own intervals and fires a heavily telegraphed line beam capable of killing several player vessels at once. Spawning reuses #52's EnemySpawnerComponent as-is via two preset scenes (EnemySpawnerComponentChaser.tscn: 5s/chaser, EnemySpawnerComponentArtillery.tscn: 18s/max 2/artillery) rather than adding multi-type support to the component - two instances of a single-purpose component is the composition this codebase already uses everywhere ("enemy bomber" in the original request is read here as the existing artillery enemy's slow telegraphed AOE, not a new enemy type - flagged as a judgment call in the ticket). New EnemyBigLaserComponent.gd ("big_laser") fires a standalone EnemyBigLaserBeam on a long cooldown - the beam owns its whole charge/ fire/flash sequence once launched, so the mothership dying mid-charge doesn't cancel an already-telegraphed shot, same design as EnemyArtilleryComponent/ArtilleryShell. The aim direction is locked once in launch() and never re-read - nothing in the charging phase touches the fleet's position again, which is what makes it dodgeable. Damage is a line-segment check (projection + perpendicular distance) against every player_ships member; Ship.take_damage() already handles shield absorption per-ship. MothershipEnemyDefinition.tres: max_hp 60, speed 35 (slow), a ~96-unit hull, pursuit + two spawners + big_laser, no type switch anywhere - every stat from the definition, every behaviour from a component. Tests: new tests/test_enemy_mothership.gd, split into beam mechanics (tested directly, not through the component's own cooldown timing, which would make the geometry assertions timing-fragile) and the composed definition (tested through a real Enemy.tscn instance). Screenshot of the charge telegraph mid-countdown. Full suite: 80/80. Found and fixed a real bug along the way, in EnemySpawnerComponent.gd (#52): its `enemy_scene: PackedScene = preload("res://Enemy.tscn")` member-level preload could get permanently baked in as a broken, empty PackedScene when a definition's component_scenes chain led back to Enemy.tscn while it was still mid-load - confirmed empirically via ResourceLoader.has_cached() being true (a good copy existed) while the preloaded reference's own resource_path was empty. This only surfaces when a SINGLE definition composes two instances of a script carrying such a preload (the mothership's chaser/artillery spawner presets; #52's single-spawner turret never hit it). Fixed by resolving enemy_scene lazily via load() on first use instead of at compile time, and additionally made a fresh spawner count down from a full interval before its first spawn rather than firing on tick one, which also happens to keep two sibling spawners with different intervals from ever landing their first attempt on the same frame. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 10:19:02 +02:00
if not mothership.has_capability("pursuit"):
return _fail("enemy_mothership has no pursuit component - it should close on the fleet")
if not mothership.has_capability("big_laser"):
return _fail("enemy_mothership has no big_laser component")
var spawners: Array = []
for child in mothership.get_children():
if child.get("capability_id") == "spawner":
spawners.append(child)
if spawners.size() != 2:
return _fail("enemy_mothership has %d spawner components, expected 2 (chaser + artillery)" % spawners.size())
for spawner in spawners:
if spawner.spawned_enemy_id == "chaser":
chaser_spawner = spawner
elif spawner.spawned_enemy_id == "artillery":
artillery_spawner = spawner
if chaser_spawner == null or artillery_spawner == null:
return _fail("the two spawner components are not one chaser + one artillery preset")
# Speed up both intervals for the test, resetting the in-progress
# timer too (#52's lesson: changing the interval alone does not
# touch a countdown already running from the definition default).
# Staggered slightly rather than both at 0.0: two sibling
# spawners both instantiating Enemy.tscn on the exact same
# physics frame hit a transient PackedScene.instantiate()
# failure ("node count is 0") on this engine build - spreading
# their first fire across different frames avoids it, and is
# also what naturally happens in real play anyway.
chaser_spawner.spawn_interval = 0.2
chaser_spawner.spawn_timer = 0.0
artillery_spawner.spawn_interval = 0.3
artillery_spawner.spawn_timer = 0.05
mothership_start_position = mothership.position
elapsed = 0.0
closing_elapsed = 0.0
stage = 5
return false
5:
# --- 6. launches both chasers and artillery on their own intervals ---
closing_elapsed += delta
if elapsed < 1.2:
return false
if chaser_spawner.spawned.is_empty():
return _fail("mothership never spawned a chaser")
if artillery_spawner.spawned.is_empty():
return _fail("mothership never spawned an artillery")
for spawn in chaser_spawner.spawned:
if spawn.enemy_id != "chaser":
return _fail("a chaser-spawner spawn has enemy_id '%s'" % spawn.enemy_id)
for spawn in artillery_spawner.spawned:
if spawn.enemy_id != "artillery":
return _fail("an artillery-spawner spawn has enemy_id '%s'" % spawn.enemy_id)
# --- 7. closes on the fleet, never exceeding its own speed ---
var traveled: float = mothership.position.distance_to(mothership_start_position)
var max_possible: float = mothership.speed * closing_elapsed + 5.0 # small integration slack
if traveled > max_possible:
return _fail("mothership traveled %.1f in %.2fs, more than speed(%.1f) allows (%.1f)" % [
traveled, closing_elapsed, mothership.speed, max_possible
])
var distance_to_fleet: float = mothership.position.distance_to(fleet.get_centroid())
var starting_distance: float = mothership_start_position.distance_to(Vector2(3000, 0))
if distance_to_fleet >= starting_distance:
return _fail("mothership did not close on the fleet at all (distance %.1f >= starting %.1f)" % [
distance_to_fleet, starting_distance
])
print("TEST_ENEMY_MOTHERSHIP: PASS")
quit(0)
return true
return false
func _pin(ship: Node, at: Vector2) -> void:
ship.position = at
ship.move_target = at
func _fail(message: String) -> bool:
print("TEST_ENEMY_MOTHERSHIP: FAIL (%s)" % message)
quit(1)
return true