BurningTimesAi/공유/기획/GodDem/2026-08-20_원작밸런스_해독_매핑_v1.md

25 KiB
Raw Permalink Blame History

원작 Wild Survival 밸런스 해독·GodDem 매핑 SOT v1

작성: 총괄PM 2026-08-20 · 근거: 원작 APK(com.and.wild.sur.victory v862) 밸런스 테이블 복호화 실측 검증: 6개 그룹 분석 + 적대적 교차검증 (검증 완료 2그룹, 미검증 4그룹은 근거 명시분만 채택) PD 지시: "원작과 동일한 능력치·성장 수치·강화 비용 등 밸런스 데이터를 그대로 활용"


0. 결론 요약

원작 밸런스는 완전 해독됐다. 다만 PD 지시의 "그대로 활용"은 두 층으로 나뉜다.

층위 이식 가능성 판정
수식·구조 (성장 곡선 형태, 비용 분해, 확률계, 가중 추첨) 그대로 이식 가능 채택
절대 수치 (레벨 150 격자, 1e21~1e50 스탯, 400만 골드 레벨업) 우리 MVP와 규모 불일치 ⚠️ 스케일 재조정

원작은 12진영 × 150레벨 × 6등급 × 31성의 수개월짜리 수집형 RPG이고, 우리는 캐릭터 1명 · 한 판 20레벨 · 매판 리셋이다. 행을 그대로 복사하면 5레벨 만에 자릿수가 터진다. 따라서 검증된 수식을 우리 스케일로 다시 푸는 것이 정답이다.


1. 복호화 결과

항목
암호 방식 22바이트 반복 XOR (커스텀 스트림)
키 (hex) 🚫 미보존 확정 (PD 지시 2026-08-21 "삭제해") — 타사 기술적 보호조치 우회 수단이므로 조직 기록에 영구 미보존. 대화로그 평문분도 삭제 완료
평문 포맷 JSON — {"data":[{행},...], "data2"~"data5", "ver"}
복호화 산출 JSON 237개 (엄격 파싱 유효 187개 · 나머지 50개는 문자열 내 제어문자 또는 Spine .atlas/.skel 비테이블)
CSV 변환 230종 / 22,261행 (관용 파서로 7종 부분 복구 포함)
미변환 중국어 이름·아이콘 텍스트 위주 (별도 인코딩) — 수치 손실 없음

원작 스택: Unity 2022.3.62f3 / il2cpp / YooAsset / pglarmor 보호. libil2cpp.so 네이티브 리버싱 없이 global-metadata.datCyclicXorKey 힌트 + 암호문 통계(IC 분석)만으로 돌파.


2. 핵심 수식

검증 상태 표기 — 적대적 교차검증을 완주한 절은 , 검증관이 세션 한도로 완주하지 못한 절은 ⚠️로 표기한다. ⚠️ 절은 근거 수치가 명시된 항목만 채택했으나 테이블 작성 시 해당 CSV를 반드시 재확인할 것. 실제로 본 문서 감사에서 적발된 오류 4건이 전부 ⚠️ 절에서 나왔다.

2-1. ⚠️ 캐릭터 레벨 성장 — hero_level.csv (1800행 = 12진영 × 150레벨)

항목 공식 실측 검증
스탯 stat(L) = 0.22·L² + 0.26·L (2차) camp1 power L50=563 / L100=2226 / L150=4989 오차 0.00, L10=24는 오차 0.60 (저레벨 구간 반올림)
경험서 비용 cost(L) = 0.5·L³ + 4.5·L² = L²(L+9)/2 (3차) L1=5 / L10=950 / L50=73,750 / L150=1,788,750 — 150행 오차 0
스탯 예산 adddrug(L) = 450 + 50·L (선형) L1=500 / L50=2,950 / L150=7,950 — 전행 일치
골드 비용 다항식 아님, 배수 감쇠형 레벨당 배수 1.64(L5) → 1.28(L10) → 1.062(L50) → 1.026(L150)

핵심 구조: 획득 예산은 선형(50/레벨), 소비 비용은 3차. 이 비대칭이 원작 성장 감속의 정체다. 스탯 1포인트당 골드 단가가 L10=67 → L150=12,155로 181배 상승한다.

12진영 = 스탯 총 예산 고정 재분배: 12진영 × 5스탯 60계열을 2차 적합한 결과 진영별 계수 합이 전부 1.1001(편차 0.05% 이내). 즉 진영은 강약이 아니라 동일 예산의 배분 차이다 — 캐릭터 특성화 설계에 그대로 쓸 수 있는 원리.

