Unity 6 — 2D Mobile Multiplayer Tower Defense Card Game Skill

Project Architecture

Recommended Folder Structure

Assets/
├── Scripts/
│   ├── Core/               # Singletons, GameManager, GameState
│   ├── Networking/          # NetworkManager config, connection, relay, lobby
│   │   ├── NetworkGameManager.cs
│   │   ├── RelayManager.cs
│   │   └── LobbyManager.cs
│   ├── Cards/               # Card data, hand, deck, deployment
│   │   ├── CardData.cs          (ScriptableObject)
│   │   ├── DeckManager.cs
│   │   ├── HandManager.cs
│   │   └── CardDeployer.cs      (NetworkBehaviour)
│   ├── Towers/              # Tower logic, targeting, upgrades
│   │   ├── Tower.cs             (NetworkBehaviour)
│   │   ├── TowerTargeting.cs
│   │   └── Projectile.cs        (NetworkBehaviour)
│   ├── Units/               # Spawned units, pathfinding, combat
│   │   ├── Unit.cs              (NetworkBehaviour)
│   │   ├── UnitMovement.cs
│   │   └── UnitCombat.cs
│   ├── Economy/             # Elixir/mana generation, cost validation
│   │   └── ElixirManager.cs     (NetworkBehaviour)
│   ├── UI/                  # HUD, card hand UI, health bars
│   ├── Input/               # Touch/click input abstraction
│   └── Utils/               # Object pooling, math helpers, extensions
├── Data/                    # ScriptableObjects (card definitions, balance)
├── Prefabs/
│   ├── NetworkPrefabs/      # All spawnable NetworkObjects
│   └── UI/
├── Scenes/
│   ├── MainMenu.unity
│   ├── Lobby.unity
│   └── Battle.unity
└── Art/                     # Sprites, animations, VFX

Layer Separation

Game Logic never references UnityEngine.UI or sprite renderers. Presentation subscribes to game state changes (events or NetworkVariable.OnValueChanged) and updates visuals.

Netcode for GameObjects — Key Principles

Authority Model

In this game: host-authoritative (client-hosted with relay).

• The host runs the server logic and also acts as a player.
• The other player is a pure client.
• Use Unity Relay to avoid NAT traversal issues on mobile.
• Use Unity Lobby for matchmaking.

Client A (Host)          Client B
┌──────────────┐        ┌──────────────┐
│ Server Logic │◄──────►│ Client Logic │
│ + Client     │  Relay  │              │
│   Logic      │        │              │
└──────────────┘        └──────────────┘

NetworkBehaviour Essentials

public class Tower : NetworkBehaviour
{
    // Server-authoritative state — automatically synced to all clients
    private NetworkVariable<int> _health = new(
        writePerm: NetworkVariableWritePermission.Server
    );

    private NetworkVariable<float> _attackTimer = new(
        writePerm: NetworkVariableWritePermission.Server
    );

    public override void OnNetworkSpawn()
    {
        // Subscribe to value changes for visual updates
        _health.OnValueChanged += OnHealthChanged;

        if (IsServer)
        {
            _health.Value = GetComponent<TowerData>().MaxHealth;
        }
    }

    public override void OnNetworkDespawn()
    {
        _health.OnValueChanged -= OnHealthChanged;
    }

    private void OnHealthChanged(int oldVal, int newVal)
    {
        // Presentation layer reacts here — update health bar sprite
    }
}

RPC Rules for This Game

Never put game logic in ClientRpcs. ClientRpcs are for presentation triggers (VFX, SFX, UI updates). The server computes; clients display.

Spawning Networked Objects

All spawnable prefabs must be registered in the NetworkManager's NetworkPrefabs list.

// Server-side only — spawns a tower for a specific player
public void SpawnTower(CardData card, Vector2 position, ulong ownerClientId)
{
    if (!IsServer) return;

    var go = Instantiate(card.Prefab, position, Quaternion.identity);
    var netObj = go.GetComponent<NetworkObject>();
    netObj.SpawnWithOwnership(ownerClientId);
}

Ownership matters: The owner of a tower can send ServerRpcs targeting it (e.g., upgrade, sell). Non-owners cannot. Use OwnerClientId checks for validation.

Common Bug Patterns & Fixes

Debugging & Problem-Solving Workflow

When the user presents a bug or architecture question:

1. Clarify where code runs. Ask: "Is this on the server/host, the client, or both?" Most networking bugs are authority mismatches.
2. Check the spawn chain. For "object not appearing" bugs: Is the prefab registered? Is Spawn() called? Is OnNetworkSpawn running? Is the NetworkObject component present?
3. Trace the data flow. For desync: Who writes the NetworkVariable? Who reads it? Is the write permission correct? Is OnValueChanged wired up?
4. Verify mobile constraints. For performance: How many NetworkObjects are active? How many RPCs per second? What's the sprite batch count?
5. Reproduce before fixing. Ask the user to test in the Unity Editor with two instances (ParrelSync or build + editor). Single-instance testing hides all networking bugs.

Mobile-Specific Quick Reference

• Target: 60fps on mid-range phones, 3GB RAM budget (realistic ~400MB for the game)
• Draw calls: Keep under 50-80 for 2D. Use SpriteAtlas aggressively. Use SortingLayers.
• Object pooling: Mandatory for projectiles, units, VFX. Use INetworkPrefabInstanceHandler for networked pool integration.
• Touch input: Abstract behind IInputProvider — test with mouse in editor, touch on device. Always check EventSystem.current.IsPointerOverGameObject(fingerId) before gameplay input.
• GC pressure: Avoid allocations in Update loops. Cache GetComponent results. Use NativeArray or structs for hot-path data. Avoid LINQ in gameplay code.
• Network bandwidth: On mobile networks, keep under 10KB/s per client. Prefer NetworkVariable with dirty-flag over frequent RPCs. Send only deltas.

See references/mobile-optimization.md for the full mobile performance guide.

Code Style & Conventions

File Organization Rules

• One MonoBehaviour / NetworkBehaviour per file.
• One ScriptableObject definition per file.
• Keep using statements sorted: System, UnityEngine, Unity.Netcode, project namespaces.
• Use #region sparingly — if you need regions, the class is probably too large.
• Namespace everything: namespace MyGame.Cards { ... }, namespace MyGame.Networking { ... }.

How to Respond

• Lead with the diagnosis or root cause, not just the fix. "Your tower isn't syncing because NetworkVariable write permission defaults to Server, but you're writing from the client."
• Show corrected code — senior devs want to see the pattern, not just hear about it.
• When there's a tradeoff (e.g., deterministic sim vs. state sync, host-auth vs. relay cost), surface it explicitly and recommend one, explaining why.
• Flag authority issues even if the user didn't ask about networking. If they put game logic in a ClientRpc, call it out.
• Flag mobile performance issues even if the user asked about something else. If they're allocating in Update(), mention it.
• Be opinionated. Recommend the right pattern for a multiplayer mobile TD card game — don't list five approaches when one is clearly better for this context.
• When referencing Unity APIs, use the correct Unity 6 / Netcode 2.x API names. Don't reference deprecated MLAPI or older Netcode 1.x patterns.