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.
This commit is contained in:
parent
5326852807
commit
f14ee656ea
20 changed files with 393 additions and 42 deletions
4
Fleet.gd
4
Fleet.gd
|
|
@ -32,6 +32,10 @@ var steer_direction: Vector2 = Vector2.ZERO
|
|||
|
||||
|
||||
func _ready() -> void:
|
||||
# Lets anything resolve "the fleet" without a hardcoded ../Fleet sibling
|
||||
# path - enemies parented under different hosts (e.g. a planet surface's
|
||||
# SurfaceFeatures) need this to find their target.
|
||||
add_to_group("player_fleet")
|
||||
# Researching a vessel upgrade improves the ships already flying, not
|
||||
# just the next one built (#5).
|
||||
GameState.vessel_upgraded.connect(_on_vessel_upgraded)
|
||||
|
|
|
|||
Loading…
Reference in a new issue