6.0 KiB
6.0 KiB
| name | description |
|---|---|
| bt-planning-fun | 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 항시 주입