--- id: wiki-2026-0508-상성-및-데미지-유형-unit-counters-damage title: "상성 및 데미지 유형(Unit Counters & Damage Profiles)" category: 10_Wiki/Topics status: verified canonical_id: self aliases: [Unit Counters, Damage Profiles, RTS 상성, Rock-Paper-Scissors Combat] duplicate_of: none source_trust_level: A confidence_score: 0.9 verification_status: applied tags: [game-design, rts, combat-system, balance] raw_sources: [] last_reinforced: 2026-05-10 github_commit: pending tech_stack: language: csharp framework: Unity-DOTS --- # 상성 및 데미지 유형 (Unit Counters & Damage Profiles) ## 매 한 줄 > **"매 unit 의 매 다른 unit 에 대한 effective vs ineffective relationship"**. RTS 의 매 핵심 strategic depth — Dune II (1992) 의 light/heavy/infantry triad 에서 시작, StarCraft II 의 armor type × damage type matrix 로 evolution, 매 modern title (Stormgate 2026, AoE IV) 에서 매 attack-bonus 시스템으로 standardize. ## 매 핵심 ### 매 두 축 — Damage Type × Armor Type - **Damage Type**: Normal, Concussive (anti-light), Explosive (anti-heavy), Piercing, Magic - **Armor Type**: Light, Medium, Heavy, Biological, Mechanical, Massive, Structure - **Multiplier matrix**: 0.5x (resist) ~ 1.5x (effective). 매 2.0x 의 X — 매 too swingy. - **Bonus damage** vs **base damage**: SC2 는 base + bonus_vs_ 분리. Balance lever. ### 매 Counter Triangle 패턴 - **Light counters Heavy counters Air counters Light** — cyclical, no dominant. - 매 transitive counter (A>B>C>A) 는 매 strategic decision 강제. Asymmetric counter 는 매 rush meta 유발. - **Soft counter** (1.3x): unit 합성 권장. **Hard counter** (2.0x+): pure composition 강요 — 매 일반적으로 avoid. ### 매 응용 1. **Composition decision** — scout 으로 enemy comp 보고 counter unit 생산. 2. **Map control** — terrain × range 의 unit type 배치 (high ground siege, choke point splash). 3. **Tech tree pacing** — counter unit 의 tier gate (T2 anti-air, T3 anti-massive). ## 💻 패턴 ### Damage type enum + armor matrix (Unity DOTS) ```csharp public enum DamageType : byte { Normal, Light, Heavy, Pierce, Magic, Siege } public enum ArmorType : byte { Light, Medium, Heavy, Bio, Mech, Massive, Structure } public struct DamageProfile : IComponentData { public DamageType type; public float baseDamage; public FixedList64Bytes bonuses; } public struct DamageBonus { public ArmorType vs; public float bonus; } public struct ArmorProfile : IComponentData { public ArmorType type; public float armorValue; } public static float ResolveDamage(in DamageProfile dp, in ArmorProfile ap) { float bonus = 0f; for (int i = 0; i < dp.bonuses.Length; i++) if (dp.bonuses[i].vs == ap.type) { bonus = dp.bonuses[i].bonus; break; } return math.max(0.5f, (dp.baseDamage + bonus) - ap.armorValue); } ``` ### Counter chart (data-driven JSON) ```json { "marauder": { "damage": 10, "type": "Heavy", "vs_armored": 10, "armor": "Bio" }, "marine": { "damage": 6, "type": "Normal", "armor": "Bio" }, "stalker": { "damage": 13, "type": "Pierce", "vs_armored": 5, "armor": "Mech" }, "zealot": { "damage": 16, "type": "Normal", "armor": "Light" } } ``` ### ECS damage system (burst-compiled) ```csharp [BurstCompile] public partial struct DamageResolveSystem : ISystem { public void OnUpdate(ref SystemState state) { var armorLookup = SystemAPI.GetComponentLookup(true); new DamageJob { armorLookup = armorLookup } .ScheduleParallel(); } } [BurstCompile] partial struct DamageJob : IJobEntity { [ReadOnly] public ComponentLookup armorLookup; void Execute(in DamageProfile dp, in TargetEntity target, ref Health hp) { if (!armorLookup.TryGetComponent(target.value, out var ap)) return; hp.current -= ResolveDamage(dp, ap); } } ``` ### Splash 응용 — counter via AoE shape ```csharp public struct SplashShape { public float innerRadius; // 100% damage public float outerRadius; // 25% damage public bool linear; // siege tank line vs colossus disc } ``` ### Balance simulation harness ```python import numpy as np # armies: list of (count, dps_vs_type_dict, hp, armor_type) def simulate(army_a, army_b, dt=0.1): while alive(army_a) and alive(army_b): damage_a_to_b = sum(c * dps[b_armor] for c, dps, _, _ in army_a for b_armor in types_in(army_b)) # ... apply to softest target first (focus fire heuristic) tick(army_b, damage_a_to_b * dt) tick(army_a, damage_b_to_a * dt) return winner_margin(army_a, army_b) ``` ## 매 결정 기준 | 상황 | Approach | |---|---| | Symmetric RTS (SC2-like) | Soft counter matrix, 1.3-1.5x multiplier | | Asymmetric (faction-unique units) | Per-faction counter chart, identity > balance | | MOBA-style hero | Stat-based counters (mobility, range, burst) — no explicit type | | Auto-battler (TFT) | Trait synergy + damage type secondary | | Tower defense | Armor-color hard counter (red = magic only) acceptable | **기본값**: SC2-style — Light/Armored/Massive armor tag + soft 1.3-1.5x bonus damage. 매 readable + balanceable. ## 🔗 Graph - 변형: [[유닛 상성(Unit Counters)]] - 응용: [[Splash_Damage]] ## 🤖 LLM 활용 **언제**: damage matrix 의 first draft, balance hypothesis ("if zergling +1 damage, what changes"), counter chart 의 markdown 화. **언제 X**: 매 actual playtested numbers — LLM 의 pure speculation. Sim harness + telemetry 가 ground truth. ## ❌ 안티패턴 - **Hard counter only (2x+)**: composition 강요 → boring "scout-and-react" gameplay. - **Hidden multipliers**: damage tooltip 에 안 보이면 매 player 의 frustration. - **Symmetric mirror (모든 unit 의 동일 multiplier)**: counter 의 의미 X. - **Too many damage types (8+)**: cognitive overload. 4-5 가 sweet spot. ## 🧪 검증 / 중복 - Verified (Blizzard SC2 design archives, Stormgate 2026 design blog, Sirlin "Playing to Win"). - 중복 candidate: [[유닛 상성(Unit Counters)]] — 매 같은 folder 에 duplicate. 매 future merge 의 candidate. - 신뢰도 A. ## 🕓 Changelog | 날짜 | 변경 | |---|---| | 2026-05-08 | Phase 1 | | 2026-05-10 | Manual cleanup — RTS counter system + Unity DOTS damage resolution patterns |