Dependency Injection started, for me, as a way to remove hidden dependencies from Unity components. Over time, the question changed from “how do I inject this object?” to “where does this system begin, who may use it and when does it stop existing?”
That change can be followed through a sequence of projects. This is not a comparison of game quality, nor a claim that every stage was planned from the start. It is a learning timeline: small experiments exposed limits that larger projects forced into explicit architecture.
How to read the evidence
Each stage below uses a different source:
- confirmed in code and Git: the current structure and its passage through local history could be inspected;
- author recollection: the sequence is known, but the repository still needs to be recovered or catalogued;
- future proposal: a direction, not a tool that has already been released.
That distinction matters. Memory guides investigation, but it does not replace a verifiable artifact.
1. Discovery: research before the pattern
My first deliberate contact with Zenject came during the period connected to Demerara, after researching Unity architecture and a technical presentation associated with Niantic’s work on Pokémon GO. This stage remains an author recollection: it explains the origin of the direction, not a specific production implementation.
The early lesson was simple and important: a component should not discover everything it needs by itself. Making dependencies visible improves replacement, debugging and testing — but only when there is a clear place responsible for composing the whole.
2. First remembered slice: Stylized Action Prototype
The Stylized Action Prototype is the first remembered implementation of that approach. Its scope was exploratory: world navigation, area cameras and card combat were still finding their shape. Dependency Injection entered as an organizational tool, not as a universal layer designed in advance.
This stage taught a distinction that remained important: using a container is not the same as designing a composition architecture. A prototype can benefit from replaceable dependencies without anticipating every module of a future product.
Zenject’s use in this slice remains classified as author recollection until the corresponding repository state is recovered and associated with a build.
3. Applied integration: an educational math prototype
In an educational prototype where the player answered questions while a bird was falling, the architecture also had to support API calls and endpoint implementation. Dependency Injection helped separate integration, game rules and presentation — a more concrete need than in the earlier experiment.
The final name, exact period and repository still need to be catalogued. This stage is therefore published as an author recollection pending recovery, without turning remembered details into technical proof.
4. DATA2073: composition at product scale
In DATA2073, between 2025 and 2026, the approach reached product scale. Local inspection confirms Zenject across tutorial, inventory, deck, mission, reward, store, season, leaderboard and game-mode systems. It also reveals distinct compositions for client, server and shared responsibilities.
The leap is not the number of injection points. It is the common language used to assemble features:
- installers define what each module offers;
- controllers and services resolve through contracts;
- signals communicate transitions without directly coupling screens to rules;
- factories preserve container-based construction;
- scene and state contexts help select the right scope;
- client and server modules can compose different implementations of the same capability.
The project also contains helpers for objects created outside the container’s normal flow and recursive installation of contracts found in a hierarchy. These solutions reduced manual work in a large product, but exposed the next risk: the more automatic discovery becomes, the more important it is to know which scope owns a dependency and which lifecycle removes it.
The stated objective was automatic composition without meaningful runtime cost. The structure confirms the architectural intent; it does not replace a benchmark. Performance remains a hypothesis that requires reproducible profiling.
5. Triple Z Stealth: explicit boundaries and runtime lifecycle
In Triple Z Stealth, in 2026, earlier lessons are reorganized into a more explicit infrastructure layer. The project retains equivalent helpers and factories, but makes simulation composition a visible responsibility.
Client, server, host and shared concerns have separate installation paths. Authority systems are kept apart from prediction and presentation systems. Entities such as players, sessions, projectiles and interactable objects receive composition scopes appropriate to their lifecycle. Runtime infrastructure can install, query, enable, disable and tear down sets of systems without making game rules depend on one connection topology.
There are also test-specific compositions. Instead of forcing a test to initialize the whole game, it can construct only the container and contracts required by the scenario. This is a qualitative change: architecture stops merely providing objects and starts defining executable boundaries between environments.
Local history confirms the injection foundation in early 2026 and the consolidation of simulation compositions in the following months. Because the case is anonymized, this account publishes architectural principles only; proprietary rules, endpoints and source code remain outside the portfolio.
The evolution in one line
| Stage | Dominant question | Current evidence |
|---|---|---|
| Research at Demerara | How can dependencies become visible? | Author recollection |
| Stylized Action Prototype | Where does DI help without inflating a prototype? | Recollection; code pending recovery |
| Educational prototype | How can API, rules and presentation stay separate? | Recollection; project pending cataloguing |
| DATA2073 | How can many modules and contexts be composed? | Code and Git inspected |
| Triple Z Stealth | How can authority, runtime and testing become explicit? | Code and Git inspected |
| Reusable tool | What can become independent infrastructure? | Future proposal |
What deserves to become a tool
The next step should not be copying helpers from one game into another. A reusable library must extract only contracts that survived different contexts:
- readable composition roots for application, scene, entity and test scopes;
- symmetrical installation and teardown;
- separation between shared, client, server and host composition;
- factories that preserve container construction without hiding creation;
- diagnostics for bindings, scopes and duplicates;
- minimal examples and tests independent from a specific game;
- comparable profiling before any performance promise;
- a versioned package, documentation and migration strategy.
This tool is not published yet. The current work is identifying the core that can be generalized without carrying proprietary project names, rules or dependencies with it.
The main insight
Dependency Injection matured when it stopped being a convenience applied to components and started representing the software’s operating design. In the first stage, it answered “who provides this object?”. In DATA2073, it began to answer “which module offers this capability?”. In Triple Z Stealth, it must also answer “under which authority, in which environment and at what moment may this system exist?”.
The best measure of progress is therefore not the number of Inject attributes. It is the
reduction of ambiguity: fewer dependencies discovered by accident, fewer duplicated
initializations, fewer rules mixed between client and server, and tests capable of composing
only the world they need to observe.
