yeahweregames/UnityTowerDefense
3
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Painted units correspond to damage types

Browse source
This commit is contained in:
Ben Calegari 2026-06-09 21:50:03 -07:00
parent 04ead32846
commit 2be2e52fe4
3 changed files with 242 additions and 75 deletions
Download patch file Download diff file Expand all files Collapse all files

22
Project_Roadmap.md
View file

@ -155,10 +155,30 @@ Flagged for revisit; not blocking anything.
- Center-on-builder hotkey (e.g., Space)
- Initial camera position taking race or match phase into account
### 1.10 Tower Customization & Meta-Progression (DEFERRED — DESIGN CAPTURED)
### 1.10 Tower Customization & Meta-Progression (DEFERRED — DESIGN CAPTURED; IN-MATCH PAINT v1 + EFFECTS IMPLEMENTED)
Long-term cross-match progression loop. Recorded here so Phase 1.8 race-system design and Phase 2 visual prototype work can anticipate the customization data model when they're scheduled. Not blocking Phase 1 exit criteria — a single match is fully playable without it.
**Implemented — in-match paint v1 + paint-driven effects (2026-06-03 / 2026-06-09)**
A first-pass, in-match paint mechanic is built, verified in-engine, and now drives both tower visuals **and** projectile behavior.
Paint UI + recolor (2026-06-03):
- **Build / Paint tabs** in the command grid (shown when the builder is selected). Build tab is the existing tower menu.
- **Paint tab:** Red / Green / Blue swatches plus a **Reset** (clear) brush, selectable by click or **Q / W / E / R** hotkeys. The active brush swaps the cursor to a tinted paint circle.
- **Click a tower you own → recolors it**; Reset reverts it to its owner color.
- **Server-authoritative & networked:** `PaintColor` enum + `paintColor` `NetworkVariable` on `TowerInstance`, set via `RequestPaintServerRpc` (own-tower-only validation), replicated to all clients. Tint applied through the existing `MaterialPropertyBlock` path (`TowerInstance.ApplyTint`, which falls back to all child `MeshRenderer`s when none are explicitly listed).
- **New code:** `TowerPaintController` (client-local, mirrors `TowerPlacementController`), `PaintColors` palette in Core, Paint tab + swatches in `HUDController`.
Paint-driven combat effects (2026-06-09):
- `TowerCombat` resolves an effective **`CombatProfile`** per shot from the tower's `TowerDefinition` overridden by its `Paint` color, threaded through both the projectile and hitscan paths (unpainted towers fire as authored).
- **Red = Splash** (radius 2 tiles), **Green = Poison DoT** (½ base damage/sec for 3s), **Blue = Cold slow** (50% speed for 2s). Reuses the existing `EnemyStatus.ApplyEffect` / splash systems. Magnitudes are named constants in `TowerCombat` (promote to a ScriptableObject if designer tuning without recompile is needed).
- **Projectiles tint to the paint color**, replicated via a `PaintColor` `NetworkVariable` on `Projectile` (same pre-spawn → `OnNetworkSpawn` pattern as `TowerInstance`).
Still pending for the full meta-progression:
- Persistence / player profile, end-of-match reward rolls, decals, stat-modifier stack, layering / set bonuses, and the customization menu — all remain deferred as described below.
- The current paint→effect mapping is **override** (paint replaces authored effects) and a fixed 3-color set; the eventual customization system will generalize this to a layered modifier stack drawn from a reward pool.
**Core concept**
- Every player starts each match with the same **base tower set** — a small fixed roster (universal or per-race; see open question below).