Component services in practice

Shared systems often begin as static helpers. That works until the system needs configuration, state, cleanup or a relationship with the active scene. Component services make that ownership explicit.

Let the scene own the lifetime

A service is mounted on a scene-owned game object and follows the same lifecycle as any other component. Startup, teardown and dependencies are therefore attached to a runtime object that developers can inspect.

This is especially useful for systems such as inventories, session rules or feature registries that need to exist once per scene.

Keep registration deterministic

Service discovery should identify a concrete service type, create it through the supported type system and mount it through the active scene. Logging a successful registration is not enough if the object itself is detached from that scene.

Prefer collaboration over reach-through

Addons should request a service through its public contract and communicate through named events when direct coupling is unnecessary. The result is a graph of explicit relationships rather than a chain of hidden static calls.

The pattern is intentionally small: a scene owns components, services own shared runtime behavior and addons own feature-level setup.