22 KiB

Raw Permalink Blame History

GodDem SurvivalBattle S3 밸런스 정밀 조정안 v2 (재산출)

작성: balance-designer(기획팀) 2026-08-21 · 근거: plan-auditor 반려 3건 해소(C49 재상정) · PD 원승인 "전부 진행해"(2026-08-21) 유효 성격: v1 대체 아님 — 증보. v1 전체 본문은 그대로 유효하며, 본 문서는 반려 3건에 해당하는 변경분만 다룬다. v1 미변경 섹션(§4 스킬 정규화 전반·§5 A10·§7 EXP 페이싱)은 본 문서에서 재인용하지 않으므로 반드시 v1과 함께 볼 것. v1: 2026-08-21_S3_밸런스_조정안_v1.md 절대 제약: 본 문서가 유일 산출물. GodDem 레포(E:\NerdNavis\GodDem)는 Read만 수행, 수정 0건 (v1과 동일). 중요 고지 — 세션 중 동시편집 확인: 본 작업 도중 git status로 GodDem 레포에 5개 파일 미커밋 변경(개발팀장 4차 반영, 동시 진행 세션)을 확인했다 — SurvivalBattleManager.cs·SurvivalMeta.cs·SurvivalProjectile.cs·SurvivalUIController.cs·SurvivalBattle.unity. 아래 실측은 이 변경이 이미 반영된 현재 워킹트리 상태를 기준으로 하며, git diff로 변경분을 직접 대조 확인했다(v1의 Critical 원인이 된 "Read 시점 경합"의 재발 방지). 단, 미커밋 상태이므로 해당 세션이 커밋하지 않고 되돌리면 아래 "확인 완료" 항목이 무효화될 수 있음 — 개발팀장 커밋 후 재확인 권고.

0. 반려 3건 요약 (재상정 사유)

#	반려 항목	심각도	v1의 결함
1	메타 장비 가산 전제 누락	Critical	`ApplyMetaEquipment()`(커밋 `57a8fcf`)가 시작 스탯에 장비 능력치를 가산하는데, v1은 "IAP·메타 재화 연동 0건"으로 오판(§0) — 3차 미커밋 작업분과 Read 시점이 겹친 경합
2	골드 경제 미검토	Major	`EnemyCountPerWave` 2→1은 적 처치 수를 줄여 골드 획득도 줄이는데, 설계 앵커("20웨이브 약 460마리≈4,600G→12종 중 4종 만렙")와의 정합을 검토하지 않음
3	도달 시차 미반영	Major	3장 생존모델이 "전원 t=0 즉시 근접·지속공격"을 가정 — 스폰~사거리 도달 시간(무피해 구간)을 반영하지 않아 잔여 HP 과소계상

1. Critical 해소 — 메타 장비 2케이스 밴드

1-1. 실측 (코드 인용)

SurvivalBattleManager.cs (현재 워킹트리, 이중 SOT 해소 반영 후):

void ApplyMetaEquipment()
{
    PlayerAttack = SurvivalMeta.BaseAttack + SurvivalMeta.TotalAttack();   // Base 22
    PlayerHp     = SurvivalMeta.BaseHp     + SurvivalMeta.TotalHp();       // Base 400
}

Start()에서 ApplyMetaEquipment() → SpawnPlayer() → RecalcPlayer() 순서로 호출되며, 레벨1·강화0단계 시점엔 RecalcPlayer의 배율(atkRatio·hpRatio 등)이 전부 0이므로 웨이브1~2 실효 스탯 = ApplyMetaEquipment 결과값 그대로다(추가 배율 없음, 직접 확인).

SurvivalItemCatalog.cs 9종(6부위) 실측 — 개발 임시값 명시 상태("신규 장비·수치 밸런싱은 기획팀 후속 영역이다", 코드 주석):

부위	하위 등급	상위 등급(합성 결과)	슬롯 최댓값 채택
무기	낡은 검 6atk	강철 검 14atk	14atk (상위가 양축 모두 우위)
모자	마법사 모자 3atk/55hp(유일)	—	3atk/55hp
반지	힘의 반지 8atk	보석 반지 20atk	20atk
신발	신속의 부츠 0atk/40hp(유일)	—	0atk/40hp
갑옷	사슬 갑옷 0atk/90hp(유일)	—	0atk/90hp
부적	번개 부적 5atk/25hp	용의 보물함 10atk/120hp	10atk/120hp(양축 모두 우위)
합계			+47atk / +305hp

