The Dev Playbook
Back to Journal
Pre-ProductionFizzics

Architecting Fizzics: Manager + ScriptableObject Events

Why I chose an event-driven architecture for a physics-heavy casual game, and what happened when I tried to apply a web-app Playbook to game development.

March 16, 20267 min read

Most casual games don't need architecture. Drop a few scripts on GameObjects, wire them up in the Inspector, ship it. Honestly, for a lot of games, that's the right call.

Fizzics is different because its physics-heavy gameplay creates a web of reactions that need to happen simultaneously. When a blob detonates, scoring updates, VFX spawns, haptic feedback fires, the chain counter increments, and nearby blobs get displaced. If every system called every other system directly, I'd have spaghetti by Sprint 2. I've written that spaghetti before. I've been the spaghetti. Not again.

The Pattern: Manager + ScriptableObject Events

Unity's ScriptableObject (SO) system is usually used for data: config files, item databases, color palettes. Boring stuff. But SOs can also act as lightweight event channels, and that's where things get interesting.

The idea: create ScriptableObject assets that act as event buses. Systems raise events by invoking the SO. Other systems listen to that SO. Nobody knows who's listening. Nobody knows who raised it. Pure decoupling.

[CreateAssetMenu(menuName = "Events/Void Event")]
public class VoidEvent : ScriptableObject
{
    private readonly List<IEventListener> listeners = new();
 
    public void Raise()
    {
        for (int i = listeners.Count - 1; i >= 0; i--)
            listeners[i].OnEventRaised();
    }
 
    public void Register(IEventListener listener) => listeners.Add(listener);
    public void Unregister(IEventListener listener) => listeners.Remove(listener);
}

The merge system raises OnMergeComplete. The scoring system listens. The VFX system listens. The haptic system listens. The merge system doesn't know any of them exist. I can add a new system that responds to merges without touching a single line of merge code.

Unity editor showing ScriptableObject event assets and module structure

10 Assembly Definitions

I split the project into 10 assembly definitions (.asmdef files): Config, Core, Data, Editor, Feedback, Gameplay, Input, Rendering, Services, and UI.

This sounds like over-engineering. It's not. It's compile-time enforcement of dependency direction. The Gameplay assembly can reference Config and Core, but not UI or Rendering. If I (inevitably, at 1am) try to call a UI method from gameplay code, the compiler stops me before I ship the mistake.

For a solo dev, assemblies are your code reviewer. They don't get tired, they don't get polite, and they don't let things slide because "we'll fix it later."

No Backend

One of the best decisions I made was no backend. Zero. None.

Game Center handles leaderboards and achievements. Ads are SDK calls. Save data is local JSON. Authentication is Apple's problem.

This eliminated entire categories of work that would have taken weeks:

  • No server logic or API endpoints
  • No database schema or migrations
  • No authentication flow
  • No Row Level Security policies
  • No Edge Functions

For a casual single-player game, a backend is a liability, not a feature. Every endpoint is a thing that can go down, a thing that needs monitoring, a thing that costs money while I sleep. Local-first, platform services for the rest.

What the Playbook Got Right (and Wrong)

Here's the honest part. The Playbook's Pre-Production templates were designed for web apps with Supabase backends. Applying them to a Unity game required... adaptation.

What worked well:

  • The spike-first approach paid for itself immediately. Every downstream spec was grounded in validated performance data, not assumptions. The architecture doc referenced the spike results. The UI spec referenced the spike results. Consistency was natural because the foundation was real.
  • The 8-assembly module structure became the backbone. Every spec referenced it, every document stayed consistent.

What needed adaptation:

  • Every template assumed SwiftUI, Xcode, and Supabase. Steps 5, 6, and 8 required the most rewriting.
  • No step for audio design. For a game, audio is a core polish layer, not an afterthought. I had to bolt it onto Sprint 3.
  • I produced detailed wireframe descriptions but no actual visual mockups. For a game where the visual aesthetic is the entire differentiator, this felt like a gap. A real one.

The meta-lesson: a process framework should accelerate you, not constrain you. When the template doesn't fit, adapt it. Don't skip the step, rewrite it. The value is in the structured thinking, not the specific template.

Phase 1 Exit Criteria

Pre-Production ended with a complete foundation:

  • 8 epics, 28 user stories, 115 test cases
  • Technical spike validated (fluid rendering at 60fps, the Go/No-Go)
  • 10-assembly architecture with testability patterns
  • 11 UI components fully specified
  • Design system with neon tokens and a glow-based visual language
  • 5-sprint project plan with milestones and risks

Detailed enough that production sprints could execute without design questions. That's the whole point: front-load the thinking so production is pure execution. Or at least mostly execution with some panicked thinking.

// Assembly structure enforces dependency direction
// Gameplay → Config, Core (allowed)
// Gameplay → UI, Rendering (compiler error)
// Your 1am self will thank your planning self
All Journal Entries