Feature: Introduce engine-driven lifecycle with libGDX-adapted app loop

[GuilhermeF03]

Summary

Add a platform-agnostic, engine-defined lifecycle by introducing a core loop abstraction, while adapting execution to the libGDX application loop.

Motivation

Currently, the application lifecycle is implicitly controlled by platform drivers. Each driver (e.g., libGDX) defines its own execution model, which can lead to inconsistencies in how lifecycle events (enter, update, resize, exit) are triggered.

This makes the engine:

• dependent on backend behavior
• harder to reason about
• inconsistent across platforms

The engine should define how the lifecycle behaves, while platform drivers only determine when it is executed.

Proposed Solution

1. Introduce EngineLoop

Create a core loop abstraction responsible for lifecycle orchestration:

• enter()
• update(delta)
• resize(width, height)
• exit()

This becomes the single source of truth for:

• timing (e.g., fixed timestep)
• update ordering
• lifecycle flow

---

2. Adapt libGDX to the engine loop

Implement a thin adapter that bridges libGDX’s ApplicationListener to the engine:

• create() → loop.enter()
• render() → loop.update(delta)
• resize() → loop.resize(...)
• dispose() → loop.exit()

libGDX remains the loop owner, but delegates all logic to the engine.

---

3. Move lifecycle control into the engine

Ensure:

• App.enter(), update(), resize(), exit() are only called via EngineLoop
• platform drivers do not implement custom lifecycle behavior

---

4. (Optional) Add fixed timestep support

Inside EngineLoop.update(delta):

• accumulate time
• run fixed-step updates (physics)
• run variable-step updates (frame)

This ensures consistent simulation across platforms.

---

Expected Outcome

• Unified lifecycle behavior across all backends

• Clear separation of concerns:

  • engine = lifecycle + logic
  • platform = execution trigger

• Easier debugging and reasoning about frame execution

• Foundation for future backends (desktop, web, etc.)