🏛️ Facade Pattern

Game Programming - CSCI 3213

Spring 2026 - Lecture 14

Oklahoma City University

• Understand the Facade design pattern
• Learn to simplify complex subsystem interfaces
• Design and implement a bike engine system
• Recognize when to use Facade vs Adapter patterns
• Avoid common pitfalls (hiding messy code, too many facades)
• Create maintainable, simplified interfaces for complex systems

Starting Your Car

Think about what happens when you turn the ignition key:

Core Concept

Provide a unified, simplified interface to a set of interfaces in a subsystem, making the subsystem easier to use.

The Problem It Solves

Your game has multiple complex, interacting systems. Clients need to use these systems but shouldn't need to understand their intricate interactions.

Key Participants:

• Facade: Simplified interface to subsystems
  • In our case: BikeEngine
• Subsystems: Complex components that do the work
  • FuelPump
  • CoolingSystem
  • TurboCharger
• Client: Uses the Facade
  • ClientFacade - doesn't know about subsystems

Client → Facade.TurnOn() → FuelPump.Start()
                         → CoolingSystem.Start()
                         → Internal orchestration
                    

• Simplified Interface:
  • Hides complexity from client code
  • Easier to understand and use
  • Reduces cognitive load
• Loose Coupling:
  • Client depends on facade, not subsystems
  • Subsystems can change without affecting client
  • Easier to swap implementations
• Easy Refactoring:
  • Modify subsystems behind the facade
  • Interface remains stable for clients
  • Isolates changes to one layer
• Layered Architecture:
  • Clear separation of concerns
  • Promotes organized code structure

• Hiding the Mess:
  • Easy to use facade to mask poorly designed code
  • Temporary fix becomes permanent technical debt
  • Defeats pattern's core benefits
• Too Many Facades (God Object):
  • Unity developers love Singleton + Facade = Manager classes
  • Leads to tightly coupled "manager hell"
  • Difficult to debug, refactor, unit test
  • Example: GameManager, InputManager, UIManager, SoundManager...
• Over-Simplification:
  • Facade might not expose all needed functionality
  • Forces workarounds or direct subsystem access

Use Facade When:

• ✅ Subsystem is complex and has many dependencies
• ✅ Want to provide simple interface for common tasks
• ✅ Need to decouple client from subsystem implementation
• ✅ Want to layer your application architecture
• ✅ Subsystem has poor or confusing API

Don't Use Facade When:

• ❌ Subsystem is already simple (adds unnecessary layer)
• ❌ Trying to hide messy code instead of refactoring
• ❌ All clients need full subsystem functionality

Common Game Use Cases:

• Engine systems (physics, audio, rendering)
• Input handling (keyboard, gamepad, touch unified)
• Save/load systems with multiple backends
• Network communication abstraction

Design Goal:

Simulate a motorcycle engine with realistic component interactions, but expose a simple interface for gameplay.

Without Facade:

// Client needs to know EVERYTHING
var fuelPump = gameObject.AddComponent<FuelPump>();
var coolingSystem = gameObject.AddComponent<CoolingSystem>();
var turboCharger = gameObject.AddComponent<TurboCharger>();

fuelPump.engine = this;
coolingSystem.engine = this;
turboCharger.engine = this;

StartCoroutine(fuelPump.burnFuel);
StartCoroutine(coolingSystem.coolEngine);
// ... and on and on ...

With Facade:

// Client just uses the engine
_bikeEngine.TurnOn();

Steps:

1. Create new Unity scene
2. Create empty GameObject named "BikeEngineTest"
3. Attach ClientFacade script
4. Press Play
5. Click "Turn On" button
6. Watch fuel decrease and temperature regulate
7. Click "Toggle Turbo" - see cooling pause
8. Wait for fuel to run out or engine to overheat

Example: Add Nitro Injector

// 1. Create new subsystem
public class NitroInjector : MonoBehaviour
{
    public BikeEngine engine;

    public void InjectNitro()
    {
        // Massive speed boost!
        // Huge fuel consumption!
        // Temperature spike!
    }
}

// 2. Update facade
public class BikeEngine : MonoBehaviour
{
    private NitroInjector _nitroInjector;

    void Awake()
    {
        // ... existing code ...
        _nitroInjector = gameObject.AddComponent<NitroInjector>();
    }

