16 KiB

Raw Blame History

수상한잡화점 밸런스 기획 시행착오 아카이브 v1

조직: NerdNavis → BurningTimes 전환 기점 추출 대상 프로젝트: 수상한잡화점 (2D 덱빌딩 로그라이트) 차기 프로젝트: EerieVillage (2D 플랫포머 퇴마) 추출일: 2026-04-20 추출자: 밸런스 기획자 (balance-designer) 데이터 소스 실측: 참조 원본 직접 Read 기반 (C23 준수 — 추정·역할연기 없음)

§1. 데이터 파싱 오해 — 퍼센트값·음수값 해석 실증

§1-1. 각성트리 퍼센트값 오해 경위

발생 시점: Phase 3 성장 요소 기여도 분석 중 (2026-04-14 REQ001 기획팀 → 개발팀)

오해 내용: PCAwakening.json 테이블에서 s_Value='500%' 형식이 s_Value='5'와 혼재. 기획팀은 '500%'를 "기존 스탯의 500% 배율 적용"으로 해석하여 각성 만렙 시 DPS +1067% / EHP +197% 라는 비정상 수치를 산출했다.

실제 동작: table_base.cs Get_Value() 메서드가 % 포함 문자열을 float * 0.01f로 파싱. 즉 '500%' = 500 × 0.01 = 5.0f = '5'와 동일한 고정값. 배율 적용이 아님.

// 실제 파싱 로직 (REQ001 응답 코드 근거)
if (IsPercentValue(str)) return float.Parse(str.Replace("%", "")) * 0.01f;

만렙 효과 재계산: s_Value='500%', s_UpgradeStatValuePara='100%', n_MaxLv=5 기준

기획팀 추정: 500% + 100% × 4 = 900% (배율 해석 오류)
실제 결과: 5.0 + 1.0 × 4 = +9 (고정값 가산)

정정 방법:

개발팀에 REQ 발행 → 코드 레벨 파싱 로직 확인 요청
확인 후 기여도 문서 수치 전면 재계산
데이터 입력 형식 통일 권고 (런타임 동작은 정상이나 가독성 문제)

차기 프로젝트 EerieVillage 적용 원칙: 수치 테이블의 문자열 포맷(%, s, exp 등)이 런타임 파싱 로직에 따라 전혀 다른 결과를 낼 수 있다. 밸런스 시트 작성 전 반드시 파싱 함수 코드를 개발팀과 공유·확인한다. 특히 동일 컬럼 내 혼재 포맷은 오해 위험이 높다.

§1-2. 장비 옵션 음수값 — 디버프 의도 명확화

발생 시점: Phase 3 성장 요소 기여도 분석 중 (2026-04-14 REQ002 기획팀 → 개발팀)

발견 내용: 8부위 풀셋 장착 시뮬에서 CriDmg -20%, Avoid_Melee -3%, HitRate -2 등 음수 값이 합산. 기획팀은 오류 가능성을 제기.

실제 의미: 의도적 트레이드오프 설계. 무기 MainOption2가 페널티성 옵션을 고정 보유하는 구조.

패턴	사례	밸런스 의도
무기 고공격력 + 치명타 피해 페널티	ATK 강화 대신 CriDmg -20%	딜러 빌드 트레이드오프
쿨타임 음수 = 보너스	`AttackCoolTime -3%` = 공속 +3% 증가	스탯명 방향성 주의
강화로도 완화되지 않는 고정 페널티	`UpgradeStatValuePara = 0`	성장해도 단점 유지
세트 옵션 양수/음수 쌍	HP -10% + 보호막 +10%	빌드 방향 차별화

핵심 교훈: AttackCoolTime -3%처럼 스탯명의 방향성이 음수값 해석을 역전시키는 사례가 존재한다. 쿨타임 감소 = DPS 증가. 밸런스 계산 시 스탯 의미와 음수 방향을 함께 명시해야 한다.

차기 프로젝트 EerieVillage 적용 원칙: 장비·스킬 옵션의 음수값이 "오류"인지 "의도된 페널티"인지는 반드시 설계 문서에 명시한다. 특히 "방향성이 역전되는 스탯(쿨타임·캐스팅타임 등)"은 별도 명세표를 작성한다. DPS/EHP 계산 시 이 방향성 역전을 반영하지 않으면 수치가 왜곡된다.

§2. 어뷰징 판정 임계값 설계 — 서버 이관 원칙

출처: 공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md

§2-1. 설계 전제 (재미 우선 원칙 P30 연계)

어뷰징 판정은 "어뷰저를 잡는 것"이 목표가 아니라 **"정직한 플레이어의 재미를 보호"**하는 것이 목표다. 이 전제가 임계값 설계의 모든 수치를 결정한다.

