[FEATURE] Add Signals for Fuel System in Player.gd

[ikostan]

Description:
Add signals to the fuel management system in Player.gd to improve modularity and enable better event handling across the game. Currently, fuel is managed within Player.gd (e.g., via fuel and max_fuel variables and related logic), with updates likely handled in _process or similar methods. Introducing signals will allow other nodes (e.g., UI, GameManager, or audio systems) to react to fuel changes without direct coupling, supporting the project’s clean, modular architecture.

Why is this useful? (e.g., for learning Godot, web exports)
This enhancement is useful for several reasons:

• Learning Godot: Demonstrates best practices for signal implementation, a core Godot feature, which is valuable for contributors or learners exploring the engine.
• Extensibility: Enables easier integration of new features (e.g., fuel-based power-ups, mobile UI updates) as outlined in the roadmap.
• Decoupling: Reduces dependency between Player.gd and other systems, making the codebase more maintainable and scalable.
• Mobile Optimization: Signals can trigger lightweight UI or haptic feedback on fuel events, critical for mobile performance.

Proposed Implementation (optional):

1. Define Signals in Player.gd: Add signals such as:
   • fuel_changed(new_amount: float, max_fuel: float): Emitted when the fuel level updates.
   • fuel_low(threshold: float): Emitted when fuel drops below a configurable threshold (e.g., 20%).
   • fuel_depleted(): Emitted when fuel reaches zero, potentially triggering game over.
   • fuel_refueled(amount: float): Emitted when fuel is replenished (e.g., via a power-up).
2. Update Existing Fuel Logic: Modify the fuel management code in Player.gd (currently handling fuel and max_fuel) to emit these signals at appropriate points (e.g., in _process for consumption, or a refuel method).
3. Connect Signals: Example connections in other scripts (e.g., HUD.gd for UI updates, GameManager.gd for game over logic) using connect or the editor’s signal system.
4. Testing: Update the test suite (e.g., tests/) to verify signal emissions and responses.

Additional Context:

• The current Player.gd already manages fuel with variables like fuel and max_fuel, and likely updates them in _process or a similar method. For example, lines 45-50 in the current player.gd show fuel-related logic:

  if fuel > 0:
      fuel -= fuel_consumption_rate * delta
      if fuel <= 0:
          fuel = 0
          # Game over logic here```
  
  

Relation to Current Code

• Existing Structure: The scripts/ directory includes player.gd, which handles player movement, weapon switching, and fuel management. The fuel system is currently embedded in Player.gd, with variables like fuel and max_fuel (lines 45-50) and consumption logic tied to delta in _process. There are no signals yet, and updates are handled internally or via direct method calls to other nodes.
• Improvement Opportunity: Adding signals decouples fuel events from Player.gd, allowing nodes like HUD.gd or GameManager.gd to subscribe to changes. For instance, the current fuel depletion check (if fuel <= 0) could emit fuel_depleted, triggering a game over scene change in GameManager.gd instead of handling it inline.
• Modularity: The project’s modular design (e.g., separate components for movement and weapons) benefits from signals, as seen in the suggested fuel_changed signal, which can update the UI without Player.gd knowing about the UI’s existence.