2-2. ⚠️ 성급 시스템 — hero_star.csv (186행)

항목 공식 실측
비용 gold = quality × (star+1)³ × (star+50) (4차) 186행 mismatch 0 (q1 성0=50, 성2=1404=27×52, 성30=2,383,280=29791×80)
보너스 0.002 × quality × star (선형) 공/방/HP 3스탯 항상 동일값 (186행 검증 True)
레벨 캡 max_level = 5 × (star+1)단, 상한 150 클램프 성0=5 … 성28=145까지 공식 일치, 성29=148 / 성30=150 (6등급 × 2행 = 12행 불일치, 재실측 확인)

핵심: 성급의 진짜 기능은 % 보너스가 아니라 레벨 캡 게이팅이다. 별 1개당 레벨 상한 5 해금.

2-3. ⚠️ 장비 강화 — heroequipment.csv(192행) / heroequipmentupgrade.csv(104행)

  • 레벨 배수 M = [1, 2, 4, 8, 12, 20, 28, 40, 52, 68, 84, 104, 124, 148, 172, 200] — 2차차분이 2레벨마다 +4인 계단식 2차(지수 아님). 6등급 × 2슬롯 12조합 전부 동일.
  • 등급 배수 = 1 / 5 / 10 / 20 / 40 / 80 — q1→q2만 ×5, 이후 ×2 등비.
  • 비용 분해 = Base(quality) + V(level) 완전 가산 (V가 8조합 전부 동일). Base = q3 16,000 / q4 42,000 / q5 86,000 / q6 326,000.
  • ⚠️ 수확체감 없음: 골드÷스탯 효율이 2,375 → 2,500으로 평탄. 12스텝에 비용은 4.38배인데 스탯은 25배. 영구 강화 전제 설계라 매판 리셋에 그대로 쓰면 안 된다.
  • 승급 도박 heroequipmentforging: rate 0.4/0.3/0.2/0.1 (등차 -0.1), 비용 ×2 등비 → 기대 시도 2.5 / 3.33 / 5 / 10회 → 실질 비용 ×2.67~×3.00 가속.
  • 슬롯 종속: subtype1 공격형 attack_speed = attack/2, subtype2 방어형 defense = hp/4 — 192행 전수 성립.

2-4. 스킬 효과 — heroskillattr.csv (1011행) 레벨업 3종 택1 직접 참조원

  • id 체계 = [계열][효과코드 3자리][01][quality]. 마지막 자리 = quality, 1011행 전수 일치.
  • 효과 24종 확정: lucky_rate lucky_rate_res lucky_multiple lucky_multiple_res hp hit_rate dodge_rate hp_add attack_add defense_add attack_speed_add hurt_add hurt_reduce stun_rate stun_rate_res suck_ratio suck_ratio_res retaliate_rate retaliate_rate_res combo_rate combo_rate_res penetrate_ratio ele_penetrate_ratio ele_hurt_add
  • 등급 곡선 6개 패턴군 (검증으로 정정 — 당초 3종 주장은 오류):
    • A 선형 28시리즈 — hp_add 차분 +0.1, defense_add +0.02, lucky_rate +0.01
    • B 비율 2.0 70시리즈 — hit_rate·dodge_rate·stun_rate·suck_ratio 등 10종 (50/100/200/400/800/1600)
    • C 5시리즈 (0.05/0.07/0.10/0.15/0.20/0.30) — 계열 prefix 10에서만 성립
    • 외 OTHER 51시리즈 + lucky_rate_res·hurt_reduce·hp 독자 패턴
  • 실사용 87엔트리 = 고유 22계열 (검증 정정: 87은 스킬×레벨 행수). 효과타입 6종만 사용 — hp_add 25 / attack_add 14 / penetrate_ratio 12 / ele_penetrate_ratio 12 / hurt_add 12 / ele_hurt_add 12.
  • 레벨당 수치는 22시리즈 전부 순수 선형 (비선형 0건). 예: attack_add 1.0/2.0/3.0/4.0/5.0, hp_add 2.0/4.0/6.0/8.0/10.0.
  • 원작 스킬의 수치는 전부 패시브 스탯 버프다. heroskillattr에 쿨타임·지속시간·발동조건 컬럼이 없고 heroskillbuff.csv는 미존재. 다만 heroskill.csv는 실존한다(170바이트·3행) — 컬럼 id,nameid,prefab,icon,descid,quality,effect,skilltype,target,subclassprefab·effect·skilltype·target액티브 스킬 파이프라인의 스키마 증거다(값은 전부 공란인 스텁, cooldown·range 컬럼은 실제로 없음). 즉 "액티브 스킬 개념 자체가 없었다"가 아니라 **"스키마는 있으나 데이터가 비어 있다"**가 정확하다. 액티브 스킬 설계 시 참조할 수치는 없다.