1-2. 밴드 확정 — 대화로그 기재치와의 차이 명시

케이스	Attack	HP	근거
하한 (미장착)	22	400	`TotalAttack()/TotalHp()=0` — Equipped 전 슬롯 0
개발팀장 실측 예시 (대화로그 §8, 2026-08-21)	52	610	특정 장착 조합(무기만 상위 등급, 반지·부적은 하위 등급) — 카탈로그 최댓값이 아닌 진행 도중 스냅샷
상한 (풀장착 최댓값, 본 문서 채택)	69	705	슬롯별 상위 등급 완전 합성(1-1표) — 현재 카탈로그가 허용하는 이론적 최댓값

기각안: 대화로그의 "52/610"을 그대로 밴드 상한으로 채택 — 기각. 사유: 반지·부적을 상위 등급으로 합성한 조합이 두 스탯 모두 엄격히 더 크므로(20>8, 120>25 등) 도달 가능한 실제 최댓값이 아니다. 밴드 상한은 "안전마진을 과소평가하지 않는" 방향으로 실제 도달 가능한 최댓값을 써야 하므로 69/705를 채택하고, 52/610은 "중간 진행 예시"로 별도 병기한다.

1-3. 밴드별 웨이브1~2 재계산 (제안값 EnemyBaseHp 42·EnemyCountPerWave 1 적용, 시차 미반영 기존 비관적 모델 기준)

케이스	PlayerDPS	웨이브1 잔여	웨이브2 잔여(누적)
하한(22/400)	31.4	283.1 (70.8%)	93.6 (23.4%) — v1과 동일
상한(69/705)	98.6	667.7 (94.7%)	607.3 (86.1%)

세그먼트 영향: 현재는 전 세그먼트 동일(IAP 미연동, v1 §0 유지). 단 상점 실화폐 슬롯(젬 팩)이 결선되면 고과금 유저가 풀장착 상한(69/705)에 더 빨리 도달해 웨이브1~2 무위협 구간에 더 일찍 진입하는 파급이 예상된다(추정, IAP 결선 후 재분석 필요).

→ 상한 케이스는 비관적 모델에서조차 86.1% 잔여로 위협이 사실상 소멸한다. 이는 §4(도달 시차)에서 더 심화되므로 종합 판정은 §4-3에서 다룬다.

2. Major 해소 — 골드 경제 재설계

2-1. 설계 앵커의 실체 검증

SurvivalBattleManager.cs:41~44 주석(불변): "20웨이브 약 460마리 ≈ 4,600골드 → 12종 중 4종 정도 만렙".

이 "460마리"를 역산하면 Σ(w=1→20) [4+(w-1)×2] = 460 — 즉 보스 웨이브 희석(10·20웨이브는 count=1)과 스테이지 리셋을 반영하지 않은 산술급수 근사임이 확인된다(실측). 보스 희석·스테이지 리셋을 반영한 정밀 재계산(waveInStage 산식 확인 반영 — §2-2)은 다음과 같다.

항목	근사(주석의 방식)	정밀(실측, boss 희석+waveInStage 반영)
20웨이브 총 처치 수(EnemyCountPerWave=2)	460	218
20웨이브 총 골드(BaseGoldReward10+GoldPerStage2 그대로)	4,600	2,596 (≈2.38/12 트랙)

→ 개발자 주석의 "4,600G/4트랙" 자체가 실제 코드 동작보다 약 1.77배 부풀려진 근사치다 — 이는 EnemyCountPerWave 변경과 무관하게 이미 존재하던 갭이며, 본 조정안이 만든 문제가 아니다. 따라서 앵커를 "4,600G 정확히 복원"이 아니라 **"현재 실제 동작 중인 2,596G 페이스 유지"**로 재정의한다(과잉조정 방지, C2).

2-2. EnemyCountPerWave 1 적용 시 격차

waveInStage 기준 적 수 산식은 현재 워킹트리에 이미 반영 확인됨(SurvivalBattleManager.cs:252, int count = boss ? 1 : BaseEnemyCount + waveInStage * EnemyCountPerWave;).

