Matt F
4892d7253d
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>
26 lines
1.2 KiB
C#
26 lines
1.2 KiB
C#
// Assets/_Project/Scripts/Core/MatchRules.cs
|
|
namespace TD.Core
|
|
{
|
|
/// <summary>
|
|
/// Match-wide constants that several unrelated systems have to agree on.
|
|
/// </summary>
|
|
public static class MatchRules
|
|
{
|
|
/// <summary>
|
|
/// Maximum players in one lobby.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// <b>Reduced from 9 to 3 for the 2.0 design</b> as a deliberate scope cut: three players
|
|
/// is enough for the shared-lives and shared-vote mechanics to matter, and it shrinks map
|
|
/// authoring, balance surface, and network load all at once.
|
|
///
|
|
/// <para><b>Why <see cref="PlayerSlot"/> still runs to 9.</b> Shrinking the enum would
|
|
/// invalidate the owner grids baked into existing <c>LevelData</c> assets and force a
|
|
/// re-bake of every map, for no runtime benefit — the extra values are simply never
|
|
/// allocated. Slot allocation caps here instead, which is the only place that decides who
|
|
/// gets a slot at all. Per-slot arrays stay sized to the enum, so they hold a few unused
|
|
/// entries; that is intentional and costs nothing.</para>
|
|
/// </remarks>
|
|
public const int MaxPlayers = 3;
|
|
}
|
|
}
|