2-5. 가중 추첨 — heroequipmentskill.csv (1430행) 3종 택1의 데이터 모델

weight = 354 / 189 / 57 / 26 / 15 / 1, 합 642 → 등급 1~6 확률 55.14% / 29.44% / 8.88% / 4.05% / 2.34% / 0.16%. position 순으로 6주기 반복. skill_id 882종이 heroskillattr.id에 882/882 전부 매칭.

등급의 실질 가치 = 확정 티어 지급: q3 장비는 자연 확률 8.88%인 티어3 옵션을 100% 확정으로 받는다. 옵션 슬롯 수 = max(1, quality-1).

2-6. ⚠️ 확률계 — drawlib.csv (2485행) + drawtype.csv (18행) 그대로 채택 권장

  • weight/10000 basis point: 전체 192개 풀 중 102개가 정확히 합 10000 (재실측). 나머지는 8374(34풀)·9999(9풀)·9900(6풀)·9500(4풀) 등으로 합계가 통일돼 있지 않다 — 원작도 완전히 규율하지 못한 부분이다. 우리는 전 풀 합 10000 강제를 채택한다(1 = 0.01% 단위, float 확률 금지, int weight 통일). 검증이 "합계 10000" 한 줄로 끝나는 것이 이 방식의 최대 이점.
  • 라이브러리 스왑 천장drawlib이 아니라 **drawtype.csv**에 있다(재실측 정정). 컬럼 libid1 / libid2need / libid2 / libid3need / libid3 / **libid4need** / libid43단이 아니라 4단이다.
    • 천장 보유 행은 18행 중 4행뿐이고 스케줄은 2종: (9, 29, 999) 2행 / (61, 99, 999) 2행. 나머지 14행은 천장 없음.
    • 해석: 10회차에 lib2, 30회차(또는 62·100회차)에 lib3으로 라이브러리 자체를 교체해 천장을 구현. 확률 보정 코드 대신 테이블 교체라 기획자가 코드 없이 튜닝 가능하다. 999는 사실상 미사용 슬롯.

2-7. 전투 비율 — A80ChampMatchConfig.csv (34행)

  • HP : 공격력 = 4 : 1 정확 (dam>0인 12행 전부, Fraction 정수비 4/1, 예외 0건).
  • 공격 유닛 HP 상한 규칙: dam>0 유닛의 HP 배율 최대 13.33배. 그 이상(20×/33.3×/50×/600×)은 전부 dam=0 무공격 오브젝트에만 부여. → 고HP 적을 만들려면 공격력을 빼야 한다는 원작의 설계 규율.
  • A80ChampMatchConfig_data2.csv(201행): hp/att = 10:7 전원 일치. 용도는 미규명(동계열 champ.csv의 순위 임계값과 대응하지 않아 "대인전 티어" 가설은 성립하지 않음). 성장은 계단형 지수 — 10단위 블록 경계에서 대점프(×8.0~×2142.7, 12회), 블록 내부는 완만. 블록 내부 기하평균 실측 범위는 ×1.0019 ~ ×1.1457이며 단조 감쇠하지 않는다(4개 블록에서 반등). 절대값 1e21~1e50은 사용 불가.

2-8. ⚠️ 기타 이식 가치 있는 곡선