항목	현재(2)	제안(1)	증감
스테이지1 처치(웨이브1~9)	108	72	-33%
20웨이브(2스테이지) 총 처치	218	146	-33%
20웨이브 총 골드(현행 요율 10/+2)	2,596G	1,804G	-30.5%

2-3. 보상안 — 골드 요율 조정 (앵커 유지)

항목	현재 값	제안 값	근거
`BaseGoldReward`	10	14	목표: 1,804G(제안 적수) → 2,596G(현재 실동작 페이스) 복원. 배율 2596/1804=1.439 → 10×1.439≈14
`GoldPerStage`	2	3	동일 배율 적용(2×1.439≈2.9→3)
→ 재계산 결과	—	2,542G(≈2.33/12 트랙)	목표(2,596G) 대비 -2.1% — 오차범위 내

유의 (plan-auditor 재검증 Minor): 총액 앵커는 유지되나 분포가 초반으로 이동 — 웨이브1 골드 40→56(+40%)·웨이브2 +16.7%, 웨이브4 부근 교차 역전. 초반 강화 속도 가속은 R-J(풀장착 무위협)와 같은 방향의 가산 요인 — 플레이테스트 시 관찰 항목.

세그먼트 영향: 전 세그먼트 동일(IAP 미연동, §1-2 동일 고지).

기각안 1: 강화 비용 곡선(10/42/99/184/301/454)을 인하해 앵커를 맞추는 방안 — 기각. 사유: 이 곡선은 "원작 hero_level 골드 곡선 실측값 그대로" 이식된 것(SurvivalUpgrade.cs 주석)으로, 원작 정합성이라는 별도 설계 가치가 있다. 골드 획득 쪽(플레이어 손에 들어오는 수치)을 조정하는 편이 원작 이식 자산을 건드리지 않아 리스크가 낮다.

기각안 2: 개발자 주석의 "4,600G/4트랙"을 문자 그대로 복원(배율 2.42배, BaseGoldReward→24 수준) — 기각. 사유: §2-1에서 확인했듯 그 수치 자체가 부풀려진 근사치였다. 실제로 필요한 보정은 "내 제안이 깎은 -30.5%"만이며, "주석과 실제 구현의 기존 괴리(-44%)"까지 이번 조정에서 함께 메우는 것은 범위를 벗어난 과잉조정(C2)이다. 후자는 별도 항목(§6 Minor 4)으로 분리해 주석 정정만 권고한다.

3. Major 해소 — 도달 시차 반영

3-1. 상수 재확인

상수	값	출처
SpawnRadius	4 (가로축 ×0.55)	`SurvivalBattleManager.cs:29`, `SpawnWave()` 스폰 좌표식
EnemyMoveSpeed	1.1	동 파일:40, 씬 직렬화 동일값 재확인
적 공격 사거리	1.3 (하드코딩)	`unit.Init(hp, atk, 1.2f, 1.3f, EnemyMoveSpeed)`
적 공격 쿨다운	1.2 (하드코딩)	동일 라인
플레이어 공격 사거리	3.2	`PlayerAttackRange`
플레이어 공격 쿨다운	0.7	`PlayerAttackCooldown`

스폰 지점~원점(플레이어) 거리는 타원 파라미터상 2.2(근거리 축)~4.0(원거리 축) 범위.

3-2. 정밀 도달 시각 — 쿨다운 게이트 보정 (신규 발견)

SurvivalUnit.cs FixedUpdate() 확인 결과, 공격 타이머(_timer)는 유닛 스폰 시점부터 무조건 누적되며(사거리 진입 여부와 무관), 최초 공격은 _timer >= AttackCooldown이 될 때만 발생한다. 즉 최초 공격 시각 = **max(사거리 도달 시간, 자신의 공격 쿨다운)**이다 — 이동 시간만으로 근거리를 계산한 과제 지시치(0.8초)보다 실제로는 다소 늦다.