false positive 최소화: 정상 유저를 어뷰저로 오판정하면 성취 경험이 훼손된다. 이것이 C7 재미 우선 원칙 위반이다.
안전 마진의 존재 이유: 프레임 드랍, 클라 시계 오차, 반올림 오차 — 이 기술적 노이즈가 정상 유저를 "경계 초과"로 만드는 구조를 막기 위해 마진이 필요하다.

§2-2. 임계값 도출 공식

경계값 = 시뮬_이론_극값 × 안전마진계수

시뮬 이론 극값은 10,000회 이상 반복 시뮬레이션의 상위/하위 0.1% 값을 채택한다. 절대 최대/최소가 아닌 이유: 시뮬 자체 오차 흡수.

벡터 특성	마진 방향	계수	근거
클리어타임 (짧을수록 의심)	하한 = 이론 최단 × 0.80	0.80	클라 시계 오차 15% 흡수
획득 재화 (많을수록 의심)	상한 = 이론 최대 × 1.05	1.05	반올림·버프 중첩 케이스 흡수
랭킹 점수 (높을수록 의심)	상한 = 이론 최대 × 1.10	1.10	신규 카드 출시 과도기 흡수
피격 수 (적을수록 의심)	하한 = 0 (음수만 차단)	—	0회도 이론상 가능
미션 카운트	상한 = 일일 최대 × 1.00	1.00	마진 불필요 (정수 카운트)

"안전 마진 0%" 기각 근거: 시뮬 극값 그대로 경계값으로 쓰면 false positive 폭발. 정상 유저도 매번 플래그됨. 재미 원칙 위반.

§2-3. 플래그 3단계 — 어뷰저 학습 방지와 false positive 보호 균형

단계	트리거	클라 응답	자동 조치
F1 경미	경계값 +5~10% 초과	없음 (무감지)	플래그 기록만
F2 중대	+10~50% 초과 또는 F1×3	"서버 동기화 오류"	보상 보류 + 알림
F3 확정	+50% 초과 또는 논리 모순	"blocked"	보상 미지급 + 계정 플래그

F1에서 클라에게 경고를 노출하지 않는 이유: 어뷰저가 경계값을 학습하지 못하도록 막기 위함.

§2-4. 기각안 (검토했으나 채택 안 한 방법론)

서버 단독 시뮬 재현 검증: 서버가 클라 입력을 받아 전투 재시뮬 → 기각. CPU 비용 폭증 + 부동소수점 동기화 이슈. 싱글플레이 구조에 과잉 투자.
머신러닝 이상치 탐지: 학습 데이터 축적 전 초기 출시 대응 불가. 장기 보조 수단으로만 검토.
클라 단독 판정: 메모리 조작으로 즉시 무력화. 원천 제외.
안전 마진 0% 엄격 검증: false positive 폭발 → 재미 원칙 위반으로 기각.

§2-5. ★조건 교차 검증 (P17 배타 배치 연계)

서버 검증에 기획팀이 정의한 ★조건을 포함시켜야 어뷰저가 "달성 못 한 ★조건을 클리어한 것처럼" 위조하는 AV-4 벡터를 막을 수 있다.

"starConditions": {
  "C6": { "field": "potionUsed", "operator": "==", "value": 0 },
  "N2": { "field": "hitsTaken", "operator": "<=", "formula": "subMapCount * 1" }
}

★조건 통과 보고와 필드값이 모순되면 F3 확정 (논리 모순 범주).

차기 프로젝트 EerieVillage 적용 원칙: 퇴마 클리어 보상·퍼펙트 클리어 인증 등 서버 검증이 필요한 성취 체계가 있다면, 기획팀이 "이론 극값 산정 방법론 + ★조건 검증 규칙"을 서버 개발팀에 제공하는 역할 분담을 사전에 확정한다. 경계값 수치는 시뮬 가동 후 채우는 구조로 설계 틀을 먼저 확정하면 개발팀과 병렬 진행 가능하다.

§3. Day 11~14 밸런스축 본작업 — TTK 기반 난이도 곡선 체계

출처: 공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md

§3-1. 설계 전제 확정 방식 (앵커 포인트 접근법)

밸런스 수치는 전체를 동시에 잡으려 하지 않고 앵커 포인트(기준점) 1개를 먼저 고정한 뒤, 그 기준에서 각 요소의 기여도를 순차 측정하는 방식으로 진행했다.

기준	값	출처
앵커 DPS	1.05	Phase 0 전투 시뮬 실측
앵커 TTK	5.7s	Phase 0 실측
앵커 EHP	64	Phase 0 실측
G1 풀빌드 실전 DPS	5.24	Phase 3 실측 (UTF 14/14 Passed)
장비 세트 완성 기여	+71.46%	Phase 3 실측 (±0.86% 오차)

