← Chapter 1: Why Projects Become SpaghettiYou are reading Chapter 2
How Professional Unity Projects Stay Maintainable
By the time most developers start thinking seriously about architecture, they have already experienced the consequences of poor architecture. Not because they read about it. Not because someone warned them. But because they felt it.
A feature that should have taken thirty minutes suddenly takes an entire afternoon. A small change breaks a completely unrelated system. Most Unity projects do not collapse because they become enormous. They become difficult because they become connected.
The inventory needs to update the UI. The save system needs inventory data. The shop needs inventory information. One connection becomes two. Two become five. Five become twenty. Eventually, nobody remembers exactly how everything is connected.
Complexity is rarely caused by the number of systems. Complexity is caused by the relationships between systems.
In Chapter 1 we explored why projects become spaghetti. Now it is time to answer the next question. How should systems be organized? By the end of this chapter you will understand:
Can you identify one system in your current project that seems connected to everything else? Write it down. You will revisit it throughout this chapter.
Architecture becomes difficult because of the things that are harder to see: dependencies. A dependency exists whenever one system relies on another. The real danger comes from dependencies that slowly spread throughout a project without anyone intentionally designing them.
Imagine a simple Player system. At first it only controls movement. Then you add health. Now UI needs player health. Audio needs death sounds. Achievements need kill tracking. Analytics needs statistics. Save needs persistence. The Player becomes connected to half the project — not because someone designed it that way, but because every new feature seemed reasonable when added.
The problem is what happens when change occurs. Suppose you redesign the health system. That change now affects UI, Audio, Save, Analytics, and Achievements. A modification that should have remained local suddenly spreads. This is change amplification.
Healthy architecture contains damage. Unhealthy architecture spreads damage.
The question "If I change this system tomorrow, what else breaks?" reveals more about architectural quality than almost any metric. If the answer is "half the project" — you have found an architectural hotspot.
Projects become difficult to maintain not because they contain many systems — but because too many systems depend on each other in uncontrolled ways. Complexity grows through relationships. Maintainability is achieved through boundaries.
List the five most important systems in your project. Identify which communicate most, and which feels most fragile.
Most architectural problems remain invisible until change arrives. The design team wants to modify health regeneration. The UI depends on health updates. The save system stores health values. Achievements track healing. Analytics records events. Audio plays feedback. What appeared to be a small modification now touches half the project.
Think of architecture through the concept of blast radius. Healthy architecture contains change. Unhealthy architecture spreads change.
Architectural quality is not measured by how easy a project is to build. It is measured by how easy a project is to change. The true cost of architecture appears when requirements evolve. And requirements always evolve.
Many Unity projects have a startup architecture problem nobody notices until something breaks. Systems initialize themselves. Managers create other managers. Scripts assume other systems already exist. Nobody is truly controlling how the application is assembled.
A bootstrapper solves this by establishing intentional startup order. Think of it as the conductor of an orchestra — without coordination, talented musicians produce noise, but with coordination, they produce music. During application startup, the bootstrap process prepares shared infrastructure before gameplay begins.
Systems should not initialize themselves randomly. Startup should be intentional and predictable. A bootstrap process transforms a scattered collection of initialization decisions into a deliberate, ordered architectural approach.
As Unity projects grow, certain systems seem to be needed everywhere. Not occasionally. Everywhere. The Audio System is used by UI, gameplay, combat, quests, and achievements. The Save System is used by inventory, progression, settings, and statistics. Should every system create its own audio functionality? Of course not — that creates duplication, inconsistency, and maintenance problems.
This is where services become useful. A service is a system that provides shared functionality to multiple parts of the application. A useful guideline: a service provides a capability. A gameplay system provides behavior.
Compare that to: Enemy AI, Inventory Logic, Quest Progression, Combat System. These are gameplay concerns. They represent game behavior. Not shared infrastructure. The distinction matters. When everything becomes a service, architecture becomes confusing. When nothing becomes a service, duplication spreads throughout the project.
Think about a city. Every building needs electricity, water, and roads. Yet individual buildings do not create their own power stations. Those responsibilities are centralized. Services perform a similar role — they provide infrastructure for the application. Gameplay systems use the infrastructure. They do not own it.
Services create consistency. Instead of five different systems implementing save logic, one Save Service exists. Instead of multiple systems managing audio independently, one Audio Service exists. This creates several benefits: reduced duplication, easier maintenance (changes happen in one location, not ten), clear ownership, and improved discoverability for new developers.
During application startup, the bootstrap process prepares shared infrastructure before gameplay begins. This means gameplay systems do not need to worry about creating or finding their dependencies — the infrastructure is already in place when gameplay starts. The exact mechanics of how this is implemented will be explored in future chapters.
Many developers discover services and make everything a service — EnemyService, QuestService, WeaponService, NPCService. This creates more complexity, not less. A service should exist because functionality is shared, not because a system exists. Ask: "Would multiple parts of the project benefit from accessing this functionality?" If yes, a service may be appropriate. If no, it is probably just a normal gameplay system.
Services are not a collection of important systems. Services are a collection of shared capabilities. The purpose of a service is to provide infrastructure so gameplay systems can remain focused on gameplay. Services support the application without becoming the application.
List five major systems from your project and determine whether each should become a service.
Imagine joining a new project. You open a script. At first glance it seems simple — the class is small, the methods are clear, the responsibilities appear focused. Then you notice:
AudioManager.Instance.Play(sound);
SaveManager.Instance.Save();
AnalyticsManager.Instance.TrackEvent();
GameManager.Instance.PlayerDataThe script looked independent. In reality it secretly depends on half the project. This is one of the most common architectural traps in Unity development. The code appears simple. The architecture becomes invisible.
When dependencies remain hidden, developers cannot easily answer: what does this system need? What can break this system? What will this system affect? Architecture becomes difficult to reason about. The result is a subtle but important shift — developers stop trusting the codebase. Changes become stressful. Refactoring becomes risky. Maintenance slows down.
Consider two situations. In Situation A, a developer opens a script and immediately sees which services and systems are required — the architectural requirements are visible. In Situation B, the script appears independent, yet only after reading the implementation do they discover audio, save, analytics, and UI dependencies. Which version is easier to understand? Which is easier to maintain? Which is easier to test? The answer is obvious.
Singletons became popular for understandable reasons — they are convenient. Need audio? AudioManager.Instance. Need save data? SaveManager.Instance. At first this feels powerful. The hidden cost appears later. Every system can now depend on every other system. Architectural boundaries begin to disappear. Dependencies spread invisibly. The problem is not the Singleton itself. The problem is unrestricted access.
One of the most important architectural habits is making dependencies visible. Visible dependencies force developers to think. Questions naturally emerge: does this system really need audio? Should this communication happen through an event instead? Visibility encourages intentional architecture. Hidden dependencies encourage accidental architecture.
The goal is not to eliminate dependencies. The goal is to make dependencies visible.
A developer should be able to quickly understand what a system needs in order to function. The less investigation required, the healthier the architecture usually becomes. This improves maintenance, refactoring, testing, and team collaboration.
Review three major systems. For each, identify hidden dependencies — things the system needs that are not immediately obvious from its structure.
Count how many of each pattern exist in your project to receive a visibility score.
Systems become difficult to maintain when they know too much about each other. The natural question becomes: how should systems communicate? Most developers begin with direct communication. A Player system needs to update the UI — so the Player references the UI. The Player needs audio feedback — so the Player references AudioManager. The Player needs analytics — so the Player references AnalyticsManager.
Imagine a player dies. The game needs to update the UI, play audio, track analytics, update achievements, save statistics, and notify quests. A direct-reference approach means the Player must know about every single one of those systems. At first glance this seems harmless. After all, the Player does need those things. Or does it?
This question leads to one of the most important architectural realizations in software development. The Player does not need to know who is interested. The Player only needs to communicate what happened. That distinction changes everything.
This structure creates several problems. The Player becomes responsible for understanding multiple systems. Adding new listeners requires modifying Player code. Removing listeners requires modifying Player code. The Player accumulates responsibilities that do not belong to it. Over time the Player becomes an architectural hotspot.
Instead of saying "Update the UI", "Play a sound", "Track analytics" — the Player simply says: "Player Died." The Player publishes information. Other systems decide whether they care. Think about a fire alarm. When it activates, it does not know which people are inside, which exits will be used, or which firefighters will respond. It simply broadcasts information. Everyone else reacts appropriately. Events work the same way.
Events create separation. The sender becomes independent. The receivers become independent. Communication still occurs — the relationship simply becomes weaker. Need achievement tracking? Subscribe to the event. No Player changes required. Removing analytics? Unsubscribe. No Player changes required. Systems can be evaluated independently. Communication remains flexible as the project grows.
Instead of asking "What systems need to talk to each other?" ask "What information happened?" Events like PlayerDied, HealthChanged, QuestCompleted, LevelLoaded describe facts. Facts are easier to reason about than relationships. Professional architecture often becomes simpler when communication is organized around information rather than implementation.
Like services, events can be overused. Some developers attempt to solve everything with them — soon every action becomes an event, architecture becomes difficult to follow, and debugging becomes confusing. Events are most valuable when multiple systems care about the same information, when direct references create coupling, and when communication crosses module boundaries. They are less useful when communication is simple or only one system is involved.
Choose one direct dependency and redesign it as event-driven communication.
Enter a direct dependency and save an event-driven communication design.
Events do not remove communication. Events remove unnecessary knowledge. The sender no longer needs to understand who is listening. It only needs to communicate what happened. That distinction is one of the foundations of modular architecture.
One of the biggest shifts in architectural maturity happens when developers stop thinking primarily about classes. Not because classes stop being important — but because classes are too small to explain the behavior of a large project. Once a project reaches sufficient complexity, understanding individual classes is no longer enough. You must understand how groups of systems work together. You must understand modules.
This is why experienced developers describe architecture using phrases like: Gameplay Module, UI Module, Persistence Module, Audio Module, Analytics Module. They are not talking about classes. They are talking about responsibilities.
A module is a collection of systems that work together to solve a specific problem. The important idea is not size — the important idea is ownership. A UI Module might contain Screens, Panels, Menus, Navigation Logic, and UI Events. These systems are different, but they share a common purpose: presenting information to the player. A Persistence Module might contain Save Logic, Load Logic, Serialization, Player Data Storage, and Configuration Storage. Again, different systems — one responsibility.
Imagine a city. Cities contain Residential Areas, Industrial Areas, Commercial Areas, Parks, and Transportation Systems. Each area serves a different purpose. Each area has clear responsibilities. Now imagine a city where factories are built inside parks and airports appear in shopping centers. Nothing has a clear purpose. The city becomes difficult to navigate. Software architecture behaves similarly. Modules create neighborhoods of responsibility. Without them, systems become scattered and difficult to understand.
Most architecture problems are not caused by bad code. They are caused by unclear ownership. When responsibilities become unclear, systems begin doing work that belongs elsewhere. Dependencies spread. Coupling increases. Maintenance becomes harder. Consider a Quest System. Should it track progress? Save data? Play sounds? Update UI? Track analytics? Some of those responsibilities belong elsewhere. Without boundaries, systems slowly accumulate responsibilities. This is how architectural hotspots emerge.
Cohesion means systems inside a module belong together. Coupling means modules depend on each other. Healthy architecture aims for strong cohesion and weak coupling. The Gameplay Module should contain gameplay concerns. The UI Module should contain presentation concerns. Each module should have a clear reason to exist.
Boundary violations occur when responsibilities leak between modules. The UI Module modifies save files. The Save System controls gameplay. The Analytics System updates quests. Each violation may appear harmless. But repeated violations gradually erode architectural clarity. Eventually nobody knows where functionality belongs. One of the easiest ways to detect architectural problems is to ask: "If I removed this module, what would stop working?" The answer should be obvious. If the answer is confusing, module boundaries may be unclear.
A common mistake among newer developers is thinking: "What class should I create?" Experienced developers often ask: "What responsibility am I adding?" Classes are implementation details. Responsibilities are architectural decisions. Architecture improves when responsibilities are organized intentionally.
Group your project's systems into modules. Be honest — some systems may not have a clear home, and that is a finding too.
Answer boundary questions to assess your module health.
At some point during this chapter you may have recognized several architectural problems in your own project. Hidden dependencies. Initialization issues. Service opportunities. Coupling problems. Weak module boundaries. This realization can be uncomfortable. Many developers immediately think: "I should probably rewrite everything."
This reaction is understandable. It is also usually a mistake. One of the most important lessons in software architecture is this: good architecture is rarely created through massive rewrites. Good architecture is usually created through a series of intentional improvements. Professional teams rarely stop development for six months to rebuild everything from scratch. Instead they improve architecture continuously, reduce risk incrementally, and improve boundaries gradually while continuing to deliver features.
Large rewrites are tempting. The vision is appealing — a clean codebase, perfect architecture, no technical debt, no historical mistakes. Unfortunately reality is usually different. The rewrite introduces new bugs, new assumptions, new technical debt, and new architecture problems. Many teams eventually discover a painful truth: rewriting architecture does not automatically improve architecture. Better decisions improve architecture.
Not every problem deserves immediate attention. Once you learn to see problems, you begin seeing them everywhere — fifteen hidden dependencies, six service opportunities, three initialization problems, multiple boundary violations. Trying to fix everything at once usually creates more chaos. Instead, ask: "What improvement creates the greatest benefit?" Professional architects often focus on the highest risk, the highest coupling, and the greatest source of future pain.
Many developers think of refactoring as a major event. In reality, sustainable architecture usually grows through small improvements: introduce one service, remove one dependency, add one event, clarify one module boundary, simplify one initialization chain. Individually these changes seem small. Collectively they transform architecture. This approach creates momentum. Progress becomes measurable. Risk remains manageable. Development continues.
Architectural maturity is not measured by how many patterns you know. It is measured by how effectively you make tradeoffs. Sometimes a dependency is acceptable. Sometimes a service is unnecessary. Sometimes an event adds complexity rather than removing it. Architecture is not about applying rules mechanically — it is about making informed decisions. The more clearly you understand responsibilities, boundaries, and dependencies, the better those decisions become.
Architecture improves through deliberate decisions. Not dramatic rewrites. Not perfect patterns. Not theoretical frameworks. The most valuable architectural improvement is often the next one. Small improvements applied consistently create maintainable systems.
Create a concrete, actionable improvement plan based on everything you have discovered in this chapter.
Throughout this chapter we explored a simple idea: maintainable projects do not happen by accident. They are designed. Their dependencies are intentional. Their responsibilities are clear. Their communication patterns are controlled. The purpose of this assessment is not to judge your project — it is to help you understand it.
Architecture is not binary. Projects do not suddenly become maintainable or unmaintainable. Instead, architectural health exists on a spectrum. The objective is not achieving a high score. The objective is identifying opportunities for improvement. Answer based on how the project looks today — not how you want it to look.
At the beginning of this chapter, we started with a simple observation. Projects rarely become difficult because they contain too many systems. They become difficult because those systems become increasingly connected. Dependencies spread. Responsibilities blur. Communication becomes difficult to understand. Small changes become expensive.
Fortunately, architecture is not mysterious. It is not magic. It is not reserved for senior developers. Architecture is simply the practice of making intentional decisions about how systems are organized and how they communicate. Throughout this chapter we explored several principles that help maintain that intentionality.
Maintainable projects are not created accidentally. They are assembled intentionally. Every dependency, every boundary, every service, every event, every architectural decision contributes to the long-term health of the project. The developers who understand this are not necessarily better programmers. They simply become more effective at managing complexity. And in software development, managing complexity is one of the most valuable skills you can develop.
Although these concepts were introduced individually, they are most powerful when combined. A maintainable Unity project often looks something like this: the startup process prepares shared infrastructure. Services provide shared capabilities. Modules organize responsibilities. Events enable communication. Gameplay systems focus on gameplay. Each layer has a purpose. Each layer contributes to maintainability.
Before continuing, take a moment to consider your project honestly. What dependency creates the most friction? What service would provide the greatest benefit? What direct reference should become an event? Which module boundary needs improvement? What architectural improvement will you implement first? What would become easier if you succeeded? Do not underestimate the value of these answers. Architecture improves when developers move from awareness to action.
Chapter 2 is complete when all exercises, the Modularity Health Assessment, and the final reflection are finished. The certificate download button unlocks automatically when everything is done.
Complete all exercises and the Modularity Assessment to unlock.
Architecture improves through repetition. Not inspiration. Practice consistently. Measure honestly. Improve intentionally.