    public void ActivateNitro()
    {
        if (_isEngineOn)
            _nitroInjector.InjectNitro();
    }
}

Additional Subsystems to Consider:

• Transmission/Gearbox:
  • Calculate RPM (revolutions per minute)
  • Manual or automatic shifting
  • Gear ratios affect speed and acceleration
• Damage System:
  • Engine wear over time
  • Crash damage affects performance
  • Repair mechanics
• Audio System:
  • Engine sound pitch based on RPM
  • Turbo whoosh sound effect
  • Backfire on overheat
• Particle Effects:
  • Exhaust smoke
  • Turbo flames
  • Overheat steam

Before Using Facade, Consider:

• Abstract Factory Pattern:
  • Use if you only need to hide object creation
  • Facade does more than just creation
• Adapter Pattern:
  • Use if bridging incompatible interfaces
  • Facade creates new simplified interface
• Mediator Pattern:
  • Use if subsystems need to communicate
  • Facade is one-way: client → subsystems
  • Mediator is multi-way: subsystems ↔ mediator ↔ subsystems
• Service Locator Pattern:
  • Use for global service access
  • Facade is instance-specific

1. Using Facade to Hide Bad Code:

   // BAD - Facade hiding spaghetti code
   public void DoEverything()
   {
       // 500 lines of messy logic
   }
   
   // GOOD - Facade coordinating clean subsystems
   public void StartGame()
   {
       _levelLoader.Load();
       _playerSpawner.Spawn();
       _uiManager.ShowHUD();
   }

2. Too Many Manager Classes:
   • ❌ GameManager, LevelManager, PlayerManager, EnemyManager...
   • ✅ Use facades sparingly, only where needed
3. Leaky Abstraction:

   // BAD - Exposing subsystem details
   public FuelPump GetFuelPump() { return _fuelPump; }
   
   // GOOD - Exposing only needed info
   public float GetFuelPercent() { return fuelAmount / maxFuel; }

4. Overly Complex Facade:
   • If facade has 50+ methods, reconsider design
   • Might need multiple smaller facades

Add Logging to Facade:

public void TurnOn()
{
    Debug.Log("[BikeEngine] TurnOn() called");
    _isEngineOn = true;

    Debug.Log("[BikeEngine] Starting FuelPump coroutine");
    StartCoroutine(_fuelPump.burnFuel);

    Debug.Log("[BikeEngine] Starting CoolingSystem coroutine");
    StartCoroutine(_coolingSystem.coolEngine);

    Debug.Log("[BikeEngine] Engine is now running");
}

Visual Debugging:

• Gizmos to show component states
• Color-coded status indicators
• Debug UI overlay

void OnDrawGizmos()
{
    if (_isEngineOn)
        Gizmos.color = Color.green;
    else
        Gizmos.color = Color.red;

    Gizmos.DrawWireSphere(transform.position, 1f);
}

Optimization Strategies:

• Lazy Initialization:

  // Only create subsystems when needed
  private FuelPump _fuelPump;
  public FuelPump FuelPump
  {
      get
      {
          if (_fuelPump == null)
              _fuelPump = gameObject.AddComponent<FuelPump>();
          return _fuelPump;
      }
  }

• Update Rate Control:

  // Don't update every frame
  private float _updateInterval = 0.1f;
  private float _nextUpdate = 0f;
  
  void Update()
  {
      if (Time.time >= _nextUpdate)
      {
          UpdateEngine();
          _nextUpdate = Time.time + _updateInterval;
      }
  }

• Object Pooling for Effects:
  • Pool exhaust particles
  • Pool audio sources

Common Unity Pattern:

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    private AudioSystem _audio;
    private InputSystem _input;
    private SaveSystem _save;

    void Awake()
    {
        if (Instance != null && Instance != this)
        {
            Destroy(gameObject);
            return;
        }

        Instance = this;
        DontDestroyOnLoad(gameObject);

        // Initialize subsystems
        _audio = new AudioSystem();
        _input = new InputSystem();
        _save = new SaveSystem();
    }

    // Simplified facade methods
    public void PlaySound(string name) => _audio.Play(name);
    public float GetAxis(string name) => _input.GetAxis(name);
    public void SaveGame() => _save.Save();
}

Facade Pattern in Production Games:

