Problem Statement

There is currently no built-in way to close the application window by pressing the Escape key. While this is a common quality-of-life behavior in many applications and prototypes, it should not be forced upon every project — some games and applications intentionally prevent this shortcut.

Proposed Solution

Provide an optional, ready-to-use system (e.g. EscapeKeyCloseSystem) that registers a callback to shut down the window when the Escape key is pressed. This system should:

• Be self-contained and clearly named so users can easily find and opt into it.
• Not be added to any default plugin or system pipeline — it must be explicitly registered by the user if desired.
• Follow the existing system/plugin architecture of the engine.

Example usage (opt-in by the user):

app.AddSystem(ECS::Scheduler::Update, EscapeKeyCloseSystem);

Alternative Solutions

• Document how users can write this system themselves from scratch (less convenient, more boilerplate).
• Provide it as part of a broader "utility systems" collection.

Use Cases

• Use case 1: A developer building a prototype or tech demo wants a quick way to exit the window without writing boilerplate input handling code.
• Use case 2: A user following a tutorial wants a minimal runnable example that can be closed cleanly.
• Use case 3: A developer wants to reference an idiomatic example of how to bind a key to a window lifecycle callback.

Impact

• No performance implications — the system is opt-in and only active when explicitly registered.
• No API changes to existing systems or plugins.
• No breaking changes.

Implementation Details (optional)

• The system should query the keyboard input state for the Escape key each frame.
• On detection, it should trigger the window close/shutdown callback (e.g. glfwSetWindowShouldClose or equivalent abstraction).
• It should live in a dedicated file (e.g. EscapeKeyClose.hpp/.cpp) under the appropriate system directory, making it easy to include selectively.

Additional Context

This is a convenience utility for developers and should be treated as an example/helper system rather than a core feature. It should be clearly documented as opt-in in the relevant README or system documentation.

Related Issues

N/A