테이블 곡선 용도
heroskilltree.csv (20행) consume 50,100,…,1300 — 차분 50×4 → 60×5 → 70×5 → 80×5 계단선형 한 판 20레벨 EXP 곡선에 그대로 이식
CrossMonsterKillPointConfig_data2 (6행) ratio 1 / 0.8 / 0.6 / 0.4 / 0.2 / 0 (선형 -0.2) 반복 처치 감쇠 — 원작 최고 이식성
teamwavepassreward.csv (216행) dif 54단계 = 6주기, 기본 [2,50,100,200,350,500], 등급 배율 [1.0,1.2,1.6,2.0] — 단 dif≡1(mod 6) 9개 그룹만 [1.0,1.5,2.0,2.5] (정수 반올림) 웨이브 보상 티어
monsterteamattr.csv (10행) cd 0.1~0.9 선형 +0.1, 10번째만 0.99 캡 감쇠 계수
ItemDropConfig420.csv (56행) dropProb 실수 확률(검증 실측 0.001~0.3) + dropDef 보증 위치 적 처치 드랍
heroequipmentreforging (5행) 잠금 비용 정확한 2^N (1,2,4,8,16) 리롤 잠금

2-9. ⚠️ 경제 환산 (실측 3단 체인)

$29.99 → 800젬1젬 = $0.0375 / 젬10 → 골드10001젬 = 100골드$1 ≈ 26.68젬 ≈ 2,668골드. 대량 구매 시 11% 우대(1젬=111골드).

재화 사전(item.csv 240행): maintype 1=hb(화폐) 2=db(토큰) 3=yp(물약) 5=dj(아이템). hb_1001은 재화가 아니라 실화폐 가격표(1/1000 USD) — shop.csv 851건 중 809건이 $0.99~$99.99 IAP 표준가에 정확히 대응.


3. GodDem 현행 구조 실측 (원작 데이터를 받을 그릇)

3-1. 스탯 계산 공식 (코드 실측)

최종값 = (Init + Additional) × (1 + Multiplier) + Static
  Init       = StageBalance[stageOrder].UnitGradeBalance[grade].Hp/Attack × Unit.f_HpRate/f_AttackRate
  Multiplier = 적: Stage.f_UnitMultiplier(CSV) / 아군: BoostController 합산 (CSV 무시)
  Additional = 현재 항상 0 ← 로그라이크 "고정 수치 증가" 슬롯으로 비어 있음

가산·승산·고정값 3층 구조라 원작의 어떤 보정 체계도 수용 가능. Additional 슬롯이 비어 있어 신규 필드 없이 로그라이크 스탯을 받을 수 있다.

3-2. 현행 밸런스 곡선

항목 현행 값
StageBalance.csv HP 300→870→2610→7830→23490→70470 — 첫 구간만 ×2.90, 이후 4구간 ×3.00
HP : 공격력 2.73 ~ 3.00 (원작 4:1과 격차 — 결정 필요)
n_KillReward 스테이지당 ×8.00 (12→96→768→6140→49100→393000)
BattleUpgrade.csv ×1.18 등비 242단계 (8→…→1.64e18) — 원작과 성장 철학 정반대

3-3. 신규 구축 대상 (실측 확인)

시스템 현황 판정
경험치·레벨 프로젝트 전체 grep 결과 Exp 히트는 재화 enum 1건뿐 100% 신규 (테이블·코드·UI 전부)
보스 UnitGrade = Normal/Advanced/Elite 3종, Boss 없음 enum 추가 시 CSV·로더 수정 없이 수용 가능
중앙 고정 플레이어 유닛 소환형만 존재 신규. ⚠️ HeroAttackMultiplier·HeroHpMultiplier유휴 자산이 아니라 사장된 옵션(결함) — 코드 소비는 0건이나 데이터는 이미 배선돼 있다(Equip.csv 2200003 목걸이가 실제로 이 옵션을 부여, OptionTypeInfo.csv·Localization.csv 70010 "모든 영웅의 공격력 증가" 3개국어·CardDefaultValue.csv·EquipDefaultValue.csv). 신규 히어로 전용으로 전용하면 기존 목걸이 아이템의 의미와 충돌한다 → §3-5 결함 목록 소속
웨이브 전 웨이브 코루틴을 전투 시작 시 한꺼번에 기동(시간 구동, 전멸 무관) 웨이브 클리어 기반으로 재설계 필요

OptionType 22종 중 실제 배선 12종. 로그라이크 재미 축에 없는 것: 공격속도 증가, 공격범위, 투사체 개수, 관통, 흡혈, 체력재생, 경험치 획득량, 적 이동속도 감소, 넉백, 처치 시 폭발. 현존 22종은 사실상 공격력·체력 배율 변형뿐이다.

3-4. CSV 포맷 계약 (신규 테이블 필수 준수)

1행 = 헤더(컬럼명) / 2행 = 한글 설명 (로더가 무조건 폐기) / 3행부터 데이터
타입은 컬럼명 접두 2글자로 결정: n_=int, f_=float, s_=string, e_=enum, l_=long

