← devlog

· 5 min · #unity #architecture #design

Bloom & Place devlog #9: solution shape and the Waterfall plan

With the literature review done, the design phase opens. Here's the shape of the solution and the five-phase Waterfall plan I'm running it on.

Out of research, into design

The lit-review burst (devlogs #2–#8) ended on methodology. This one starts the System Design phase. Two things to nail down before I touch any production code: what the solution actually is, and the Waterfall plan it runs on.

The solution, in two complementary halves

Loosely Coupled Architecture for Bloom & Place pairs two techniques that handle different kinds of coupling:

  • Dependency Injection (VContainer) handles the static dependency graph. Decided once, at startup, by the container. Every system gets the interfaces it needs by constructor injection. No FindObjectOfType, no static Instance.
  • Event-Driven Architecture (C# native events) handles runtime communication. Systems publish events, and other systems subscribe. Neither side knows the other exists.

DI alone leaves you with chatty interfaces full of “tell me when X happens” methods. EDA alone leaves you with a global bus that everyone reaches into. Together they cover both axes: who-knows-whom (DI) and who-talks-to-whom (EDA).

The four headline systems

The game itself is a casual placement puzzle: plants want specific environmental conditions, the player slots them into seats, the level resolves when every plant is satisfied. Underneath, four domain systems carry the load.

01
CharacterSystem
Plant data, identity, lookup.
02
PlacementSystem
Placement rules, seat occupancy, valid moves.
03
SatisfactionSystem
Plant-vs-seat preference scoring.
04
LevelSystem
Win/lose conditions, level transitions.

Each one is a plain C# class. None inherits from MonoBehaviour. View work (animations, particles, UI feedback) lives in MonoBehaviours that subscribe to events from the systems above.

Why Waterfall fits this design phase specifically

Devlog #8 made the methodology argument in general. The design phase is where Waterfall’s strictness pays off most concretely. The artefacts produced here are contracts the implementation phase will consume, and Waterfall’s “finish each phase before moving on” rule is what stops me from quietly redrawing a contract halfway through implementation.

The five phases mapped to this thesis:

  1. 01
    Requirements Analysis
    Identify the tight-coupling problem; lock the metric set.
    → required system list, Ca/Ce/I as the measurement standard.
  2. 02
    System Design · current phase
    Design the loosely coupled architecture on paper.
    → dependency graph, VContainer binding scheme, event flow, interface contracts. Devlogs #10–#12 land here.
  3. 03
    Implementation
    Code the four systems against the design, plus a non-DI version for comparison.
    → CharacterSystem, PlacementSystem, SatisfactionSystem, LevelSystem; non-DI baseline.
  4. 04
    Testing
    Functional tests + the coupling analysis pass.
    → test-case table, side-by-side Ca/Ce/I comparison (DI vs non-DI).
  5. 05
    Maintenance
    Refactor based on the data; finalise documentation.
    → playable build, full technical writeup, architecture as a reference.

The reason I’m marking the design phase outputs explicitly: those four artefacts are the deliverables the rest of the thesis depends on. If any of them is wrong, every later phase compounds the mistake.

What the next three devlogs cover

  • #10. Architecture layers and the dependency graph, before vs after.
  • #11. VContainer binding scheme and event flow.
  • #12. Interface contracts and testing plan.

Next

Devlog #10 covers the layer hierarchy and what loosely coupled actually changes about the dependency graph.