Update plugins and examples

[waynemwashuma]

Objective

Introduce explicit CoreSystems scheduling groups across engine plugins to establish deterministic execution phases for startup, input, asset processing, rendering, diagnostics, and cleanup systems. Previously, many systems were registered into schedules without explicit ordering groups, relying on insertion order or incidental topology. This standardizes system placement into well-defined execution phases.

Solution

Root cause

A large portion of engine systems were registered without explicit scheduling groups creating several issues:

• Execution order depended on plugin registration order
• Rendering systems could run before asset or buffer preparation
• Cleanup systems could execute too early
• Startup initialization ordering was inconsistent
• Event clearing and command execution timing was ambiguous
• Cross-plugin scheduling behavior became difficult to reason about

As the engine ecosystem grew, implicit ordering became increasingly fragile.

Changes made

• Startup initialization: Initialization and registration systems now consistently execute at the beginning of startup/update flows. Examples include type registration, asset registration, parser registration, renderer setup, input initialization and window registration

• Runtime input and timing: Input and timing updates now execute early in the frame lifecycle. Examples include keyboard updates, mouse updates, touch updates, virtual clock updates, timer updates and render buffer registration. This guarantees downstream gameplay and rendering systems observe fresh frame state.

• Rendering pipeline: Rendering preparation and rendering execution were moved into post-main phase. Examples render bin generation, render pipeline initialization, canvas rendering, mesh queueing and rendering submission. This separates gameplay/update logic from rendering execution more cleanly.

Note

This will later be moved into its own schedule

• Cleanup and deferred processing: Late-frame systems now consistently execute at the end of the frame.This ensures deferred operations occur after gameplay and rendering preparation phases. Examples command execution, asset event propagation, dropped asset unloading, event clearing, diagnostics updates, profiler updates and scene spawning.

• Added startup command execution: Command flushing now also runs in the end of AppSchedule.Startup: allowing deferred startup commands to run deterministically during initialization.

Why this approach

Alternative approaches considered:

• preserving implicit plugin registration ordering
• adding more localized before/after constraints
• introducing plugin-specific scheduling stages

These approaches scale poorly as subsystem interactions increase.

Using shared core scheduling phases provides:

• predictable frame structure
• clearer subsystem responsibilities
• easier plugin interoperability
• reduced ordering bugs
• simpler debugging and profiling

without significantly increasing scheduling complexity.

Showcase

N/A

Migration guide

Behavioral changes

Systems that previously relied on implicit plugin registration order may now execute in different relative positions due to explicit phase assignment.

This primarily affects:

• rendering timing
• event clearing timing
• command execution timing
• asset update ordering

Plugin authors

Custom plugins can now integrate more predictably by targeting appropriate core phases:

Checklist

• I have updated the documentation accordingly.
• I have added tests to cover my changes.