Why I Stopped Using Event Buses in Unity – Developer Debate!

Technological focus: Unity architecture debate (event buses, events, queues, and related patterns)

Message queues / event buses in games

One speaker argues that in most single-process, mostly single-threaded games, “message buses” and “message queues” are often overkill and end up behaving like:

• immediate delegate/event callbacks wrapped in extra layers
• a debugging nightmare (call stacks become hard to follow; messages may fire but never be handled)
• something with no real benefit because the promised “defer/decouple” advantage usually isn’t achieved

They also claim that many “service locator” implementations devolve into just singletons stored in one place, offering little real value in swapping/replacement.

Events vs event buses vs queues (terminology clarification)

Another speaker emphasizes that community discussions frequently blur terminology—people conflate events, message buses, message queues, service locators, and mediators.

The debate distinguishes:

• Events: direct announcement/observer mechanisms
• Message bus / queue approaches: broader routing/dispatch systems, sometimes used for async or dynamic scenarios

The “wrong layer” problem

A key conceptual argument is that game logic relationships—e.g., “when all enemies die → advance level”—should not be hidden behind abstract event-bus indirection.

This is treated as an architecture issue (layering/structure), not as an inherent flaw of events themselves.

That said, the other side argues that bus-like mechanisms can make sense for some cases, such as:

• terminal/command frameworks
• logging
• asynchronous workflows

Command/query and “waiting for results” framing

The discussion connects messaging patterns to command vs query concepts and how systems deal with:

• sync return values
• async notification, via events/futures/queue-like patterns

One speaker notes that many “in-memory” operations in games are effectively assumed to be immediate, so they question why heavier async messaging abstractions are used unless the system interacts with external concerns like:

• networking
• disk I/O

Practical guidance on over-engineering

The stream also includes broader engineering philosophy:

• favor refactorability over extensibility
  • build for change where it’s needed
  • avoid pre-planning “wrong hooks”
• build complex systems when learning, but keep production code minimal
• treat code “ick factor” as a signal for redesign

Finding Unity objects

A related topic discussed was locating Unity objects:

• One speaker strongly discourages FindObjectOfType due to tree walks and concerns around performance and clarity.
  • Suggested alternatives include:
    • static references
    • serialized fields
    • centralized loading
• Another speaker uses it more for prototyping/temporary uncertainty, but overall sentiment warns against letting it become the “obvious permanent solution.”

---

Unity tooling / product notes included in the stream

Asset store sale announcements

Andrew’s assets were discussed as being on sale:

• Flash sale: character bundles
  • mentioned as 70% off, with some items at 50% off
• upcoming deal: Game Modules 4 on the 7th (sale nearly ending)

V tabs / hierarchy / editor utility tools

The hosts promoted V tabs and similar editor tooling, including:

• creating and managing tabs
• locking/inspecting within a tabbed workflow
• a hover “+” on the tab bar to add new tabs
• productivity features like multi copy/paste
• Alt-drag to float an inspector/component window

A giveaway was mentioned: viewers can comment to win a V tabs code.

---

Reviews / guides / tutorials detected

No single formal tutorial segment was provided. Instead, the debate functions as architecture guidance-by-argument, particularly around:

• when not to use event buses in Unity/game code
• how to think about events vs bus/queue vs async workflows
• avoiding FindObjectOfType and better ways to manage references
• refactorability vs extensibility principles

---

Main speakers / sources

• Andrew
• Story (also referred to as Jason in the dialogue)
• Enco (mentioned as a trigger/comment: “rant about singletons”)
• Audience/chat participants, including references like polls/comments and “Dave says…”