• Input System Facade:
  • Unify keyboard, gamepad, touch, VR inputs
  • Client calls GetMoveDirection(), not Input.GetAxis()
  • Easy to rebind controls
• Audio System Facade:
  • Wrap Unity's AudioSource, AudioMixer, etc.
  • Simple PlaySFX(), PlayMusic(), SetVolume()
  • Handle pooling, fade in/out, priority
• Save System Facade:
  • Hide PlayerPrefs, file I/O, cloud saves
  • Client calls Save(key, value), Load(key)
  • Automatic serialization, encryption
• UI Manager Facade:
  • Manage canvas hierarchy, panels, popups
  • ShowMenu(), HideMenu(), ShowDialog()
  • Handle transitions, stacking
• Network Facade:
  • Wrap Netcode, Mirror, Photon
  • SendMessage(), Connect(), Disconnect()
  • Easy to swap networking solutions

Organizing Your Game:

┌─────────────────────────────────────┐
│    Presentation Layer (UI)          │
│    - Buttons, Menus, HUD             │
└──────────────┬──────────────────────┘
               │
┌──────────────▼──────────────────────┐
│    Facade Layer (Managers)          │ ← Simplified Interface
│    - GameManager                     │
│    - LevelManager                    │
│    - PlayerManager                   │
└──────────────┬──────────────────────┘
               │
┌──────────────▼──────────────────────┐
│    Business Logic Layer              │
│    - Game rules, systems             │
│    - Physics, AI, progression        │
└──────────────┬──────────────────────┘
               │
┌──────────────▼──────────────────────┐
│    Data Layer                        │
│    - Save files, databases           │
│    - Assets, configuration           │
└─────────────────────────────────────┘
                    

Gradual Improvement Strategy:

// Wrap existing messy system
public class LegacyInventoryFacade
{
    private OldMessyInventory _legacy = new OldMessyInventory();

    public void AddItem(string item)
    {
        // Simple interface hides complexity
        _legacy.DoComplicatedThingToAddItem(item, true, null, 0);
    }
}

// Change all client code to use facade
// Before: OldMessyInventory inventory;
// After:  LegacyInventoryFacade inventory;

// Replace implementation, keep interface
public class LegacyInventoryFacade
{
    private NewCleanInventory _new = new NewCleanInventory();

    public void AddItem(string item)
    {
        _new.Add(item); // Much better!
    }
}

What We Learned:

• ✅ Facade pattern provides simplified interface to complex subsystems
• ✅ Hides complexity, not functionality
• ✅ Different from Adapter (simplify vs adapt)
• ✅ Implemented realistic bike engine with 3 subsystems
• ✅ Client code reduced from 20+ lines to 1 line
• ✅ Easy to extend with new subsystems

Key Takeaways:

• Facade creates NEW simplified interface
• Subsystems remain accessible if needed
• Don't use to hide bad code - use to organize good code
• Beware of too many manager classes (Singleton + Facade)
• Perfect for layered architecture
• Excellent for refactoring legacy systems

Build a Character Combat System Facade

Further Reading:

• Design Patterns (GoF): Original Facade pattern definition
• Game Development Patterns with Unity 2021:
  • Chapter 15: Concealing Complexity with a Facade
• Head First Design Patterns: Facade chapter with home theater example
• Refactoring.Guru:
  • https://refactoring.guru/design-patterns/facade

Unity Resources:

• Unity Manual: Coroutines
• Unity Scripting Reference: MonoBehaviour lifecycle
• Unity Learn: Intermediate Scripting

Related Patterns:

• Adapter Pattern (Lecture 13)
• Mediator Pattern
• Service Locator Pattern

Course Progress:

• ✅ Lecture 13: Adapter Pattern
• ✅ Lecture 14: Facade Pattern (current)
• ⏭️ Lecture 15: Final Project Workshop

Design Patterns Covered:

• Creational: Singleton, Object Pool, Abstract Factory
• Structural: Adapter, Facade, Decorator
• Behavioral: Observer, Visitor, Strategy, Command
• Optimization: Spatial Partition

Final Project Ideas Using Facade:

• Racing game with complex vehicle systems
• RPG with combat, inventory, quest systems
• Strategy game with resource management
• Simulation game with interconnected systems

Thank you! 🎮