구분	이동 시간만	쿨다운 게이트 보정(채택)
적 근거리 최초 피격	(4.0−1.3)/1.1=2.45초* → 정정: 근거리 스폰은 2.2−1.3=0.9,0.9/1.1=0.82초	max(0.82, 쿨다운1.2) = 1.2초 (쿨다운이 이동보다 늦게 걸림)
적 원거리 최초 피격	(4.0−1.3)/1.1=2.45초	max(2.45, 1.2) = 2.45초 ≈ 2.5초 (이동이 쿨다운보다 늦음, 과제 지시치와 일치)
플레이어 최초 공격(웨이브1, 타이머 리셋 직후)	근거리 스폰은 즉시 사거리 내(2.2<3.2)	max(0, 쿨다운0.7) = 0.7초
플레이어 최초 공격(웨이브2+)	전멸 대기 + WaveInterval(1.5초) 동안 `_timer`가 쿨다운을 이미 초과 상태로 유지	≈0초(사실상 즉시, 도달한 순간 공격)

→ 근거리 지시치는 "0.8초"가 아니라 쿨다운에 걸려 1.2초가 정확한 값이다(이동만으로는 0.82초에 사거리 진입하지만 아직 쿨다운이 안 돌아 공격 못 함). 원거리는 지시치(2.5초)와 일치.

3-3. 밴드별 재계산 — 2×2 매트릭스 (장비 × 시차)

방법: N마리를 "근거리 일괄 도착(1.2초)" / "원거리 일괄 도착(2.45초)"의 두 경계로 근사(과제 지시 방식과 동일 구조) + 위 쿨다운 보정 적용. 순차처치 사망시각 t_k = t_p + k·T_kill(T_kill=적HP/플레이어DPS)에서 각 적의 공격구간 = max(0, t_k − t_e).

장비 케이스	시차 가정	웨이브1 잔여	웨이브2 잔여(누적)
하한(22/400)	없음(v1 비관 모델, 하한 참고용)	70.8%	23.4%
하한(22/400)	근거리(1.2초)	75.2%	41.4%
하한(22/400)	원거리(2.45초)	85.2%	63.3%
상한(69/705)	없음(비관 모델)	94.7%	86.1%
상한(69/705)	근거리(1.2초)	97.1%	94.9%
상한(69/705)	원거리(2.45초)	100%	100%

3-4. 목표 밴드(15~35%) 재판정

판정: 조건부 유지 — "최악 하한 보장"으로는 성립, "평균 체감"으로는 불성립.

목표1의 핵심("죽는 경험 제거")은 모든 케이스에서 사망 0건으로 강하게 충족된다.
15~35% 밴드는 비관적 하한선(스폰 클러스터링 등 최악의 불운)에서만 성립(23.4%). 시차를 반영한 현실적 모델은 하한장비 기준으로도 **41.4~63.3%**로 밴드 상단(35%)을 상회하고, 장비 상한 기준으로는 86~100%로 위협이 사실상 없다.
즉 15~35%는 "항상 이 범위에 들어온다"가 아니라 "최악의 경우에도 이 범위 아래로 안 떨어진다(=죽지 않는다)"는 안전 하한 지표로 재해석해야 한다. "평균적으로 위협을 느끼는" 체감은 스폰 클러스터링 등 불운 시행에서만 발생하는 구조이며, 이는 v1 §8이 이미 지적한 "동일 코드에서 결과가 극단적으로 갈리는" 편차 문제와 같은 뿌리다.

권고: EnemyBaseHp 42 / EnemyCountPerWave 1은 그대로 유지한다(추가 너프 반대). 이유:

이미 모든 밴드에서 사망 위험이 0이므로 목표1(최우선)을 견고하게 만족.
"평균 체감을 15~35%에 맞추려는" 추가 너프는 최악 하한(현재 23.4%)을 더 낮춰 목표1(사망 방지)을 다시 위협한다 — 죽는 경험 재발이 "가끔 안전한 느낌"보다 더 나쁜 실패 모드다.
체감 편차 문제의 올바른 해법은 수치 재조정이 아니라 v1 §8의 편차 완화안(웨이브1 스폰 그레이스, 방어 패시브 카탈로그 신설)이다 — 이미 제안되어 있고 반려 대상도 아니었다.

신규 리스크(장비 상한 관련, §1과 연결): 풀장착 유저는 시차를 반영하지 않아도 86.1%, 반영하면 94.9~100% — 웨이브1~2가 사실상 완전 무위협이다. 이는 파라미터 미세조정으로 해결 불가능한 구조적 질문(초반 웨이브를 장비 수준에 따라 스케일할지 여부)이며, 본 조정 범위 밖의 별도 설계 결정이 필요하다(§7 리스크 R-J).

