25 KiB
원작 Wild Survival 밸런스 해독·GodDem 매핑 SOT v1
작성: 총괄PM 2026-08-20 · 근거: 원작 APK(
com.and.wild.sur.victoryv862) 밸런스 테이블 복호화 실측 검증: 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.dat의 CyclicXorKey 힌트 + 암호문 통계(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_ratelucky_rate_reslucky_multiplelucky_multiple_reshphit_ratedodge_ratehp_addattack_adddefense_addattack_speed_addhurt_addhurt_reducestun_ratestun_rate_ressuck_ratiosuck_ratio_resretaliate_rateretaliate_rate_rescombo_ratecombo_rate_respenetrate_ratioele_penetrate_ratioele_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,subclass로prefab·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** / libid4— 3단이 아니라 4단이다.- 천장 보유 행은 18행 중 4행뿐이고 스케줄은 2종:
(9, 29, 999)2행 /(61, 99, 999)2행. 나머지 14행은 천장 없음. - 해석: 10회차에 lib2, 30회차(또는 62·100회차)에 lib3으로 라이브러리 자체를 교체해 천장을 구현. 확률 보정 코드 대신 테이블 교체라 기획자가 코드 없이 튜닝 가능하다.
999는 사실상 미사용 슬롯.
- 천장 보유 행은 18행 중 4행뿐이고 스케줄은 2종:
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 → 골드1000 → 1젬 = 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건 (별건 수정 필요)
AbilityConfig.csv18행 — 선행 스킬 ID1702가 존재하지 않는 ID (문맥상10702오타). 파싱 에러 없이 조용히 깨진 참조가 됨.AbilityConfig.csv32행 —700030/7000030자릿수 불일치 의심.HeroAttackMultiplier·HeroHpMultiplier사장 —Equip.csv2200003(목걸이)가 이 옵션을 부여하고 아이콘·3개국어 텍스트까지 완비돼 있으나 소비 코드가 0건이라 아이템이 아무 효과도 내지 않는다. 출고된 아이템의 무효화 결함.- 미사용 컬럼 5종 —
Unit.csv의f_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 패턴 — 시스템 늘 때 클래스 추가 불필요 |
코드 측: BoostType에 RunSkill 추가 + RunSkillBoost : Boost 1클래스 + 매판 초기화 메서드 → 기존 GetPlayerAttackMultiplier() 경로에 자동 합류. UnitGrade에 Boss 추가. OptionType에 위 표의 ⚠️ 항목 신설.
6. 주의·한계
- 저작권 — 원작 밸런스 "수치"는 참고 자료이며, 아트·텍스트·사운드 리소스는 사용 불가. 추출물은 scratchpad 임시 폴더에만 보관하고 레포에 커밋하지 않았다. 우리 테이블은 위 수식을 우리 스케일로 다시 푼 자체 수치로 채운다.
- 규모 불일치 — 원작 12진영×150레벨×6등급×31성 vs 우리 캐릭터 1명·20레벨·매판 리셋. 행 단위 복사는 전면 금지.
- 영구 vs 매판 — 원작 강화 곡선은 수확체감이 없다(영구 전제). 매판 리셋에는 반드시 지수 비용 + 선형 증가로 재설계해야 선택의 재미가 생긴다.
- 액티브 스킬 수치 부재 — 원작에 채워진 스킬 데이터는 전부 패시브 스탯 버프다. 단
heroskill.csv에prefab·effect·skilltype·target스키마가 존재하므로(값은 공란 스텁) "액티브 개념이 없었다"가 아니라 **"틀은 있고 데이터가 비었다"**가 정확하다. 액티브 스킬을 만들 경우 참조할 수치는 없으므로 자체 설계다. - 미검증 구간 — 검증 에이전트가 세션 한도로 4개 그룹(성장·장비·경제·자사구조)을 완주하지 못했다. 해당 절은 본문에 ⚠️로 표기했다. 실제로 이후 PM 감사에서 적발된 오류 4건이 전부 ⚠️ 절에서 나왔다 — 전역 고지 1줄은 절 단위 표기를 대체하지 못한다는 교훈이다. ⚠️ 절의 수치는 테이블 작성 시 반드시 원본 CSV 재확인.
- 원작 몬스터 스탯 원본 부재 —
wildernesspk가 참조하는monsterteam[10001~10052]테이블이 추출본에 없다. 참고 가능한 적 절대 스탯은A80ChampMatchConfig34행이 전부다. - 복호화 키 취급 — 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), .gitignore에 scratchpad/·wild/ 선제 등재.
부록: CSV 산출물
- 위치:
scratchpad\wild\csv\(230종 / 22,261행), 인덱스_TABLE_INDEX.csv - 복호화 원본 JSON:
scratchpad\wild\decrypted\ - 복호화 스크립트:
scratchpad\decrypt_final.py(키 자동 복원 + 전량 복호화)