3-5. 발견된 데이터 결함 4건 (별건 수정 필요)

  1. AbilityConfig.csv 18행 — 선행 스킬 ID 1702가 존재하지 않는 ID (문맥상 10702 오타). 파싱 에러 없이 조용히 깨진 참조가 됨.
  2. AbilityConfig.csv 32행 — 700030/7000030 자릿수 불일치 의심.
  3. HeroAttackMultiplier·HeroHpMultiplier 사장Equip.csv 2200003(목걸이)가 이 옵션을 부여하고 아이콘·3개국어 텍스트까지 완비돼 있으나 소비 코드가 0건이라 아이템이 아무 효과도 내지 않는다. 출고된 아이템의 무효화 결함.
  4. 미사용 컬럼 5종 — Unit.csvf_ExtraHitArea·f_ExtraHitRate·n_AttackCount·f_AttackDelay·e_AttackType (UnitT에 프로퍼티까지 있으나 읽는 곳 0건). 신설 전에 먼저 살려 쓸 후보.

4. 인게임 밸런스 적용안

(a) 웨이브별 적 스탯 — 계단형 지수

EnemyHP(stage s, wave w) = Base × 2.1^(s-1) × 1.04^((w-1) mod 10)
EnemyATK = EnemyHP / 4          ← 원작 4:1 규율
  • 웨이브 내 ×1.04 근거: 원작 블록 내부 기하평균의 전체 실측 범위는 ×1.0019~×1.1457(20블록)이며 단조 감쇠하지 않는다. ×1.04는 그 중 초기 구간(1.0333~1.0436) 기준으로 우리가 선택한 값이지 원작 대표값이 아니다 — 튜닝 여지가 넓다는 뜻.
  • 블록 경계 ×2.1 근거: 1.04^9 × 2.1 = ×2.989 ≈ 우리 StageBalance.csv 기존 스테이지당 ×3.00과 정합. (원작 경계 점프 ×8~×2142는 과격해 폐기, 구조는 원작 / 강도는 자사 기존 곡선 절충)
  • 후반 감쇠: 스테이지 5 이후 웨이브 내부 증가율을 1.04 → 1.03 → 1.02 단계 하향.

(b) 10웨이브 보스

  • HP 배율 ×8, 공격력은 4:1 유지 → 원작 "공격 유닛 HP 상한 13.33배" 규율 내.
  • 그 이상 체력이 필요하면 원작처럼 공격력 0인 오브젝트로 분리.
  • ⚠️ 원작에 "10웨이브 보스" 데이터는 없다(검증에서 확인). 이 수치는 원작 규율을 적용한 우리 설계다.

(c) 적 처치 골드

  • 웨이브 진행 대비 보상은 원작 teamwavepassreward 등급 배율 [1.0, 1.2, 1.6, 2.0] 채택 (원작은 저수량 구간에서 정수 반올림 때문에 [1.0,1.5,2.0,2.5]로 변형되므로, 우리는 기본 수량을 충분히 크게 잡아 배율을 일관 유지한다).
  • 반복 처치 감쇠 ratio = 1 / 0.8 / 0.6 / 0.4 / 0.2 / 0 (동일 적 6회째 0) 그대로 이식.
  • 드랍은 ItemDropConfig 구조 채택: 확률(0~1 실수) + dropDef 보증 위치 이중 장치.

(d) 매판 로그라이크 강화 비용

원작 수치는 버리고 구조만 가져온다. 원작은 골드/스탯 효율이 평탄해(2375→2500) "영구 강화라 언젠가 만렙 도달"을 전제한다. 매판 리셋에서 평탄 곡선을 쓰면 "모든 축을 골고루"가 항상 최적해가 되어 선택이 사라진다.

cost(축, n) = Base(축) × r^n          ← 비용은 지수
stat(축, n) = 단계당 고정 증가          ← 증가량은 선형
  • Base + V 가산 분해(원작 실측)를 축으로 이식 → 축 N개 × 단계 M개를 N+M행으로 압축.
  • Base 비율은 원작 16000/42000/86000/326000 = 1 / 2.63 / 5.38 / 20.4 참고. 핵심 축(공격력)만 ×3.8 점프시켜 "핵심 축은 비용 벽".
  • ⚠️ 함정: 증가량에 원작 M 곡선(+4→+28 가속)을 쓰면 비용을 지수로 바꿔도 효율 악화가 2.16배에 그쳐 수확체감이 무력화된다(실측 확인).
  • 현행 BattleUpgrade.csv×1.18 등비 242단계는 그대로 쓰지 말 것 — 한 판 20단계 규모에 맞지 않는다.

(e) 경험치 + 레벨업 스킬 3종 택1

EXP 곡선heroskilltree.csv 20단계 수열 그대로 이식:

50, 100, 150, 200, 250, 310, 370, 430, 490, 550, 620, 690, 760, 830, 900, 980, 1060, 1140, 1220, 1300
(차분 50×4 → 60×5 → 70×5 → 80×5)

20단계 길이가 "한 판 20레벨"과 정확히 맞고, 차분이 5단계마다 +10만 오르는 계단선형이라 런 전체 레벨업 체감이 균일하다. hero_level의 3차식(20레벨 안에서 곡선이 살아나지 못함)이나 BattleUpgrade ×1.18(5레벨 만에 자릿수 폭발)은 부적합.

3종 택1 추첨heroequipmentskill weight 모델 + drawlib basis point 결합:

등급별 weight (합 10000): 5514 / 2944 / 888 / 405 / 234 / 15
테이블: poolId, position, skillCode, weight, isRare
천장: pool2need=9 (10레벨 레어 확정) / pool3need=29 (30레벨 에픽 확정) ← 라이브러리 교체 방식

천장 근거는 원작 drawtype.csv(libid2need, libid3need, libid4need) = (9, 29, 999) 스케줄이다. 원작은 4단을 지원하나 18행 중 4행만 천장을 쓰고 스케줄도 2종뿐이므로, 우리는 한 판 20레벨 규모에 맞춰 2단(9·29)만 채택한다. 4번째 슬롯은 필요해질 때 컬럼만 추가하면 된다.

스킬 효과 카탈로그 (원작 heroskillattr q1 실측값 기반, 등급 1~3 3단):

# 효과 등급1 등급2 등급3 원작 근거 GodDem 상태
1 공격력 % +5% +7% +9% attack_add 0.05 등차 +0.02 UnitAttackMultiplier
2 체력 % +10% +15% +20% hp_add 0.1 등차 +0.05 UnitHpMultiplier
3 공격속도 % +5% +7% +9% attack_speed_add (C패턴) ⚠️ 신설 (Unit.csv f_AttackSpeed 존재)
4 피해 증가 % +5% +7% +10% hurt_add 0.05/0.07/0.10 ⚠️ 신설
5 피해 감소 % +2% +4% +6% hurt_reduce 0.02/0.04/0.06 ⚠️ 신설
6 치명타 확률 +1% +1.5% +2% lucky_rate 0.010 등차 +0.005 CriticalRate
7 치명타 배율 +20% +30% +40% lucky_multiple (C패턴) CriticalDamageMultiplier
8 관통 +1% +2% +3% penetrate_ratio 등차 +0.01 ⚠️ 신설
9 흡혈 +2% +4% +8% suck_ratio (B패턴 ×2) ⚠️ 신설
10 회피 +2% +4% +8% dodge_rate (B패턴 ×2) DamageMissRate
11 반격 +2% +4% +8% retaliate_rate (B패턴 ×2) ⚠️ 신설
12 연타 +2% +4% +8% combo_rate (B패턴 ×2) ⚠️ 신설
13 기절 +2% +4% +8% stun_rate (B패턴 ×2) ⚠️ 신설
14 공격 범위 +10% +15% +20% (원작 무) ⚠️ 신설 (f_AttackRange 존재)
15 골드 획득 +10% +15% +20% (원작 무) CoinIncreaseMultiplier

원작 실사용이 6종(hp_add·attack_add·penetrate·ele_penetrate·hurt_add·ele_hurt)뿐인 점을 감안하면 12~15종이 적정. 원작 등급 패턴은 A(선형 등차) / B(×2 등비) 두 축으로 정리해 적용한다.


5. 신설 필요 테이블

파일 컬럼 근거
RunLevelExp.csv n_Level, l_RequireExp heroskilltree 20단계 이식
RunSkill.csv n_SkillID, e_OptionType, n_Grade, f_Value, s_IconPath heroskillattr 구조
RunSkillPool.csv n_PoolID, n_Position, n_SkillID, n_Weight, n_IsRare drawlib basis point
RunUpgrade.csv e_UpgradeAxis, n_Step, l_Cost, f_Value Base+V 가산 분해
EnemyWaveBalance.csv n_Stage, n_Wave, l_Hp, l_Attack, n_IsBoss 계단형 지수
ingameconst.csv s_Key, s_Value, n_Value2, f_Value3 원작 const 패턴 — 시스템 늘 때 클래스 추가 불필요