기각안: 시차를 몬테카를로 수준으로 정밀 시뮬레이션(적별 개별 스폰각·이동 스태거링 전부 반영) — 기각. 사유: 과제 지시 자체가 근거리/원거리 2-경계 밴드를 요청했고, 이는 v1의 장비 2케이스 구조와 동형이라 문서 일관성이 높다. 완전 시뮬레이션은 §10 검증 시나리오3처럼 "플레이테스트 전용" 영역으로 남긴다(과잉정밀 방지, C14).

4. Minor 정정 3건 + 부수 확인 1건

#	항목	정정 내용
1	R-E 조건 표현	v1 "speed≥1이면 항상 무시"는 부정확 — `Mathf.Max(MaxRange, speed×6)`은 speed>1일 때만(등호에서는 동률이라 실질적 override 없음) 자산값을 이긴다. +추가 확인: 코드 자체가 이미 수정 완료(`SurvivalProjectile.cs`, 워킹트리 확인) — override 로직 삭제, 자산 `MaxRange` 직접 사용. R-E는 더 이상 활성 결함이 아니다.
2	A13 명칭	자산 `DisplayName`="저주 구체"(유니코드 실측 확인), `EnglishName`="Cursed Orb". 파일명 `A13_cheondoongbal.asset`은 내부 리소스명으로 유지, 문서 표기는 "A13 저주 구체(Cursed Orb)"로 통일
3	A13 DebuffStackLimit	자산값 `DebuffStackLimit: 3` 보유 확인. 관통 재타격마다 `SurvivalDebuffStack.AddStack` 호출 — v1·본 문서의 DPS 수치는 이 스택 폭발분을 포함하지 않은 순수 관통타 데미지만의 값이다
4(부수)	A13 이론상 DPS 갱신	정정 1의 R-E 수정 결과, MaxRange가 12(버그)→6(자산값)로 되며 관통 생존시간이 6초→3초로 반감. 재계산: 240 dmg/96 DPS(v1, 30틱 기준) → 120 dmg/48 DPS(15틱 기준)로 갱신. 여전히 단일 표적 정적 최대치이며 스택 폭발 미포함(정정3과 동일 유보) — "실측 필요" 판정은 유지

부수 확인(과제 범위 외지만 직접 실측): penetrate_ratio는 배선도 비노출 양자택일이 아니라 이미 "비노출"로 확정 반영됨을 워킹트리에서 확인. SurvivalBattleManager.cs에 ConsumedUpgradeKeys(RecalcPlayer가 실제 소비하는 11개 키 집합, penetrate_ratio 제외) 신설 + SurvivalUIController.cs가 이 집합에 없는 키를 상점에서 자동 제외하도록 수정 — "골드 소모·효과 0" 함정이 구조적으로 차단됐다. 추후 배선 시 RecalcPlayer + ConsumedUpgradeKeys 양쪽에 키를 추가하면 자동 복귀하도록 self-documenting 되어 있음(코드 주석 확인).

5. 마스터 변경 요약 (v1 §9 갱신판 — 본 문서 신규/변경분만)

항목	현재 값	제안 값	근거	세그먼트 영향
`EnemyBaseHp`	60	42	v1 §3 유지 — §3-4 재판정 통과(밴드는 안전하한 지표로 재해석)	전 세그먼트 동일
`EnemyCountPerWave`	2	1	v1 §3 유지 — 상동	전 세그먼트 동일
`BaseGoldReward`	10	14	§2-3 — EnemyCountPerWave 변경분(-30.5%)만 정확히 보상, 개발자 주석의 기존 과대추정(§2-1)은 별도 이슈로 분리	전 세그먼트 동일(IAP 미연동)
`GoldPerStage`	2	3	상동	전 세그먼트 동일
`PlayerHp` 2차 버퍼(440~480)	400	보류 철회 권고	v1은 "미달 시 투입"으로 보류했으나, 재계산 결과 최저 케이스도 23.4%(사망 아님)·시차 반영 시 41%+ — 버퍼 필요성 근거가 오히려 약해짐	전 세그먼트 동일
SpawnWave 적 수 산식	—	(조정 아님, 확인만)	이미 waveInStage 기준으로 반영 확인(§2-2)	—
A13 관통 사거리 override	—	(조정 아님, 확인만)	이미 자산 MaxRange 직접 사용으로 수정 확인(§4)	—
`penetrate_ratio`	—	(조정 아님, 확인만)	이미 상점 비노출로 확정 반영 확인(§4 부수)	—

