8.0 KiB
기획 시스템 설계 시행착오 아카이브 v1
섹션 1. 잘 작동한 것
1-1. Prove-2-of-3 ★ 조건 체계
"스테이지 클리어 + 슬롯2·슬롯3 조건 2개 동시 달성"으로 3성을 구조화한 것이 성공적이었다.
성공 요인 3가지:
- 조건 풀 확정 → 배치 분리: PD 승인으로 조건 12개를 먼저 확정한 뒤 스테이지 배치를 진행했다. 밸런싱 검증과 규칙 위반 체크를 독립 수행할 수 있었다.
- C 계열(스테이지 전체) / N 계열(서브맵 단위) 이원 분류: 레벨 설계자의 배치 의도를 명확히 표현하는 기반이 됐다.
- "재도전 유도" 방향 명시: 임계값 튜닝 기준이 "완화"가 아닌 "재도전 유도"로 고정되어 의사결정 경계가 명확했다.
EerieVillage 이식 시: 2-of-3 구조·풀 사전 확정 절차·재도전 유도 원칙은 계승한다. 조건 내용(HP·피격·포션 등)은 2D 플랫포머 퇴마 메카닉에 맞게 전면 재설계한다.
1-2. 배타 조합 규칙 선제 정의 (P17 방법론)
배치 착수 전에 동시 배치 금지 조합 7종을 명문화한 것이 실제 오류를 차단했다.
| 배타 조합 | 기각 이유 |
|---|---|
| C2(완벽 클리어) ∧ N2(피격 제한) | 동일 축(피격 최소화) 이중 부담 |
| C9(보스 집중) ∧ 보스 미등장 스테이지 | 보스 없으면 조건 논리 불성립 |
| N5(후열 선공) ∧ N6(전열 선공) | 타겟팅 자유도 동시 박탈 — 플레이어 선택 불가 |
EerieVillage: 신규 조건 풀 정의 시 배타 조합을 반드시 동시 정의한다. 배치 단계 즉석 판단은 누락을 유발한다. 체크 3문항: (1) 동일 플레이 축 중복, (2) 특정 스테이지 구성에서 논리 불성립, (3) 특정 빌드를 배타적으로 배제하는 조합.
1-3. 어뷰징 판정 — 클라 주도 + 서버 플래그 수신 구조
초기 설계는 서버가 경계값 테이블을 직접 검증하는 구조였다. PD님 재결정으로 "클라 판정 → is_abuse_flag 서버 전송 → 서버는 플래그 수신 시 지급 거부"로 정리됐다.
싱글 플레이 구조에서 이 구조가 적합한 이유: 서버 재시뮬레이션은 CPU 폭증 + 난수 동기화 이슈(기각안 G-1), 경계값을 서버에 두면 클라 업데이트마다 동기화 의존성 발생. F1(플래그만) / F2(보상 보류) / F3(미지급) 3단계 체계가 false positive 관리와 어뷰저 학습 방지를 양립시켰다.
EerieVillage: 경계값은 시뮬레이터 극값 × 안전마진 계수로 산출한다. 시뮬레이터 가동 전까지 플레이스홀더로 기획서를 발행하고 수치 미확정을 명시한다.
섹션 2. 실패한 것 (반복 금지)
2-1. 데이터 구조 미검증 기반 기획 착수
Phase 4 지역 1 노드 구성 v1은 "지역 1 = Stage 1~6 = 6개"를 전제로 설계됐다. CreateMapConfig.csv 실측 결과 실제 구조는 21개 지역 × N개 스테이지 = 총 122 스테이지이며, 지역 1은 Stage1_1~1_4 = 4개였다.
결과: v1 전체 폐기 + 데이터 구조 재정비(#42) · 기획팀 실측 의무 문서(#43) · v2 재작성(#44) 3종 동시 집행.
근본 원인: Unity Export 원본 CSV를 직접 실측하지 않고 2차 해석 문서 표현("WorldMap 4그룹")에 의존했다.
EerieVillage 재발 방지: 레벨·스테이지 구성 파일 전수 실측 후 PD 확정 용어와 일치 확인. 이전 프로젝트 설계 재사용 시에도 신 프로젝트 데이터 정합성 재확인.
2-2. 테이블 수치 파싱 로직 미확인 기반 밸런싱
PCAwakening.json의 s_Value 컬럼에 '5'와 '500%'가 혼재했다. 기획팀은 '500%'를 "기존 스탯의 500% 배율"로 해석하여 각성 만렙 DPS +1067%라는 이상 수치를 산출했다.
실제 파싱 로직: % 포함 시 숫자 × 0.01f → '500%' = 5.0f = '5'와 동일. 실제 효과는 고정값 +9 수준이었다.
EerieVillage 원칙: % 표기 컬럼은 파싱 코드 경로 확인 후 적용한다. 목표치 대비 10배 이상 이상치가 나오면 해석 오류를 먼저 의심하고 개발팀 REQ를 발행한다.
2-3. 디버프 설계 미명문화 — 음수값 혼동
EquipmentList.json 분석 중 풀셋 장착 시 CriDmg -20%, Avoid_Melee -3% 등 음수 합산 발견. 기획팀은 오류 여부를 판단하지 못하고 REQ를 발행했다.
실측 결과 의도적 트레이드오프 설계였다. UpgradeVal=0이라 강화해도 완화되지 않는 고정 디버프 구조. AttackCoolTime -10%는 예외적으로 음수지만 공격속도 증가(긍정 효과)였다.
EerieVillage 원칙: 장비 시스템 설계 명세서에 "어떤 부위가 어떤 스탯에 디버프 부여", "강화로 완화 가능 여부", "음수 = 긍정 효과인 스탯 목록"을 명시한다.
2-4. 코드 하드코딩 수치를 테이블에서만 탐색
인장 기본 슬롯 수를 GlobalValue.json에서 찾지 못해 REQ를 발행했다. 실측 결과 ServerClass.cs에 list_equipseal = new List<uint> { 0, 0, 0, 0, 0, 0 }으로 하드코딩. 슬롯 개방 조건(진화 단계별)과 속성 매칭 제한도 코드 로직에 있었다.
EerieVillage 원칙: 기획 착수 전 "테이블 관리 수치"와 "코드 하드코딩 수치"를 개발팀과 합의하고 문서화한다.
섹션 3. 미해결 채로 남긴 것
3-1. ★ 조건 임계값 — 시뮬레이터 의존 미완결
조건 체계 구조는 확정됐으나 구체적 임계값(C1 신속 N초, N2 피격 제한 서브맵수×1 등)은 전부 플레이스홀더 상태로 종결됐다. EerieVillage 교훈: 문서 status 필드로 "구조 확정·임계값 플레이스홀더"와 "임계값 확정" 상태를 구분한다.
3-2. 어뷰징 경계값 — 전수 플레이스홀더 상태 종결
기획서 v1의 모든 경계값은 플레이스홀더다. 기각된 대안(서버 재시뮬·ML 탐지·클라 단독 판정·전체 로그 전송)과 기각 사유는 기획서 G 섹션에 보존되어 있다. EerieVillage 어뷰징 방어 설계 시 해당 기각안을 먼저 참조한다.
섹션 4. 의사결정 경계 (P23 기준)
| 수준 | 해당 사례 |
|---|---|
| 기획팀장 재량 | 조건 판정 로직 의사코드 · 배타 조합 초안 · 어뷰징 프레임워크 구조 |
| PM 확인 필요 | 신규 시스템 기획서 최초 발행 · 개발팀 영향 REQ 발행 |
| PD 확인 필수 | 지역·스테이지 수량 변경 · 조건 풀 추가·삭제 · 어뷰징 판정 주체 전환 · 보상 체계 방향 전환 |
섹션 5. EerieVillage 즉시 적용 권장
5-1. 조건 체계 설계 절차 (검증된 순서)
1단계: 장르 메카닉 분석 → 유저 컨트롤 가능한 행동 축 열거
2단계: 조건 후보 초안 (10~15개) 작성
3단계: 각 조건별 배타 조합 동시 정의
4단계: PD 승인으로 조건 풀 확정
5단계: 스테이지별 배치 (4단계 이전 배치 착수 금지)
6단계: 임계값 설정 (시뮬레이터 또는 플레이테스트 기반)
5-2. 기획 착수 전 데이터 실측 체크리스트
- 레벨·스테이지 구성 파일 전수 실측
- 성장 시스템 파싱 로직 코드 레벨 확인
- 장비·아이템 옵션 체계 (음수값 의미 포함)
- 코드 하드코딩 수치 목록 (테이블 외 관리 항목)
5-3. 어뷰징 방어 설계 시작점
- 어뷰징 공격 벡터 열거 (AV 번호 부여)
- 물리적 불가능 / 확률적 극단 / 논리적 모순 3범주 분류
- 판정 책임 주체 확정 (싱글 플레이: 클라 주도 + 서버 플래그 수신 권장)
- 경계값은 플레이스홀더로 기획서 발행 후 시뮬레이터 결과로 채워 넣기
참조: 공유/조직공지/방향전환_히스토리_아카이브.md