First pass at full refactor to 2.0 design

Restructures the game around the cyclical run loop from Game Design Doc V2:
5 waves = a cycle, 3 cycles = a phase, each phase ends in a boss.

- New TD.Gameplay.Waves: WaveGroup / PhaseDefinition / RunDefinition author the
  run as draggable weighted pools; RunState owns phase/cycle position, the drawn
  wave slots, and the per-slot enemy buff sets. WaveManager's flat wave array is
  gone -- it now only runs the encounter RunState points at.
- New TD.Gameplay.EnemyUpgrades: the post-wave enemy-buff vote, with public
  live-replicated ballots so the HUD can show who voted for what.
- Inter-wave flow is now strictly sequential: draft -> vote -> build, each stage
  ending early once every player has acted.
- Enemy abilities inverted from per-instance random rolls to deterministic,
  stacking per-wave-slot sets. Six cards ship: Split (reworked), Flight, Blink,
  No Bounty, Gold Theft, Double Up.
- Tower upgrades are a two-step tree: a draft pick unlocks a node, gold converts
  an already-placed tower in place.
- Boss encounters flag their enemies and drive a boss HP bar.
- Player cap reduced to 3 via MatchRules.MaxPlayers.
- GoldConfig is now keyed by global encounter number rather than wave index.

Compiles clean; NOT yet verified in-engine. Editor wiring still required --
see Docs/2.0_Setup_Checklist.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Matt F 2026-07-30 17:45:11 -07:00
parent 7e5c3a8279
commit 4892d7253d
64 changed files with 4023 additions and 344 deletions

View file

@ -0,0 +1,102 @@
// Assets/_Project/Scripts/Gameplay/Waves/PhaseDefinition.cs
using System.Collections.Generic;
using UnityEngine;
namespace TD.Gameplay.Waves
{
/// <summary>
/// One phase of a run: the pool its cycle waves are drawn from, and the pool its boss is
/// drawn from. A phase runs the same drawn wave set for every one of its cycles, then ends
/// in a boss.
/// </summary>
/// <remarks>
/// <b>Groups, not waves.</b> Both pools are lists of <see cref="WaveGroup"/> assets rather
/// than flat wave lists, so re-balancing a run means dragging a group between phases instead
/// of re-authoring individual entries. Listing the same group in two phases is legal — the
/// draws are independent.
///
/// <para><b>Draw contract.</b> <c>RunState</c> draws <c>WavesPerCycle</c> waves from
/// <see cref="WaveGroups"/> with <b>distinct enemy types</b>, because enemy upgrades are keyed
/// to a wave slot and two slots sharing an enemy type would make "which wave did this buff
/// apply to" ambiguous. That makes the real authoring requirement stricter than the entry
/// count: a phase needs at least <c>WavesPerCycle</c> distinct enemy types across its groups,
/// not just that many waves. <see cref="CountDistinctEnemyTypes"/> exists so the draw can
/// fail loudly at match start rather than mid-run.</para>
/// </remarks>
[CreateAssetMenu(fileName = "PhaseDefinition", menuName = "TD/Run/Phase Definition", order = 11)]
public class PhaseDefinition : ScriptableObject
{
[Tooltip("Designer-facing name for this phase, shown in validation messages. " +
"Falls back to the asset name when empty.")]
public string DisplayName;
[Tooltip("Groups this phase's cycle waves are drawn from. All groups are pooled " +
"together for the draw; group membership is an authoring convenience, not a " +
"draw boundary.")]
public WaveGroup[] WaveGroups;
[Tooltip("Groups this phase's boss is drawn from. A boss is an ordinary WaveDefinition " +
"that happens to spawn a single powerful enemy.")]
public WaveGroup[] BossGroups;
[Tooltip("Enemy-buff cards votable during this phase. Gating is per PHASE, not per cycle " +
"— every card listed here can be voted on from this phase's very first wave. " +
"Cards must also appear in the scene's EnemyUpgradePool to be offerable.")]
public EnemyUpgrades.EnemyUpgradeGroup[] EnemyUpgradeGroups;
/// <summary>Name used in validation and log messages. Falls back to the asset name.</summary>
public string Label => string.IsNullOrWhiteSpace(DisplayName) ? name : DisplayName;
/// <summary>
/// Appends every non-null, non-zero-weight entry across <paramref name="groups"/> into
/// <paramref name="into"/>. Zero-weight entries are filtered here (not at draw time) so
/// "weight 0 means it can never appear" is enforced in exactly one place.
/// </summary>
public static void CollectCandidates(WaveGroup[] groups, List<WavePoolEntry> into)
{
into.Clear();
if (groups == null) return;
for (int g = 0; g < groups.Length; g++)
{
var group = groups[g];
if (group?.Waves == null) continue;
for (int i = 0; i < group.Waves.Length; i++)
{
var entry = group.Waves[i];
if (entry?.Wave == null) continue;
if (entry.Weight <= 0f) continue;
into.Add(entry);
}
}
}
/// <summary>Collects this phase's cycle-wave candidates.</summary>
public void CollectWaveCandidates(List<WavePoolEntry> into)
=> CollectCandidates(WaveGroups, into);
/// <summary>Collects this phase's boss candidates.</summary>
public void CollectBossCandidates(List<WavePoolEntry> into)
=> CollectCandidates(BossGroups, into);
/// <summary>
/// How many distinct enemy types are reachable across this phase's wave groups. The
/// upper bound on how many wave slots this phase can fill, since the draw requires
/// distinct types.
/// </summary>
public int CountDistinctEnemyTypes()
{
var candidates = new List<WavePoolEntry>();
CollectWaveCandidates(candidates);
var seen = new HashSet<EnemyDefinition>();
foreach (var entry in candidates)
{
var type = entry.Wave.PrimaryEnemyType;
if (type != null) seen.Add(type);
}
return seen.Count;
}
}
}