6. 검증 시나리오 갱신 (v1 §10 대체분만)

#	시나리오	통과 기준	결과
2	웨이브2 종료 위협구간(하한 장비, 시차無)	HP>0 && 15~35%	23.4% — 통과(안전하한 지표로 재정의, §3-4)
2b(신규)	웨이브2 종료(하한 장비, 시차 반영)	참고치(밴드 강제 아님)	41.4~63.3% — 밴드 상회, §3-4 판정대로 허용
2c(신규)	웨이브2 종료(상한 장비, 전 조건)	사망 0	86.1~100% — 통과(위협 소멸은 별도 리스크 R-J로 관리)
7(신규)	골드 앵커 유지	20웨이브 시점 골드가 현재 실동작치(2,596G) 대비 ±10% 이내	2,542G(−2.1%) — 통과
8(신규)	penetrate_ratio 상점 비노출	강화 탭(공격)에 관통 항목 미표시	코드 실측 통과 — QA 최종 확인 권고(런타임 미검증)

7. 리스크 갱신 (v1 §11 추가분)

ID	리스크	심각도	내용
R-I(갱신)	세그먼트 분석 — 향후 리스크로 격상	낮음→정보성 갱신	현재는 여전히 무관하나(§1-2), 상점 실화폐 슬롯 결선 시 고과금 유저의 장비 상한 조기 도달이 예상됨(추정)
R-J(신규)	장비 상한 유저 웨이브1~2 무위협	중간	§3-4 — 파라미터 조정으로 해결 불가. 초반 웨이브를 장비 수준에 연동할지는 별도 설계 결정(시스템 기획 영역 상의 필요)
R-K(신규)	골드 앵커 자체의 기존 과대추정	낮음(정보성)	§2-1 — 개발자 주석("4,600G")이 boss 희석·스테이지 리셋 미반영 근사치였음. 코드 변경 아님, 주석 정정만 권고(개발팀 REQ 불요, 팀장 재량)
R-L(신규)	미커밋 동시편집 의존성	낮음(일시적)	본 문서의 "이미 반영 확인" 3건(waveInStage·A13 MaxRange·penetrate_ratio)은 개발팀장 세션의 미커밋 워킹트리 기준 — 커밋 전 되돌려지면 무효화. 커밋 완료 후 재확인 권고

8. 변경 이력 (P16)

일시	변경자	항목	이전값	이후값	사유
2026-08-21	balance-designer	문서 최초 작성(v2)	(v1 §9 마스터 표)	본 문서 §0~7	plan-auditor 반려 3건(Critical 1·Major 2) 해소 + Minor 3건 정정 (C49 재상정)
2026-08-21	balance-designer	메타 장비 밴드 확정	미검토(v1 "해당없음" 오판)	22/400(하한)~69/705(상한), 대화로그 52/610은 중간 예시로 별도 병기	`ApplyMetaEquipment()`·`SurvivalItemCatalog.cs` 실측(§1)
2026-08-21	balance-designer	골드 요율 조정 제안	BaseGoldReward10/GoldPerStage2	14/3	EnemyCountPerWave 1 적용분(-30.5%) 보상, 앵커는 실동작 페이스(2,596G) 기준 재정의(§2)
2026-08-21	balance-designer	PlayerHp 2차 버퍼	보류(v1)	철회 권고	재계산 결과 안전마진 충분(§3-4·§5)

후속 조치 (본 문서 범위 밖, 팀장급 확인 필요):

§7 R-K(골드 주석 정정)·R-L(미커밋 확인) — 개발팀장 재량, REQ 불요.
§3-4 R-J(장비 상한 무위협)는 시스템 기획 영역과 협의가 필요한 설계 질문 — plan-team-lead 상정 권고.
PD 지시 로그·대화로그 동기화는 balance-designer가 별도 엔트리로 직접 기록(C13·C32, 팀장 경유 아님).

22 KiB Raw Permalink Blame History Unescape Escape