§3-2. TTK를 "재미"로 번역하는 방법

재미 정의 선행: Stage 11~15 = "장비를 맞추기 시작해야 안정적으로 클리어되는 중반 구간." 이 재미 정의가 TTK 목표를 결정한다.

카드 단독 DPS(5.24)로 타이트 또는 클리어 곤란 → 장비 투자 동기 부여
장비 세트 완성(DPS 8.98)으로 TTK 24~45초 범위 → 긴장감 있되 클리어 가능
★1 클리어 TTK 목표: 장비 세트 결합 후 20~35초 (보스 1체 기준)

공식:

TTK (카드+세트) = HP + Shield 합산 / DPS_세트결합
DPS_세트결합 = 5.24 × 1.7146 = 8.98

주의: Shield는 직접 감소 방식 (방어력 계수 적용 없음). HP는 방어력 계수 적용.

§3-3. Stage별 검증 결과 요약

Stage	HP+Shield 합산	세트결합 TTK	C9 가능	핵심 주의사항
11	313.5 (+42%)	24.6~45.2s	가능	흡혈귀여왕2 Shield 급등 — 의도 설계
12	289.0 (-7.8%)	17.6~45.2s	최적합	C2∧N2 동시 배치 회피 권고
13	253.0 (-12.5%)	28.2s	금지	단독 보스 — P17 배타 #5 C9 불가
14	300.5 (+18.7%)	28.2~38.8s	가능	N4∧C6 동시 배치 주의 (P17 #3)
15	308.5 (+2.7%)	30.0~38.8s	가능	흑기사1 ATK Max 45 — C2∧N2 금지 (P17 #1)

고Shield 보스 패턴: 흡혈귀여왕2(Shield 315), 메두사2(Shield 230)는 세트+각성 결합 기준에서도 35~45초 영역. 이 구간은 "추가 성장 요소(각성·진화) 투자 동기 부여" 의도로 설계됨.

§3-4. 성장 단계별 DPS 조합표 (EerieVillage 설계 참조용)

성장 조합	DPS 배율	해당 Stage 11 보스 TTK
카드 단독	×1.00	42.2s (클리어 곤란)
카드 + 일반장비	×1.30	32.5s
카드 + 세트완성	×1.71	24.6s (적정)
카드 + 세트 + 각성 1.50	×2.57	16.4s (쾌적)
카드 + 세트 + 각성 + 진화 1.40	×3.59	11.7s (매우 쾌적)

이 테이블 구조는 "각 성장 요소가 클리어 경험을 어떻게 바꾸는가"를 수치로 직접 보여준다. 재미 설계의 수치 번역 예시로 활용 가능.

§4. 밸런스 자산 변경 전 백업 및 버전 관리 (C6-1 실무)

§4-1. 백업 포맷 표준

수치 밸런스 파일(xlsm·csv·json) 변경 전 반드시 다음 포맷으로 백업한다.

{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}
예: PCAwakening.bak_20260420_1430.json

금지 형식: .bak-* (하이픈), Unix timestamp, 버전 번호 단독 (_v1.bak).

§4-2. 경계값 테이블 버전 관리

어뷰징 판정 경계값 테이블은 게임 밸런스 패치마다 갱신이 필요하다. 이때:

정기 갱신: 카드 수치 변경·신규 몬스터 추가 시 해당 영역 시뮬 재실행
긴급 갱신: 어뷰징 신고 접수 또는 랭킹 이상치 감지 시 즉시 재실행
버전 관리: boundary_table.bak_YYYYMMDD_HHMM.json 백업 후 교체
변경 이력: PD 지시 로그·대화로그에 기각안 포함 기록 (P16 산출물 추적성)

§4-3. 변경 이력 테이블 필수 항목

밸런스 파일 하단에 다음 형식으로 기록한다.

일시	변경자	변경 필드	이전값 → 이후값	재미 근거	관련 PD 지시#

"재미 근거" 컬럼이 공란이면 수치 조정 금지: 어떤 재미를 강화하는지 먼저 정의하지 않은 수치 조정은 P30 위반이다.

§4-4. JSON/CSV SOT 맹신 금지 (기획팀 데이터 실측 의무 v1 §1-4)

실증 사건: 스테이지난이도곡선_v1.md §1에 "WorldMap_1~4 4개 그룹"이라는 표현이 기획 문서 SOT처럼 인용·전파되어, Phase 4 지역 1 전체를 "Stage 1~6 = 지역 1 = 6개"로 설계하는 오류가 발생했다. 실제 데이터는 21개 구역 × 각 4개 하위 스테이지 = 총 122 스테이지였다.

재발 방지 원칙:

기획 문서의 수치·구조를 무비판 수용 금지
Unity Export CSV/JSON 직접 실측 선행 의무
기획 문서 상단에 "데이터 소스 실측 일시" 필드 명기 필수
실측 일시 미기입 문서는 참조 금지 (참조 시 실측 재수행)

수치 검증 체계: 모든 DPS·TTK 계산은 Unity 실측 데이터 기반이어야 하며, "UTF N/N Passed" 형식으로 검증 통과 여부를 기록한다.

§5. 수치 설계 원칙 — EerieVillage 이관 핵심

§5-1. 재미 정의 없는 수치 조정 금지 (P30 실무)

수상한잡화점에서 모든 밸런스 변경 제안은 "어떤 재미를 강화하는가"를 먼저 정의했다. 대표 사례:

어뷰징 안전 마진 0% 기각: 이유는 기술적 정확성이 아니라 "false positive가 정상 플레이어 경험을 훼손한다"는 재미 관점이었다.
이슈 1 현 수치 고정 결정: G1 풀빌드 DPS +200~280%가 목표 +80~120% 대비 2배 초과이나, 수치 재조정보다 HP·TTK 설계가 현 DPS를 반영한 상태로 일관성을 유지하는 것이 재미 경험 보전에 유리하다고 판단.
Stage 10→11 내구도 +42% 급등: 오류가 아닌 "장비 투자 동기 부여"라는 재미 의도 설계임을 TTK 수치로 확인.

§5-2. 어뷰징 임계값과 재미의 교점

어뷰징 판정 기준을 너무 엄격하게 잡으면 실력 있는 정상 유저를 차단하게 된다. 이것은 재미 설계 실패다. 임계값 설계는 밸런스 기획자가 개입해야 하는 영역이다.

안전 마진 계수(0.80·1.05·1.10 등)는 "기술적으로 합당한 오차 범위"가 아니라 **"이 오차 범위 안에 있는 유저는 재미있게 플레이하고 있는 정상 유저"**라는 재미 판단이 선행된 수치다.

§5-3. P17 배타 배치 체계의 의미

★조건 배타 7종(P17)은 단순한 기술적 제약이 아니다. 각 배타 조합이 금지된 이유는 **"그 조합이 플레이어에게 이중·삼중 부담을 주어 재미를 손상시키기 때문"**이다.

배타 조합	재미 손상 이유
C2∧N2 (완벽 클리어 + 피격 제한)	피격 최소화 부담을 두 방향에서 동시 부과 — 스트레스 빌드
C6∧N4 (포션 절제 + 쉴드 하한)	회복 빌드 외 빌드 선택지 전면 배제 — 다양성 파괴
N5∧N6 (후열 선공 + 전열 선공)	타겟팅 자유도 박탈 + 논리 모순 — 달성 불가 조건

EerieVillage에서 유사한 "달성 조건" 체계를 설계할 때, 각 조건 쌍의 재미 충돌 여부를 먼저 검토한다.

§5-4. 드랍률·확률 설계 교훈

수상한잡화점 드래프트 확률:

G1(일반) 66.2%, G2 19.9%, G3 9.9%, G4 3.3%, G5 0.66%

핵심 교훈:

G5 물약 카드 등장 확률 = 0.66% × (G5 중 물약 비율) ≈ ~0.15% → "나오면 기적" 수준
이 확률에서 "물약 빌드"는 설계 의도와 달리 사실상 형성 불가능한 빌드가 되어버림
빌드 형성에 필요한 핵심 카드 등장 확률을 역산해서 "1런에 빌드 시작이 가능한 최소 확률"을 별도로 검증해야 한다
확률 표기는 분수·백분율 동시 기재: G5 = 10/1510 ≈ 0.66%

EerieVillage에서 "퇴마 도구" 드랍 풀 설계 시 동일한 검증이 필요하다.

변경 이력 (P16 산출물 추적성)

일시	변경자	변경 내역	재미 근거	관련 지시
2026-04-20	밸런스 기획자 (balance-designer)	전체 신설 — NerdNavis 수상한잡화점 밸런스 시행착오 5섹션 추출	BurningTimes EerieVillage 밸런스 설계 품질 향상	BurningTimes 조직 전환 기점 자산 추출

참조 원본: REQ001·REQ002 기획팀→개발팀 소통 (2026-04-14·16) / 어뷰징판정솔루션 기획서 v1 (2026-04-17) / Day11-14 밸런스축 본작업 v1 (2026-04-20) / 대화로그 수상한잡화점 2026-04-20 / 기획팀 데이터 실측 의무 v1 (2026-04-20)

16 KiB Raw Blame History Unescape Escape