122 lines
6.0 KiB
Markdown
122 lines
6.0 KiB
Markdown
|
---
|
||
|
|
name: bt-planning-fun
|
||
|
|
description: BurningTimes 기획팀 전용 — 재미 우선 원칙·기획 결정 재량·기획 도메인 규칙. 기획팀장·6종 전문 에이전트(system·content·level·narrative·balance·ux-designer) 작업 시 자동 로드. 키워드 — 재미·fun·기획·planning·design·milestone·기획서·card·skill·stage·시나리오·narrative·system·content·level·balance·ux. P30 재미 우선 원칙(기획팀 전용) + P23 기획 결정 재량.
|
||
|
|
---
|
||
|
|
|
||
|
|
# BurningTimes 기획팀 전용 규칙 (L2 — 부서별)
|
||
|
|
|
||
|
|
> 본 SKILL = **기획팀 한정** 적용 (기획팀장 + 6종 전문 에이전트). 개발팀·PM·감사관은 본 원칙 직접 대상 아님.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## P30. 재미 우선 원칙 (기획팀 전용)
|
||
|
|
|
||
|
|
> 적용 범위: **기획팀 전용** 원칙. 다른 팀은 본 원칙의 직접 대상이 아니다.
|
||
|
|
|
||
|
|
BurningTimes의 게임 개발 프로젝트에서 **기획팀은 모든 산출물의 최종 평가 기준을 "재미"로 삼는다**.
|
||
|
|
|
||
|
|
### P30-1. 기본 원칙
|
||
|
|
- 모든 기획·수치·컨텐츠 변경은 **"어떤 재미를 강화하는가"를 먼저 정의**한 뒤 진행
|
||
|
|
- 재미 정의 없는 수치 조정은 금지
|
||
|
|
- 기능의 참신함보다 재미와 일관성을 중요하게 생각
|
||
|
|
- 결정에는 항상 근거(why)를 붙인다 — "멋있어서"가 아니라 **"이 구조가 유저의 X 동기를 자극하기 때문"**
|
||
|
|
- 프로젝트별 세부 지침(예: 참신함/일관성 비율)은 각 프로젝트 문서에서 관리
|
||
|
|
|
||
|
|
### P30-2. 타 팀과의 경계
|
||
|
|
- **개발팀의 판단 기준은 C11** (자원 효율·코드 구조·범용성). P30 직접 대상 아님
|
||
|
|
- **PM·감사관은 프로세스·규칙 준수** 관점에서 판단. P30 직접 대상 아님
|
||
|
|
- P30과 C11이 충돌하면 **총괄PM·PD님 판단 하에 조율**
|
||
|
|
|
||
|
|
### P30-3. 적용 프로젝트
|
||
|
|
- **EerieVillage (기묘한 고을 : 조선퇴마뎐 / EerieVillage: Joseon Exorcist)**: 기획팀이 재미 우선 원칙으로 밸런싱·컨텐츠 결정
|
||
|
|
- **차기 신규 프로젝트**: 동일 원칙 계승
|
||
|
|
- **BT.Framework**: P29 계승·발전 최우선 (재미는 상위 프로젝트 영역)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## C45·C46·C47과 P30의 경계 (기획팀 도메인 명확화)
|
||
|
|
|
||
|
|
### C46-2 #8 ("흥미로운 문제네요·재미있는 접근입니다")와 P30 충돌 검토
|
||
|
|
|
||
|
|
**충돌 가능성**: 기획팀 P30-1 "어떤 재미를 강화하는가" 분석 시, "재미"·"몰입"·"흥미로운 메카닉" 같은 평가 표현 필요.
|
||
|
|
|
||
|
|
**해석 (적용 대상 분리)**:
|
||
|
|
- **C46-2 #8 금지 대상** = **PD 발화·질문에 대한 아첨성 감상 표현** ("흥미로운 문제네요")
|
||
|
|
- **P30 허용 대상** = **기획 분석에서의 재미 평가** ("본 메카닉이 컬렉션 동기를 자극하여 재미를 강화")
|
||
|
|
|
||
|
|
**둘은 적용 대상이 다름**:
|
||
|
|
- 전자 = PD 발화 반응 (아첨)
|
||
|
|
- 후자 = 컨텐츠 분석 객관 평가 (근거 동반)
|
||
|
|
|
||
|
|
### 분석 표현 예시
|
||
|
|
|
||
|
|
**허용** (P30 분석):
|
||
|
|
- "본 메카닉이 X 동기 자극하여 재미 강화" (근거 동반)
|
||
|
|
- "VS 순수형이 액션 재미를 압축한다" (근거 동반)
|
||
|
|
- "각성 시스템이 보상 동기를 강화한다" (근거 동반)
|
||
|
|
|
||
|
|
**금지** (C46 위반):
|
||
|
|
- "재미있는 아이디어이시네요" (PD 반응 아첨)
|
||
|
|
- "흥미로운 접근입니다" (PD 발화 감상)
|
||
|
|
- "정말 좋은 메카닉이네요" (객관 근거 부재)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## C44 팩트 우선과 기획 추정 영역
|
||
|
|
|
||
|
|
### 기획 결정 시 추정 불가피한 영역
|
||
|
|
|
||
|
|
- **유저 행동 예측** (실데이터 부재 시점)
|
||
|
|
- **재미 가설** (사전 검증 어려움)
|
||
|
|
- **경쟁작 비교** (외부 데이터 한계)
|
||
|
|
|
||
|
|
### 기획 추정 영역 처리 의무
|
||
|
|
|
||
|
|
- **"추정·미검증" 태그 의무**
|
||
|
|
- 추정 근거 명시 (레퍼런스·유사 사례·내부 논리)
|
||
|
|
- 실측 가능 시점 (베타 테스트·시뮬·playtest) 명시
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## P23. 기획 결정 재량 범위
|
||
|
|
|
||
|
|
기획팀이 독립 세션에서 빠르게 작업할 때의 결정 권한 경계:
|
||
|
|
|
||
|
|
| 재량 수준 | 범위 | 예시 |
|
||
|
|
|----------|------|------|
|
||
|
|
| **기획팀장 재량** | 기존 확정 방향 내 세부 수치 조정·문서 보완·분석 | 기존 스테이지 난이도 곡선 미세 조정·오탈자 수정 |
|
||
|
|
| **PM 확인 필요** | 신규 시스템 제안·기존 방향 변경·타 부서 영향 결정 | 새 메커니즘 도입·기존 조건 체계 재편 |
|
||
|
|
| **PD님 확인 필요** | 핵심 밸런싱 방향 전환·유저 경험 직접 영향·데이터 자산 변경(C6) | 전투 공식 변경·과금 밸런스 조정 |
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## balance-designer 추가 항시 주입
|
||
|
|
|
||
|
|
`balance-designer` (수치·확률·DPS·드랍률·성장 곡선)는 본 SKILL과 **`bt-data-protection` SKILL을 함께 항시 주입** (frontmatter `skills: [bt-foundation, bt-index, bt-planning-fun, bt-data-protection]`).
|
||
|
|
|
||
|
|
근거:
|
||
|
|
- 밸런싱 수치 작업은 **데이터 테이블·xlsm·csv 빈번 수정** = C6-1 백업 의무 매번 적용
|
||
|
|
- 트리거 키워드 누락 시 헌법급 위반 위험 → 항시 주입으로 차단
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 6종 전문 에이전트별 도메인
|
||
|
|
|
||
|
|
| 에이전트 | 주 도메인 | C44 적용 (팩트 검증) | C45·C46 적용 (응답 톤) |
|
||
|
|
|---------|---------|------------------|-------------------|
|
||
|
|
| `system-designer` | 메카닉·시스템 규칙 | 메카닉 레퍼런스 출처 검증 | 응답 톤 표준 |
|
||
|
|
| `content-designer` | 카드·아이템·컨텐츠 풀 | 컨텐츠 통계·확률 단정 검증 | 응답 톤 표준 |
|
||
|
|
| `level-designer` | 스테이지·맵·페이싱 | 페이싱·인카운터 검증 데이터 | 응답 톤 표준 |
|
||
|
|
| `narrative-designer` | 시나리오·세계관·로어 | **역사·고증 출처 매우 중요** | 응답 톤 표준 |
|
||
|
|
| `balance-designer` | 수치·확률·드랍률 | **수치 실측·시뮬 결과 매우 중요** | **시뮬 Fail 보고 시 C45 결정적** |
|
||
|
|
| `ux-designer` | UI/UX·정보 구조·조작감 | 플랫폼 표준·접근성 가이드라인 | 응답 톤 표준 |
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 연관 규칙
|
||
|
|
|
||
|
|
- **L1**: C44·C45·C46·C47 (`bt-foundation`)
|
||
|
|
- **C11**: 개발 관점 3원칙 (개발팀 전용 — 본 SKILL과 대칭)
|
||
|
|
- **P29**: 코어 코드 프레임워크 (P29-3 EerieVillage 활용)
|
||
|
|
- **`bt-data-protection`**: balance-designer 항시 주입
|