📚 Learning Objectives

• Understand the Decorator design pattern
• Learn how to add functionality without altering objects
• Implement a customizable weapon attachment system
• Combine Decorator pattern with Unity ScriptableObjects
• Create designer-friendly upgrade mechanics
• Explore when Decorator is better than inheritance

Developer's Note: "Never Panic Early"

🎯 Weapon System Design

Core Concept

Every bike comes with a front-mounted laser weapon. Players can purchase attachments to boost weapon stats.

Requirements:

• Customizable: Multiple attachments available
• Dynamic: Add/remove attachments at runtime
• Limited Slots: Maximum of 2 expansion slots
• Stackable: Attachments combine their effects
• Reversible: Can restore to base weapon

🔧 Weapon Attachments

Three Attachment Categories:

• Injector (Plasma):
  • Amplifies damage capacity
  • Increases weapon strength
  • Perfect for aggressive players
• Stabilizer:
  • Reduces vibration at high speed
  • Expands weapon range
  • Improves accuracy
• Cooler (Water-Cooling):
  • Enhances rate of fire
  • Reduces cooldown duration
  • Sustains longer combat

🔍 Understanding Decorator Pattern

Core Definition

Add new functionality to an existing object without altering it, by creating a decorator class that wraps the original.

Real-World Analogy:

Think of a smartphone:

• Base phone: iPhone (core functionality)
• Decorators: Case, screen protector, pop socket
• Each adds functionality without modifying the phone
• Can add/remove decorators independently
• Phone works the same with or without decorators

🏗️ Decorator Pattern Structure

Key Participants:

• Component Interface: Defines common interface
  • In our case: IWeapon
• Concrete Component: Original object
  • In our case: Weapon
• Decorator Base: Wraps component
  • In our case: WeaponDecorator
• Concrete Decorators: Specific enhancements
  • In our case: WeaponAttachment instances

⚖️ Decorator vs Inheritance

✅ Benefits of Decorator Pattern

• Runtime Flexibility:
  • Add/remove functionality dynamically
  • Change behavior without restarting
  • Player can customize on-the-fly
• Alternative to Subclassing:
  • Avoid class explosion (too many subclasses)
  • Overcome limits of single inheritance
  • More flexible than static inheritance
• Single Responsibility:
  • Each decorator has one job
  • Easy to understand and test
  • Maintainable code
• Open/Closed Principle:
  • Open for extension (new decorators)
  • Closed for modification (base weapon unchanged)

⚠️ Potential Drawbacks

• Relationship Complexity:
  • Multiple layers of wrapping can be confusing
  • Hard to track initialization chain
  • Debugging nested decorators is tricky
• Code Complexity:
  • Many small decorator classes to maintain
  • Can be overkill for simple cases
  • Learning curve for team members
• Performance:
  • Extra indirection through wrappers
  • More objects in memory
  • Usually negligible, but consider for mobile

🤔 When to Use Decorator Pattern

Use Decorator When:

• ✅ Need to add functionality at runtime
• ✅ Want to avoid inheritance explosion
• ✅ Behaviors should be composable/stackable
• ✅ Need to add/remove features dynamically
• ✅ Extending sealed/final classes

Other Game Use Cases:

• Collectible Card Games: Buff cards stacked on base cards
• RPG Equipment: Armor with enchantments and gems
• Character Abilities: Temporary buffs/debuffs
• UI Systems: Windows with borders, shadows, animations
• Audio Processing: Effects chain (reverb, delay, distortion)

🎮 Unity-Specific Challenge

The Constructor Problem

Traditional Decorator: Relies heavily on constructors

// Standard C# approach
IWeapon weapon = new Weapon();
weapon = new InjectorDecorator(weapon);
weapon = new CoolerDecorator(weapon);

Our Solution:

Adapt the pattern to use Unity's ScriptableObject system while preserving Decorator benefits!

💻 Implementation: IWeapon Interface

┌─────────────┐
│   IWeapon   │
│  (interface)│
└──────┬──────┘
       │ implements
  ┌────┴────┐
  ▼         ▼
┌──────┐ ┌────────────────┐
│Weapon│ │WeaponDecorator │
└──────┘ └────────────────┘

💻 WeaponConfig - Base Configuration

💻 WeaponConfig - Properties & Metadata

💻 Weapon - The Component

💻 WeaponDecorator - The Wrapper

💻 WeaponDecorator - Complete

💻 WeaponAttachment - Designer Assets

💻 WeaponAttachment - Properties

💻 BikeWeapon - MonoBehaviour Client

💻 BikeWeapon - The Magic Method

💻 BikeWeapon - Reset Functionality

💻 BikeWeapon - Debug GUI

🔄 The Complete Flow

🧪 Testing the System

Setup Steps:

1. Create new Unity scene
2. Create empty GameObject, add BikeWeapon component
3. Create WeaponConfig asset:
   • Assets → Create → Weapon → Config
   • Name: "BaseLaser"
   • Set: Rate=5, Range=10, Strength=25, Cooldown=2
4. Create Attachment assets:
   • Assets → Create → Weapon → Attachment
   • "Injector": Strength +15
   • "Cooler": Rate +10, Cooldown -1
   • "Stabilizer": Range +20
5. Assign assets to BikeWeapon in Inspector
6. Add Decorator section to TestPanel (next slide)

🎮 Updating TestPanel for Decorator Pattern

📊 Expected Behavior

Before Decoration:

