From 8a0d4c9abd6e49b88a3d2e9442e15adc76d3ee45 Mon Sep 17 00:00:00 2001 From: swrring Date: Thu, 16 Apr 2026 17:21:58 +0900 Subject: [PATCH] =?UTF-8?q?comm(dev=E2=86=92plan):=20REQ001~003=20?= =?UTF-8?q?=EC=BD=94=EB=93=9C=20=EB=B6=84=EC=84=9D=20=EC=9D=91=EB=8B=B5=20?= =?UTF-8?q?=E2=80=94=20=EA=B8=B0=ED=9A=8D=ED=8C=80=20=EB=B0=B8=EB=9F=B0?= =?UTF-8?q?=EC=8B=B1=20=EC=9E=91=EC=97=85=20=EC=A7=80=EC=9B=90=20(PD?= =?UTF-8?q?=EB=8B=98=20=EC=A7=80=EC=8B=9C)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - REQ001: 각성트리 '500%' = Get_Value()에서 5.0으로 파싱, '5'와 동일 (입력 형식 불일치) - REQ002: 장비옵션 음수값은 의도적 트레이드오프 설계, AttackCoolTime 음수는 공속 보너스 - REQ003: 인장 슬롯 6개, 진화 단계별 순차 개방, 속성 매칭 제한 Co-Authored-By: Claude Opus 4.6 (1M context) --- .../2026-04-16_REQ001_응답_각성트리_퍼센트값.md | 76 +++++++++++++++++++ .../2026-04-16_REQ002_응답_장비옵션_음수값.md | 59 ++++++++++++++ .../2026-04-16_REQ003_응답_인장_장착수제한.md | 76 +++++++++++++++++++ .../2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md | 2 +- .../2026-04-14_REQ002_장비옵션_음수값_의미확인.md | 2 +- .../2026-04-14_REQ003_인장_장착수제한_확인.md | 2 +- 6 files changed, 214 insertions(+), 3 deletions(-) create mode 100644 공유/소통/개발팀→기획팀/2026-04-16_REQ001_응답_각성트리_퍼센트값.md create mode 100644 공유/소통/개발팀→기획팀/2026-04-16_REQ002_응답_장비옵션_음수값.md create mode 100644 공유/소통/개발팀→기획팀/2026-04-16_REQ003_응답_인장_장착수제한.md diff --git a/공유/소통/개발팀→기획팀/2026-04-16_REQ001_응답_각성트리_퍼센트값.md b/공유/소통/개발팀→기획팀/2026-04-16_REQ001_응답_각성트리_퍼센트값.md new file mode 100644 index 0000000..c9f5541 --- /dev/null +++ b/공유/소통/개발팀→기획팀/2026-04-16_REQ001_응답_각성트리_퍼센트값.md @@ -0,0 +1,76 @@ +--- +from: 개발팀장 +to: 기획팀장 +type: REQ응답 +subject: "REQ001 응답 — 각성트리 퍼센트값 파싱 방식 확인" +priority: high +status: 대기 +date: 2026-04-16 +ref: 공유/소통/기획팀→개발팀/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md +--- + +# REQ001 응답 — 각성트리 퍼센트값(`'500%'`) 실제 파싱 방식 + +## 결론 + +**`'500%'`는 런타임에서 `5.0f`(= 500 * 0.01)로 파싱된다. `'5'`와 결과가 동일하며, 데이터 입력 형식의 불일치(입력 오류)이다.** + +기획팀이 제시한 4가지 가능성 중 **사실상 (D) 데이터 입력 오류**에 해당. 단, 런타임 결과는 정상 동작하므로 긴급 수정은 불필요. + +## 코드 근거 + +### 핵심 파싱 메서드: `table_base.cs` 20~26행 `Get_Value(string str)` + +```csharp +protected float Get_Value(string str) +{ + if (IsPercentValue(str)) return float.Parse(str.Replace("%", "")) * 0.01f; + else if (str.Contains("s")) return float.Parse(str.Replace("s", "")); + else if (str.Contains("exp")) return float.Parse(str.Replace("exp", "")); + return float.Parse(str); +} +``` + +- `%` 포함 시: 숫자 추출 후 `* 0.01f` 적용 +- `%` 미포함 시: 숫자를 그대로 float 변환 + +### `table_PCAwakening.cs` 53행에서 호출 + +```csharp +temp.f_Value = Get_Value(temp.s_Value); +``` + +### 파싱 결과 비교 + +| s_Value | 파싱 결과 (f_Value) | 해석 | +|---------|-------------------|------| +| `"5"` | `5.0f` | 고정값 5 | +| `"500%"` | `5.0f` (= 500 * 0.01) | 퍼센트 표기이나 **결과 동일** | + +### 실측 검증: PCID=6001, MaxHP 노드 + +- Step 2, 14, 26: `s_Value="5"` => `f_Value = 5.0` +- Step 39, 51, 63, 86, 110, 123: `s_Value="500%"` => `f_Value = 5.0` + +**PCID 6001에만 `500%` 형식이 다수 존재.** PCID 6002~6005는 대부분 정수 형식 사용. + +## 만렙 총 효과 계산 (기획팀 질문 2번) + +`Get_Value(int pcid, ServerData sdata, int addlv)` 메서드: `f_Value + (f_ValuePerLv * (lv - 1))` + +따라서 `s_Value="500%"`, `s_UpgradeStatValuePara="100%"`, `n_MaxLv=5` 일 때: +- `f_Value = 5.0`, `f_ValuePerLv = 1.0` (100% * 0.01) +- 만렙 효과 = `5.0 + 1.0 * 4 = 9.0` (고정값 +9) + +기획팀 추정 `900%`는 잘못된 해석. 실제는 **고정값 +9**. + +## 기획팀 밸런싱 시 유의사항 + +1. `'500%'`는 "MaxHP를 500% 배율 적용"이 아니라, 파이프라인에 의해 **고정값 5.0으로 변환** +2. 레벨업당 고정 증분 방식 (f_Value + f_ValuePerLv * (lv-1)) +3. **Phase 3 기여도 재계산 시 DPS +1067%라는 비정상 수치는 해소됨** — 실제 효과는 고정값 수준 +4. 다른 스탯(Attack_Min, Attack_Max, MaxPotion 등)도 동일한 파싱 로직 적용 + +## 권장 조치 + +기획 엑셀 시트에서 `s_Value` 컬럼 포맷을 정수 또는 퍼센트 한 가지로 통일 권장. 현재 런타임 결과는 동일하므로 긴급 수정 불필요. diff --git a/공유/소통/개발팀→기획팀/2026-04-16_REQ002_응답_장비옵션_음수값.md b/공유/소통/개발팀→기획팀/2026-04-16_REQ002_응답_장비옵션_음수값.md new file mode 100644 index 0000000..1a2150e --- /dev/null +++ b/공유/소통/개발팀→기획팀/2026-04-16_REQ002_응답_장비옵션_음수값.md @@ -0,0 +1,59 @@ +--- +from: 개발팀장 +to: 기획팀장 +type: REQ응답 +subject: "REQ002 응답 — 장비옵션 음수값은 의도적 트레이드오프" +priority: medium +status: 대기 +date: 2026-04-16 +ref: 공유/소통/기획팀→개발팀/2026-04-14_REQ002_장비옵션_음수값_의미확인.md +--- + +# REQ002 응답 — 장비옵션 음수값 의미 + +## 결론 + +**음수 스탯은 의도적인 트레이드오프 설계이다. 데이터 오류가 아니다.** + +기획팀이 제시한 가능성 중 **(A) 그대로 차감 (의도적 페널티)**에 해당. 단, `AttackCoolTime`은 예외. + +## 코드 근거 + +### 1. 무기 MainOption2에 음수값 배정 + +EquipmentList.json에서 무기의 `n_MainOtion2`가 참조하는 StatusOptionSet: + +| StatusID | Stat1 | DefaultVal1 | 해석 | +|----------|-------|-------------|------| +| 13010001 | CriDmg | **-20%** | 치명타 피해 -20% (페널티) | +| 13010002 | HitRate | **-3** | 명중률 -3 (페널티) | +| 13010003 | Cri | **-2%** | 치명타 확률 -2% (페널티) | +| 13010004 | AttackCoolTime | **-10%** | 공격 쿨타임 -10% = **공속 10% 증가 (보너스)** | +| 13010005 | MaxHP | **-10** | 최대HP -10 (페널티) | + +`UpgradeStatValuePara1`이 모두 `0` → **강화해도 음수값 불변 (고정 페널티)**. + +### 2. 방어구 MainOption2에도 음수값 존재 + +| StatusID | Stat1 | DefaultVal1 | +|----------|-------|-------------| +| 13030001 | Avoid_Melee | **-5%** | +| 13030002 | Avoid_Melee | **-3%** | +| 13030003 | Avoid_Melee | **-1%** | + +### 3. 세트 옵션의 양수/음수 쌍 (트레이드오프 설계 증거) + +- ID 21006(-10% MaxHP_Mul) + ID 21007(+10% MaxShield_Mul): "HP 깎고 보호막 강화" +- ID 21017(+30% CriDmg) + ID 21018(-30% CriDmg): 세트별 방향 차별화 + +### 4. AttackCoolTime -10% 해석 (기획팀 질문 3번) + +`eStat.AttackCoolTime`은 공격 쿨타임이므로 **음수 = 쿨타임 감소 = 공격속도 증가**. 이것은 페널티가 아니라 **보너스**. 해당 무기 라인(n_MainOtion2=13010004)은 다른 라인의 CriDmg 페널티 대신 공속 보너스를 받는 변종. + +## 기획팀 밸런싱 시 유의사항 + +1. 무기 각 라인은 MainOption1(공격력 등 주 스탯) + MainOption2(트레이드오프)로 구성 +2. 음수값은 **강화로도 완화되지 않는 고정 페널티** (UpgradeVal=0) +3. 풀셋 시뮬 시 음수가 합산되는 것은 **정상 동작** +4. DPS/EHP 계산 시 `AttackCoolTime` 음수는 **DPS 증가 효과로 반영** 필요 +5. 장비 라인별 트레이드오프 구조를 인지하고 밸런싱에 반영 권장 diff --git a/공유/소통/개발팀→기획팀/2026-04-16_REQ003_응답_인장_장착수제한.md b/공유/소통/개발팀→기획팀/2026-04-16_REQ003_응답_인장_장착수제한.md new file mode 100644 index 0000000..ec4802d --- /dev/null +++ b/공유/소통/개발팀→기획팀/2026-04-16_REQ003_응답_인장_장착수제한.md @@ -0,0 +1,76 @@ +--- +from: 개발팀장 +to: 기획팀장 +type: REQ응답 +subject: "REQ003 응답 — 인장 기본 슬롯 6개, 진화 순차 개방, 속성 매칭 제한" +priority: low +status: 대기 +date: 2026-04-16 +ref: 공유/소통/기획팀→개발팀/2026-04-14_REQ003_인장_장착수제한_확인.md +--- + +# REQ003 응답 — 인장 장착수 제한 + +## 결론 + +**인장 기본 슬롯 6개. 캐릭터 진화(Evolution) 단계에 따라 순차 개방. 속성(Element) 매칭 제한 있음.** + +## 코드 근거 + +### 1. 기본 슬롯 수 = 6개 + +`ServerClass.cs` 1665행: +```csharp +public List list_equipseal = new List { 0, 0, 0, 0, 0, 0 }; +``` + +PC 생성 시 6개 슬롯 초기화 (값 0 = 빈 슬롯). + +### 2. 슬롯 개방 조건 = 캐릭터 진화(Evolution) 단계 + +`MainMenu_Hero_Seal.cs` 60~63행: +```csharp +var alv = MyValue.sdata.Get_PCEvolution(pcid); +gos_lock[0].SetActive(false); // 슬롯 0은 항상 개방 +for (int i = 1; i < gos_lock.Length; i++) + gos_lock[i].SetActive(i > alv); +``` + +| 진화 단계 | 개방 슬롯 수 | +|----------|-------------| +| 0 | 1개 (슬롯0) | +| 1 | 2개 (슬롯0~1) | +| 2 | 3개 (슬롯0~2) | +| 3 | 4개 (슬롯0~3) | +| 4 | 5개 (슬롯0~4) | +| 5+ | 6개 (전체) | + +진화 최대 레벨: `MyValue.PCEvolutionMaxLv = 6` (`MyValue.cs` 22행) + +### 3. 속성(Element) 매칭 제한 + +`ServerClass.cs` 717~734행 `Get_CanEquipSealSlotIndex`: +- 각 슬롯은 캐릭터별로 **고정된 속성(Element)**이 지정 (`pclist` 테이블의 `s_SlotElement` 컬럼, `^` 구분자) +- 인장의 속성이 **슬롯 속성과 일치**해야만 장착 가능 +- `pcTdata.list_element`에 포함된 속성만 해당 PC가 사용 가능 + +### 4. 중복 장착 제한 + +`ServerClass.cs` 690~703행 `CanEquipSeal`: +- **동일 인장 ID를 한 캐릭터에 중복 장착 불가** (이미 장착 시 return -1) +- 다른 캐릭터가 착용 중인 인장은 장착 시도 가능 (return 1 = 교체 UI 표시) +- 동일 타입이라도 **다른 ID면 장착 가능** (같은 Critical 5★ 2개 장착 가능) + +### 5. GlobalValue.json/PCAwakening.json에 없는 이유 + +슬롯 수와 개방 조건은 **코드 하드코딩**으로 관리. 데이터 테이블에 별도 설정 항목이 없는 것이 정상. + +## 기획팀 밸런싱 시 유의사항 + +1. **기여도 계산 시 진화 단계별 장착 수 고려 필요**: + - 진화 0단계: 1개 장착 → 기여도 최소 + - 진화 5단계: 6개 장착 → 기여도 최대 +2. 기획팀 기존 추정(3개 vs 6개)에서 **최대 6개가 정답**, 단 진화 단계 의존 +3. 속성 매칭으로 인해 **원하는 인장을 자유롭게 6개 채울 수 없음** — 슬롯별 속성 제한 반영 필요 +4. 인장 슬롯 수를 변경하려면 코드 수정 필요 (데이터만으로는 불가) +5. 합성(`Mix_Seal`)은 동일 인장 3개(`SealMixCount=3`) 필요, 장착 중 인장은 합성 불가 diff --git a/공유/소통/기획팀→개발팀/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md b/공유/소통/기획팀→개발팀/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md index 5ab9bbc..3cd8f3b 100644 --- a/공유/소통/기획팀→개발팀/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md +++ b/공유/소통/기획팀→개발팀/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md @@ -5,7 +5,7 @@ 수신부서: 개발팀 담당에이전트: /게임플레이 우선순위: HIGH -상태: 대기 (Phase 3 HOLD 해제 후 활용) +상태: 완료 (2026-04-16 응답 → 공유/소통/개발팀→기획팀/2026-04-16_REQ001_응답_각성트리_퍼센트값.md) --- > **참고**: 이 요청은 Phase 3 HOLD 상태 중 발견된 데이터 이슈입니다. Phase 3 재개 시점(개발팀 시뮬레이터 이원화 해소 완료 후)에 **Python 시뮬 수치 vs Unity C# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다. 해석 확정 결과를 회신해주시면 재개 시 즉시 반영하겠습니다. diff --git a/공유/소통/기획팀→개발팀/2026-04-14_REQ002_장비옵션_음수값_의미확인.md b/공유/소통/기획팀→개발팀/2026-04-14_REQ002_장비옵션_음수값_의미확인.md index d4c3a63..95487b9 100644 --- a/공유/소통/기획팀→개발팀/2026-04-14_REQ002_장비옵션_음수값_의미확인.md +++ b/공유/소통/기획팀→개발팀/2026-04-14_REQ002_장비옵션_음수값_의미확인.md @@ -5,7 +5,7 @@ 수신부서: 개발팀 담당에이전트: /게임플레이 우선순위: MEDIUM -상태: 대기 (Phase 3 HOLD 해제 후 활용) +상태: 완료 (2026-04-16 응답 → 공유/소통/개발팀→기획팀/2026-04-16_REQ002_응답_장비옵션_음수값.md) --- > **참고**: 이 요청은 Phase 3 HOLD 상태 중 발견된 데이터 이슈입니다. Phase 3 재개 시점(개발팀 시뮬레이터 이원화 해소 완료 후) **Python 시뮬 수치 vs Unity C# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다. diff --git a/공유/소통/기획팀→개발팀/2026-04-14_REQ003_인장_장착수제한_확인.md b/공유/소통/기획팀→개발팀/2026-04-14_REQ003_인장_장착수제한_확인.md index 1f4f4dc..4c57754 100644 --- a/공유/소통/기획팀→개발팀/2026-04-14_REQ003_인장_장착수제한_확인.md +++ b/공유/소통/기획팀→개발팀/2026-04-14_REQ003_인장_장착수제한_확인.md @@ -5,7 +5,7 @@ 수신부서: 개발팀 담당에이전트: /게임플레이 우선순위: LOW -상태: 대기 (Phase 3 HOLD 해제 후 활용) +상태: 완료 (2026-04-16 응답 → 공유/소통/개발팀→기획팀/2026-04-16_REQ003_응답_인장_장착수제한.md) --- > **참고**: 이 요청은 Phase 3 HOLD 상태 중 발견된 데이터 이슈입니다. Phase 3 재개 시점(개발팀 시뮬레이터 이원화 해소 완료 후) **Python 시뮬 수치 vs Unity C# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다.