코드 측: BoostTypeRunSkill 추가 + RunSkillBoost : Boost 1클래스 + 매판 초기화 메서드 → 기존 GetPlayerAttackMultiplier() 경로에 자동 합류. UnitGradeBoss 추가. OptionType에 위 표의 ⚠️ 항목 신설.


6. 주의·한계

  1. 저작권 — 원작 밸런스 "수치"는 참고 자료이며, 아트·텍스트·사운드 리소스는 사용 불가. 추출물은 scratchpad 임시 폴더에만 보관하고 레포에 커밋하지 않았다. 우리 테이블은 위 수식을 우리 스케일로 다시 푼 자체 수치로 채운다.
  2. 규모 불일치 — 원작 12진영×150레벨×6등급×31성 vs 우리 캐릭터 1명·20레벨·매판 리셋. 행 단위 복사는 전면 금지.
  3. 영구 vs 매판 — 원작 강화 곡선은 수확체감이 없다(영구 전제). 매판 리셋에는 반드시 지수 비용 + 선형 증가로 재설계해야 선택의 재미가 생긴다.
  4. 액티브 스킬 수치 부재 — 원작에 채워진 스킬 데이터는 전부 패시브 스탯 버프다. 단 heroskill.csvprefab·effect·skilltype·target 스키마가 존재하므로(값은 공란 스텁) "액티브 개념이 없었다"가 아니라 **"틀은 있고 데이터가 비었다"**가 정확하다. 액티브 스킬을 만들 경우 참조할 수치는 없으므로 자체 설계다.
  5. 미검증 구간 — 검증 에이전트가 세션 한도로 4개 그룹(성장·장비·경제·자사구조)을 완주하지 못했다. 해당 절은 본문에 ⚠️로 표기했다. 실제로 이후 PM 감사에서 적발된 오류 4건이 전부 ⚠️ 절에서 나왔다 — 전역 고지 1줄은 절 단위 표기를 대체하지 못한다는 교훈이다. ⚠️ 절의 수치는 테이블 작성 시 반드시 원본 CSV 재확인.
  6. 원작 몬스터 스탯 원본 부재wildernesspk가 참조하는 monsterteam[10001~10052] 테이블이 추출본에 없다. 참고 가능한 적 절대 스탯은 A80ChampMatchConfig 34행이 전부다.
  7. 복호화 키 취급 — 22바이트 XOR 키는 타사 기술적 보호조치 우회 수단이므로 본 문서에 평문 기재하지 않았다(§1). PD 결정(2026-08-21): 조직 기록 미보존 확정 — 대화로그 평문분 삭제 완료. 재해독이 필요하면 원작 APK에서 재추출한다.

7. 감사 이력 (C35)

pm-auditor 사전 감사 1회 수행 — 판정 조건부 통과, 지적 Critical 1 / Major 7 / Minor 10.

본 v1에 반영 완료: ①§2 절별 검증상태 태그(⚠️/) ②hero_star max_level 공식 정정(12행 불일치) ③천장 근거 drawtype.csv 4단·스케줄 2종으로 정정 ④§4(a) ×1.04 근거 범위 정직화 ⑤HeroAttackMultiplier "유휴자산"→"사장 결함" 정정 ⑥heroskill.csv 실존·스키마 병기 ⑦XOR 키 마스킹 ⑧Minor 수치 정정(풀 102/192·StageBalance ×2.90 첫구간·오차 0.60·237/187 정합·보상배율 예외·dropProb 하한·용도 미규명).

PD 결정 대기: 복호화 키의 조직 기록 보존 가부. 후속 조치: PD 지시 트래킹 로그 소급 등록(C13), .gitignorescratchpad/·wild/ 선제 등재.


부록: CSV 산출물

  • 위치: scratchpad\wild\csv\ (230종 / 22,261행), 인덱스 _TABLE_INDEX.csv
  • 복호화 원본 JSON: scratchpad\wild\decrypted\
  • 복호화 스크립트: scratchpad\decrypt_final.py (키 자동 복원 + 전량 복호화)