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>
66 lines
3.2 KiB
C#
66 lines
3.2 KiB
C#
// Assets/_Project/Scripts/Gameplay/EnemyUpgrades/EnemyUpgradeOption.cs
|
|
using UnityEngine;
|
|
using TD.Gameplay.Waves;
|
|
|
|
namespace TD.Gameplay.EnemyUpgrades
|
|
{
|
|
/// <summary>
|
|
/// Base class for one card in the post-wave enemy-buff vote. Players collectively choose one
|
|
/// of these to permanently attach to the wave they just cleared; it takes effect the next time
|
|
/// that wave comes round in the cycle.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// <para><b>Mirrors <c>DraftOption</c> deliberately.</b> Same shape — abstract SO, one asset
|
|
/// per card, concrete subclasses carry the payload — so the two authoring surfaces read the
|
|
/// same way. The difference is who it targets: a draft option applies to a player, an enemy
|
|
/// upgrade applies to a <i>wave slot</i>.</para>
|
|
///
|
|
/// <para><b>Identity.</b> Options live in <see cref="EnemyUpgradePool"/> and cross the network
|
|
/// as their pool index, the same stable-within-a-match id pattern used by the tower catalog
|
|
/// and draft pool.</para>
|
|
///
|
|
/// <para><b>Recording is not this type's job.</b> <c>WaveVote</c> records the winning option id
|
|
/// onto the slot via <c>RunState.ServerAddUpgrade</c>; <see cref="ServerOnApplied"/> is only
|
|
/// for cards that need a side effect <i>beyond</i> being recorded (the vote-meta cards).
|
|
/// Ability cards need nothing here — the spawn path reads the slot's recorded set.</para>
|
|
/// </remarks>
|
|
public abstract class EnemyUpgradeOption : ScriptableObject
|
|
{
|
|
[Header("Presentation")]
|
|
[Tooltip("Name shown on the vote card.")]
|
|
public string DisplayName;
|
|
|
|
[Tooltip("Short description shown on the vote card. Say what it does to the enemies, in " +
|
|
"the players' terms — this is the only thing they get to judge the vote on.")]
|
|
[TextArea(2, 4)]
|
|
public string Description;
|
|
|
|
[Tooltip("OPTIONAL override for the vote card icon. Leave empty to inherit the icon of " +
|
|
"whatever this option grants.")]
|
|
public Sprite Icon;
|
|
|
|
/// <summary>
|
|
/// Icon actually shown on the vote card. Subclasses override to fall back to the icon of
|
|
/// the thing they grant; the base has nothing to inherit from, so it returns
|
|
/// <see cref="Icon"/> (which may be null).
|
|
/// </summary>
|
|
public virtual Sprite ResolveIcon() => Icon;
|
|
|
|
/// <summary>
|
|
/// Server-only: may this option be OFFERED for <paramref name="slot"/> right now? Default
|
|
/// true; override for cards with prerequisites or ones that would be a no-op.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// Callers already skip options the slot has taken before, so implementations don't need
|
|
/// to re-check that.
|
|
/// </remarks>
|
|
public virtual bool IsValidForSlot(RunState run, int slot) => true;
|
|
|
|
/// <summary>
|
|
/// Server-only: side effect to run after this option has been recorded onto
|
|
/// <paramref name="slot"/>. Default no-op — most cards do their work at enemy-spawn time
|
|
/// by virtue of being on the slot, not at vote-resolution time.
|
|
/// </summary>
|
|
public virtual void ServerOnApplied(RunState run, int slot) { }
|
|
}
|
|
}
|