Summary of "Alexey Merzlikin - Architecture Behind Our Most Popular Unity Games"
Architecture Behind Our Most Popular Unity Games
Alexey Merzlikin — game developer, tech lead at Playtika, author of GameDev.Center
Core idea: a practical, production-proven HMVC variant called the “controller tree” — an engine-agnostic hierarchical extension of MVC where MVC triads are organized into a tree and controllers drive data flow by spawning child controllers.
This approach has been used across multiple large live mobile titles (examples mentioned in the talk: Board Kings, Best Fiends, Solitaire, and others).
Core concept
- A single root controller is the app entry point and owns a tree of controllers.
- Each controller encapsulates a specific responsibility and may spawn child controllers to delegate work.
- Controllers drive data flow and lifecycle; models and views remain plain and testable where possible.
How the controller tree works
Structure and ownership
- Single entry point (root controller) starts and owns the controller tree. Other controllers can only be created from inside the tree.
- Controllers form branches; each controller delegates tasks to its children and encapsulates a focused responsibility.
Types of controllers
- Base controller: lifecycle is managed by its parent; it stops when the parent stops or on exception.
- Controller-with-result: an asynchronous controller that returns a result to its parent and stops when finished (useful for flows like login or an entire mini-game).
Models, Views, Controllers
- Models and controllers are plain C# objects.
- Views are Unity MonoBehaviours and contain only Unity API/rendering. Business logic lives outside views (passive view pattern).
- Multiple controllers can reference the same model or view. Many controllers are “headless” (no view).
API and lifecycle rules
- Controllers expose a single protected Execute method to enforce correct lifecycle usage.
- Initialize/start/stop/dispose are internal; only the root controller provides a minimal public API for app entry.
- Controllers are asynchronous (Task/UniTask) and receive cancellation tokens for interrupting flows.
Resource management
- Controllers follow RAII: acquire resources in initialize and release in dispose.
- Dynamic asset bundles are loaded on demand and unloaded immediately after use.
- Object pooling is used for frequently-created objects to reduce GC pressure and avoid leaks.
Debugging and tooling
- An editor “tree viewer” can inspect active controllers, their states, and invoke lifecycle/debug methods.
- Static/runtime analysis tools can build and visualize the game’s controller graph to help find hard-to-reproduce flows.
Why it’s useful (advantages)
- Single entry point and enforced structure lead to consistent data flow and lower cognitive load.
- Strong modularity and separation of responsibilities make large codebases easier to maintain and navigate.
- Facilitates parallel development: independent controllers/features can be developed and tested in isolation.
- Reusability: common controllers (e.g., rewards controller) can be shared across many features.
- Supports lazy DI/subcontainers: subcontexts allow lazy binding/resolution to reduce startup time and memory footprint.
- Can be combined selectively with other architectures (for example, running an ECS world inside a dedicated feature controller/subtree).
Trade-offs and disadvantages
- Boilerplate: argument/payload classes and supporting infrastructure are required per controller (mitigations: code generation, IDE templates, AI assistance).
- No public methods on controllers: forces mediated communication (models-as-events). This avoids tight coupling but can feel restrictive.
- Testing controllers in isolation is harder because you must run their lifecycle; models remain unit-testable but controller logic can accumulate.
- Overhead: controllers are reference types — excessive creation (e.g., every frame) can increase GC pressure. Not suitable for ultra-high-frequency per-frame logic.
- Communication complexity: requires clear mediator patterns and dependency directions to avoid circular dependencies and spaghetti code.
- UI concurrency: multiple controllers may want to display full-screen UI simultaneously; coordination (state machine, async queue/semaphore) is required.
Practical advice / recommended practices
- Keep views thin (passive view). Put business logic into models (plain C#) to improve testability.
- Use the single Execute pattern to prevent lifecycle misuse and resource leaks.
- Provide cancellation tokens to interrupt long-running flows (animations, async operations).
- Build editor tools: tree viewer, lifecycle invocation, and static analysis that graphs the controller tree.
- Use subcontainers / lazy DI to reduce startup cost and isolate feature bindings.
- Encapsulate ECS or other architectures inside their own controller subtrees when needed.
- Choose a UI coordination strategy (queue/semaphore, state machine) appropriate to your project.
Metrics / production evidence
- The controller tree has been used in live-ops heavy games with large teams and rapid cadence (examples from the talk: ~40 devs pushing daily, >50 features added in a year, biweekly releases with frequent technical releases in between).
- Example: a Board Kings mini-game controller spawns child controllers for rolling dice, resource loading, and UI, then disposes everything at the end to unload assets and avoid leaks.
Guides and tutorial content covered in the talk
- Conceptual walkthrough of HMVC/controller tree and scenarios for adoption.
- Implementation patterns: controller lifecycle, async controllers, cancellation, and resource acquisition/disposal.
- Tooling suggestions: editor tree viewer, static analysis, code generation for boilerplate.
- Testing approaches and workarounds for controller testing.
- Tips for combining with DI and ECS, and for handling UI concurrency.
Main speaker / source
Alexey Merzlikin (Alex M) — game developer with 10+ years experience, tech lead at Playtika, author of GameDev.Center (resource for performance optimization and coding practices).
Note: Some game names and small phrases may be inaccurate due to auto-generated subtitles.
Category
Technology
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.
Preparing reprocess...