Range: 10
Strength: 25
Cooldown: 2
Firing Rate: 5
Weapon Firing: False

After Decoration (Injector + Cooler):

Range: 10          (no change)
Strength: 40       (25 + 15 from Injector)
Cooldown: 1        (2 + -1 from Cooler)
Firing Rate: 15    (5 + 10 from Cooler)
Weapon Firing: False
Main: Injector
Secondary: Cooler

Click "Toggle Fire" to see firing rate in action!

🎨 Designer-Friendly Workflow

Creating New Attachments (No Code!):

1. Right-click in Project: Create → Weapon → Attachment
2. Name it: "TurboCharger"
3. Configure in Inspector:
   • Rate: +15 (fires faster)
   • Range: 0 (no change)
   • Strength: -5 (trade-off for speed)
   • Cooldown: -2 (cools faster)
   • Attachment Name: "Turbo Charger"
   • Description: "High speed, low power"
4. Assign prefab: Drag 3D model
5. Done! No programming required

🔀 Combination Possibilities

With 3 Attachments:

🔧 Extending Beyond 2 Slots

Current Limitation: Hardcoded 2 Slots

Better Approach: Dynamic Slots

Now easily configurable to 3, 4, or more slots!

🔄 Alternative: Without Decorator

Simple Iteration Approach:

🎭 Pattern Experimentation

Our Implementation is "Unorthodox":

• Mixes C# constructors with Unity ScriptableObjects
• Uses assets instead of pure code classes
• Adapts pattern to Unity's lifecycle
• Prioritizes designer workflow over "purity"

Why This is OK:

• ✅ Preserves core pattern benefits (wrapping, chaining)
• ✅ Adds practical value (no-code asset creation)
• ✅ Solves real problem (weapon customization)
• ✅ Maintainable and scalable

⚖️ Decorator vs Simple: Trade-offs

🌍 Beyond Weapons

Other Decorator Use Cases:

• Character Customization:
  • Base character + clothing + accessories + buffs
  • Each layer decorates appearance and stats
• Spell System (Magic Game):
  • Base spell + modifiers (area, duration, power)
  • Infinite spell variations from combinations
• Vehicle Upgrades (Racing):
  • Base car + engine upgrade + tire upgrade + turbo
  • Each affects different performance aspects
• UI System:
  • Base window + border + shadow + animation
  • Each decorator adds visual/functional layer
• Damage System:
  • Base damage + elemental + critical + armor penetration
  • Chain damage modifiers

⚡ Performance Tips

Optimization Strategies:

• Cache Decorated Values:
  // Instead of calculating every frame: float strength = _weapon.Strength; // Traverses decorator chain // Cache when decorators change: private float _cachedStrength; public void Decorate() { // Apply decorators... _cachedStrength = _weapon.Strength; // Calculate once }

  Caching the decorated value after each Decorate() call avoids re-traversing the chain every frame. Compute once when the chain changes, read cheaply in Update() or OnGUI().

• Limit Decorator Depth:
  • 2-3 layers: negligible performance impact
  • 10+ layers: consider caching
  • Our 2-slot system: perfectly fine
• ScriptableObject Benefits:
  • Shared data across instances (memory efficient)
  • No runtime allocation (created as assets)
  • Better than creating classes at runtime

🚫 Common Mistakes to Avoid

1. Modifying Wrapped Object Directly:
   // BAD - breaks pattern intent public class WeaponDecorator : IWeapon { public WeaponDecorator(IWeapon weapon) { weapon.Strength = 100; // ❌ Don't modify! } } // GOOD - return modified values public float Strength { get { return _weapon.Strength + 50; } // ✓ Enhance }

   Mutating the wrapped object's state permanently breaks the "wrap without modifying" guarantee. If you set weapon.Strength = 100 in the constructor, the original object is permanently changed — other code reading it will see the corrupted value. The correct approach returns a new computed value in the property getter, leaving the original untouched.

2. Forgetting Interface Consistency:
   • Decorator must implement same interface as component
   • Otherwise can't wrap/chain properly
3. Not Handling null Attachments:
   // Add null checks! if (mainAttachment && secondaryAttachment) { ... }

   Always check for null before constructing decorators. An unassigned WeaponAttachment ScriptableObject reference is null in Unity. Passing null into WeaponDecorator will throw a NullReferenceException at runtime.

4. Overcomplicating Simple Systems:
   • If you only have 1-2 attachments total, pattern may be overkill

🧪 Unit Testing Decorators

📝 Summary

What We Learned:

• ✅ Decorator pattern adds functionality without altering objects
• ✅ Works by wrapping objects in decorator classes
• ✅ Perfect for weapon attachments and equipment upgrades
• ✅ More flexible than inheritance (runtime, reversible)
• ✅ Can chain decorators for unlimited combinations
• ✅ Adapted pattern to use Unity ScriptableObjects
• ✅ Enabled designer-friendly asset creation

Key Takeaways:

• Interface consistency is crucial (IWeapon)
• Decorators wrap, don't modify directly
• Pattern experimentation is encouraged
• Balance pattern benefits vs code complexity
• ScriptableObjects make patterns more practical

Gaming History Moment 🕹️

Pokémon Mania (1996-2000)

💪 Practice Exercise

Implement an Armor Decoration System

❓ Questions?

Next Lecture:

Spatial Partition Pattern: Optimizing large game worlds with spatial data structures

Thank you! 🎮