From 0d2abe1b471743ef3bb1c786f2075edaba8b345e Mon Sep 17 00:00:00 2001 From: swrring Date: Sat, 22 Aug 2026 05:02:13 +0900 Subject: [PATCH] =?UTF-8?q?docs(BT13-GodDem):=20B1=20=EB=A0=88=EB=B2=A8?= =?UTF-8?q?=EC=8A=B9=EA=B8=89=20=EC=84=A4=EA=B3=84=EC=99=84=EB=A3=8C=C2=B7?= =?UTF-8?q?=EC=A0=84=ED=99=98=EB=B8=8C=EB=A6=BF=EC=A7=80=20=EB=B0=9C?= =?UTF-8?q?=EA=B2=AC=C2=B7=EB=A9=94=ED=83=80=EB=AC=B8=EC=84=9C=20ele?= =?UTF-8?q?=EA=B0=B1=EC=8B=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - B1 plan-auditor 조건부통과(레벨1~60·승급11·매판베이스 결합·defense 분리클램프) - ★발견: 인게임 골드→아웃게임 전환 브릿지 부재(영구성장 전제 미구현) - C36 경계: 유한캡(원작정합) vs 메타아키텍처 상한없음 — PD 확인 - system-designer 메타문서 ele④→⑤ 갱신 Co-Authored-By: Claude Fable 5 --- .../GodDem/2026-08-22_P3B1_레벨승급_설계_v1.md | 408 ++++++++++++++++++ .../GodDem/2026-08-22_메타아키텍처_재설계_v1.md | 29 +- 공유/대화로그/GodDem/2026-08-22.md | 20 + 3 files changed, 443 insertions(+), 14 deletions(-) create mode 100644 공유/기획/GodDem/2026-08-22_P3B1_레벨승급_설계_v1.md diff --git a/공유/기획/GodDem/2026-08-22_P3B1_레벨승급_설계_v1.md b/공유/기획/GodDem/2026-08-22_P3B1_레벨승급_설계_v1.md new file mode 100644 index 0000000..e3f037f --- /dev/null +++ b/공유/기획/GodDem/2026-08-22_P3B1_레벨승급_설계_v1.md @@ -0,0 +1,408 @@ +# GodDem 영웅레벨+승급(아웃게임 Layer①②) 수치 설계 v1 + +> **작성**: balance-designer(기획팀) 2026-08-22 · **P3-B1 산출물** (P32 맥락 분할 · C50 규모 "중") +> **PD 승인 원문 (C42-2 A, 2026-08-22)**: "설계대로 진행" — `2026-08-22_메타아키텍처_재설계_v1.md`(이하 메타v1) 골격에 대한 승인 +> **선행 문서(전부 Read 완료)**: [`2026-08-22_메타아키텍처_재설계_v1.md`](./2026-08-22_메타아키텍처_재설계_v1.md)(메타v1, §P3-B1·§3-4·Layer①②) · [`2026-08-22_원작아키텍처_이식청사진_v1.md`](./2026-08-22_원작아키텍처_이식청사진_v1.md)(청사진v1) · [`2026-08-20_원작밸런스_해독_매핑_v1.md`](./2026-08-20_원작밸런스_해독_매핑_v1.md)(매핑v1, §2-2 hero_star) · [`2026-08-22_원작배율_재추출_원본_v1.md`](./2026-08-22_원작배율_재추출_원본_v1.md)(재추출v1) · [`2026-08-22_공격력_원작2층_재설계_v2.md`](./2026-08-22_공격력_원작2층_재설계_v2.md)(2층 구조·4:1 유도 선례) +> **절대 제약**: GodDem 레포(`E:\NerdNavis\GodDem`) Read만 수행, 수정 0건. Unity MCP 미사용. 본 문서가 유일 산출물. +> **범위**: Layer①(영웅레벨)·Layer②(승급) 실수치 설계만. ele_*/가챠(B3·B4)·스테이지(C) 범위 침범 없음. +> **표기 규칙(C5·C44)**: 🟢확정(코드 직접 실측) · 🟡추정(근거 있으나 미확정, 플레이테스트 필요) · 🔴재추출 필요/미확보 +> **감사 이력(C35)**: plan-auditor 모드A 1회 수행 — 판정 **조건부통과**(Critical 1·Major 4·Minor 3, 산술은 전량 무오류 확인). 본 v1은 그 지적을 전부 반영한 최종본이다(§2-3·§4-2·§6·§11·§12). + +--- + +## 0. 결론 요약 + +메타v1이 골격만 정의하고 유보한 실수치·미정 사항 4건을 본 문서에서 확정한다. + +| 유보 사항(메타v1 출처) | 본 문서 결정 | +|---|---| +| §1-1 "소비 재화 TBD, 중간재 도입 필요성은 balance-designer 열린 이슈" | **기존 골드(GOLD_ID=201) 직접 소비 채택 + 런종료 전환 브릿지 신규 설계**(중간재 도입 안 함, §2-3) | +| §3-4 "defense 클램프 공유 리스크… 최종 수식·클램프 정책은 P3-B1에서 balance-designer 확정" | **클램프 후 별도 승산항 분리식 확정**(R-B2 해소, §7) | +| §1-2 "레벨캡·비용·보너스 공식 형태만 재사용, 절대 계수는 TBD(P3-B1)" | **영웅레벨 60캡·승급 star11캡, 전 수식·수치 확정**(§4·§5) | +| §1-2 "hero_star 성29·30 레벨캡 불일치, 재실측이 P3-B1 직접 선행 조건" | **우리 설계는 이 불일치 구간을 회피하도록 캡을 선택**(star11=cap60, 클램프 미도달) — 단, 재추출 자체는 미해소이므로 개발팀장 표시 유지(§5-5) | + +**⚠️ 원칙 반전 고지(plan-auditor M-4 지적, C36 경계)**: 메타v1 §1-1은 Layer①을 **"상한: 없음(원작 '수확체감 없음' 원칙 승계)"**으로 명시했다. 본 문서는 HeroLevel 60·PromotionStar 11이라는 **유한 캡**을 도입한다 — 이는 메타v1이 명시한 방향과 정면으로 다르므로 축소 은폐하지 않고 여기서 표면화한다. 근거: "상한 없음" 공식은 CSV 테이블 기반으로 실제 구현 불가능하다(무한 행을 미리 채울 수 없음 — 원작조차 실제로는 150에서 멈춘 유한 시스템이었다, 매핑v1 §2-1). 60/11은 **"현재 콘텐츠 패치의 캡"**이며, 향후 PD·system-designer 판단에 따라 동일 공식 형태로 CSV 행만 추가해 확장 가능한 구조로 설계했다(§3-2·§4-2 공식은 L·star에 대해 닫힌 형태라 상한 값 자체는 자유롭게 늘릴 수 있음). 그러나 이것이 "무한 유한화"라는 방향성 조정 자체는 PM·system-designer 인지가 필요한 사안(C36 (b) 해당 가능성)이므로 팀장 확인 후 진행을 권고한다. + +**실측 중 신규 발견(C39·C3, 은폐하지 않음)**: 런 종료 시 인게임 골드(`SurvivalBattleManager.Gold`)를 영구 재화(`CurrencyManager`/`GOLD_ID`)로 전환하는 코드가 **현재 존재하지 않는다**(`OnVictoryContinue()`·`OnDefeatContinue()` 직접 확인, `CurrencyManager.Add` 호출 0건). 또한 "Victory" 팝업은 런 종료가 아니라 **스테이지 클리어마다** 뜨는 것으로 확인됐다(`_pendingVictory = M.Stage > _shownStage`, Stage 무한 증가) — 사망(`OnDefeatContinue()`)과 일시정지 메뉴의 수동 재시작(`OnPauseRestart()`) **2곳 모두 `SurvivalBattleManager.Restart()`를 호출**하는 실제 런 종료 지점이다(plan-auditor C-1 지적으로 재확인, §2-2·§2-3). 이 신규 사실이 Layer① 재화 설계의 전제이므로 §2에서 상세를 다룬다. + +--- + +## 1. 설계 전제 + +| 항목 | 값 | +|---|---| +| 기준 플레이어 수준 | 신규(0/0/미투자) ~ 장기(HeroLevel60·PromotionStar11·풀장착) 4단 밴드 | +| 목표 경험 | "판을 거듭할수록 이번 판 시작점이 조금씩 높아진다"(메타v1 §1-1 P30 근거) — 로그라이크 매판 완결성은 유지, 계정 장기투자자가 신규 유저보다 항상 유리한 출발선 | +| 전제 스탯 앵커 | `SurvivalMeta.BaseAttack=22`/`BaseHp=400`(HeroLevel=0 앵커, 불변) · 장비 상한 `+47atk/+305hp`(S3 v2 §1-2 풀장착) | +| 전제 경제 앵커 | 인게임(매판) 20웨이브 총 골드 2,542G(S3 v2 §2-3 확정 앵커) — 아웃게임 영구 경제의 **보수적 하한 앵커**로 재사용(§2-4) | +| 재화 | 기존 `GOLD_ID=201`(persistent, `CurrencyManager` SOT) 직접 소비. 신규 중간재 도입 안 함 | +| C39 실측 확증 | `SurvivalMeta.cs`·`SurvivalBattleManager.cs`·`SurvivalUpgrade.cs`·`SurvivalItemCatalog.cs`·`SurvivalLobbyController.Hero.cs`·`SurvivalUIController.cs`(BuildResults/OnVictoryContinue/OnDefeatContinue)·`SurvivalStatCatalog.cs`·`SurvivalMetaSkillMastery.csv`·`Constant.cs`(GOLD_ID=201/GEM_ID=101) 직접 Read 완료 | + +--- + +## 2. 실측 확인 — 재화 흐름 (C39·C3) + +### 2-1. 현재 구조 (🟢 확정) + +``` +[인게임, 매판] SurvivalBattleManager.Gold (int, 런 시작 0) + ↑ OnEnemyDied() 가산 ↓ TryUpgrade() 차감(12트랙 강화) + → 런 종료(Defeat) 시 그대로 소멸. 영구 재화로 전환 코드 없음. + +[영구, 계정] CurrencyManager.Instance / Constant.GOLD_ID(=201) + ← 상점 IAP 골드팩(500/2000/600·12000·48000, SurvivalShopCatalog.cs) 만 확인됨 + ← Survival 플레이로부터의 유입 경로 0건(🟢 실측) +``` + +### 2-2. Victory ≠ 런 종료 (신규 발견) + +`SurvivalUIController.cs:546` `if (M.Stage > _shownStage) { _pendingVictory = true; ... }` — Stage는 상한이 없으므로(청사진 §3 "Stage 무한 증가") **Victory 팝업은 스테이지 클리어마다 반복 표시되는 중간 보상 연출**이다. `OnVictoryContinue()`는 `Time.timeScale=1f`만 하고 런을 이어간다. `OnDefeatContinue()`(플레이어 사망)는 `M.Restart()`를 호출해 씬을 리로드하는 확실한 런 종료 지점이다 — **단, 유일한 지점은 아니다**. `OnPauseRestart()`(일시정지 메뉴의 수동 재시작)도 동일하게 `M.Restart()`를 호출한다(plan-auditor C-1 지적, 본 balance-designer가 코드로 재확인 완료 — §2-3). 즉 런 종료 경로는 2개이며, 전환 브릿지는 이 **공통 호출 대상인 `Restart()` 자체**에 심어야 두 경로 모두 놓치지 않는다(§2-3). + +### 2-3. 설계 결정 — 전환 브릿지 신규 도입 (개발팀 구현 필요) + +메타v1이 "디폴트 권고"로 남긴 두 옵션(기존 골드 직접소비 vs 신규 중간재) 중 **기존 골드 직접소비를 채택**하되, 현재 브릿지가 없다는 실측 결과에 따라 다음을 **P3-B1 구현의 필수 동반 항목**으로 명시한다. + +**정정(plan-auditor C-1)**: §2-2가 확인했듯 런 종료 경로는 `OnDefeatContinue()`·`OnPauseRestart()` 2개이며 둘 다 `M.Restart()`를 호출한다(`SurvivalUIController.cs:517-523`, 본 balance-designer 재확인 완료 🟢). `OnDefeatContinue()`에만 전환 훅을 심으면 사망 전 일시정지→재시작 경로에서 `TotalGoldEarned`가 소실된다 — §2-3이 없애려던 역유인(스펜드/축적 딜레마)과 **반대 방향의 새 손실 버그**가 되므로, 전환 훅은 `SurvivalUIController` 콜백이 아니라 **`SurvivalBattleManager.Restart()` 자체**(두 호출부의 공통 choke point)에 배치한다. + +```csharp +// SurvivalBattleManager.cs — 신규 필드(Gold와 별개, 감소 없음) +public int TotalGoldEarned { get; private set; } + +void OnEnemyDied(SurvivalUnit e) +{ + int reward = Mathf.RoundToInt(e.GoldReward * GoldMultiplier); + Gold += reward; + TotalGoldEarned += reward; // ← 신규 + AddExp(Mathf.RoundToInt(e.ExpReward * ExpMultiplier)); +} + +// Restart() 자체를 단일 choke point로 사용 — OnDefeatContinue()·OnPauseRestart() 양쪽 경로 모두 흡수 +public void Restart() +{ + int convert = Mathf.RoundToInt(TotalGoldEarned * HeroCurrencyConversionRate); // 제안 1.0 + CurrencyManager.Instance?.Add(ItemType.Goods, Constant.GOLD_ID, convert); // ← 신규 + Time.timeScale = 1f; + UnityEngine.SceneManagement.SceneManager.LoadScene( + UnityEngine.SceneManagement.SceneManager.GetActiveScene().name); +} +``` +씬 리로드로 `SurvivalBattleManager` 인스턴스 자체가 재생성되므로(`Awake()` 재호출) `TotalGoldEarned`는 다음 런에서 자동으로 0부터 시작한다 — 중복 전환 위험 없음. + +**전환율 100% 채택 근거**: `Gold`(런 내 소모 가능)와 별개로 `TotalGoldEarned`(런 내 소모와 무관, 누적만)를 추적해 **"이번 판에서 쓴 골드"와 "영구 재화로 남는 골드"를 완전히 분리**한다. 이러면 "런에서 안 쓰고 아끼는 것이 아웃게임에 유리하다"는 역유인이 생기지 않는다(총 획득량 기준이므로 오히려 잘 플레이할수록 — 더 오래 살아남아 더 많이 죽일수록 — 아웃게임 성장도 빨라져 "실력=보상" 원칙과 정합). 100%는 초기값이며 §11 리스크에 튜닝 구간을 명시한다. + +**미해결 표시(plan-auditor M-2 반영) — 보상 팝업 표기 불일치**: `SurvivalUIController.cs`의 Victory/Defeat 팝업 보상란은 현재 `M.Gold`(런 내 잔여, 소비 후 남은 값)를 표시한다(`_victoryReward.text = $"{M.Gold:N0}"` 등, 코드 확인). 전환 재화는 `TotalGoldEarned`(총 획득량, 잔여보다 항상 크거나 같음)를 쓰므로 **팝업에 보이는 숫자와 실제로 영구 전환되는 숫자가 다르다**. 이 문서 범위에서 UI 문구까지 확정하지 않으며, §14 후속 조치에 UI 동반 수정 필요 항목으로 명시한다(ux-designer·클라이언트팀 협의 대상). + +**세그먼트 영향**: 현재 상점 IAP 골드팩과 이 브릿지는 **같은 `GOLD_ID` 풀을 공유**한다. 즉 고과금 유저는 골드팩 구매로 Layer①②를 더 빨리 채울 수 있다 — 이는 결함이 아니라 "무과금은 플레이로, 과금은 시간 단축으로" 표준 F2P 구조이며, 메타v1 §1-1의 디폴트 권고(기존 골드 재사용)가 의도한 결과와 일치한다. + +--- + +## 3. Layer① 영웅레벨(HeroLevel) 설계 + +### 3-1. 설계 전제 + +원작 `hero_level.csv`(1800행=12진영×150레벨)의 **핵심 비대칭**(예산은 선형, 비용은 3차 — 매핑v1 §2-1)을 형태만 이식한다. 원작 절대치(스탯 1e0~1e3, 비용은 "경험서" 단위)는 규모·통화 단위 모두 불일치하므로 폐기(청사진 §0 승계, 재추출v1 §0이 "hero_level엔 hp 컬럼 자체가 없다"는 사실로 재확인 — 개별 스탯 분해식은 원본 데이터가 애초에 지원하지 않는다). + +- **레벨 범위**: 1~60 (0=초기 상태, `SurvivalMetaData.HeroLevel` 기존 필드 그대로) +- **60을 택한 근거**: §4 승급 star11 게이팅(5×12=60)과 나눗셈 없이 정확히 맞물리도록 역산 — 원작의 "성29=148/성30=150 클램프 불일치"(§5-5) 같은 반올림 경계 버그를 원천 회피하는 설계 +- **기여 스탯**: 공격력·체력 2종(4:1 비율, `공격력_원작2층_재설계_v2.md` §5가 이미 확립한 유도 방식과 동일 원칙 재사용) + +### 3-2. 공식 + +``` +AttackBudget(L) = 2 × L (flat, 선형) +HpBudget(L) = 8 × L = 4 × AttackBudget(L) (flat, 선형, A80ChampMatchConfig 4:1 준수) + +Cost(L) [L-1 → L 승급 비용, GOLD_ID] + = 0.2×L³ + 1.8×L² + = 0.4 × (0.5×L³ + 4.5×L²) ← 원작 hero_level cost(L) 형태 × 0.4 축소 +``` + +**0.4 축소 계수 도출**: `Cost(60)`을 목표값 약 50,000G에 맞추기 위해 역산했다. 원작 `cost(60)=0.5×60³+4.5×60²=124,200`(원작 "경험서" 단위, 무의미) → `50,000/124,200≈0.4027` → 깔끔한 계수 **0.4**로 반올림해 `Cost(60)=49,680G`을 얻었다(§3-3 표 확인). 이 축소 계수 0.4가 **본 설계의 1차 튜닝 손잡이**다 — 플레이테스트 결과 레벨업이 너무 빠르거나 느리면 이 상수 하나만 조정하면 전체 곡선 형태(3차 가속)는 그대로 유지된다. + +### 3-3. 수치 테이블 (체크포인트 — 전체 60행은 공식 적용 결과, 대표 구간만 표기 C14) + +| Level | AttackBudget | HpBudget | 단계 비용(Cost) | 누적 비용 | +|---|---|---|---|---| +| 1 | 2 | 8 | 2 | 2 | +| 5 | 10 | 40 | 70 | 144 | +| 10 | 20 | 80 | 380 | 1,298 | +| 15 | 30 | 120 | 1,080 | 5,112 | +| 20 | 40 | 160 | 2,320 | 13,986 | +| 25 | 50 | 200 | 4,250 | 31,070 | +| 30 | 60 | 240 | 7,020 | 60,264 | +| 35 | 70 | 280 | 10,780 | 106,218 | +| 40 | 80 | 320 | 15,680 | 174,332 | +| 45 | 90 | 360 | 21,870 | 270,756 | +| 50 | 100 | 400 | 29,500 | 402,390 | +| 55 | 110 | 440 | 38,720 | 576,884 | +| **60(캡)** | **120** | **480** | 49,680 | **802,638** | + +### 3-4. 성장 곡선 — 예산은 직선, 효율은 급락 + +- **AttackBudget/HpBudget**: 완전 선형(레벨당 균일 +2/+8) — 원작 "예산은 선형" 원칙 그대로. +- **비용**: 3차 가속. 골드/공격력포인트 단가(`Cost(L)/2`)가 **L1의 1G/point → L60의 24,840G/point로 24,840배 상승**(원작 매핑v1 §2-1의 "181배"보다 가파른 것은 우리가 150레벨을 60레벨로 압축했기 때문 — 같은 상대적 감속을 더 짧은 구간에 눌러 담은 결과, 의도된 설계). +- **후반 집중**: 마지막 10레벨(51~60)의 비용(802,638−402,390=400,248G)이 **전체 누적 비용의 49.9%**를 차지 — 원작의 "후반 급가속" 철학이 정확히 재현됨. +- **런 환산(§2-4 참고 앵커, 🟡추정)**: 아래 §6 참고. + +--- + +## 4. Layer② 승급(Promotion) 설계 + +### 4-1. 설계 전제 + +원작 `hero_star.csv`(186행=6등급×31성)의 진짜 기능은 **% 보너스가 아니라 레벨 캡 게이팅**(매핑v1 §2-2 "핵심: 성급의 진짜 기능은... 레벨 캡 게이팅이다"). GodDem은 히어로가 1명뿐이라 원작의 "quality"(진영별 희귀도 1~6) 축이 성립하지 않는다 — 이를 **비용식과 보너스식에서 서로 다르게 처리**한다(사유는 각 항목에 명시, 결정 근거 투명성 C5). + +- **star 범위**: 0(초기)~11(캡) — 12단계(원작 31단계 대비 축소) +- **11을 택한 근거**: `5×(star+1)`이 정확히 60(=HeroLevel 캡)에 도달하는 지점이 star=11(`5×12=60`) — 나머지·클램프 없이 딱 맞물림 + +### 4-2. 공식 + +**비용 — quality=1 고정, 재계수화 없음**: +``` +Cost(star → star+1) = (star+1)³ × (star+50) [quality=1 대입, 원작 공식 그대로] +``` +*채택 사유(plan-auditor M-3 반영 — 근거 재작성)*: 원작 quality 1~6은 히어로 희귀도를 나타내는 축이며, **원작 공식 내부**에서는 비용 대비 보너스 효율이 quality에 무관하게 동일하다(`Cost/Bonus` 비를 대수적으로 정리하면 quality가 약분되어 사라짐 — quality는 원작 내부의 순수 스케일 파라미터). 그러나 이 약분 성질은 quality=1과 quality=6 어느 쪽이든 "원작 안에서는 동등히 정당하다"는 뜻일 뿐 **quality=1을 특정해서 지목하는 근거는 아니며**, quality=1은 "보수적"이 아니라 원작 절대비용이 **가장 저렴한(가장 관대한) 값**이다(quality=6 대비 1/6). 실제 채택 이유는 단순함이다 — 별도 배율 계수를 곱하지 않고 원작 공식의 리터럴 최저 케이스를 그대로 쓸 수 있는 유일한 지점이기 때문이다. **다만 이 선택은 보너스식(아래) 결정과 독립적이다** — 보너스에는 quality=1을 대입하지 않고 §7 목표에서 역산한 별도 계수를 쓰므로, 원작의 "Cost/Bonus 비 불변" 성질은 우리 최종 설계에서 더 이상 성립하지 않는다(계산 결과 우리 Cost/Bonus 비는 원작 대비 약 1/10 — 원작보다 10배 관대, 아래 단락에서 상술). 이는 "원작 그대로"가 아니라 "형태는 원작에서, 절대 관대함은 우리 목표로 재설계"했음을 투명하게 밝히는 것이며(C5), 비용식(원작 리터럴 근거)과 보너스식(§7 클램프 검증을 만족해야 하는 우리 목표치)이 서로 다른 설계 압력을 받으므로 굳이 하나의 quality 값에 묶어둘 이유가 없다는 판단이다. + +**보너스 — 원작 축소형(quality×0.002) 대신 목표 역산 채택**: +``` +AttackBonusRatio(star) = HpBonusRatio(star) = PromoDefenseAddRatio(star) = 0.02 × star (3스탯 동일값, 원작 원칙 유지) +``` +*채택 사유*: 원작 그대로 quality=1을 보너스 공식(`0.002×quality×star`)에도 대입하면 star=11 최댓값이 `0.002×1×11=0.022`(2.2%)로 무의미한 수준이다 — 원작에서 이 계수가 유의미했던 건 실제 플레이 quality가 최대 6까지 올라가기 때문(원작 최댓값 `0.002×6×30=0.36`, 36%)이며, 우리는 quality 축 자체가 없으므로 이 결합을 그대로 가져오면 "형태 재사용"이 아니라 "의미 없는 숫자 재사용"이 된다. 대신 §7의 defense 클램프 결합 검증(0.8→0.844, 완만한 상승)을 만족하는 **목표값 22%(star11)를 먼저 정하고 역산**해 star당 +2%(선형)를 얻었다. 이는 C5 원칙에 따라 "원작 공식이 아니라 우리 목표에서 역산했다"는 점을 투명하게 밝힌다. **정량 고지**: `0.02÷(0.002×1)=10` — 우리 보너스 계수는 quality=1 대입 원작값의 정확히 10배다. 비용은 quality=1(원작 그대로) 유지·보너스만 10배 인상했으므로, 우리 게임의 Cost/Bonus 비는 원작(quality 무관 고정비)의 약 1/10 — 즉 **원작보다 별 하나당 10배 더 관대한 보너스**를 설계한 것이며, 이는 우연이 아니라 §7 클램프 검증 목표(22%)를 만족시키기 위한 의도적 선택이다. + +**레벨캡 게이팅**: +``` +MaxHeroLevel(star) = 5 × (star + 1) [원작 형태 그대로, 재계수화 없음] +CanLevelUp() := SurvivalMeta.Data.HeroLevel < MaxHeroLevel(PromotionStar) +``` + +### 4-3. 수치 테이블 (전체 12행 — 원작 186행 대비 압축이므로 전량 표기) + +| Star | 비용(→Star) | 누적 비용 | AttackBonusRatio | HpBonusRatio | PromoDefenseAddRatio | LevelCap | +|---|---|---|---|---|---|---| +| 0(초기) | — | 0 | 0% | 0% | 0% | 5 | +| 1 | 50 | 50 | 2% | 2% | 2% | 10 | +| 2 | 408 | 458 | 4% | 4% | 4% | 15 | +| 3 | 1,404 | 1,862 | 6% | 6% | 6% | 20 | +| 4 | 3,392 | 5,254 | 8% | 8% | 8% | 25 | +| 5 | 6,750 | 12,004 | 10% | 10% | 10% | 30 | +| 6 | 11,880 | 23,884 | 12% | 12% | 12% | 35 | +| 7 | 19,208 | 43,092 | 14% | 14% | 14% | 40 | +| 8 | 29,184 | 72,276 | 16% | 16% | 16% | 45 | +| 9 | 42,282 | 114,558 | 18% | 18% | 18% | 50 | +| 10 | 59,000 | 173,558 | 20% | 20% | 20% | 55 | +| **11(캡)** | 79,860 | **253,418** | **22%** | **22%** | **22%** | **60** | + +### 4-4. 레벨캡 게이팅 검증 — "승급이 레벨의 문지기" + +Star0(초기)만으로도 HeroLevel 1~5는 즉시 구매 가능(누적 비용 144G, §3-3 — 1런 미만). Level6부터는 Star1 승급(50G, 사실상 무료 수준)이 선행되어야 한다. 승급 비용은 항상 같은 구간의 레벨업 비용보다 훨씬 저렴하다 — 예: Star4→5 승급(6,750G) vs Level26~30 레벨업(29,194G, 약 4.3배) — 이는 "승급은 저렴한 문 열기, 실제 그라인드는 레벨"이라는 원작 설계 의도(매핑v1 §2-2)가 우리 스케일에서도 유지됨을 확인한다. + +### 4-5. 🔴 hero_star 레벨캡 불일치 — 재실측 필요 (개발팀장 APK 재추출 표시) + +매핑v1 §2-2가 남긴 "성29=148(공식상 150이어야 함)/성30=150, 6등급×2행=12행 불일치" 이슈는 **본 설계에서는 직접 부딪히지 않는다** — 우리는 star11(=cap60)에서 멈추도록 설계했고, `5×(11+1)=60`은 정확히 딱 떨어져 클램프 자체가 발생하지 않는다(§3-1 근거). 그러나 이 불일치의 **원인 자체**(공식 오류인지 원작의 의도적 상한 클램프 부작용인지)는 여전히 미해소이며, **향후 캡을 확장할 경우**(예: PD가 star12 이상, level65 이상으로 콘텐츠를 늘리기로 결정하는 시점) 동일 클래스의 반올림 경계 버그가 재발할 수 있다. + +**재추출 시 필요 데이터(직접 재추출 불가, 개발팀장 표시)**: `hero_star.csv`의 **star=28, 29, 30 행 전체(6등급×3star=18행)**의 `max_level` 컬럼 원본값. 확인 목적: `max_level` 컬럼이 `5×(star+1)` 공식에서 이탈하는 지점이 (a) 150 클램프 로직(설계 의도) 때문인지 (b) 데이터 입력 오류인지 판별. 현재 설계에는 즉시 필요하지 않으므로 **P3-B1 착수 차단 조건은 아니며**, 향후 캡 확장 검토 시점의 선행 조건으로 유보한다. + +--- + +## 5. 매판 시작 베이스 결합 — FinalAttack()/FinalHp() 확정 + +메타v1 §3-4가 제시한 캡슐화 방향을 그대로 채택하고, Layer①②의 실제 항을 채워 확정한다. + +```csharp +// SurvivalMeta.cs — 신규 메서드(호출부는 전부 이것만 부른다, 3중 SOT 방지) +public static float FinalAttack() => + (BaseAttack + TotalAttack() + HeroLevelAttackBudget()) * (1f + PromotionAttackRatio()); + +public static float FinalHp() => + (BaseHp + TotalHp() + HeroLevelHpBudget()) * (1f + PromotionHpRatio()); + +static float HeroLevelAttackBudget() => 2f * Data.HeroLevel; // §3-2 +static float HeroLevelHpBudget() => 8f * Data.HeroLevel; // §3-2 +static float PromotionAttackRatio() => 0.02f * Data.PromotionStar; // §4-2 (3스탯 동일 계수) +static float PromotionHpRatio() => 0.02f * Data.PromotionStar; +public static float PromotionDefenseRatio() => 0.02f * Data.PromotionStar; // §7 defense 결합식이 참조(public — RecalcPlayer 외부 호출) + +// 호출부 정정 (메타v1 §3-4 4곳 그대로 적용) +// ApplyMetaEquipment(): PlayerAttack = SurvivalMeta.FinalAttack(); PlayerHp = SurvivalMeta.FinalHp(); +// SurvivalLobbyController.Hero.cs RefreshHeroStats()/UpdatePropertyText(): 동일 호출로 교체 +``` + +`TotalAttack()`/`TotalHp()`는 기존 장비 합산 로직을 그대로 유지하고 그 안에 `HeroLevelAttackBudget()`/`HeroLevelHpBudget()` 항만 추가하는 형태(메타v1 §3-4 스켈레톤과 동일 구조, ③장비강화 항은 P3-B2 범위이므로 본 문서는 자리만 예약). + +### 5-1. 결합 시나리오 검증 (신규~맥스 4단 밴드) + +| 밴드 | HeroLevel | PromotionStar | 장비 | FinalAttack | FinalHp | +|---|---|---|---|---|---| +| 신규(하위호환 확인) | 0 | 0 | 0/0 | **22**(불변) | **400**(불변) | +| 초반 진행 | 10 | 2 | 0/0 | (22+0+20)×1.04=43.7 | (400+0+80)×1.04=499.2 | +| 중견 | 30 | 5 | 47/305(풀장착) | (22+47+60)×1.10=141.9 | (400+305+240)×1.10=1,039.5 | +| **맥스** | 60 | 11 | 47/305(풀장착) | (22+47+120)×1.22=**230.6** | (400+305+480)×1.22=**1,445.7** | + +신규 유저 기준선(22/400)이 기존과 완전히 동일함을 확인 — **비파괴 확인 통과**. + +**주의(TTK 연쇄 영향, §11 리스크 연계)**: 맥스 밴드의 FinalAttack 230.6은 현재 "장비만" 상한(69, S3 v2)의 **3.3배**다. 몬스터 스탯(EnemyBaseHp 등)은 아웃게임 진척도와 무관하게 고정이므로, 장기 유저는 초반 웨이브를 지금보다 훨씬 더 압도적으로 통과하게 된다 — 이는 S3 v2가 이미 식별한 R-J("장비 상한 유저 웨이브1~2 무위협")를 **심화**시키는 방향이다. 본 문서 범위(스테이지 설계는 P3-C)에서 대응하지 않되, 은폐하지 않고 §11에 명시한다. + +--- + +## 6. 런 환산 참고표 (🟡 추정 — 플레이테스트 전 안전판) + +Layer①② 총 누적 비용(802,638+253,418=1,056,056G)을 "런 몇 회분"으로 환산하려면 "평균 런이 몇 골드를 버는가"가 필요한데, Stage가 무한 증가 구조라 **이 값 자체가 미확정**(스테이지 도달 깊이에 좌우, 플레이테스트 데이터 없음). 확정된 앵커(S3 v2, 20웨이브/2스테이지=2,542G)를 보수적 하한으로, 계단형 지수 공식을 그대로 연장한 스테이지10(100웨이브) 값을 낙관적 참고치로 병기한다. + +| 시나리오 | 런당 골드(참고) | Layer① 소요 런수 | Layer② 소요 런수 | 합계 소요 런수 | +|---|---|---|---|---| +| 보수적 하한(S3 v2 앵커, 2스테이지 클리어) | 2,542G | 316런 | 100런 | 416런 | +| 중간 참고(5스테이지 클리어, 계단식 지수 공식 연장) | 8,200G | 98런 | 31런 | 129런 | +| 낙관적 참고(10스테이지 클리어) | 22,550G | 36런 | **12런** | **48런** | + +**해석**: 초반 레벨(L1~10, 누적 1,298G 미만)은 어느 시나리오에서도 **1런 이내** 도달 가능(즉각적 보상 체감 확보). 완전 맥스(캡60/star11)는 실력·투자에 따라 **48~416런**의 넓은 폭 — 이는 결함이 아니라 "장기 리텐션 콘텐츠"로서 의도된 넓은 목표이나, 폭 자체가 크므로 **실제 평균 런 도달 스테이지 플레이테스트 데이터 확보 후 §3-2의 0.4 축소계수·§4-2의 quality=1 재검토**를 권고한다(변수화·구간화 원칙). + +--- + +## 7. defense 클램프 분리 결합식 확정 (메타v1 R-B2 해소) + +메타v1 §3-4가 스스로 지적한 함정(승급 defense%를 인게임과 같은 0.8 클램프에 그냥 더하면, 인게임 클램프에 이미 근접한 장기 유저는 그 판의 방어 강화 선택이 무의미해짐)을 **곱연산 분리식**으로 해소한다. 이것이 메타v1이 "P3-B1에서 balance-designer 확정" 요청한 바로 그 결정이다. + +```csharp +// RecalcPlayer() 확정 수정 — 메타v1 §3-4 코드 스니펫(단순 가산)을 대체 +float ingameReduce = Mathf.Clamp( + t.Total("hurt_reduce") + t.Total("defense_add") + t.Total("dodge_rate"), 0f, 0.8f); // 기존 로직 완전 불변 +float outgameRatio = SurvivalMeta.PromotionDefenseRatio(); // §4-2, 0~0.22 +Player.DamageReduction = 1f - (1f - ingameReduce) * (1f - outgameRatio); +``` + +### 7-1. 검증 테이블 + +| 인게임 감소(클램프 후) | 승급 defense% | 최종 DamageReduction | 비고 | +|---|---|---|---| +| 0 | 0 | 0 | 신규 유저, 기존과 동일 | +| 0 | 22%(star11) | 22% | 인게임 미투자자도 항상 체감(§메타v1 지적 사항 해소 확인) | +| 0.8(캡) | 0 | 80% | 기존 그대로 | +| 0.8(캡) | 22%(star11) | **84.4%** | 클램프 근접 유저도 승급 투자가 여전히 유효(0.8→0.844, +4.4%p) — **함정 해소 확인** | +| 0.5 | 11%(star5) | 55.5% | 중견 밴드 참고 | + +100%(완전 무적)에 도달하려면 `ingameReduce=1`이거나 `outgameRatio=1`이어야 하는데, 전자는 기존 0.8 클램프가 막고 후자는 §4 설계상 최댓값이 0.22이므로 **극한에서도 무적화되지 않음**을 수식적으로 확인. + +--- + +## 8. 데이터 모델 — CSV 스키마 실값 (메타v1 §5-2 스키마 준수) + +### 8-1. `SurvivalMetaHeroLevel.csv` + +``` +n_Level,l_RequireCost,f_AttackBudget,f_HpBudget +영웅레벨,강화비용(GOLD_ID),공격력예산(누적아님·해당레벨 1회성 flat),체력예산(동일) +1,2,2,8 +2,9,4,16 +...(공식 0.2L³+1.8L² / 2L / 8L 적용, 3~59행 생략 — §3-3 체크포인트 참고) +60,49680,120,480 +``` +*컬럼 의미*: `f_AttackBudget`/`f_HpBudget`은 **그 레벨 1회분 증가량**(누적 아님) — `SurvivalUpgradeTable.Total()`과 동일하게 로더가 `HeroLevel` 이하 전 행을 순회 합산하는 방식(§5의 `HeroLevelAttackBudget()=2×Data.HeroLevel`은 이 합산의 폐쇄형 결과와 동일하므로 런타임은 공식으로 직접 계산해도 무방 — CSV 실값과 공식 계산값이 반드시 일치해야 함을 QA 체크리스트에 명시). + +### 8-2. `SurvivalMetaPromotion.csv` + +``` +n_Star,n_Quality,l_GoldCost,n_LevelCap,f_AttackBonusRatio,f_HpBonusRatio,f_PromoDefenseAddRatio +승급성급,등급(단일히어로 고정값·§4-2 비용식 전용),골드비용(→해당성급),레벨상한,공격%보너스,체력%보너스,방어%보너스 +0,1,0,5,0,0,0 +1,1,50,10,0.02,0.02,0.02 +2,1,408,15,0.04,0.04,0.04 +3,1,1404,20,0.06,0.06,0.06 +4,1,3392,25,0.08,0.08,0.08 +5,1,6750,30,0.10,0.10,0.10 +6,1,11880,35,0.12,0.12,0.12 +7,1,19208,40,0.14,0.14,0.14 +8,1,29184,45,0.16,0.16,0.16 +9,1,42282,50,0.18,0.18,0.18 +10,1,59000,55,0.20,0.20,0.20 +11,1,79860,60,0.22,0.22,0.22 +``` + +**`n_Quality` 필드 주의**: 스키마는 메타v1이 확정했으므로 컬럼 자체는 유지하되(향후 다중 히어로 확장 시 재사용 대비), 현재 로더는 이 값을 비용식 계산에 사용하지 않는다(비용은 이미 `l_GoldCost`에 리터럴로 계산 완료돼 있음, quality=1은 §4-2 도출 근거의 기록용 표기). `f_*Ratio` 3열도 quality 파생이 아니라 §4-2에서 목표 역산한 리터럴값이다 — 런타임이 `n_Quality × 0.002`를 계산하지 않도록 주의(원작 공식과 다른 값이 될 것). + +### 8-3. `SurvivalMetaData` 스키마 정정 제안 (메타v1 §5-1 대비) + +메타v1 §5-1이 예비해 둔 `public long HeroLevelExp` 필드는 **본 설계에서 불필요**하다 — 원작의 "골드→경험서→소비 2단 경제"를 스킵하고 골드를 직접 소비하기로 확정했으므로(§1, 메타v1 §1-1 열린 이슈의 본 문서 결론) 중간 경험치 자원 자체가 없다. 구현 시 이 필드는 제외 권고(죽은 필드 방지, C22 일관성). + +--- + +## 9. 검증 시나리오 + +| # | 시나리오 | 통과 기준 | 결과 | +|---|---|---|---| +| 1 | 기준선 무결성 — HeroLevel0/PromotionStar0/미장착 | FinalAttack=22, FinalHp=400 | **통과**(§5-1) | +| 2 | 즉각 접근성 — 신규 유저 Level1~5 | 승급 없이 구매 가능, 누적비용<1런 | **통과**(Star0 캡=5, 누적 144G) | +| 3 | 게이팅 검증 — Level6 시도 | Star0(캡5) 상태에서 차단, Star1 승급(50G) 후 허용 | **통과**(설계상 자명, §4-4) | +| 4 | defense 클램프 안전성 — 극한값 | DamageReduction < 100% 항상 성립 | **통과**(§7-1, 최댓값 84.4%) | +| 5 | 맥스 밴드 인게임 영향 | 참고치(밴드 강제 아님) | FinalAttack 230.6(현재比 3.3배) — **R-J 심화 확인, §11로 이관** | +| 6 | 활성 스킬 증폭 상호작용 | 참고치 | §11 R-C4 참고 | +| 7 | 레벨캡 나눗셈 정합 | `5×(star+1)`이 원작 클램프 버그 구간(성29/30) 재현 안 함 | **통과**(star11=cap60 정확히 나눔, §4-5) | + +--- + +## 10. 밸런싱 제안 표 + +| 항목 | 현재 값 | 제안 값 | 근거 | +|---|---|---|---| +| HeroLevel 범위 | 없음(신규) | 1~60 | 승급 star11×5 게이팅과 나눗셈 없이 정합(§3-1) | +| HeroLevel AttackBudget/레벨 | 없음 | +2(flat, 선형) | hp Flat 트랙 4:1 유도 관례 계승(§3-2) | +| HeroLevel HpBudget/레벨 | 없음 | +8(flat, 선형) | =4×AttackBudget, A80ChampMatchConfig 4:1(§3-2) | +| HeroLevel 비용식 | 없음 | `0.2L³+1.8L²` | 원작 hero_level cost 형태×0.4(L60=49,680G 역산, §3-2) | +| Promotion 범위 | 없음(신규) | star 0~11 | HeroLevel60을 정확히 게이팅(§4-1) | +| Promotion 비용식 | 없음 | `(star+1)³×(star+50)`, quality=1 | 원작 hero_star quality=1 그대로, 재계수화 없음(§4-2) | +| Promotion 보너스/star | 없음 | +2%(공/방/HP 동일) | defense 클램프 결합 검증(0.8→0.844) 기반 목표 역산(§4-2·§7) | +| defense 결합식 | 없음(메타v1 나이브 가산 초안) | 곱연산 분리식(§7) | R-B2 함정(클램프 근접 시 아웃게임 투자 무의미화) 회피 | +| 런→영구골드 전환 | 없음(브릿지 부재, §2 신규 발견) | `TotalGoldEarned`×100% | 스펜드/축적 딜레마 제거, 실력 비례 성장(§2-3) | + +**세그먼트 영향**: 전 항목 **현재 전 세그먼트 동일**(Survival IAP 미연동, S3 v2·공격력2층v2와 동일 고지 승계). `GOLD_ID`가 상점 골드팩과 공유되므로, 향후 상점 IAP 결선 시 **고과금 유저는 골드 구매로 Layer①②를 시간 단축 가능**(🟡추정 리스크, §2-3에서 이미 F2P 표준 구조로 판단·별도 조치 불요). + +--- + +## 11. 리스크 + +| ID | 리스크 | 심각도 | 내용 | +|---|---|---|---| +| **R-C1(신규, plan-auditor 지적 반영)** | 런→영구골드 브릿지 부재 + 런 종료 경로 2개(`OnDefeatContinue()`·`OnPauseRestart()`) | 높음(구현 필수) | §2 신규 발견 — `TotalGoldEarned` 필드·전환 코드 없이는 Layer①②가 소비할 재화 자체가 유입되지 않는다. 최초 설계는 `OnDefeatContinue()` 1곳에만 훅을 심으려 했으나 plan-auditor가 `OnPauseRestart()`도 동일하게 `M.Restart()`를 호출함을 코드로 확인(본 balance-designer 재확인 완료) — **`SurvivalBattleManager.Restart()` 자체를 단일 choke point로 정정**(§2-3). P3-B1 구현의 **선행 필수 항목**, 팀장급 확인 필요 | +| **R-C2(신규)** | 평균 런 도달 스테이지 미확정 | 중(🟡추정) | §6 — "완전 맥스까지 몇 런"의 폭이 48~416런으로 넓다. 실제 플레이테스트로 축소계수(0.4)·quality(1) 재조정 필요 | +| R-C3(해소) | defense 클램프 공유 시 아웃게임 투자 무의미화(메타v1 R-B2) | — | §7 곱연산 분리식으로 해소 확인(수식 검증 통과) | +| **R-C4(승계·수치 정정, plan-auditor M-1)** | `SurvivalActiveSkillRunner.BaselineAttack=22f` 상수 복제(메타v1 R-B4) | 중 | **최초 계산에 `RecalcPlayer()`의 `atkRatio=Total("attack_add")+Total("hurt_add")` 중 `hurt_add`(누적 0.87) 누락 오류가 있었다 — plan-auditor 지적으로 정정.** 올바른 계산: 현재 맥스(장비만, FinalAttack=69) → `Player.Attack=(69×(1+0.87+0.87)+1650)=1,839` → 배율 1839/22=**83.6배**. 미래 맥스(Hero60+Promo11+장비, FinalAttack=230.6) → `Player.Attack=(230.6×2.74+1650)=2,282` → 배율 2282/22=**103.7배**. 증폭 103.7/83.6=**+24.1%**(최초 발신값 "+17%"보다 큼 — 리스크는 과소 보고돼 있었다). P3-B1 구현과 **병행 수정 권고**(`BaselineAttack`→`SurvivalMeta.BaseAttack` 참조 교체, 1줄 수정) | +| **R-C5(승계·부분 해소)** | hero_star 레벨캡 성29/30 불일치 미해소 | 낮음(현재 무관) | §4-5 — 본 설계(star11=cap60)는 이 구간과 부딪히지 않으나, 향후 캡 확장 시 재발 가능. 재추출 필요 데이터 명시 완료(§4-5) | +| **R-C6(신규)** | 맥스 밴드 인게임 초반 웨이브 무위협 가속 | 중(범위 외) | §5-1 — S3 v2 R-J를 심화. 스테이지 설계(P3-C) 영역이므로 본 문서에서 대응하지 않되, system-designer·PD 인지 필요 사항으로 명시 | +| **R-C7(신규)** | 상점 골드팩 판매력 재산정 필요 가능성 | 낮음(정보성) | §10 — Layer①②라는 새 골드 소모처가 생기면 기존 골드팩(500~48,000) 판매 매력이 상대적으로 상승할 수 있음(소모처 증가=재화 가치 상승). 데이터 없는 선제 조정은 C2 위반이므로 관찰만 권고 | + +--- + +## 12. 기각안 (C32) + +| # | 검토안 | 기각 사유 | +|---|---|---| +| 1 | Promotion에 원작처럼 quality 1~6 다중 등급(히어로 희귀도) 도입 | GodDem은 히어로 1명 고정 — 희귀도 시스템 자체가 없어 다중 quality를 도입할 근거 데이터가 없다(범위 밖, 가챠 B3와도 무관한 별개 축) | +| 2 | HeroLevel을 원작 150레벨 그대로 채택 | 청사진 §0 "150레벨 스케일 그대로 대입 불가" 전제 + 재추출v1 §0 "hero_level엔 스탯 개별 분해식 자체가 없음" 확정 — 규모·데이터 양쪽 이유로 재산정 필수 | +| 3 | Promotion 보너스도 quality=1을 그대로 대입(0.002×1×star, 최댓값 2.2%) | 원작 원형은 보존되나 체감 임팩트가 무의미한 수준 — §7 defense 클램프 결합 검증이 성립하는 목표치(22%)를 먼저 정하고 역산하는 편이 "형태는 재사용하되 의미 있는 값" 원칙에 더 부합 | +| 4 | 신규 전용 중간재("영웅 증표" 등) 도입 | 메타v1 §1-1 디폴트 권고(기존 골드 재사용) 존중 + C50 범위 확대 방지 — 기존 골드 재사용만으로 설계 목표(장기 성장 유인) 달성 가능, 별도 통화 UI·환전 로직 등 불필요한 복잡도 회피 | +| 5 | 승급 게이팅을 없애고 HeroLevel 완전 자유 성장 | 원작 실측(매핑v1 §2-2)의 "승급의 진짜 기능=레벨캡 게이팅" 원칙과 메타v1 §1-2 확정 방향을 정면으로 위반 — 이미 PD 승인된 방향(C36) | +| **6(plan-auditor m-3 반영 — #6 재작성)** | HeroLevel·Promotion을 원작처럼 상한 없이(무한 확장) 설계 | 메타v1 §1-1이 이 방향("상한 없음")을 명시했으나, CSV 테이블 구조는 무한 행을 미리 채울 수 없어 실제 구현이 불가능하다(원작조차 실제로는 150에서 멈춘 유한 시스템, 매핑v1 §2-1). 60/11 유한 캡을 채택하되 이 반전 자체는 §0·§3-1에 은폐 없이 명시하고 시스템기획·PD 인지를 요청했다(C36 경계) | + +**참고(기각 아님, 튜닝값 명시)**: 런종료 전환율(§2-3)은 100%로 제안했으나 이는 "기각된 대안"이 아니라 **1차 제안값**이다 — §11 R-C2(평균 런 도달 스테이지 미확정) 해소 후 플레이테스트 결과에 따라 50~100% 구간에서 하향 조정 가능한 손잡이로 남겨둔다. + +--- + +## 13. 변경 이력 (P16) + +| 일시 | 변경자 | 항목 | 이전값 | 이후값 | 사유 | +|---|---|---|---|---|---| +| 2026-08-22 | balance-designer | 문서 신규 작성(v1) | — | 본 문서 전체(Layer①② 실수치·결합식·CSV 스키마 실값) | PD 승인 "설계대로 진행" 집행, 메타v1 §P3-B1 유보사항 확정 | +| 2026-08-22 | balance-designer | 런→영구골드 브릿지 설계 | 없음(메타v1 미언급) | `TotalGoldEarned`+`Restart()` 단일 choke point 전환 100% | C39 실측 중 브릿지 부재 신규 발견, C3 은폐 없이 반영 | +| 2026-08-22 | balance-designer | defense 클램프 결합식 확정 | 메타v1 나이브 가산 초안(R-B2 리스크 열림) | 곱연산 분리식 `1-(1-in)×(1-out)` | 메타v1이 명시 위임한 "P3-B1에서 balance-designer 확정" 이행 | +| 2026-08-22 | balance-designer | plan-auditor 감사 반영 최종화(같은 v1 내 확정) | 초안(Critical 1·Major 4·Minor 3 지적 전) | Critical(브릿지 choke point `OnDefeatContinue()`→`Restart()` 이전)·Major(R-C4 배율 80.9→83.6배·94.6→103.7배 정정, §4-2 quality 근거 재작성, M-4 상한반전 고지, 보상팝업 표기 불일치 명시)·Minor(인용 §5-3→§0 2건, §6 12런/48런 정정, 기각안#6 재작성) 전부 반영 | C35 감사 게이트 — 조건부통과 정정 완료 후 발신(산술은 전량 무오류 확인됨) | + +--- + +## 14. 후속 조치 (본 문서 범위 밖) + +1. **개발팀 구현 선행 필수(팀장급 확인 후)**: §2-3 전환 브릿지(`TotalGoldEarned`+`Restart()` 단일 choke point) + §5 `FinalAttack()`/`FinalHp()` 신규 메서드 + §7 `RecalcPlayer()` defense 결합식 교체 + §8-3 `HeroLevelExp` 필드 제외. +2. **병행 권고**: R-C4(`SurvivalActiveSkillRunner.BaselineAttack` 상수 참조 교체) — 별건이나 P3-B1과 동시 작업 시 회귀 리스크 낮음. +3. **UI 동반 수정 필요(ux-designer·클라이언트팀 협의)**: §2-3 M-2 — Victory/Defeat 팝업 보상란이 현재 `M.Gold`(잔여)를 표시하는데 영구 전환은 `TotalGoldEarned`(총 획득)을 쓴다. 표기 문구 정합 필요. +4. **개발팀장 재추출**(차단 조건 아님, 향후 캡 확장 대비): `hero_star.csv` star=28~30 전체(18행) `max_level` 원본(§4-5). +5. **system-designer·PD 인지 필요**: ①R-C6(맥스 밴드 초반 웨이브 무위협 가속, R-J 심화) ②§0·§3-1 M-4(HeroLevel 유한 캡 도입이 메타v1 "상한 없음" 명시 방향과 다름, C36 경계) — 둘 다 본 문서는 문제 제기까지만. +6. **PM 공유**: 본 문서 산출 완료를 `개발팀_PD_지시_로그.md`(GodDem/BT13 단일 관리) 및 대화로그 반영. +7. **plan-auditor 교차검증**: 완료(본 문서 헤더 감사 이력 참조) — 후속은 기획팀장 검증(C49) 재상정. diff --git a/공유/기획/GodDem/2026-08-22_메타아키텍처_재설계_v1.md b/공유/기획/GodDem/2026-08-22_메타아키텍처_재설계_v1.md index 0bf7772..bbaab72 100644 --- a/공유/기획/GodDem/2026-08-22_메타아키텍처_재설계_v1.md +++ b/공유/기획/GodDem/2026-08-22_메타아키텍처_재설계_v1.md @@ -23,10 +23,10 @@ | 항목 | 결론 | |---|---| | 5층 채택 | ①레벨→"영웅레벨"(신규 영구) ②승급→레벨 게이팅+3스탯 보너스(신규 영구) ③장비강화→per-item 레벨업(SurvivalItemCatalog 확장) ④가챠→장비 확률 획득(전면 신규, PD 확인 완료) ⑤스킬→마스터리 영구 해금(SurvivalActiveSkillRunner 연동, 드래프트 풀 필터링 방식으로 확정) | -| 능력치 18종 배치 | 인게임 기능 11종 유지 + 인게임 사장(死藏) 1종(penetrate_ratio) ⑤로 이관 + 완전 신규 6종을 ④(4종 확정: hit/stun/retaliate/combo) + ele_hurt_add·ele_penetrate_ratio(2종, 🟡 ④ 잠정·P3-A 확정) | +| 능력치 18종 배치 | 인게임 기능 11종 유지 + 인게임 사장(死藏) 1종(penetrate_ratio) ⑤로 이관 + 완전 신규 6종을 ④가챠 4종 확정(hit/stun/retaliate/combo) + ⑤스킬마스터리 2종 확정(ele_hurt_add·ele_penetrate_ratio — P3-A 재추출로 ④ 가설 반증·⑤ 확정, 정직 한계: 원작 positive 사용 근거 아님, §2-2 상세) | | 경계 재정의 | "판 시작 전 확정 vs 판 진행 중 리셋" 시점 기준. 네임스페이스 충돌은 클래스 분리+CSV 키 접두+**단일 계산 메서드 캡슐화** 3중 방지 | | 재사용/확장 | SurvivalMeta(확장 기반)·SurvivalUpgrade(불변 재사용)·SurvivalSkill(불변+조건부 확장) / SurvivalItemCatalog·**SurvivalShopCatalog(구조 확장 필요 — 확률 지급물 미지원 확인)** / 신규 클래스 4·CSV 7종 | -| 미확정 이관 사항(PD/개발팀 영역, §10) | 가챠 소비 재화(골드 vs 젬, 🔴 원작 근거 부재) · ele_* 2종 최종 층(④/⑤) · defense 클램프 공유 방식 | +| 미확정 이관 사항(PD/개발팀 영역, §10) | 가챠 소비 재화(골드 vs 젬, 🔴 원작 근거 부재) · defense 클램프 공유 방식. **(해소 2026-08-22)** ele_* 2종 최종 층 — P3-A 재추출로 ⑤ 확정 완료(§2-2) | | P3 분할 | P3-A(능력치 정리) → P3-B1(레벨+승급) → P3-B2(장비강화, 원본 재대조 선행) → P3-B4(스킬마스터리) → P3-B3(가챠, PD 정책 확인 후) → P3-C(스테이지, 병렬 가능) | --- @@ -89,7 +89,7 @@ - **등급의 실질 가치**: 원작 "등급이 높을수록 확정 티어 지급"(quality→확정 확률 대체) 원칙 재사용 — 높은 등급 뽑기권은 낮은 등급 결과를 배제. - **소비 재화 — 🔴 미확보, PD 이관**: 원작 문서 3건 어디에도 `drawlib`/`drawtype`의 소비 재화(무료 vs 유료) 언급이 없다(매핑v1 §2-6은 weight·천장만 다룸). "원작대로 가챠 도입"이라는 PD 지시가 구조·스키마 설계까지는 덮지만(C1), 무료재화(골드) 가챠와 유료재화(젬) 가챠는 서로 다른 BM이자 R-A3 정책 등급도 달라진다. **본 문서는 재화 종류를 확정하지 않는다** — 결정은 PD 영역(§10). - **드롭 대상 확장**: 가챠는 §1-3(장비강화)과 별개로 **SurvivalItemCatalog 자체의 폭 확장**(신규 등급 3+·신규 아이템) 창구다 — 청사진 §3의 "등급 1~2뿐, 극히 협소" 문제의 실제 해소 지점. -- **신규 스탯 수용(확정 4종 + 잠정 2종)**: `hit_rate`·`stun_rate`·`retaliate_rate`·`combo_rate`(명중/회피계+특수효과계, 원작 B-템플릿 ×2 등비 공유군, 재추출v1 §2-2 — 확정 배치) + `ele_hurt_add`·`ele_penetrate_ratio`(🟡 잠정, §2 상세). +- **신규 스탯 수용(확정 4종)**: `hit_rate`·`stun_rate`·`retaliate_rate`·`combo_rate`(명중/회피계+특수효과계, 원작 B-템플릿 ×2 등비 공유군, 재추출v1 §2-2 — 확정 배치). **정정(P3-A 재추출 완료, 2026-08-22)**: `ele_hurt_add`·`ele_penetrate_ratio`는 최초 초안에서 ④ 잠정 배치였으나, `heroequipmentskill`(장비옵션 드로우풀, 실사용 21종) 재대조 결과 ele 2종 참조 **0건**으로 확인돼 ④ 소속 가설이 반증됐다 — ⑤스킬마스터리로 이관 확정(§1-5·§2-2 상세). ### 1-5. Layer⑤ 스킬 마스터리(Skill Mastery) — SurvivalActiveSkillRunner 연동 @@ -99,9 +99,9 @@ - **연동 지점 실측**(C39-10): `SurvivalActiveSkillRunner`는 `_owned`/`_byId`를 인스턴스 필드로 갖고 `Awake()`에서 빈 상태로 시작한다(🟢, 완전 매판 리셋). `LoadActiveSkills()`는 `Resources/Skills/Active/*.asset` 전체를 조건 없이 로드한다 — 현재는 액티브 스킬 습득에 게이팅이 전혀 없다. - **메커니즘 확정 — 드래프트 풀 필터링(Pre-seed 방식 기각)**: `SurvivalSkill.Draw()`가 액티브 후보를 계산하는 지점(`avail` 리스트)에 `SurvivalMeta.Data.UnlockedActiveCardIds` 조회 조건 1줄을 추가해, 언락 안 된 카드는 그 판 드래프트에 아예 등장하지 않게 한다. **"판 시작 시 자동 장착(pre-seed)" 방식은 채택하지 않는다** — 로그라이크의 매판 선택 긴장감(레벨업마다 3택1)을 그대로 보존하면서 "풀이 넓어진다"는 감각만 추가하는 쪽이 재미(P30) 관점에서 더 낫고, 구현도 1줄 필터로 더 단순하다. 기본값은 **전체 언락 상태로 시작**(하위호환 유지 — 아무 투자 안 한 신규 계정은 지금과 동일하게 전체 풀에서 드래프트). -- **패시브 마스터리 노드**: 드래프트를 거치지 않고 ①②③처럼 항상 적용되는 영구 가산 스탯. 확정 배치는 `penetrate_ratio` 1종뿐이다(아래 이관 근거). `ele_hurt_add`/`ele_penetrate_ratio`는 §2에서 🟡로 별도 처리한다. +- **패시브 마스터리 노드**: 드래프트를 거치지 않고 ①②③처럼 항상 적용되는 영구 가산 스탯. **확정 배치 3종**: `penetrate_ratio`(아래 이관 근거) + `ele_hurt_add`·`ele_penetrate_ratio`(P3-A 재추출로 ④ 잠정 해소, §2-2 확정표). **정직 한계 명기(C5·C44)**: ele 2종의 ⑤ 확정은 "④ 소속 가설 반증(`heroequipmentskill` 실사용 21종에 참조 0건) + 잔여 층 배치 + `penetrate_ratio`와의 의미론적 근접성(같은 관통/속성계 변형)"에 의한 것이지, **"원작이 이 2종을 ⑤ 스킬트리에서 실제로 positive 사용했다"는 원작 근거가 확보된 것은 아니다** — 원작 자체도 이 2종을 정의만 하고 실사용은 안 했을 개연이 있다(매핑v1 §6-4가 `heroskill.csv`에 대해 이미 밝힌 "틀은 있고 데이터는 비었다" 패턴과 동일 계열 가능성). - **`penetrate_ratio` 이관(확정 권고)**: 현재 인게임 CSV(13종)에 존재하나 `ConsumedUpgradeKeys`에 없어 **사장(死藏)**돼 있다(🟢 실측, `SurvivalBattleManager.cs` L152-160). **중요 정정(plan-auditor m-2)**: 이 트랙은 방치된 위험 요소가 아니다 — `ValidateUpgradeCoverage()`(L167)가 기동 시 미소비 키를 경고하도록 이미 설계돼 있고(주석이 "동일 유형의 재발을 막는다"고 명시), 상점에서도 이미 자동으로 숨겨진다. 실제 문제는 **`ConsumedUpgradeKeys`(소비 목록)와 `RecalcPlayer`(실계산)가 손으로 동기화해야 하는 한 쌍**이라는 점이며(코드 주석 L148-150이 이미 자인), 이 수동 동기화 부담은 아웃게임에 신규 키를 추가할 때도 똑같이 발생한다(§3-3에 동일 원칙 적용). `penetrate_ratio`를 인게임에서 배선(1줄 추가)하는 대안 대신 ⑤로 이관하는 이유는 순수하게 §0 원칙("이미 인게임에 있는 건 유지, 신규만 아웃게임 배치") 적용이지, 위험 회피가 아니다(§8 기각안 다). -- **속성(elemental) 시스템 전제조건 미확인**: `ele_hurt_add`/`ele_penetrate_ratio`가 의미를 가지려면 전투에 "속성" 개념이 필요하다. `AttributeTag`(Flags enum, 물리/화염 등)가 `SkillDataAsset.cs`에 이미 존재하나(🟢), 이것이 `SurvivalUnit.TakeDamage()`의 실제 데미지 계산에서 상성/저항으로 소비되는지는 **미확인**(🔴, 범위 외 — P3-B4 착수 시 개발팀 재확인 필수 선행 조건). 이 전제조건은 ele_* 2종이 최종적으로 ④에 배치되든 ⑤에 배치되든 **동일하게 적용**된다(§2 참조). +- **속성(elemental) 시스템 전제조건 미확인**: `ele_hurt_add`/`ele_penetrate_ratio`가 의미를 가지려면 전투에 "속성" 개념이 필요하다. `AttributeTag`(Flags enum, 물리/화염 등)가 `SkillDataAsset.cs`에 이미 존재하나(🟢), 이것이 `SurvivalUnit.TakeDamage()`의 실제 데미지 계산에서 상성/저항으로 소비되는지는 **미확인**(🔴, 범위 외 — P3-B4 착수 시 개발팀 재확인 필수 선행 조건). 이 전제조건은 ele_* 2종의 층 배치가 ④에서 ⑤로 확정된 뒤에도 **동일하게 적용**된다(§2 참조) — 층이 확정됐다고 소비처 존재가 자동으로 확정되는 것은 아니다. ### 1-6. 5층 상호작용 요약 @@ -111,8 +111,8 @@ ②승급(Promotion) ──게이팅────> ①의 최대 도달 가능 HeroLevel 상한 ──보너스────> attack%·hp%·defense% (defense는 §3-4 별도 결합) ③장비강화(EquipLv) ──독립──────> 슬롯별 attack/hp + 부스탯(속도|방어) - ④가챠(Gacha) ──확률 공급──> ③이 강화할 "장비 자체"(신규 아이템) + 옵션(hit/stun/retaliate/combo, +ele_*🟡잠정) - ⑤스킬마스터리 ──패시브────> penetrate_ratio 영구 가산(+ele_*🟡잠정 시) + ④가챠(Gacha) ──확률 공급──> ③이 강화할 "장비 자체"(신규 아이템) + 옵션(hit/stun/retaliate/combo, 4종 확정) + ⑤스킬마스터리 ──패시브────> penetrate_ratio·ele_hurt_add·ele_penetrate_ratio 영구 가산(3종 확정, P3-A 재추출) ──풀 확장───> 런레벨업 드래프트의 "액티브 카드" 후보 목록(필터링, 패시브와 별개 트랙) ↓ (①②③④의 스탯 기여 = 아웃게임 최종 flat/ratio 총합, §3-4) [판 진행 중 — 인게임, 매판 리셋] @@ -146,7 +146,7 @@ |---|---|---| | attack_add, hp_add, hp, attack_speed_add, hurt_add, hurt_reduce, defense_add, lucky_rate, lucky_multiple, suck_ratio, dodge_rate | **인게임 유지**(불변, 11종) | 이미 SurvivalUpgrade에서 기능 중 — 중복 배치 금지 원칙(§0) | | hit_rate, stun_rate, retaliate_rate, combo_rate | **④가챠 옵션**(확정, 4종) | 원작 분류상 "명중/회피계"+"특수효과계"이며 원작 B-템플릿(×2 등비, 재추출v1 §2-2) 공유군 — 확률 드로우풀 스탯으로서의 원작 성격과 일치 | -| ele_hurt_add, ele_penetrate_ratio | **🟡 ④ 잠정(2종), P3-A 확정 필요** | 청사진 §1-1은 "5층(스킬) 전용 scope"로 분류했으나 🟡 태그였고, 재추출v1 §2-1(27코드−res6=21) 산술이 §3의 "장비옵션 드로우풀 실사용 21종"과 일치해 오히려 ④ 소속일 가능성이 있다(plan-auditor M-1 지적). 재추출v1 §3 스스로 "두 usage scope가 혼재"라 경고한 대목이라 본 문서 단계에서 최종 확정하지 않는다 — P3-A 재추출로 확정. 어느 쪽에 배치되든 §1-5의 속성 시스템 전제조건은 동일 적용 | +| ele_hurt_add, ele_penetrate_ratio | **✅ ⑤스킬마스터리로 확정(2종, P3-A 재추출 완료 2026-08-22)** | 최초 초안은 재추출v1 §2-1(27코드−res6=21) 산술이 §3 "장비옵션 드로우풀 실사용 21종"과 일치해 ④ 소속 가능성을 🟡로 열어뒀다(plan-auditor M-1 지적). **P3-A 재추출 재대조 결과**: `heroequipmentskill`(장비옵션 드로우풀) 실사용 21종에 ele 2종 참조 **0건** 확인 — "27−res6=21" 일치는 우연이었고 ④ 소속 가설은 반증됐다. 잔여 층 배치 원칙 + `penetrate_ratio`(이미 ⑤ 확정)와의 의미론적 근접성(관통/속성계 변형 형제 관계)으로 ⑤ 확정. **정직 한계(C5·C44 — plan-auditor 재확인 통과)**: 이 확정은 "④ 기각 + 잔여 층 + 의미론"에 의한 것이지 **"원작이 ⑤에서 이 2종을 positive 사용했다"는 근거는 아니다** — 원작도 정의만 하고 미사용이었을 개연 존재(§1-5). 속성 시스템 전제조건(§1-5)은 층 확정과 무관하게 별도 미확인 상태 유지 | | penetrate_ratio | **⑤스킬마스터리로 이관**(확정, 1종) | 인게임에서 이미 사장된 트랙을 §0 원칙(신규만 아웃게임 배치)에 따라 이관 — 위험 회피가 아니라 배치 원칙 적용(§1-5) | --- @@ -248,7 +248,7 @@ public class SurvivalMetaData public int PromotionStar = 0; // Layer② 승급 성급(게이팅 토큰) public Dictionary EquipLevel; // Layer③ itemId → 강화단계(신규, Owned와 별개) public int GachaPityCount; // Layer④ 천장 카운터(2단 중 현재 위치) - public Dictionary SkillMasteryLevel; // Layer⑤ 노드ID → 레벨(penetrate_ratio 등 패시브 전용) + public Dictionary SkillMasteryLevel; // Layer⑤ 노드ID → 레벨(penetrate_ratio·ele_hurt_add·ele_penetrate_ratio 3종 확정 패시브 전용) public HashSet UnlockedActiveCardIds; // Layer⑤ 액티브 카드 드래프트 풀 언락 목록 } ``` @@ -265,9 +265,9 @@ CSV 계약: **1행 헤더(컬럼명, 타입 접두 `n_`/`f_`/`s_`/`e_`/`l_`) · | `SurvivalMetaPromotion.csv` | `n_Star, n_Quality, l_GoldCost, n_LevelCap, f_AttackBonusRatio, f_HpBonusRatio, f_PromoDefenseAddRatio` | hero_star 4차 비용+선형 보너스+게이팅(형태만) | ②. `f_PromoDefenseAddRatio`가 §3-3 키 접두 가드 적용 예 | | `SurvivalMetaEquipUpgrade.csv` | `n_ItemId, n_Level, f_EquipAttackAdd, f_EquipHpAdd, s_SecondaryStatKey, f_SecondaryValue, l_Cost` | heroequipment Base+V 가산분해(형태만) | ③. `s_SecondaryStatKey`는 `equip_attack_speed_add` 등 접두 키만 허용 | | `SurvivalMetaGachaPool.csv` | `n_PoolId, n_ItemId, n_Grade, n_Weight` | heroequipmentskill weight, 합 10000 강제(본 층이 첫 실도입, §1-4) | ④ | -| `SurvivalMetaGachaOption.csv` | `n_OptionId, s_StatKey, n_Grade, f_Value` | heroskillattr B-템플릿(hit/stun/retaliate/combo, +ele_*🟡) | ④. `s_StatKey`=`gacha_hit_rate` 등 | +| `SurvivalMetaGachaOption.csv` | `n_OptionId, s_StatKey, n_Grade, f_Value` | heroskillattr B-템플릿(hit/stun/retaliate/combo, 4종 확정 — ele_*는 P3-A 재추출로 ⑤ 이관) | ④. `s_StatKey`=`gacha_hit_rate` 등 | | `SurvivalMetaGachaPity.csv` | `n_Tier, n_PullsNeed, n_GuaranteedGrade` | drawtype 2단(pool2need/pool3need 구조) | ④ | -| `SurvivalMetaSkillMastery.csv` | `n_NodeId, s_StatKey, n_Grade, f_Value, l_Cost` | heroskillattr(`penetrate_ratio` 확정 + ele_*🟡) | ⑤. `s_StatKey`=`mastery_penetrate_ratio` 등 | +| `SurvivalMetaSkillMastery.csv` | `n_NodeId, s_StatKey, n_Grade, f_Value, l_Cost` | heroskillattr(`penetrate_ratio`·`ele_hurt_add`·`ele_penetrate_ratio` 3종 확정, P3-A 재추출) | ⑤. `s_StatKey`=`mastery_penetrate_ratio` 등 | 예시(헤더+한글설명 행 실물, 값은 `TBD`): ``` @@ -297,7 +297,7 @@ n_Star,n_Quality,l_GoldCost,n_LevelCap,f_AttackBonusRatio,f_HpBonusRatio,f_Promo | Phase | 범위 | 규모 추정(근거) | 선행 조건 | |---|---|---|---| -| **P3-A** | 능력치 정리 — §2-2 배치표 확정 반영, `penetrate_ratio` 이관(CSV 행 제거+마스터리 CSV 등재), ele_* 2종 최종 층(④/⑤) 재추출 확정 | 소~중(재추출 1건 포함) | 본 문서 PD 확인 | +| **P3-A** | 능력치 정리 — §2-2 배치표 확정 반영, `penetrate_ratio` 이관(CSV 행 제거+마스터리 CSV 등재), ele_* 2종 최종 층 재추출 확정(④→⑤) — **완료(2026-08-22, 개발팀장 GodDem `8684211`, plan-auditor 조건부통과)** | 소~중(재추출 1건 포함) | 본 문서 PD 확인 | | **P3-B1** | Layer①+② 구현 — 영웅레벨+승급, `SurvivalMetaHeroLevel.csv`+`SurvivalMetaPromotion.csv` + defense 클램프 분리 결합식(§3-4) | 중(신규 클래스 2·결합 로직) | P3-A + `hero_star` 레벨캡 불일치 재실측(청사진 §5) | | **P3-B2** | Layer③ 구현 — 장비강화, `SurvivalMetaEquipUpgrade.csv` + `SurvivalItemCatalog` 확장 | 중(기존 패턴 복제 + 슬롯별 부스탯 매핑) | P3-B1(결합식 전제) **+ `heroequipment`/`upgrade` M수열 원본 재대조(R-A5, §7)** | | **P3-B4** | Layer⑤ 구현 — 스킬 마스터리, `SurvivalMetaSkillMastery.csv` + `SurvivalActiveSkillRunner` 드래프트 필터 연동 | 중(속성 시스템 실존 확인 선행 필요) | 개발팀 `AttributeTag` 소비 여부 재확인 | @@ -335,7 +335,7 @@ n_Star,n_Quality,l_GoldCost,n_LevelCap,f_AttackBonusRatio,f_HpBonusRatio,f_Promo | 2 | 승급(Layer②) 보너스에서 `defense`를 제외하고 attack/hp 2종만 이식 | 원작 실측(매핑v1 §2-2 "186행 검증 True")이 3스탯 동일 보너스임을 명시 — 임의 축소는 이식 충실성 훼손. 대신 §3-4 클램프 분리로 부작용만 해소 | | 3 | 장비강화(Layer③)를 슬롯 단위 설계 | 원작은 `heroequipment` 개별 ID 단위(매핑v1 §2-3). 슬롯 단위면 수집 동기 약화 | | 4 | 가챠(Layer④) 도입 시 기존 상점 직접판매 장비 항목 전부 대체 | 청사진 §3 재사용 판정과 배치. 신규 유저 저티어 접근성 보존을 위해 병존(R-B5) | -| 5 | `ele_hurt_add`/`ele_penetrate_ratio`를 속성 시스템 실존 여부 확인 없이 즉시 수치까지 확정 | C39 위반 소지 — 소비처 없는 스탯 배치는 결함 재발(청사진의 `HeroAttackMultiplier` 사장 사례와 동일 패턴). 배치(④ 잠정)만 하고 수치는 유예 | +| 5 | `ele_hurt_add`/`ele_penetrate_ratio`를 속성 시스템 실존 여부 확인 없이 즉시 수치까지 확정 | C39 위반 소지 — 소비처 없는 스탯 배치는 결함 재발(청사진의 `HeroAttackMultiplier` 사장 사례와 동일 패턴). 배치(당시 ④ 잠정)만 하고 수치는 유예 — **(2026-08-22 후속)** P3-A 재추출로 층은 ⑤ 확정됐으나(§2-2) 수치·소비처 확인은 여전히 유예 상태, 이 기각 논리는 그대로 유효 | | 6 | 청사진 §2-3 "5종" 표기를 재검증 없이 승계 | C44는 상위 문서 수치도 항상 재검증 요구. 실측 결과 6종(stun_rate 누락)이 정확 | | 7 | 본 문서에서 세부 CSV 수치까지 한 번에 확정 | PD 지시가 "P1 조망→P2 메타재설계→P3 축별 구현"으로 명시 분할(C50) | | **8(신규)** | Layer②를 성29·성30 레벨캡 12행 불일치 미해소 상태로 그대로 채택 강행 | plan-auditor M-3 지적 — 매핑v1 §2-2 자체가 재검증 필요를 명시한 ⚠️ 절이다. 채택 방향은 확정하되 **재실측을 P3-B1 선행 조건으로 강제**(§6·R-A5)해 강행하지 않는다 | @@ -350,13 +350,14 @@ n_Star,n_Quality,l_GoldCost,n_LevelCap,f_AttackBonusRatio,f_HpBonusRatio,f_Promo |---|---|---|---|---|---| | 2026-08-22 | system-designer | 문서 신규 작성 초안 | — | 5층 골격·18종 배치(5종 기준)·결합 "1곳" 주장 | PD 지시 집행 1차 초안 | | 2026-08-22 | system-designer | plan-auditor 감사 반영 최종화(같은 v1 내 확정) | 초안 | Critical 2(결합 4곳 정정·defense 채널 처리)·Major 6(ele_* 🟡화·가챠재화 🔴화·상점구조 확장·통계 정합·R-A5 승계·P30 근거 보강) 전부 반영 | C35 감사 게이트 — 조건부통과 정정 완료 후 발신 | +| 2026-08-22 | system-designer | ele_hurt_add·ele_penetrate_ratio 층 배치 정정(§0·§1-4·§1-5·§1-6·§2-2·§5-1·§5-2·§6·§8) | 🟡④가챠 잠정(2종) | ✅⑤스킬마스터리 확정(2종) | P3-A 재추출 실측 완료(개발팀장, GodDem `8684211`) — `heroequipmentskill` 실사용 21종에 ele 참조 0건 확인, ④ 소속 가설("27−res6=21" 일치) 반증. plan-auditor P3-A 검증(§27, 대화로그) 이미 통과분을 본 문서에 정합 반영. 정직 한계(원작 positive 사용 근거 아님) 각 위치에 명기 | --- ## 10. 후속 조치 (본 문서 범위 밖) 1. **개발팀 재확인 3건**: ①`hero_star` 레벨캡 성29·30 불일치 재실측(P3-B1 선행) ②`heroequipment`/`upgrade` M수열 원본 CSV 재대조(P3-B2 선행, R-A5) ③`AttributeTag`의 실전투 데미지 계산 소비 여부(P3-B4 선행, R-B2 아님 — §1-5 속성 전제조건). -2. **balance-designer 위임(P3-A)**: §2-2 배치표를 입력으로 능력치 축 확장 설계 + ele_* 2종 최종 층(④/⑤) 확정 재추출. +2. **balance-designer 위임(P3-A)**: §2-2 배치표를 입력으로 능력치 축 확장 설계. ~~ele_* 2종 최종 층 확정 재추출~~ → **완료(2026-08-22)** — 개발팀장이 수행(⑤ 확정, GodDem `8684211`), §2-2·§6 반영 완료. 3. **PD 확인 2건**: ①Layer④ 가챠 가격·확률 실제 값 및 확률형 아이템 정책 준수 방식(P3-B3 착수 전제, R-A3) ②**가챠 소비 재화(골드 vs 젬) 방향**(🔴 원작 근거 부재, §8 기각안9·M-2) — 스키마는 재화 종류 무관하게 설계됐으므로 이 결정이 P2를 재작업시키지 않는다. 4. **PM 공유**: 본 문서 산출 완료를 `개발팀_PD_지시_로그.md`(BT13-GodDem 단일 관리) 및 대화로그에 반영. 5. **별건 결함 인지(수정은 범위 외, C3 은폐 금지 목적 기록)**: `SurvivalActiveSkillRunner.BaselineAttack` const 복제(R-B4) — P3-B1 착수 시 정리 권고. diff --git a/공유/대화로그/GodDem/2026-08-22.md b/공유/대화로그/GodDem/2026-08-22.md index 964e7b2..aad0cb2 100644 --- a/공유/대화로그/GodDem/2026-08-22.md +++ b/공유/대화로그/GodDem/2026-08-22.md @@ -148,3 +148,23 @@ - **정직 노트**: catalog attack Note의 "정액"은 2층 설계 개념어(DisplayName 아님)라 C22 통일 대상 외·유지 / `Captures/p3a_attack_shop.png`(C14-7 검증 스샷) 미추적 잔존 — rm hook 차단 자동삭제 불가·GodDem `.gitignore Captures/` 추가 검토 후속 - **후속 병렬 착수**: ①balance-designer P3-B1 레벨+승급 수치 설계(영웅레벨 hero_level 곡선·승급 레벨캡+3스탯·매판 베이스 결합·hero_star 레벨캡 재추출 표시, 진행중) ②system-designer 메타문서 갱신(ele ④→⑤·가챠 4종, SendMessage 재개, 진행중) - **잔여 소건**: GodDem `.gitignore`에 `Captures/` 추가(개발팀장 후속·스크린샷 레포 유입 방지) + +## 29. P3-B1 영웅레벨+승급 수치 설계 — 완료 + plan-auditor 조건부통과 반영 (balance-designer, GodDem 수정 0건) + +- **PD 승인 원문(2026-08-22)**: "설계대로 진행" — 메타아키텍처 v1 골격에 대한 승인. §28 병렬 착수분(①balance-designer P3-B1) 완결. +- **산출물**: `공유/기획/GodDem/2026-08-22_P3B1_레벨승급_설계_v1.md`. 영웅레벨(Layer①) 1~60·승급(Layer②) star0~11 실수치 전량 확정 + `FinalAttack()`/`FinalHp()` 결합식 + defense 클램프 곱연산 분리식(메타v1 R-B2 해소) + CSV 스키마 실값. +- **실측 신규 발견(C39·C3)**: 런 종료 시 인게임 골드→영구 `GOLD_ID` 전환 브릿지가 **현재 존재하지 않음**(`CurrencyManager.Add` 호출 0건). `TotalGoldEarned` 필드+`SurvivalBattleManager.Restart()` 단일 choke point 전환(제안 100%)을 P3-B1 구현 선행 필수 항목으로 신설 설계. +- **plan-auditor 모드A 감사**: 조건부통과(Critical 1·Major 4·Minor 3) — 산술은 전량 무오류 확인. Critical(런 종료 경로가 `OnDefeatContinue()` 1개가 아니라 `OnPauseRestart()`도 `M.Restart()` 호출하는 2개 — choke point를 `Restart()` 자체로 재배치) + Major(활성스킬 증폭 배율 재계산 80.9→83.6배·94.6→103.7배 정정, 승급 quality=1 채택 근거 재작성, 메타v1 "상한 없음" 명시 방향과의 반전 미고지 시정, 보상팝업 표기 불일치 명시) + Minor 3건 — 전부 v1 내 반영 완료(재작업 없음). +- **기각안 6건(공란 금지, C32 필수 필드)**: ①Promotion 다중 quality(히어로 희귀도) 도입 — 히어로 1명 고정, 근거 데이터 없음 ②HeroLevel 150레벨 원본 그대로 — 규모·데이터(hero_level엔 스탯 분해식 자체 없음) 양쪽 불가 ③승급 보너스도 quality=1 그대로(최대 2.2%) — 체감 무의미, §7 클램프 검증 목표(22%) 역산 채택 ④신규 전용 중간재("영웅 증표") 도입 — 메타v1 디폴트 권고(기존 골드 재사용) 존중+C50 범위 확대 방지 ⑤승급 게이팅 제거·완전 자유 성장 — 원작 "승급=레벨캡 게이팅" 원칙·메타v1 확정 방향 위반 ⑥HeroLevel·Promotion 상한 없이 설계(원작처럼 무한) — CSV 구조상 실제 구현 불가(원작도 실제론 150 유한), 유한 캡 채택하되 메타v1 "상한 없음" 명시와의 반전을 §0에 은폐 없이 고지. +- **미해결·후속 필요(C36 경계, 본 문서 범위 밖)**: ①HeroLevel 유한 캡 도입이 메타v1 §1-1 "상한 없음" 방향과 다름 — system-designer·PD 인지 필요 ②맥스 밴드(FinalAttack 230.6) 도달 시 인게임 초반 웨이브 무위협 가속(S3 v2 R-J 심화) — 스테이지(P3-C) 설계 시 검토 ③`hero_star.csv` star=28~30 레벨캡 불일치 재추출(차단 조건 아님, 향후 캡 확장 대비) ④Victory/Defeat 팝업 보상 표기(`M.Gold`) ↔ 실제 전환값(`TotalGoldEarned`) 불일치 — ux-designer·클라이언트팀 협의. +- **후속 순서**: 기획팀장 검증(C49) 재상정 → 개발팀장 구현(전환 브릿지+`FinalAttack()`/`FinalHp()`+defense 결합식, §14 선행 목록) → P3-B2(장비강화, `heroequipment` M수열 재대조 선행). + +## 30. B1 검증·발견 정리 + PD 확인 대기 (PM, 2026-08-22) + +- **B1 설계 = plan-auditor 모드A 조건부통과** (Critical 1·Major 4·Minor 3 반영·산술 무오류). 영웅레벨 1~60(공2L/체8L 4:1·비용 0.2L³+1.8L² 원작×0.4)·승급 star0~11(레벨캡 5×(star+1)·+2%/star)·매판 시작 베이스 FinalAttack/FinalHp 캡슐화(신규유저 22/400 불변·맥스밴드 230.6/1445.7)·defense 곱연산 분리클램프(84.4% 미도달). balance-designer 팀원 설계→plan-auditor 검증 = C49 충족 +- **메타문서 갱신 완료**(system-designer, 14 edit): ele ④→⑤ 확정·가챠 4종 축소·정직 한계 통일. GodDem 무접촉 +- **★ PD 확인 필요 발견 3건 (구현 착수 전 정리)**: + 1. **전환 브릿지 부재** — 런 종료 시 인게임 골드를 아웃게임 영구 재화로 넘기는 경로가 **없음**(`CurrencyManager.Add` 호출 0건). 즉 현재는 판이 끝나면 번 골드가 사라짐 → **영구 성장의 근본 전제가 미구현**. B1 구현 최우선 선행 필수 + 2. **C36 경계 — 유한 캡 vs 상한 없음**: balance-designer 유한 캡(레벨60·승급11, 원작 hero_level 150·hero_star 유한 정합)과 메타아키텍처 §1-1 "상한 없음" 방향 불일치. 원작이 유한이라 유한 캡이 원작 정합이나 PD 인지·확정 필요 + 3. **맥스밴드 R-J 심화** — 아웃게임 풀성장 시 초반 웨이브 무위협 심화(P3-C 스테이지 설계 영역, 문제 제기) +- **PM 판정**: 발견 1·2가 게임 근본 구조·방향이라 개발팀장 구현 착수 전 PD 보고·확인. 대규모 다단계 진행 중 근본 사안이라 체크포인트