209 lines
15 KiB
Markdown
209 lines
15 KiB
Markdown
|
---
|
|||
|
|
type: 조직자산 — 시행착오 아카이브 (기획 컨텐츠 기획자 관점)
|
|||
|
|
추출 원본: 수상한잡화점 프로젝트 (NerdNavis)
|
|||
|
|
추출일: 2026-04-20
|
|||
|
|
추출자: 기획팀장 (BurningTimes)
|
|||
|
|
적용 대상: EerieVillage 착수 시 및 차기 컨텐츠 설계 전반
|
|||
|
|
참조 규칙: P30 재미 우선 · P17 배타 배치 · C22 용어 일관 · C23 허위 보고 금지 · C10-5 선행 검증
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 기획 컨텐츠 설계 — 시행착오 아카이브 v1
|
|||
|
|
|
|||
|
|
> **본 문서의 용도**: NerdNavis 수상한잡화점 개발 과정에서 컨텐츠 기획자(몬스터·아이템·스킬·장비·인장·퀘스트)가 겪은 시행착오를 BurningTimes 조직 자산으로 추출. EerieVillage 착수 시 동일 실수 반복을 차단한다.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §1. 몬스터·적 등장 패턴 설계 시행착오
|
|||
|
|
|
|||
|
|
### §1-1. 단독 보스 vs 혼합 등장 정합성 문제
|
|||
|
|
|
|||
|
|
**실증 사건 (수상한잡화점 #57)**
|
|||
|
|
|
|||
|
|
Unity 테스트 플레이 "랜덤 패턴"에서 몬스터 미등장 증상이 2회 연속 발생했다. 1차(commit `9e5fd5b59`)·2차(commit `521a76641`) 수정 모두 근본 원인을 해결하지 못하고 **fallback 가드 추가라는 proxy 개선**만 반복했다.
|
|||
|
|
|
|||
|
|
근본 원인은 `ToolData.json` 125/125 스테이지 전부의 `list_MobData`가 빈 배열이었다. 기획 설계 단계에서 "몬스터 그룹 ID를 CreateMapConfig에서 참조"하는 데이터 파이프라인이 실제 ToolData.json에 반영되지 않은 채 방치됐다.
|
|||
|
|
|
|||
|
|
**교훈 1 — 몬스터 등장 데이터 파이프라인 설계 시 검증 의무**
|
|||
|
|
|
|||
|
|
몬스터 등장 패턴을 기획할 때 "어떤 JSON/CSV 파일이 런타임 몬스터 ID를 결정하는가"를 설계 단계에서 명시적으로 추적해야 한다. 수상한잡화점의 경우 파이프라인은 다음과 같았다.
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
CreateMapConfig.n_AppearMonsterGroup
|
|||
|
|
→ ApprearMonsterPattern (그룹 ID별 몬스터 ID 목록)
|
|||
|
|
→ ToolData.json list_MobData (런타임 주입)
|
|||
|
|
→ MyValue.cs:380-388 (ID 풀 구성)
|
|||
|
|
→ MonsterNodeControler.Get_MobID (추첨)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
이 파이프라인 중 어느 한 단계가 비어있으면 플레이어에게 몬스터가 보이지 않는다. **기획 설계 문서에 데이터 파이프라인 기술 경로를 1줄이라도 명시**하면 개발팀이 연결 누락을 조기 감지할 수 있다.
|
|||
|
|
|
|||
|
|
**교훈 2 — C9 조건(보스 집중)과 스테이지 구조 정합성**
|
|||
|
|
|
|||
|
|
P17 배타 조합 중 "C9(보스 집중) ∧ 단독 보스·보스 미등장 스테이지"는 논리 불성립이다. 수상한잡화점 Stage1_1과 Stage1_3은 `n_AppearBossGroup=0`(보스 없음)이므로 이 스테이지에 C9를 배치하면 달성 불가 조건이 된다. 기획자는 스테이지별 보스 등장 여부를 **CreateMapConfig.n_AppearBossGroup 실측 후** 조건 배치를 확정해야 한다. 추측으로 배치하면 P17 위반 조합이 숨어든다.
|
|||
|
|
|
|||
|
|
### §1-2. 몬스터 종족 전환 패턴
|
|||
|
|
|
|||
|
|
수상한잡화점 지역 1에서 초반(14XXX 수인형/마법생물) → 후반(11XXX 인간형)으로 종족을 점진 전환하는 설계는 유효한 패턴이었다. 플레이어가 새로운 종족 특성을 한 번에 처리하지 않고 단계적으로 학습하게 된다. EerieVillage에서는 초반 잡귀·원령 → 중반 강령술사 → 후반 봉황·이매망량 같은 서사적 종족 전환에 동일 원칙을 적용할 수 있다.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §2. 아이템·장비·인장 구조 설계와 JSON 실측 기반 원칙
|
|||
|
|
|
|||
|
|
### §2-1. 기존 SOT 맹신 금지 — 데이터 구조 오해 재발 방지 (#42·#43)
|
|||
|
|
|
|||
|
|
**실증 사건**
|
|||
|
|
|
|||
|
|
수상한잡화점 기획팀은 `스테이지난이도곡선_v1.md §1`의 "WorldMap_1~4 4개 그룹" 표현을 실측 없이 SOT로 신뢰했다. 이 전제 아래 Phase 4 지역 1 v1을 "Stage 1~6 = 지역 1 = 6개 스테이지"로 설계했다. 실측 결과 실제 지역 1은 Stage1_1·1_2·1_3·1_4 = 4개였고, v1 전면 폐기 + v2 재작성이 필요했다.
|
|||
|
|
|
|||
|
|
**교훈 — 데이터 실측 5대 의무**
|
|||
|
|
|
|||
|
|
모든 기획 작업에 착수하기 전 Unity Export CSV/JSON을 직접 Read해야 한다.
|
|||
|
|
|
|||
|
|
1. **실측 선행**: 기획 문서의 수치·구조를 무비판 수용 금지. 기존 문서에 "SOT"라고 명기되어 있어도 실측과 교차 검증한다.
|
|||
|
|
2. **용어 준수**: PD가 확정한 용어 체계는 기획팀 전원이 일관 사용한다. "WorldMap_1~4" 같은 용어를 이름 기반으로 추정해서 데이터 구조로 해석하는 것은 C22 위반이다.
|
|||
|
|
3. **PD 확인**: 추측으로 결정 진행 금지. 불확실하면 기획팀 내부 논의 → PM 조율 → PD 에스컬레이션 3단계를 밟는다.
|
|||
|
|
4. **SOT 맹신 금지**: 실측 일시를 문서 상단에 명기(`데이터 소스: CreateMapConfig.csv 실측 2026-04-20`)한다. 실측 일시 미기입 문서는 참조 금지.
|
|||
|
|
5. **재사용 검증**: 기존 문서를 인용·확장할 때 §2-1 실측 결과와 대조한다. 전제가 틀릴 경우 자기 산출물도 전면 재작성 대상이다.
|
|||
|
|
|
|||
|
|
**EerieVillage 적용**
|
|||
|
|
|
|||
|
|
인장 대신 부적, 장비 대신 도구와 도복 같은 테마로 변경되더라도 동일한 JSON 파이프라인 함정이 존재한다. 새 프로젝트 착수 시 가장 먼저 "데이터 테이블 구조 재정비 v1"에 해당하는 문서를 실측 기반으로 작성하고, 이후 모든 기획 작업은 그 문서를 1차 참조로 삼아야 한다.
|
|||
|
|
|
|||
|
|
### §2-2. 장비 음수 스탯 — 트레이드오프 설계 원칙
|
|||
|
|
|
|||
|
|
**실증 사건 (REQ002)**
|
|||
|
|
|
|||
|
|
수상한잡화점 장비(`EquipmentList.json`)의 MainOption2에는 `CriDmg -20%`·`Avoid_Melee -3%`·`HitRate -3` 같은 음수 스탯이 존재했다. 기획팀은 이것이 데이터 오류인지 의도적 설계인지 알 수 없어 개발팀에 REQ를 발행했다.
|
|||
|
|
|
|||
|
|
개발팀 확인 결과 이 음수값은 **의도적인 고정 페널티**였다. 무기 라인마다 주 스탯(MainOption1) + 트레이드오프 페널티(MainOption2) 구조였으며, 강화해도 페널티는 불변(`UpgradeStatValuePara1=0`)이었다. 단, `AttackCoolTime -10%`는 예외로 공격 쿨타임 감소 = 공속 증가 = 보너스였다.
|
|||
|
|
|
|||
|
|
**교훈**
|
|||
|
|
|
|||
|
|
장비 옵션에 음수값을 설계할 때는 다음 3종을 설계 문서에 명시한다.
|
|||
|
|
|
|||
|
|
1. 어떤 스탯이 음수이며 그것이 "페널티인가 / 보너스인가"를 명시한다(`AttackCoolTime` 사례처럼 음수가 보너스인 역방향 스탯이 존재한다).
|
|||
|
|
2. 강화 시 음수값이 완화되는지 고정인지를 명시한다(수상한잡화점은 고정).
|
|||
|
|
3. 세트 옵션과의 상호작용을 명시한다(예: `MaxHP -10% + MaxShield +10%` 세트).
|
|||
|
|
|
|||
|
|
이 3가지를 문서화하지 않으면 밸런서가 DPS/EHP 시뮬레이션에서 오계산한다.
|
|||
|
|
|
|||
|
|
### §2-3. 인장(소울 장착 아이템) 슬롯 구조 설계
|
|||
|
|
|
|||
|
|
**실증 사건 (REQ003)**
|
|||
|
|
|
|||
|
|
기획팀은 인장 장착 슬롯 수를 3개와 6개 중 하나로 추정하여 기여도 분석을 진행했다. 실제는 **기본 슬롯 6개, 단 캐릭터 진화 단계에 따라 순차 개방**이었으며, 속성 매칭 제한까지 존재했다. 이 구조는 JSON에 없고 코드에 하드코딩되어 있어 JSON만 봐서는 알 수 없었다.
|
|||
|
|
|
|||
|
|
**교훈**
|
|||
|
|
|
|||
|
|
장착 슬롯 계열 컨텐츠를 설계할 때는 다음을 사전에 개발팀과 확인한다.
|
|||
|
|
|
|||
|
|
1. 슬롯 수가 데이터 테이블에 있는가, 코드에 하드코딩되어 있는가.
|
|||
|
|
2. 슬롯 개방 조건이 있는가 (진화·각성·레벨 등).
|
|||
|
|
3. 슬롯별 속성·타입 제한이 있는가.
|
|||
|
|
|
|||
|
|
이 3가지 중 하나라도 코드에 있으면 기획 변경 시 개발팀 수정이 필수다. 기획팀이 독자적으로 "슬롯 수를 4개로 조정하자"고 결정해도 반영이 안 된다.
|
|||
|
|
|
|||
|
|
EerieVillage에서 부적 슬롯, 오행 속성 슬롯 등을 설계할 때 동일한 사전 확인 절차를 적용한다.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §3. 스킬·장비 옵션 상호작용 (음수값·디버프·상태이상)
|
|||
|
|
|
|||
|
|
### §3-1. 디버프성 옵션의 역할 — 선택의 다양성 확보
|
|||
|
|
|
|||
|
|
수상한잡화점 장비 트레이드오프 구조(§2-2)는 결과적으로 빌드 다양성에 기여했다. "치명타 피해 -20%" 페널티를 감수한 무기를 선택하면 다른 보너스를 확보하는 구조이므로, 플레이어가 자신의 빌드 방향에 따라 장비를 선택하게 된다.
|
|||
|
|
|
|||
|
|
컨텐츠 기획자 관점에서 음수 스탯은 "역할 없는 컨텐츠"가 아니다. 다음 조건을 충족하면 명확한 역할을 가진다.
|
|||
|
|
|
|||
|
|
1. 해당 페널티를 감수할 만한 보상이 같은 아이템 또는 세트 효과에 있다.
|
|||
|
|
2. 특정 빌드에서는 해당 스탯이 페널티가 아닌 무관 스탯이 된다(치명타 빌드가 아닌 플레이어에게 `CriDmg -20%`는 체감 손실이 작다).
|
|||
|
|
3. 강화해도 음수가 유지되거나, 강화할수록 음수가 개선되거나를 의도적으로 결정한다.
|
|||
|
|
|
|||
|
|
### §3-2. 상태이상 조건과 빌드 축 충돌
|
|||
|
|
|
|||
|
|
P17 배타 조합 7종은 이 교훈의 체계화 결과다. 수상한잡화점에서 조건 × 빌드 120개 조합을 전수 점검한 결과 다음 패턴이 반복됐다.
|
|||
|
|
|
|||
|
|
1. **완전 배타**: 빌드 목표와 조건 달성 방향이 논리적으로 상충한다(물약 빌드 × 포션 절제).
|
|||
|
|
2. **구조적 충돌**: 동시 추구가 가능하지만 높은 난이도를 요구한다(치명타 빌드 × 완벽 클리어).
|
|||
|
|
3. **강시너지**: 빌드 플레이가 조건을 자동 충족에 가깝게 만든다(보호막 빌드 × 고HP 완주).
|
|||
|
|
|
|||
|
|
EerieVillage 퀘스트·미션·스테이지 클리어 조건 설계 시 동일한 120개(빌드 N개 × 조건 M개) 매트릭스를 작성하고, E(배타) 조합을 동일 스테이지에 동시 배치하지 않는 원칙을 초기에 확립한다.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §4. 컨텐츠 간 상호작용 배타 규칙 설계 방법론 (P17 추출)
|
|||
|
|
|
|||
|
|
### §4-1. 배타 규칙을 만드는 4단계 방법론
|
|||
|
|
|
|||
|
|
수상한잡화점의 P17 신설 과정에서 다음 4단계가 유효했다.
|
|||
|
|
|
|||
|
|
1. **조건 풀과 빌드 풀을 독립 열거한다.** 두 목록을 각각 완성한 뒤 교차 매트릭스를 그린다. 직관으로 "이 두 개는 나쁘다"고 판단하기 전에 목록을 먼저 만든다.
|
|||
|
|
2. **각 교차 지점에 E/X/S/SS/-를 배정한다.** 배정 근거는 "이 빌드를 진행하는 플레이어가 이 조건을 달성하려면 어떤 행동을 해야 하는가"를 기준으로 판단한다.
|
|||
|
|
3. **E(배타) 조합에서 동일 스테이지 슬롯에 동시 배치 금지 규칙을 추출한다.** 배타 조합이 동시 존재하면 해당 빌드 플레이어는 달성 불가 상태가 된다.
|
|||
|
|
4. **신규 조건·빌드 추가 시 기존 배타 목록과 교차 검증한다.** 추가 단계에서 검증을 빠뜨리면 배타 조합이 누적된다.
|
|||
|
|
|
|||
|
|
### §4-2. 논리 불성립 조건 사전 차단
|
|||
|
|
|
|||
|
|
수상한잡화점 P17 배타 조합 #5 "C9(보스 집중) ∧ 단독 보스·보스 미등장 스테이지"는 스테이지 구조에서 비롯된 논리 불성립이다. 이는 조건 풀의 문제가 아니라 **스테이지 데이터 구조와 조건 설계의 정합성 문제**다. EerieVillage에서 "퇴마 집중" 같은 보스 특화 조건을 설계할 때, 해당 조건을 배치할 스테이지에 실제로 보스(봉황·이매망량 등)가 등장하는지를 데이터 테이블 실측으로 확인한 뒤 배치한다.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §5. EerieVillage 착수 가이드 — 조선 시대 퇴마 테마 컨텐츠 셋 구성
|
|||
|
|
|
|||
|
|
### §5-1. 컨텐츠 셋 구성 원칙
|
|||
|
|
|
|||
|
|
수상한잡화점의 시행착오를 바탕으로 EerieVillage 컨텐츠 셋 착수 시 다음 순서를 권고한다.
|
|||
|
|
|
|||
|
|
**1순위 — 데이터 구조 SOT 확립 (착수 불가 전제 조건)**
|
|||
|
|
|
|||
|
|
신 프로젝트 데이터 체계(JSON/CSV/SQLite 등)를 실측하여 "데이터 구조 재정비 v1"에 해당하는 문서를 가장 먼저 작성한다. 몬스터·아이템·스킬·장비·퀘스트 각 테이블의 필드 목록, 레코드 구조, 참조 관계를 실측 기반으로 명시한다. 이 문서 없이 컨텐츠 셋 설계를 시작하면 수상한잡화점 v1 전면 폐기 사건이 반복된다.
|
|||
|
|
|
|||
|
|
**2순위 — PD 용어 확정 (설계 착수 전)**
|
|||
|
|
|
|||
|
|
조선 시대 세계관에서 다음 용어를 PD와 확정한다.
|
|||
|
|
|
|||
|
|
- 지역 단위 명칭 (예: 마을·고을·영·유배지)
|
|||
|
|
- 스테이지 단위 명칭 (예: 길목·처소·관아)
|
|||
|
|
- 서브맵 단위 명칭 (예: 노드·조우·구역)
|
|||
|
|
- 몬스터 분류 명칭 (예: 잡귀·원령·악귀·봉황·이매망량)
|
|||
|
|
|
|||
|
|
이 용어가 데이터 테이블 필드 명칭과 어떻게 매핑되는지를 문서화한다.
|
|||
|
|
|
|||
|
|
**3순위 — 컨텐츠 셋 다양성 축 정의**
|
|||
|
|
|
|||
|
|
EerieVillage 퇴마 테마에서 자연스러운 다양성 축은 다음과 같다.
|
|||
|
|
|
|||
|
|
| 축 | 한쪽 극단 | 다른 쪽 극단 | 기획 역할 |
|
|||
|
|
|----|---------|------------|---------|
|
|||
|
|
| 접근 방식 | 직접 퇴마(근거리 전투) | 부적 원격 제압(원거리) | 빌드 방향 분기 |
|
|||
|
|
| 오행 속성 | 금·수 방어형 | 화·목 공격형 | 상성 시스템 |
|
|||
|
|
| 처치 수단 | 정화(약화→마무리) | 즉결(직접 처치) | 전투 스타일 |
|
|||
|
|
| 시간 축 | 지속전(장기전·회복) | 속결전(버스트) | 클리어 조건 분기 |
|
|||
|
|
| 위험 감수 | 안전 빌드(회피·방어) | 공격적 빌드(디버프 감수) | 트레이드오프 |
|
|||
|
|
|
|||
|
|
**4순위 — 배타 조합 매트릭스 초안 작성**
|
|||
|
|
|
|||
|
|
위 다양성 축에서 추출한 빌드 N개 × 클리어 조건 M개의 교차 매트릭스를 P17 방법론(§4-1)으로 작성한다. 이 매트릭스는 스테이지 조건 배치 이전에 완성되어야 한다. 조건 풀이 확정되면 배타 조합 목록을 추출하고, 스테이지 설계 시마다 배타 조합 전수 체크를 의무화한다.
|
|||
|
|
|
|||
|
|
### §5-2. 조선 시대·퇴마 테마 특화 주의사항
|
|||
|
|
|
|||
|
|
**음수 스탯의 테마 일관성**
|
|||
|
|
|
|||
|
|
장비 트레이드오프로 음수 스탯을 도입할 경우, 조선 시대 세계관과 일관성이 있어야 한다. 예를 들어 "부적 강화 → 무술 능력 저하" 또는 "오행 금기 위반 → 회피 감소" 같은 형태로 서사적 납득이 가능한 페널티를 설계한다. 수상한잡화점의 "치명타 피해 감소" 페널티는 세계관 맥락이 없는 순수 수치 트레이드오프였다. EerieVillage에서는 세계관 맥락과 수치 설계를 함께 제시해야 한다.
|
|||
|
|
|
|||
|
|
**몬스터 보스 등장 패턴과 퇴마 서사 정합성**
|
|||
|
|
|
|||
|
|
퇴마 서사에서는 보스(이매망량·봉황 등)의 등장이 단순 전투 도전이 아닌 서사적 클라이맥스 역할을 한다. 스테이지 구조 설계 시 보스 등장 여부(`n_AppearBossGroup` 등가 필드 실측)와 서사 이벤트 배치를 연계한다. 수상한잡화점에서 보스 미등장 스테이지에 "보스 집중" 조건이 배치될 뻔한 사건처럼, 서사 클라이맥스 조건을 보스 미등장 스테이지에 배치하는 실수가 동일하게 발생할 수 있다.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §6. 참조 원본 (실측 기반 항목만)
|
|||
|
|
|
|||
|
|
- `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` — 데이터 구조 SOT (#42)
|
|||
|
|
- `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` — 5대 의무 룰 (#43)
|
|||
|
|
- `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md` — 실측 후 재작성 (#44)
|
|||
|
|
- `프로젝트/수상한잡화점/기획/빌드_조건_충돌점검_v1.md` — 120개 배타 매트릭스
|
|||
|
|
- `공유/소통/완료/2026-04-16_REQ002_응답_장비옵션_음수값.md` — 트레이드오프 코드 근거
|
|||
|
|
- `공유/소통/완료/2026-04-16_REQ003_응답_인장_장착수제한.md` — 슬롯 구조 코드 근거
|
|||
|
|
- `공유/대화로그/수상한잡화점/2026-04-20.md` — #42 테이블 데이터 구조 재정비 · #57 몬스터 미등장 근본 원인
|