Clean Code and Game Architecture

# CHAPTER 16

Clean Code and Game Architecture #

1. Introduction #

2. Learning Objectives #

• Understand and apply the Single Responsibility Principle (SRP).

• Transition from deep Inheritance to Component-Based Architecture.

• Decouple scripts using C# Action delegates (The Observer Pattern).

• Implement the Singleton pattern correctly for Game Managers.

• Organize a scalable, professional game codebase.

3. The Single Responsibility Principle (SRP) #

• *Bad:* Player.cs handles movement, health, and inventory.

• *Good:* PlayerMovement.cs handles walking. HealthComponent.cs handles taking damage. InventoryManager.cs handles items.

4. Component-Based Architecture #

// REUSABLE HEALTH COMPONENT
// This can be attached to the Player, an Orc, or even a Wooden Crate!
class HealthComponent
{
    public int maxHealth = 100;
    private int currentHealth;

    public void TakeDamage(int amount)
    {
        currentHealth -= amount;
        if (currentHealth <= 0) Die();
    }

    void Die() { Destroy(gameObject); }
}

5. The Observer Pattern (C# Events) #

• *Bad (Tightly Coupled):* The Player script calls UIManager.Instance.UpdateHealthBar(). The Player now relies on the UI existing.

• *Good (Decoupled):* The Player script simply shouts, "I took damage!" to the void. The UI script is listening and updates itself. The Player doesn't even know the UI exists.

using System;

class PlayerHealth
{
    // Define an event that broadcasts an integer
    public static event Action<int> OnHealthChanged;

    int health = 100;

    void TakeDamage(int dmg)
    {
        health -= dmg;
        // Broadcast the event! Any script listening will run its code.
        OnHealthChanged?.Invoke(health); 
    }
}

6. Managing the Game (Singletons) #

class GameManager
{
    // The single, globally accessible instance
    public static GameManager Instance { get; private set; }

    public int playerScore = 0;

    void Awake()
    {
        // Enforce the Singleton rule
        if (Instance != null && Instance != this)
        {
            Destroy(this); // Delete duplicates
        }
        else
        {
            Instance = this; 
        }
    }
}

7. Visual Learning: Monolithic vs. Component Architecture #

[ MONOLITHIC (Bad) ]
      Player.cs
   - Move(), Jump(), Shoot()
   - TakeDamage(), Heal()
   - PlaySound(), UpdateUI()
   (1000 lines, impossible to read)

[ COMPONENT-BASED (Good) ]
    [ Player GameObject ]
      |- PlayerMotor.cs (Only moves)
      |- Health.cs (Only takes damage)
      |- WeaponController.cs (Only shoots)

8. Best Practices #

• Avoid "Manager" Bloat: If your GameManager is handling audio, spawning enemies, saving data, and drawing the UI, it violates the Single Responsibility Principle. Break it down into an AudioManager, SpawnManager, SaveManager, and UIManager.

9. Common Mistakes #

• Overusing Singletons: Beginners learn the Singleton pattern and suddenly make *everything* a Singleton (e.g., Player.Instance). This is an "anti-pattern." It creates hidden dependencies and makes the code very hard to test. Only use Singletons for true global systems (Audio, Scene Loading, Game State).

10. Mini Project: Implement the Observer Pattern #

using System;

// --- SCRIPT 1: The Coin ---
class Coin
{
    // The Event Definition
    public static event Action OnCoinCollected;

    void OnTriggerEnter(Collider other)
    {
        if (other.tag == "Player")
        {
            // Shout to the void!
            OnCoinCollected?.Invoke(); 
            Destroy(gameObject);
        }
    }
}

// --- SCRIPT 2: The UI ---
class ScoreUI
{
    int score = 0;

    void OnEnable()
    {
        // Subscribe to the event (Listen for the shout)
        Coin.OnCoinCollected += UpdateScore;
    }

    void OnDisable()
    {
        // Always unsubscribe when destroyed to prevent memory leaks!
        Coin.OnCoinCollected -= UpdateScore;
    }

    void UpdateScore()
    {
        score += 10;
        Console.WriteLine("Score UI Updated: " + score);
    }
}

11. Practice Exercises #

1. 1. What does the "S" in SOLID principles stand for, and what does it mean?

1. 2. Why is it dangerous to have the Player.cs script directly reference the UIManager.cs script to update a health bar?

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain the Single Responsibility Principle. Describe a scenario where a massive "God Class" violates this principle and explain how you would refactor it.

• Q: Contrast Tightly Coupled code with Decoupled code. How does implementing C# Action delegates (Events) achieve decoupling between a Player's health component and the UI Canvas?

• Q: What is a Singleton? While useful for Game Managers, why is the Singleton pattern frequently referred to as an "anti-pattern" when overused by junior developers?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #