comm(dev→plan): REQ001~003 코드 분석 응답 — 기획팀 밸런싱 작업 지원 (PD님 지시)
- REQ001: 각성트리 '500%' = Get_Value()에서 5.0으로 파싱, '5'와 동일 (입력 형식 불일치) - REQ002: 장비옵션 음수값은 의도적 트레이드오프 설계, AttackCoolTime 음수는 공속 보너스 - REQ003: 인장 슬롯 6개, 진화 단계별 순차 개방, 속성 매칭 제한 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
7599231a7c
commit
8a0d4c9abd
|
|
@ -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` 컬럼 포맷을 정수 또는 퍼센트 한 가지로 통일 권장. 현재 런타임 결과는 동일하므로 긴급 수정 불필요.
|
||||
|
|
@ -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. 장비 라인별 트레이드오프 구조를 인지하고 밸런싱에 반영 권장
|
||||
|
|
@ -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<uint> list_equipseal = new List<uint> { 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`) 필요, 장착 중 인장은 합성 불가
|
||||
|
|
@ -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# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다. 해석 확정 결과를 회신해주시면 재개 시 즉시 반영하겠습니다.
|
||||
|
|
|
|||
|
|
@ -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# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다.
|
||||
|
|
|
|||
|
|
@ -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# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue