## Background The engine currently exposes very few global/static access points to gameplay code. Unlike engines such as Unity or Godot, user scripts do not currently rely on globally accessible engine subsystems such as `Input`, `SceneManager`, or `AssetDatabase`. The main exception is time-related information, but this is already passed explicitly through APIs such as: ```zig pub fn update(self: *Spinner, time: engine.Time) void { ... } ``` As a result, the engine does **not currently suffer from widespread global-state coupling**, hidden dependencies, or initialization-order hazards commonly associated with static singleton architectures. However, upcoming features such as DataAssets (#26), scene-scoped systems (#38), configuration objects, and potentially additional engine services require a clear strategy for dependency management before new patterns emerge organically. ## Goal Define and document the engine's approach for accessing shared services and configuration data. The objective is to establish architectural direction early, ensuring future systems remain testable, explicit in their dependencies, and consistent across the engine. This issue is exploratory and should determine **whether a dependency injection/service model is needed at all**, and if so, what form it should take. ## Questions to Resolve * Should engine services continue to be passed explicitly through APIs whenever possible? * Should a lightweight service locator or dependency injection container be introduced? * Should DataAssets become the primary mechanism for supplying configuration and service implementations? * Is a hybrid approach (explicit parameters + DataAsset-backed services) more appropriate? * What service lifetimes are required (engine-wide, per-scene, transient), if any? * What level of testability and mockability should the architecture support? ## Investigation Tasks * Evaluate dependency management approaches used by other engines and Zig projects. * Define criteria for selecting an approach, including: * Explicitness of dependencies * Ease of testing and mocking * Runtime overhead * Compatibility with Zig idioms * Support for DataAsset integration * Initialization and lifecycle complexity * Prototype one or more approaches using a small set of representative services (for example, asset access, configuration data, or time providers). * Verify that the chosen approach supports unit testing with substituted implementations. * Document trade-offs and rationale for the selected direction. ## Out of Scope * Large-scale migration of existing systems. * Introducing global singleton APIs for user scripts. * Converting all engine subsystems to a new pattern before architectural decisions are made. ## Acceptance Criteria * A dependency management strategy has been selected and documented. * The rationale and trade-offs of the chosen approach are recorded. * A proof-of-concept demonstrates how a subsystem receives dependencies using the selected model. * A unit test demonstrates that dependencies can be substituted or mocked when appropriate. * The approach integrates cleanly with DataAssets (#26) and scene-scoped systems (#38), if applicable. * No new globally accessible engine state is introduced without explicit justification. ## Related - #11 (DataAsset injection), #22 (per-scene services).