BurningTimesAi/공유/기획/GodDem/2026-08-22_P3B3_가챠_설계_v1.md

458 lines
41 KiB
Markdown
Raw Permalink Normal View History

# GodDem 가챠(아웃게임 Layer④) 수치 설계 v1
> 🔴 **본 문서는 v2·v3로 대체됨(2026-08-23, N-8 반영·예외적 v1 수정 허가)** — §4-4(아이템 스탯)·§7(젬가)·§10-3(Pity CSV)·§8-2(경제 프레이밍 주장) **전부 폐기**. 구현·참조는 반드시 최신본 `2026-08-22_P3B3_가챠_설계_v3.md`(또는 그 후속) 사용. 본 문서는 역사 보존 목적으로만 유지.
> **작성**: balance-designer(기획팀) 2026-08-22 · **P3-B3 산출물**(P32 맥락 분할 · C50 규모 "중~대")
> **PD 승인 원문 (C42-2 A, 2026-08-22)**: "기존 원작의 로직을 살펴보고 동일하게 맞춰. **인게임 내 뽑기는 일반 골드를 쓰며 특정 시점에만 유료 재화를 쓰는 구조**야. 제대로 실측해서 구현해야 해."
> **선행 문서(전부 Read 완료, C39)**: [`2026-08-22_원작가챠_재추출_원본_v1.md`](./2026-08-22_원작가챠_재추출_원본_v1.md)(재추출v1, 가챠 핵심 SOT) · [`2026-08-22_메타아키텍처_재설계_v1.md`](./2026-08-22_메타아키텍처_재설계_v1.md)(메타v1, §1-4·§5) · [`2026-08-22_원작배율_재추출_원본_v1.md`](./2026-08-22_원작배율_재추출_원본_v1.md)(배율재추출v1, §2-2 B-템플릿) · `2026-08-22_P3B1_레벨승급_설계_v1.md`(B1, 골드 경제 앵커) · `2026-08-22_P3B2_장비강화_설계_v2.md`(B2, §8 forging/reforging 골격·등급 체계 선행 확정) · `2026-08-22_P3B4_스킬마스터리_설계_v1.md`(B4, 골드 경제 앵커) · `2026-08-22_P3C_스테이지_설계_v2.md`(C, 런 완주 총 골드)
> **절대 제약**: GodDem 레포(`E:\NerdNavis\GodDem`) Read만 수행, 수정 0건. Unity MCP 미사용. 본 문서가 유일 산출물. **BT 레포 커밋 금지**(팀장·PM 영역).
> **표기 규칙(C5·C44)**: 🟢확정(원작 실측 또는 GodDem 코드 직접 확인) · 🟡추정(구조적 근거 있으나 원본 미확보) · 🔴미확정/PD 확인 필요
---
## 0. 결론 요약
메타v1이 골격만 정의하고 유보한 4건을 본 문서에서 확정한다.
| 유보 사항(출처) | 본 문서 결정 |
|---|---|
| 메타v1 §1-4 "소비 재화 🔴 미확보, PD 이관" | **골드(1차, GOLD_ID=201) + 젬(2차 대체, GEM_ID=101 기존) 이원 결제**(재추출v1 §7-1 그대로 채택, §2) |
| 메타v1 §1-4 "천장 2단, 히어로 표준 vs 열쇠형 중 balance-designer 결정" | **열쇠형(소프트 4회·하드 40회) 채택** — 히어로 표준(10/30)·장비형(62/100) 기각(§3, 사유 상세) |
| B2 §8 "6등급 체계·forging·reforging 골격만, 실채택은 B3 판단" | **Grade 3~6 신규 도입**(기존 Grade1~2=상점 전용과 역할 분리, R-B5 해소) — forging/reforging은 B2가 이미 가격을 매긴 골격을 **참조만 하고 본 문서 범위에서 활성화하지 않음**(§4, 후속 조치) |
| 메타v1 §1-4 "옵션 4종(hit/stun/retaliate/combo) 확정, 값은 TBD" | **원작 B-템플릿 그대로 채택**(200/400/800/1600, GodDem `BasisPoint` 컨버전으로 2%/4%/8%/16%) — 재계수화 불요(§6) |
**실측 중 신규 발견(C39·C3, 은폐하지 않음) — 옵션 4종 전투 소비처 부재**: `hit_rate`·`stun_rate`·`retaliate_rate`·`combo_rate` 문자열을 GodDem 전체 코드베이스에서 검색한 결과 **`SurvivalStatCatalog.cs`(정의부) 외 어디에도 등장하지 않는다**(🟢 실측). B4가 발견한 `ele_*`/`penetrate_ratio`(정의된 스탯인데 소비 코드 없음) 문제와 같은 계열이나, 이번은 **성격이 다르다**`ele_*`는 기존 "비율 항"에 잠정 합산이라도 가능했지만, `stun_rate`(기절)·`retaliate_rate`(반격)·`combo_rate`(연격)는 **전투에 존재하지 않는 새 이벤트 트리거**(상태이상·카운터·추가타)라 잠정 배선할 기존 항 자체가 없다. `hit_rate`(명중)만 기존 `dodge_rate`(회피, 인게임)와 대칭 개념이라 상쇄 로직이 있다면 연결 가능성이 있으나 이 역시 미확인이다. **본 문서는 옵션 4종의 획득(가챠 드롭)·저장까지만 완결하며, 전투 발동 로직 신설은 개발팀 후속 범위로 명시한다**(§13 PD 확인·§15 리스크 R-H1).
---
## 1. 설계 전제
| 항목 | 값 |
|---|---|
| 기준 플레이어 수준 | 신규(가챠 미보유) ~ 장기(하드천장 다회 도달, Grade6 다수 보유) |
| 목표 경험 | "이번엔 뭐가 나올까"라는 확률 기대감을 로그라이크 매판 루프 위에 얹는 신규 재미축(메타v1 §1-4 P30 근거) — 실패해도 등급 하위 결과가 아예 배제되는 원작 안전판 구조 계승 |
| 전제 스탯 앵커 | 상점(Grade1~2, id1~9) 무변경 유지. 가챠는 Grade3~6 **신규** 아이템 6종 도입(§4) |
| 전제 경제 앵커 | 인게임 20웨이브(2스테이지) 보수적 하한 2,542G(S3 v2·B1 §1 재사용) / 54스테이지 런완주 414,018G(C v2 §5-2) / B1+B2+B4 총 투자 1,942,464G(C v2 §0 대조치) |
| 재화 | **골드(GOLD_ID=201, 1차)** + **젬(GEM_ID=101, 2차 대체, 기존 상점에 이미 통용 중)** — 신규 재화 도입 없음 |
| C39 실측 확증 | `Constant.cs`(GOLD_ID=201/GEM_ID=101) · `SurvivalItemCatalog.cs`(전문, 9종 Grade1~2·FuseTargetId·SecondaryStatKey) · `SurvivalShopCatalog.cs`(전문, 젬/골드 상점 가격·신규유저 시작 젬 300 확인처) · `SurvivalMeta.cs`(전문, `FinalAttack()`/`FinalHp()`/`Version=4`/`EquipLevel`/`SkillMasteryLevel` 라이브 구현) · `SurvivalStatCatalog.cs`(전문, `hit_rate`·`stun_rate`·`retaliate_rate`·`combo_rate` = `Kind.BasisPoint` 확인) · `SurvivalUpgrade.cs`(`ValueType.BasisPoint` → `Value/10000f` 컨버전 공식 확인) · `PlayerManager.cs`(L75, 신규유저 젬 300 지급 확인) · 코드베이스 전체 `hit_rate`/`stun_rate`/`retaliate_rate`/`combo_rate` grep(정의부 1곳 외 소비 코드 0건 확인) |
---
## 2. 재화 매핑 — 원작 구조 요약 + GodDem 결정표
### 2-1. 원작 이원 결제 구조 (재추출v1 §3 요약)
원작 `drawtype`은 뽑기 1회당 **두 결제 라인을 동시에 정의**한다(순차 소진이 아니라 "티켓으로 낼래, 젬으로 낼래"의 병렬 옵션) — `drawitem`(1차, 획득형 티켓) / `drawitem2`(대체, 젬 `hb_2001`). GodDem은 소환권 같은 별도 "티켓" 재화가 없고 골드가 유일한 플레이 획득 재화이므로, **원작 티켓 = GodDem 골드**로 직번역하면 이 병렬-옵션 구조가 "골드로 낼래, 젬으로 낼래"로 그대로 이식된다. 이것이 PD 지시("일반은 골드, 특정 시점만 유료")의 정확한 데이터 구현이다(재추출v1 §7-1, 이미 승인된 인계 방향).
### 2-2. GodDem 매핑 결정표
| 원작 요소 | 원작 값(참고) | GodDem 매핑 | 표기 |
|---|---|---|---|
| 소환권(`dj_7001/7002`)·보물열쇠(`dj_7011`) | 1차 결제(획득형) | **골드(GOLD_ID=201) 직접 소비** | 🟢 구조 · 🟡 절대값(§5) |
| 젬(`hb_2001`) | 대체 결제(프리미엄) | **젬(GEM_ID=101, 기존 재화 재사용)** | 🟢 구조 · 🟡 절대값(§5) |
| 일일 무료(206·1402·5101) | 무과금 창구 | **일일 무료 5회, 300초 쿨다운**(원작 206 그대로 포팅, 시간값은 재화 아니므로 재조정 불요) | 🟢 |
| 히어로 조각(`dj_5XXX`) 결과물 | 수집형 캐릭터 조각 | **해당 없음** — GodDem은 히어로 1명 구조(메타v1 §1-4·§7-3, 이미 확정) | — |
| 장비/재료(`sl_XXXX`+`dj_6XXX`) 결과물 | 장비+옵션 | **SurvivalItemCatalog 신규 아이템(Grade3~6) + 옵션 4종**(§4·§6) | 🟢 구조 · 🟡 절대값 |
---
## 3. ★ 천장 스케줄 결정 — 3안 비교·채택·기각 (PM 재검토 지시 반영)
메타v1 §1-4·재추출v1 §5-2는 원작에 **3개 서로 다른 천장 스케줄 계열**이 존재함을 확인했다. 최초 검토에서 "히어로 표준(10/30)"을 1차 후보로 실었으나, **결과물 유형 대응이 어긋난다는 지적(PM 보강 지시)에 따라 3안을 정식으로 비교·재확정**한다.
### 3-1. 3안 비교표
| 안 | drawtype 원본 | 소프트/하드 | 결제구조 | 결과물(원작) | GodDem 결과물 대응 |
|---|---|---|---|---|---|
| **A. 히어로 표준** | 102·1701·7·18·29 | 10회 / 30회 | 이원(티켓+젬) | 히어로 조각(`dj_5XXX`, 수집형) | ❌ 불일치 — GodDem은 히어로 1명, 조각 수집 없음 |
| **B. 열쇠형** | 1301·217 | 4회 / 40회 | 이원(**보물열쇠**+젬) | 장비+재료(`sl_XXXX`) | ✅ 일치 — `dj_7011` 자체가 재화정체표(재추출v1 §2)에서 **"장비 뽑기 티켓"으로 명시 라벨링** |
| **C. 장비형** | 209·212·214·206 | 62회 / 100회 | **젬 단일**(티켓/골드 경로 없음) | 장비+재료(`sl_XXXX`) | ❌ 불일치 — PD "일반은 골드" 지시와 결제구조 자체가 배치 |
### 3-2. 채택 — B. 열쇠형(소프트 4회 · 하드 40회)
**결정 근거 3축**:
1. **데이터 대응 정확성(C44 최우선)**: 재추출v1 §2 재화 정체표가 `dj_7011`(보물열쇠)를 명시적으로 "**장비 뽑기 티켓**"이라 라벨링했다 — 이는 추정이 아니라 원작 아이콘·용도 3중 교차로 확정된 원문 근거다(재추출v1 §2 각주). GodDem 가챠 결과물이 히어로 조각이 아니라 장비+옵션이므로(메타v1 §1-4 기확정), 원작에서 "장비"를 내주는 뽑기 라인의 천장을 그대로 쓰는 것이 데이터 대응상 가장 정확하다.
2. **결제구조 정합**: 열쇠형은 이원 결제(열쇠 1차·젬 대체)로 PD 지시("일반 골드+특정 시점 유료")와 정확히 일치한다. 장비형(C안)은 젬 단일이라 이 조건 자체를 만족 못 해 원천 배제된다.
3. **P30 재미 근거와의 정합**: 소프트천장 4회는 신규 유저가 **거의 즉시**(가입 첫 세션 내) "어, 벌써 희귀템이 나올 수도 있네"를 체감하게 한다 — 이는 메타v1 §1-4가 명시한 "이번엔 뭐가 나올까" 기대감 재미축을 초반부터 강하게 건다. 하드천장 40회는 히어로 표준(30회)보다 길어 "영구 성장 5층의 마지막 층"이라는 위상에 맞는 장기 목표로 기능한다(§8 경제 시뮬레이션에서 수치 근거 확인).
### 3-3. 기각안 (C32 필수 필드)
| 기각안 | 기각 사유 |
|---|---|
| **A. 히어로 표준(10/30) 채택** | 원작에서 이 스케줄이 딸린 결과물은 히어로 조각(수집형)이며 GodDem은 히어로 1명 구조라 결과물 유형 자체가 대응하지 않는다(§3-1). 단, 히어로 단차(drawtype 102)는 재추출v1 §4·§5-1이 **유일하게 풀 가중치를 전량 실측**한 계열이라(16pos/9500, 23pos/7747, 7pos/499) 열쇠형 자체의 풀 가중치 원본이 없는 본 설계에서 **가중치 "형태"(등급별 상대 비중 패턴)만 참고용으로 차용**했다(§6, 🟡 표기) — 스케줄(카덴스)은 기각, 형태(비중 곡선)는 부분 채용이라는 점을 분리해 명시한다. |
| **C. 장비형(62/100) 채택** | 결제구조가 젬 단일이라 PD 지시("일반 뽑기는 골드")의 이원결제 조건 자체를 충족하지 못한다. 스케줄 값(장주기)은 참고했으나 채택 전제(결제구조)가 어긋나 전체 기각. |
| 열쇠형 자체 풀 가중치 원본 재추출 선행 후 본 설계 착수 | C50(과도 토큰) 위반 소지 — 재추출은 개발팀장 영역(APK 재복호화)이며 이미 3회(배율·장비·스테이지·가챠) 수행됐다. 히어로 단차 가중치 형태 차용 + GodDem 자체 정합화로 충분히 신뢰 가능한 설계가 가능해 재추출 재요청 대신 🟡 표기로 정직하게 진행한다(C5). |
---
## 4. 등급 체계 확정 — Grade 3~6 신규 도입
### 4-1. 배경 — B2가 남긴 미해결 축
B2 §8은 forging(등급 도박)·reforging(옵션 리롤)·옵션 슬롯 수(§8-4, `max(1,q-1)`) 골격값을 **이미 가격까지 매겨뒀으나 "실채택은 B3 판단"으로 유보**했다. 이는 B2 스스로 "GodDem 현재 Grade 1~2뿐이라 이 표는 참고자료"라 명시한 대로, **가챠가 Grade3+ 를 실제로 게임에 들여오기 전까지는 의미가 생기지 않는 골격**이었기 때문이다. 본 절에서 이 축을 완성한다.
### 4-2. 결정 — Grade1~2(상점 전용) / Grade3~6(가챠 전용) 역할 분리
메타v1 R-B5("가챠·상점 중복 판매 시 상점 가치 희석 — 상점=저확정 티어, 가챠=고티어+옵션 역할 분리 권고")를 그대로 실행한다.
- **기존 Grade1~2(id1~9)**: 무변경. 상점에서만 계속 판매(젬 12~50 직접구매, §5-2 실측).
- **신규 Grade3~6**: 가챠 전용 아이템 6종 신규 도입(§4-4 카탈로그). 상점 판매 없음.
- 등급 대응은 원작 quality q1~q6 중 **q3~q6 슬라이스**를 그대로 쓴다 — GodDem Grade1=원작q1, Grade2=원작q2(이미 상점이 점유)이므로, 가챠가 원작 q3~q6을 Grade3~6으로 잇는 것이 원작의 6단 등급 사다리를 끊지 않고 자연스럽게 잇는 유일한 방법이다. B2 §8-1 forging 표가 이미 "q2→q3→q4→q5→q6"로 **Grade2를 시작점으로 잡아뒀다**는 사실이 이 매핑이 우연이 아니라 B2 설계 시점부터 전제된 것임을 보여준다.
### 4-3. Forging·Reforging — 참조만, 본 문서 범위에서 비활성
B2 §8-1(forging 성공률·비용)·§8-3(reforging 잠금 비용)·§8-4(옵션 슬롯 수)는 **이미 확정된 골격값**이며 본 문서가 재도출하지 않는다(C10 중복 작업 방지). 다만 forging/reforging을 "지금 게임에 넣을지"는 **본 문서 범위 밖으로 명시 유보**한다 — 사유:
1. forging의 "재료"(B2 표의 원작 `dj_6003`/`dj_6004` 대응 GodDem 자원)가 아직 정의되지 않았다. 신규 자원 도입은 그 자체로 별도 설계 결정이며 본 문서(가챠 확률·비용) 범위를 벗어난다.
2. 가챠 자체만으로 Grade3~6 아이템을 직접 획득 가능하므로(§6 풀 구성), forging은 "필수 경로"가 아니라 "대체 경로"다 — 5층 완성(가챠 도입)이 선행 목표이고 forging 활성화는 후속 확장으로 미뤄도 게임 진행에 공백이 생기지 않는다.
3. §8-4 옵션 슬롯 수(q3=2·q4=3·q5=4·q6=5)는 **가챠 드롭 아이템에는 즉시 적용**한다(§6-3) — 이 표가 가챠와 무관한 부분(forging 재료)만 유보 대상이다.
**옵션 슬롯 수 표(B2 §8-4 그대로 인용)**:
| Grade | 3 | 4 | 5 | 6 |
|---|---|---|---|---|
| 슬롯 수 | 2 | 3 | 4 | 5 |
Grade6의 5슬롯은 옵션 종류(4종)보다 많다 — **5번째 슬롯은 이미 보유한 4종 중 하나를 중복 재추첨**해 해당 스탯을 두 겹 적용한다(중복 스택 허용, §6-4 상세).
### 4-4. 신규 아이템 카탈로그 (Grade3~6, 6종)
가챠 전용 신규 아이템의 기본 Attack/Hp 값이다. **content-designer 영역인 정식 이름·아트는 배정하지 않고 가칭으로 표기**한다(B4가 "카드ID 미배정"으로 처리한 것과 동일 원칙) — 수치도 기존 Grade1~2 앵커(`SurvivalItemCatalog.cs` 실측)에 등급당 약 ×1.6배(B2 §6 성장곡선이 쓴 것과 같은 계열의 기하 감각을 차용, 정밀 역산 아님)를 적용한 **1차 초안**이며, B1·B2의 공식 기반 수치와 달리 **정밀 도출식 없이 플레이테스트 전 안전판으로 제시**한다(🟡, C5 정직 표기 — "첫 숫자는 틀릴 것" 원칙 명시 적용).
| ItemId | 이름(가칭) | 슬롯 | Grade | Attack | Hp | FuseTargetId | SecondaryStatKey | 앵커 근거 |
|---|---|---|---|---|---|---|---|---|
| 10 | 벼려진 단검 | Weapon | 3 | 22 | 0 | 0 | `equip_attack_speed_add` | id2(Weapon G2=14atk) ×1.6 |
| 11 | 강화 판금갑 | Armor | 3 | 0 | 230 | 0 | `equip_defense_add` | id3(Armor G1=90hp) ×2.5(G1→G3, G2 앵커 부재로 2단 압축) |
| 12 | 서릿발 대검 | Weapon | 4 | 35 | 0 | 0 | `equip_attack_speed_add` | id10(신규 G3=22atk) ×1.6 |
| 13 | 용비늘 흉갑 | Armor | 4 | 0 | 370 | 0 | `equip_defense_add` | id11(신규 G3=230hp) ×1.6 |
| 14 | 고대의 유물 | Charm | 5 | 25 | 300 | 0 | `equip_defense_add` | id9(Charm G2=10atk/120hp) 하이브리드 확장, 공/체 동시 배분 |
| 15 | 천계의 인장 | Ring | 6 | 55 | 0 | 0 | `equip_attack_speed_add` | id8(Ring G2=20atk) ×1.6³(G2→G6 3단) |
**FuseTargetId=0(전항)**: 기존 아이템(id1·4·7)의 3개→1개 합성 체인과 달리, 가챠 아이템은 중복 처리를 §6-4의 "옵션 슬롯 무료 재추첨"으로 대체한다 — 옵션이 랜덤인 아이템을 합성하면 "어느 개체의 옵션이 살아남는가"라는 별도 규칙이 필요해지므로(§15 기각안 미포함 — 애초에 검토했으나 §6-4가 더 단순해 합성 자체를 시도하지 않음), 합성 체인을 만들지 않는 쪽을 채택했다.
---
## 5. 공식 — 뽑기 비용
### 5-1. 골드 단가 도출 (🟡 신규 도출, 근거 명시)
젬 단가는 원작 열쇠/히어로 계열의 실측값(재추출v1 §3-2 "단차 1티켓 ≈ 20젬")을 **그대로 포팅**한다 — 젬(GEM_ID=101)은 B1~B4 어느 층에서도 재조정된 적 없는 처녀 재화라 원작 절대값을 재계수화 없이 직접 재사용할 수 있다(공격력·골드처럼 GodDem 스케일 재산정이 필요했던 트랙과 다름).
골드 단가는 **GodDem 자체 상점의 기존 골드↔젬 교환비**(`SurvivalShopCatalog.cs` 실측: 600골드=30젬 → 20골드/젬)를 가교로 역산한다:
```
1회 뽑기 젬가 = 20젬 (원작 §3-2 그대로 포팅)
1회 뽑기 골드가 = 20젬 × 20골드/젬 = 400골드 (GodDem 기존 상점 SOT로 환산)
```
이 방식은 (a) 젬 절대값은 원작 그대로, (b) 골드 절대값은 GodDem 자체에서 이미 검증된 교환비로 도출 — 두 재화 모두 "근거 없이 정하지 않는다" 원칙을 만족한다.
### 5-2. 10연·100연 배율 (원작 그대로 포팅)
원작 데이터 포인트 2건을 그대로 적용한다: 10연은 할인 없음(장비 212 = 10×20젬 = 200젬, 배율 정확히 10배), 100연은 10% 할인(1800/2000 = 0.9).
```
10연 비용 = 단가 × 10 (할인 없음, 원작 212 정합)
100연 비용 = 단가 × 100 × 0.9 (10% 할인, 원작 209/7/18/29 정합)
```
---
## 6. 풀 구성·확률표
### 6-1. 3단 풀 가중치 (등급별, 각 풀 합계 10000 basis point — 메타v1 §1-4 강제 원칙)
풀 형태(비중 곡선)는 §3-3 기각안 표에서 밝힌 대로 **원작 히어로 단차(drawtype 102) 실측 비중**(재추출v1 §4·§5-1)의 "형태"를 차용해 GodDem 4등급(Grade3~6)에 재정합한 값이다(🟡 — 열쇠형 자체 가중치 원본은 미보유, §3-3 기각안).
**Pool1(일반, 1~3회차 — 소프트천장 미도달 구간)**
4항목 균등(2500씩)이 아니라 Grade3:Grade4 = 60:40으로 편중했다 — 원작 pool1 실측(재추출v1 §4)의 q3:q4 개별 weight 비율(375:250 = 3:2)을 그대로 가져온 값이며, 동시에 신규유저 초반 "손맛"(저등급 다수 노출)에도 부합한다. Grade3는 아이템 2종에 개별 3000씩(등급 합계 6000), Grade4는 2종에 개별 2000씩(등급 합계 4000), 총합 10000.
| PoolId | ItemId | Grade | Weight | 확률 |
|---|---|---|---|---|
| 1 | 10 | 3 | 3000 | 30.00% |
| 1 | 11 | 3 | 3000 | 30.00% |
| 1 | 12 | 4 | 2000 | 20.00% |
| 1 | 13 | 4 | 2000 | 20.00% |
| | | (Grade5·6 weight 0, 미등장) | | |
| | | **합계** | **10000** | **100%** |
**Pool2(소프트천장 이후, 4~39회차 — Grade5·6 개방)**
| PoolId | ItemId | Grade | Weight | 확률 |
|---|---|---|---|---|
| 2 | 10 | 3 | 2805 | 28.05% |
| 2 | 11 | 3 | 2805 | 28.05% |
| 2 | 12 | 4 | 1870 | 18.70% |
| 2 | 13 | 4 | 1870 | 18.70% |
| 2 | 14 | 5 | 500 | 5.00% |
| 2 | 15 | 6 | 150 | 1.50% |
| | | **합계** | **10000** | **100%** |
도출: 원작 소프트천장 비중 패턴("q1~q4 유지 + q5 4종×1.291%(합5.164%)+q6 3종×0.426%(합1.278%)" → 희귀 합 약 6.4%)을 재정합 — GodDem은 Grade5·6 각 1종뿐이라 원작의 "6.4% 희귀 합"을 5.0%(Grade5)+1.5%(Grade6)=6.5%로 근사 재현했다. 잔여 93.5%를 Pool1의 Grade3:Grade4=3:2 비율 그대로 유지해 재분배(935 단위, Grade3 935×3=2805, Grade4 935×2=1870).
**Pool3(하드천장, 40회차 이상 — 100% Grade5+ 확정)**
| PoolId | ItemId | Grade | Weight | 확률 |
|---|---|---|---|---|
| 3 | 14 | 5 | 8000 | 80.00% |
| 3 | 15 | 6 | 2000 | 20.00% |
| | | **합계** | **10000** | **100%** |
도출: 원작 하드천장 비율(q5 80.16% : q6 19.84%, 재추출v1 §5-1)을 반올림 그대로 재현(80:20) — Grade3·4 weight는 0으로 죽여 저등급 완전 배제(원작 "라이브러리 교체=테이블 스왑" 방식 그대로, 재추출v1 §5).
### 6-2. 천장 카운터 및 리셋 규칙
- `SurvivalMetaData.GachaPityCount`(메타v1 §5-1 기존 스텁, int) — 뽑기 1회당 +1.
- **Grade5 또는 Grade6 결과 획득 시 0으로 리셋**(🟡 표준 가챠 관행 적용 — 원작 데이터가 리셋 시점을 명문화하지 않아 장르 관행으로 보충, §3 기각안과 별개의 독립 추정치이므로 별도 표기).
- 카운터 값에 따라 활성 Pool 결정: `count < 3` → Pool1, `3 ≤ count < 39` → Pool2, `count ≥ 39` → Pool3 (0-index 기준, "4회차"="count=3에서 뽑는 순간" 매핑 — 원작 `libidNneed`의 "need값 도달 후 다음 회차부터 스왑" 컨벤션과 동일 오프셋).
### 6-3. 옵션(hit/stun/retaliate/combo) 값 테이블
원작 B-템플릿(배율재추출v1 §2-2, 확률계 ×2등비 `50/100/200/400/800/1600`)의 **q3~q6 슬라이스**(`200/400/800/1600`)를 재계수화 없이 그대로 사용한다 — `SurvivalStatCatalog.cs`가 이미 이 4종을 `ValueType.BasisPoint`로 선언했고, `SurvivalUpgradeTable.Entry.Applied``Value/10000f`로 자동 환산하므로(🟢 코드 확인, §1) 원작 raw값을 그대로 CSV에 넣기만 하면 별도 변환 없이 올바른 %가 나온다.
| Grade | s_StatKey 후보(4종 중 1개 랜덤) | n_Value(raw) | 환산(Applied) |
|---|---|---|---|
| 3 | gacha_hit_rate / gacha_stun_rate / gacha_retaliate_rate / gacha_combo_rate | 200 | 2.00% |
| 4 | 〃 | 400 | 4.00% |
| 5 | 〃 | 800 | 8.00% |
| 6 | 〃 | 1600 | 16.00% |
### 6-4. 옵션 슬롯 채우기 규칙
아이템 획득 시 Grade별 슬롯 수(§4-3 표)만큼 옵션을 **비복원 추출**로 채운다(4종 중 슬롯 수만큼 서로 다른 스탯). 단 Grade6(5슬롯 > 4종)은 4종을 전부 채운 뒤 5번째 슬롯에 한해 **1종을 재추첨해 중복 허용**(중복된 스탯은 값이 합산 적용, 예: `combo_rate` 슬롯 2개 = 16%+16%=32% 누적).
**중복 재획득(뽑기 결과가 이미 보유한 ItemId) 처리**: 해당 아이템의 슬롯 1개를 무작위로 골라 옵션을 무료 재추첨한다(같은 Grade 내에서만, 값 범위는 §6-3 표 그대로). 이는 원작에 없는 GodDem 자체 보완 설계다(🟡, 표준 F2P 관행 — "중복 뽑기가 완전히 무가치하지 않도록" 설계, 근거: P30 재미 원칙 "실패해도 손해는 아니다"를 중복 상황까지 확장 적용).
---
## 7. 뽑기 상품 구성 (수치 테이블)
| 상품 | 골드가 | 젬가 | 비고 |
|---|---|---|---|
| 단차(1회) | 400G | 20젬 | §5-1 도출 |
| 10연(10회) | 4,000G | 200젬 | 할인 없음(원작 212 정합) |
| 100연(100회) | 36,000G | 1,800젬 | 10% 할인(원작 209/7/18/29 정합) |
| 일일 무료 | 0 | 0 | 1일 5회, 300초 쿨다운(원작 206 그대로) |
**세그먼트 영향**:
- **무과금**: 일일 무료 5회(쿨다운 300초 간격으로 하루 25분 내 전부 소진 가능) + 플레이로 번 골드로 단차/10연 추가 구매. 하드천장(40회)까지 무료만으로는 8일 소요(5회×8일=40회) — 장기 목표로 적절한 페이스.
- **소과금**: 골드팩(기존 상점 SOT, 예: 12000골드=600젬)으로 골드 보충해 뽑기 빈도 상승. 별도 신규 과금 경로 불요(기존 상점 재사용).
- **고과금**: 100연 젬 직접 구매(1800젬, 기존 상점 최고가 팩 15000젬의 12%)로 즉시 하드천장 2.5회 도달 가능 — "시간 단축" 표준 F2P 구조(B1 §2-3이 이미 인정한 패턴과 동일선상).
---
## 8. 경제 시뮬레이션
### 8-1. 런 시나리오별 뽑기 가능 횟수 (B1 §6 3단 시나리오 재사용)
| 시나리오 | 런당 골드 | 뽑기 가능 횟수(400G 기준) | 소프트천장(4회) 도달 | 하드천장(40회) 도달 |
|---|---|---|---|---|
| 보수적 하한(2스테이지) | 2,542G | 6.36회 | 1런 이내 | 6.3런 |
| 중간 참고(5스테이지) | 8,200G | 20.5회 | 1런 이내 | 2.0런 |
| 낙관적 참고(10스테이지) | 22,550G | 56.4회 | 1런 이내 | 1런 이내 |
**해석**: 소프트천장(4회)은 **모든 시나리오에서 1런 이내 도달** — Grade5·6 가능성을 매 런마다 사실상 열어준다는 점이 §3-2가 근거로 든 "즉각적 기대감" 설계 의도와 정확히 일치한다. 하드천장(40회)은 실력·시나리오에 따라 1~6.3런 폭 — B1의 레벨캡 도달 폭(48~416런)보다 훨씬 좁다. 이는 결함이 아니라 **가챠가 B1/B2/B4보다 저비용·고빈도 사이클로 설계된 결과**이며, 메타v1 §1-4가 규정한 가챠의 역할("확률 기대감 재미축")과 B1~B4의 역할("장기 성장 목표")이 서로 다른 페이스여야 한다는 설계 의도에 부합한다.
### 8-2. 총 경제 대조
| 항목 | 총액 | 가챠 100연 대비 비율 |
|---|---|---|
| B1(레벨+승급) 총투자 | 1,056,056G | 29.3회분 |
| B2(장비강화 9종) 총투자 | 510,496G | 14.2회분 |
| B4(스킬마스터리 3종+언락20단) 총투자 | 1,766,680G | 49.1회분 |
| **B1+B2+B4 합계** | **3,333,232G**\* | 92.6회분 |
| 54스테이지 런완주 총 골드 | 414,018G | 11.5회분 |
\* C v2 §0의 "1,942,464G"는 B1+B2+B4 중 **실투자 기준**(B2는 9종 중 6종 실투자 359,728G, B4는 마스터리 3종만 526,680G 기준 카드언락 제외)이었다 — 본 표는 **전항목 만렙 기준**(B2 9종 전체 510,496G + B4 마스터리 526,680G + 언락20단 1,240,000G)으로 재계산해 상한선을 제시한다. 실투자 기준 대조치는 C v2 §0 그대로 1,942,464G.
**균형 판정**: 가챠 100연(36,000G)이 B1~B4 전체 투자 총액(1,942,464G~3,333,232G)의 1.1~1.9% 수준 — 가챠는 "5층 중 하나의 큰 목돈 지출"이 아니라 **반복적으로 자주 도는 소액 사이클**로 설계됐다(§8-1과 정합). 총 골드 소모처가 B1·B2·B4(대형 1회성 목표)와 B3(소액 반복)로 성격이 나뉘어 **인플레이션 흡수 창구가 이중화**된다 — 획득 골드가 B1~B4를 다 채운 후에도 가챠가 계속 골드를 흡수하므로 "더 이상 쓸 곳 없는 골드"로 인한 경제 붕괴 리스크가 낮아진다(밸런스 기획자 책임 "인플레이션과 소모처의 균형" 체크 통과).
---
## 9. 매판 시작 베이스 결합
가챠로 획득한 Grade3~6 아이템은 **B2가 이미 구축한 장착·집계 파이프라인을 그대로 재사용**한다 — 별도 `FinalAttack()`/`FinalHp()` 신규 항 불요:
```
SurvivalMeta.TotalAttack() / TotalHp() // 기존 B2 구현, 장착 아이템 순회
└─ SurvivalItemCatalog.All 에 id10~15 추가되는 즉시 자동 편입(코드 변경 없음)
```
**옵션 4종(hit/stun/retaliate/combo)은 별도 집계 경로가 필요하다** — 기존 `TotalAttack()`/`TotalHp()`는 Attack/Hp 필드만 순회하며 옵션 슬롯을 보지 않는다(§9-1 코드 터치포인트에서 신규 메서드 명시).
### 9-1. 코드 터치포인트
| 파일 | 변경 |
|---|---|
| `SurvivalItemCatalog.cs` | `SurvivalItemDef``List<(string statKey, float value)> GachaOptionSlots` 필드 추가(기본 빈 리스트, id1~9 무영향) + id10~15 6종 신규 항목 추가(§4-4 스탯) |
| `SurvivalMeta.cs` | `SurvivalMetaData``int GachaPityCount`(메타v1 §5-1 기존 스텁, 실필드화) + `Dictionary<int,int> GachaOwned`(itemId→보유수, 중복 판정용) + `Dictionary<int, List<(string,float)>> GachaRolledOptions`(itemId→실제 뽑힌 옵션, 슬롯은 카탈로그 정의와 별개로 개별 저장) 3필드 추가, `Version` 4→5 상향 + 마이그레이션 분기(v4 이하 로드 시 3필드 전부 빈 값 초기화) · **신규 메서드**: `TotalOptionValue(string statKey)` — 장착 아이템 전체의 `GachaRolledOptions` 순회 합산(중복 스택 자연 반영) |
| `SurvivalBattleManager.cs` | `RecalcPlayer()``hit_rate`/`stun_rate`/`retaliate_rate`/`combo_rate` 4항 조회 추가 — **단, §0이 밝힌 대로 소비처(전투 발동 로직) 자체가 없어 값 저장·표시까지만 가능, 실제 전투 효과는 개발팀 신규 로직 필요(별도 스코프, §13)** |
| 신규 파일 | `SurvivalGachaTable.cs``SurvivalMetaGachaPool.csv`/`SurvivalMetaGachaOption.csv`/`SurvivalMetaGachaPity.csv` 3종 로드(`SurvivalUpgradeTable.Load()` 헤더 2행 스킵 패턴 복제, 메타v1 §5-3 지정 패턴) |
| `SurvivalShopCatalog.cs` | 무변경(가챠는 별도 UI 진입점, 메타v1 §5-3 "구조 확장 필요"는 신규 가챠 화면 신설로 해소 — 클라이언트팀 협의 대상, 상점 카탈로그 자체는 손대지 않음) |
---
## 10. 데이터 모델 — CSV 스키마 전체
CSV 계약(메타v1 §5-2 준수): 1행 헤더(타입 접두 `n_`/`f_`/`s_`) · 2행 한글 설명(로더 폐기) · 3행부터 데이터.
### 10-1. `SurvivalMetaGachaPool.csv`
```
n_PoolId,n_ItemId,n_Grade,n_Weight
풀번호(1일반/2소프트/3하드),아이템ID,등급,가중치(만분율)
1,10,3,3000
1,11,3,3000
1,12,4,2000
1,13,4,2000
2,10,3,2805
2,11,3,2805
2,12,4,1870
2,13,4,1870
2,14,5,500
2,15,6,150
3,14,5,8000
3,15,6,2000
```
### 10-2. `SurvivalMetaGachaOption.csv`
```
n_OptionId,s_StatKey,n_Grade,f_Value
옵션ID,스탯키(가챠 접두 gacha_),등급,원시값(BasisPoint·만분율)
1,gacha_hit_rate,3,200
2,gacha_stun_rate,3,200
3,gacha_retaliate_rate,3,200
4,gacha_combo_rate,3,200
5,gacha_hit_rate,4,400
6,gacha_stun_rate,4,400
7,gacha_retaliate_rate,4,400
8,gacha_combo_rate,4,400
9,gacha_hit_rate,5,800
10,gacha_stun_rate,5,800
11,gacha_retaliate_rate,5,800
12,gacha_combo_rate,5,800
13,gacha_hit_rate,6,1600
14,gacha_stun_rate,6,1600
15,gacha_retaliate_rate,6,1600
16,gacha_combo_rate,6,1600
```
*(주: `s_StatKey``gacha_` 접두를 붙여 메타v1 §3-3 "CSV 키 접두 가드" 원칙을 준수한다. `SurvivalStatCatalog.cs`의 정본 키(`hit_rate` 등)와 별도 네임스페이스 — 소비 시점에 `TotalOptionValue()`가 접두 제거 매핑을 수행한다.)*
### 10-3. `SurvivalMetaGachaPity.csv`
```
n_Tier,n_PullsNeed,n_PoolId,n_GuaranteedGradeFloor
천장단계,발동회차,활성풀ID,보장등급하한(0=없음)
1,1,1,0
2,4,2,5
3,40,3,5
```
### 10-4. 뽑기 비용 테이블(참고 — 코드 상수 or 신규 CSV `SurvivalMetaGachaPrice.csv` 택1, 구현 세부는 개발팀장 재량)
```
n_PullCount,l_GoldCost,l_GemCost
1,400,20
10,4000,200
100,36000,1800
```
### 10-5. `SurvivalMetaData` v5 필드 (§9-1 요약 재게재)
```csharp
public int GachaPityCount; // 신규(메타v1 §5-1 스텁 실필드화)
public Dictionary<int, int> GachaOwned; // 신규 — itemId → 보유수(중복 판정)
public Dictionary<int, List<(string statKey, float value)>> GachaRolledOptions; // 신규 — itemId → 실제 옵션
public const int CurrentVersion = 5; // 4 → 5
```
---
## 11. 검증 시나리오
| # | 시나리오 | 기대 결과 | 검증 |
|---|---|---|---|
| 1 | 신규유저 1회 단차(Pool1, count=0) | Grade3·4만 등장, Grade5·6 확률 0% | §6-1 Pool1 weight 확인(Grade5·6 미기재=0) |
| 2 | 3회 연속 미획득 후 4회차(count=3) | Pool2로 전환, Grade5·6 등장 시작(5.00%+1.50%) | §6-2 카운터 규칙(`3≤count<39`Pool2) |
| 3 | 39회 연속 Grade5·6 미획득(count=39) | Pool3 전환, Grade5 또는 Grade6 100% 확정 | §6-2 규칙(`count≥39`→Pool3), §6-1 Pool3 weight합 10000 |
| 4 | 하드천장에서 Grade5 획득 | GachaPityCount 0으로 리셋, 다음 뽑기부터 Pool1 재시작 | §6-2 리셋 규칙 |
| 5 | 이미 보유한 id10을 재뽑기 | 골드/젬 정상 차감 + id10 옵션 슬롯 1개 무료 재추첨(중복 낭비 아님) | §6-4 중복 처리 |
| 6 | Grade6 아이템 옵션 5슬롯 채우기 | hit/stun/retaliate/combo 4종 전부 1회씩 + 1종 중복(값 합산) | §6-4 규칙 |
| 7 | 100연 젬 결제 | 1800젬 정확히 차감(할인 10% 반영), 1800/1800=정수 나눠떨어짐 확인 | §5-2 공식 |
| 8 | 보수적 하한 시나리오 1런(2,542G) 전액 가챠 투입 | 단차 6회 가능(2400G), 소프트천장(4회) 이미 통과 | §8-1 표 |
| 9 | 옵션값 CSV 원시값 200 저장 후 `Applied` 조회 | 0.02(2%) 반환 — `SurvivalUpgradeTable.Entry.Applied = Value/10000f` 공식과 정합 | §6-3, C39 코드 확인 |
| 10 | Grade3~6 아이템 장착 후 `TotalAttack()`/`TotalHp()` | 기존 B2 로직이 코드 변경 없이 신규 id10~15의 Attack/Hp를 자동 합산 | §9 결합 확인 |
---
## 12. 밸런싱 제안 표 (표준 포맷)
| 항목 | 현재 값 | 제안 값 | 근거 |
|---|---|---|---|
| 뽑기 소비 재화 | N/A(신규 도입) | 골드 1차 + 젬 2차 이원 결제 | PD 직접 지시 문자 그대로 + 재추출v1 §7-1 구조 승인 기반(§2) |
| 천장 스케줄 | N/A(PM 1차 권고: 히어로 표준 10/30) | **열쇠형 4/40** | 원작 `dj_7011`="장비 뽑기 티켓" 명시 라벨과 GodDem 가챠 결과물(장비) 대응 정합(§3) — PM 권고 대비 변경, 사유 상세 §3-2·3-3 |
| 단차 골드가 | N/A(신규 도입) | 400G | 원작 젬단가(20젬) × GodDem 기존 골드/젬 교환비(20:1, 상점 SOT) 교차 도출(§5-1) |
| 단차 젬가 | N/A(신규 도입) | 20젬 | 원작 절대값 그대로 포팅(젬은 미재조정 처녀 재화, §5-1) |
| 신규 등급 범위 | Grade1~2뿐(상점) | Grade3~6(가챠 전용) | 메타v1 R-B5 상점/가챠 역할분리 권고 실행 + B2 §8 forging 사다리(q2→q6)와 정합(§4) |
| 옵션 4종 값(Grade3~6) | N/A(정의만 존재, `SurvivalStatCatalog.cs`) | 200/400/800/1600(raw) = 2%/4%/8%/16% | 원작 B-템플릿(배율재추출v1 §2-2) 원시값 그대로, GodDem `BasisPoint` 컨버전 기존 공식 재사용(§6-3) |
**세그먼트 영향**: §7 "뽑기 상품 구성" 절 세그먼트 표 참조(무과금/소과금/고과금 3단 기재 완료).
---
## 13. PD 확인 대기 항목
1. **젬 IAP 실화폐 가격**: 기존 상점 카탈로그의 젬팩 5종(180/500/1200/6500/15000젬)이 전부 `Price=0`(IAP 미연동 placeholder)이다. 가챠가 젬 소모를 실제로 유발하는 이상 이 가격 확정이 필요하다 — 원작 기준(재추출v1 §6: $29.99=800젬 → $0.0375/젬)을 그대로 적용하면 180젬=$6.75/500젬=$18.75/1200젬=$45/6500젬=$243.75/15000젬=$562.5가 되는데, **이 가격이 GodDem의 시장·지역 전략에 맞는지는 balance-designer 재량 밖**(과금 정책, P23 PD님 확인 영역)이다.
2. **천장 스케줄 최종 확인**: 본 문서는 열쇠형(4/40)을 채택했다(§3) — PM 1차 권고(히어로 표준 10/30)와 다른 결론이므로, 실제 구현 착수 전 이 판단 자체를 PD님께 재확인 권고(C36 보수적 해석 — 방향 자체는 balance-designer 재량 범위 내이나, 원작 이식이라는 프로젝트 전체 방침의 핵심 축이라 재확인이 안전).
3. **옵션 4종(hit/stun/retaliate/combo) 전투 소비 로직 신설 여부**: §0에서 밝힌 대로 코드베이스 전체에 소비처가 0건이다. 가챠 구현과 동시에 전투 로직(명중 판정 상쇄·기절 상태이상·반격 트리거·연격 트리거)을 신설할지, 아니면 "저장만 하고 추후 시스템 신설"로 미룰지는 **개발 리소스 범위 판단**이 필요해 balance-designer 단독 결정 밖이다(system-designer·개발팀장 협의 권고).
4. **forging/reforging 활성화 여부**: §4-3에서 본 문서 범위 밖으로 유보했다. B2가 이미 가격을 매겨뒀으므로 "재료" 자원 정의만 확정되면 즉시 활성화 가능한 상태다 — 5층 완성(가챠) 이후 후속 확장으로 진행할지 PD 판단 필요.
---
## 14. 리스크
| ID | 리스크 | 심각도 | 내용 |
|---|---|---|---|
| R-H1(신규, §0 핵심) | 옵션 4종 전투 미소비 | 높음(정보성) | hit/stun/retaliate/combo가 정의·획득까지만 완결되고 실전투 발동 로직이 전무 — 가챠를 완료해도 플레이어 체감 효과가 Attack/Hp 증가분(기존 파이프라인)에 한정되고 옵션 4종은 수치만 쌓일 뿐 전투에 반영 안 됨. §13-3 PD 확인 |
| R-H2(신규) | 천장 가중치 형태 차용의 부정확성 | 중(🟡) | §6-1 Pool2/3 weight는 히어로 단차 비중을 열쇠형 카덴스에 재정합한 값이라 원작 열쇠 자체의 실제 곡선과 다를 수 있다. 열쇠 원본 가중치 재추출 시 교체 권고 |
| R-H3(신규) | Grade6 중복 스택 언밸런스 | 중 | 5번째 슬롯 중복 허용(§6-4)으로 최상위 등급템은 동일 옵션 2배 스택 가능 — 예: combo_rate 32% 등 단일 스탯 과확률이 전투 밸런스를 왜곡할 여지(단, R-H1이 먼저 해소돼야 실제 영향 판정 가능) |
| R-H4(신규) | 젬 경제 이중 소모처 충돌 | 낮음~중 | 기존 상점(daily_sword 50젬 등 Grade1~2 직접구매)과 가챠(20젬 단차) 젬 소모처가 공존 — 신규유저 시작 젬 300 기준 상점 아이템 구매(30~50젬)와 가챠 1~2회 중 무엇을 우선할지는 플레이어 선택이나, 상점의 "일일 1회 한정" 제약과 가챠의 "무제한 반복" 성격 차이로 젬이 결국 가챠에 쏠릴 가능성(설계 의도와 일치하나 상점 가치 추가 희석 여지, R-B5 연장선) |
| R-H5(승계) | 가챠 도입 정책 리스크(메타v1 R-A3) | 낮음(부분 해소) | 재화 종류는 본 문서로 확정됐으나(§2), IAP 실가격(§13-1)은 여전히 미확정 |
---
## 15. 기각안 (C32)
| # | 검토안 | 기각 사유 |
|---|---|---|
| 1 | 천장 스케줄 = 히어로 표준(10/30) 그대로 채택 | §3-2·3-3 — 결과물 유형(히어로 조각 vs GodDem 장비) 불일치. PM 1차 권고였으나 재검토 지시로 재조사 후 기각 |
| 2 | 천장 스케줄 = 장비형(62/100) 채택 | §3-3 — 결제구조가 젬 단일이라 PD "일반은 골드" 지시와 배치 |
| 3 | Grade1~2 기존 아이템도 가챠 풀에 포함(상점과 가챠 완전 공유) | 메타v1 R-B5가 이미 지적한 "상점 가치 희석" 리스크를 그대로 재현 — Grade1~2는 상점 전용으로 역할 고정(§4-2) |
| 4 | 원작 6등급(q1~q6)을 GodDem Grade1~6에 그대로 1:1 매핑, 가챠도 Grade1부터 등장 | 위와 동일 사유 + B2 §8-1 forging 사다리가 이미 q2→q3 시작으로 설계돼 있어(Grade1→2는 TryFuse 별도 경로) 가챠 시작점도 Grade3부터가 기존 골격과 정합 |
| 5 | forging/reforging을 본 문서에서 완전히 설계·활성화 | §4-3 — "재료" 자원이 미정의 상태라 신규 자원 도입이라는 별도 결정이 선행돼야 함. C50 범위 통제 + B2가 이미 가격을 매긴 부분의 중복 작업 방지(C10) |
| 6 | 옵션 4종 값을 GodDem 자체 재계수화(예: B4의 D(grade) 한계단가 균일화 방식 차용) | 옵션은 "지배 전략" 문제가 아니라(4종 모두 같은 확률 구조로 동등 가중 추첨되므로 "무엇을 살지 선택"하는 B4식 구매가 아니라 "무엇이 나올지 뽑는" 가챠라 균일화 유인 자체가 없음) — 원작 raw값을 그대로 쓰는 것이 더 정직하고 단순함(C44) |
| 7 | Grade6 5번째 슬롯을 빈 슬롯(미사용)으로 유지 | 슬롯 수 표(B2 §8-4)를 그대로 존중하되 낭비 없이 활용하는 편이 P30(재미) 관점에서 낫다고 판단 — "중복 스택"을 채택했으나 R-H3로 리스크 인지·병기 |
| 8 | 뽑기 비용을 B1/B2/B4처럼 "대형 1회성 목표" 스케일로 설계(예: 100연 비용을 총 경제의 10%대로 책정) | §8-2 — 가챠는 메타v1 §1-4가 정의한 역할(반복적 확률 기대감)이 B1~B4(장기 완결형 목표)와 다르다. 큰 목돈 스케일로 설계하면 §8-1의 "매 런마다 소프트천장 도달"이라는 P30 근거 자체가 무너짐 |
---
## 16. 변경 이력 (P16)
| 일시 | 작성 | 변경 | 근거 |
|---|---|---|---|
| 2026-08-22 | balance-designer | v1 신규 — 재화 이원결제(골드+젬) 확정, 천장 3안 비교 후 열쇠형(4/40) 채택, Grade3~6 신규 등급 도입, 풀/옵션/천장 CSV 3종 스키마 확정, 옵션 4종 전투 미소비 신규 발견(R-H1) | PD "원작 로직 동일·일반 골드+특정시점 유료" 지시 + PM 보강 지시(천장 3안 비교 요구) 반영 |
---
## 17. 후속 조치 (본 문서 범위 밖)
1. **plan-auditor 모드A 검증** — C35 의무 호출 대상(부서 간 산출물 공유·중요 결정). 본 문서 확정 전 선행 필요.
2. **옵션 4종 전투 로직 신설 여부 결정**(§13-3) — system-designer·개발팀장 협의.
3. **forging/reforging 활성화 판단**(§13-4, §4-3) — "재료" 자원 정의 선행.
4. **젬 IAP 가격 확정**(§13-1) — PD 과금 정책 판단.
5. **개발팀장 구현 착수** — C49 표준(설계 완료 → plan-auditor 검증 → 개발팀장 구현 → PM 커밋·push).
6. **열쇠형 자체 가중치 원본 재추출**(R-H2) — 여유 있을 때 개발팀장 APK 재복호화로 §6-1 Pool2/3 weight를 🟡에서 🟢로 격상 가능.
7. **가챠 UI 진입점 신설**`SurvivalShopCatalog.cs`와 별도 화면(메타v1 §5-3 "구조 확장 필요" 항목), ux-designer·클라이언트팀 협의.