32 KiB
수상한 잡화점 — ★ 조건 12개 풀 상세 명세서 v1
작성일: 2026-04-14 / 최신화: 2026-04-18 담당: 기획팀장 (PD님 재량 위임 — Phase 3 HOLD 중 가능 작업) 위임 근거: 2026-04-14 PD님 지시 "Phase 3 작업 전 진행 가능한 작업을 기획팀장이 판단하에 진행" 문서 성격: P18 설계 문서화 의무 이행 (Phase 2 §5 PD님 3차 승인의 조건 풀 12개에 대한 본문 작성) HOLD 준수: 본 문서는 판정 로직·측정 변수·UI 표시·개발팀 구현 요청까지만 다룸. 구체적 수치 최종 확정은 Phase 3 재개 후 시뮬 검증으로 수행
0. 본 문서의 목적·범위
목적
Phase 2 §5에서 PD님 3차 승인으로 확정된 ★ 조건 풀 12개(+N7 실측 완료, 조건 풀 13번째 추가 여부 Phase 3 재개 시 PD님 결정 대기)에 대해, 각 조건별:
- 정의 (기본 의미)
- 달성 판정 로직 의사코드
- 측정 변수 (게임 런타임 중 추적해야 할 값)
- UI 표시 방식
- 개발팀 구현 요청 포인트
- 엣지 케이스 및 주의 사항
를 한 곳에 정리한다. 개발팀이 Unity MCP EditMode 독립 어셈블리(Assets/Sim/BurningTimes.Sim.asmdef)에서 구현해야 할 조건 판정 코드의 설계 기반 자료.
범위 외 (HOLD 준수)
- 조건별 구체적 수치 최종 확정 금지 — 수치는 Phase 3 재개 후 시뮬 결과로만 산출
- 조건 풀 12개 추가·삭제 금지 — PD님 3차 승인으로 확정된 풀 유지
- 스테이지별 슬롯 배치 확정 금지 — 맵 패턴 사전분석 v1 §3-3 검증틀을 실제로 적용하는 것은 Phase 3 재개 후
- 카드 수치 조정 제안 금지 — 이슈 1·3 재논의 영역
P18 준수 (설계 문서 필수 포함 사항)
| 항목 | 본 문서 위치 |
|---|---|
| 결정의 배경 | §1 (Prove-2-of-3 체계 도입 배경) |
| 선택된 방향과 대안 | §2 (조건 풀 12개 선정 경위) |
| 구현 가이드라인 | §3~§5 (조건별 명세) |
| 검증 방법 | §6 (조건 판정 검증 체크리스트) |
| 변경 이력 | §8 |
1. Prove-2-of-3 체계 개요 (결정 배경)
1-1. 체계 구조
수상한 잡화점 스테이지의 3성(★★★) 클리어는 Prove-2-of-3 체계로 판정:
| 별 | 충족 조건 |
|---|---|
| ★1 | 스테이지 클리어 (기본) |
| ★2 | 스테이지 클리어 + 슬롯2 조건 1개 달성 |
| ★3 | 스테이지 클리어 + 슬롯2·슬롯3 조건 2개 동시 달성 |
- 스테이지별 슬롯2·슬롯3은 사전 지정 (고정). 런타임 랜덤 없음
- 슬롯 지정은 스테이지 특성(노드 수·몬스터 배치 패턴·등장 몬스터 수)과 연동
- PD님 2차 승인 (2026-04-14)으로 대방향 확정
1-2. 조건 설계 원칙 (PD님 3차 승인 기준)
- 유저가 확실히 컨트롤할 수 있는 조건: 누적형·운 의존·빌드 의존 조건 부적합
- 재도전 유도 방향성: "무난하게 모든 조건을 완성"이 아니라 "특정 조건을 만족하기 위해 여러 번 재도전"을 유발하도록 다소 난해한 수준
- 완화 방향 금지: 조건 수치는 "완화"가 아닌 "재도전 유도" 방향 튜닝
- P17 배타 배치 규칙 준수: 동시 배치 금지 조합 7종 회피
1-3. 조건 분류
Phase 2 §5 용어 기준:
- C 계열 (Clear 조건): 스테이지 진행 과정 전체 관점 6종 — C1·C2·C3·C6·C9·C12
- N 계열 (Node 조건 또는 Numeric 조건): 서브맵 단위 또는 특정 행동 기반 6종 — N1·N2·N3·N4·N5·N6
- 합계: 12종 (C10 "성장의 증거" 보류, N7 "방어 성공" 실측 완료 — PCDefence_Mul=0.3·쿨다운 없음·지속형·Melee/Range 공통·Mob 방어 부재, 조건 풀 추가 여부 Phase 3 재개 시 PD님 결정 / N8 "저 HP 완주" 변형 채택)
2. 조건 풀 12개 요약 테이블
| ID | 명칭 | 계열 | 수치 방식 | 유저 컨트롤 난이도 | 재도전 유도 강도 |
|---|---|---|---|---|---|
| C1 | 신속 | 시간 | 스테이지 총 소요 시간 ≤ 임계값 | 중 | 중 |
| C2 | 완벽 클리어 | HP | 스테이지 종료 시 PC HP = MaxHP | 중 | 고 |
| C3 | 고 HP 완주 | HP | 스테이지 종료 시 PC HP ≥ MaxHP × 70% | 저 | 저~중 |
| C6 | 포션 절제 | 카운트 | 스테이지 내 포션 사용 횟수 ≤ 임계값 | 저 | 중 |
| C9 | 보스 집중 | 카운트 | 보스 대상 유효 공격 ≥ 임계값 | 중 | 중 |
| C12 | 회피 주도 | 카운트 | 회피 발생 횟수 ≥ 서브맵수 × 3 이상 (유지 이상) | 고 | 고 |
| N1 | 빗맞힘 절제 | 카운트 | 빗맞힘 횟수 ≤ 임계값 | 중 | 중 |
| N2 | 피격 제한 | 카운트 | 피격 횟수 ≤ 서브맵수 × 1 이하 | 고 | 고 |
| N3 | 치명타 처치 | 카운트 | 치명타로 몬스터 처치 ≥ 임계값 | 중~고 | 고 |
| N4 | 쉴드 보존 | 비율 | 스테이지 종료 시 Shield ≥ MaxShield × 30% 이상 | 중 | 중 |
| N5 | 후열 선공 | 순서 | 서브맵마다 최초 공격 대상이 후열 | 저~중 | 중 |
| N6 | 전열 선공 | 순서 | 서브맵마다 최초 공격 대상이 전열 | 저~중 | 중 |
주의: 임계값 "이상/이하"의 구체적 숫자는 본 문서에서 확정하지 않는다 (HOLD 범위). Unity MCP 시뮬로 재도전 유도 강도와 밸런스를 검증한 후 Phase 3 재개 시점에 PD님 승인으로 확정.
3. C 계열 조건 상세 명세 (6종)
3-1. C1 — 신속 (스테이지 총 소요 시간)
정의
스테이지 시작부터 최종 보스 처치(또는 스테이지 종료)까지의 총 경과 시간이 임계값 이하.
달성 판정 로직 (의사코드)
OnStageStart:
stageTimer.start()
OnStageClear:
totalTime = stageTimer.elapsed()
if totalTime <= C1_threshold_of_stage(stageID):
condition_C1_satisfied = true
else:
condition_C1_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 | 리셋 시점 |
|---|---|---|---|
stageTimer_elapsedSec |
float | 스테이지 시작부터 누적 시간(초) | 스테이지 시작 시 0으로 |
UI 표시
- 스테이지 진입 시: 상단 또는 슬롯 표시 영역에 "목표: XX초 이내 클리어" (임계값 명시)
- 플레이 중: HUD에 경과 타이머 실시간 표시 (기존 시스템 활용 여지 확인 필요)
- 스테이지 종료 시: 결과창에 실제 소요 시간 vs 임계값 병기 + ✓/✗ 표시
개발팀 구현 요청 포인트
- 스테이지 경과 시간이 이미 측정되고 있는지 확인 (
StageManager또는 유사 클래스) - 포즈·메뉴 오픈 시간 제외 여부 결정 필요 — 기획팀장 초안: 실제 전투 시간만 카운트, UI 포즈 중 시간 제외
- 임계값은 스테이지별 고정 테이블로 관리 (예:
StageClearCondition.json또는 기존 테이블 확장)
엣지 케이스
- 사망 후 재시작: 재시작 시 타이머 0 리셋 (같은 스테이지 내 이어하기 없음 가정)
- 일시정지: 포즈 시간 제외 여부는 구현 방식에 따름
- 매우 짧은 스테이지 (Stage 1~2): 임계값이 너무 타이트하면 첫 플레이에서는 거의 불가능 — 재도전 유도 목적에는 적합하나 Stage 1·2의 입문 부담 고려 필요
P17 배타 조합
- (입문 1~6) C1 ∧ C3 동시 배치 금지 — 입문 구간 이중 부담
- 중반·후반은 허용
3-2. C2 — 완벽 클리어 (HP = MaxHP)
정의
스테이지 종료 시점에 PC의 HP가 MaxHP와 같음 (피격 후 회복도 인정).
달성 판정 로직 (의사코드)
OnStageClear:
if pc.currentHP == pc.maxHP:
condition_C2_satisfied = true
else:
condition_C2_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 | 리셋 시점 |
|---|---|---|---|
pc.currentHP |
int/float | PC 현재 HP | 실시간 갱신 |
pc.maxHP |
int/float | PC 최대 HP (성장·카드 효과 반영) | 성장·버프 적용 시 갱신 |
UI 표시
- 스테이지 진입 시: "HP Full 유지 필요" 뱃지
- 플레이 중: HP 바가 100% 미만으로 떨어지면 해당 조건 위반 예고 상태 (아이콘 흐려짐 등)
- 스테이지 종료 시: 결과창 ✓/✗
개발팀 구현 요청 포인트
pc.maxHP가 카드·각성·장비 효과로 실시간 변하는 경우의 처리 필요- 스테이지 종료 시점 정의 명확화: 최종 보스 처치 직후 프레임 vs 결과창 오픈 시점
- 중요: 피격 후 회복하여 HP=MaxHP 도달해도 인정 (PD님 해석 확인 필요 시 문의)
엣지 케이스
- MaxHP 증가 효과 (G3 "MaxHP 2배" 등) 중 HP도 2배로 회복되는가? — 개발팀 코드 확인 필요
- 종료 시점 판정 프레임: 결과창 오픈 시점 HP 기준으로 통일 권장
P17 배타 조합
- C2 ∧ N2 동시 배치 금지 — 피격 최소화 축 이중 부담
3-3. C3 — 고 HP 완주 (HP ≥ MaxHP × 70%)
정의
스테이지 종료 시점에 PC의 HP가 MaxHP의 70% 이상.
※ 임계값 "70%"는 Phase 2 §5 원안 기반 초안. Phase 3 재개 후 시뮬 결과로 재튜닝 가능.
달성 판정 로직 (의사코드)
OnStageClear:
hpRatio = pc.currentHP / pc.maxHP
if hpRatio >= C3_threshold: // 초안 0.7
condition_C3_satisfied = true
else:
condition_C3_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 |
|---|---|---|
pc.currentHP / pc.maxHP |
float | HP 비율 (0.0~1.0) |
UI 표시
- 스테이지 진입 시: "HP 70% 이상 유지" 뱃지
- 플레이 중: HP 바에 "70% 마커" 표시
- 스테이지 종료 시: 결과창에 최종 HP 비율 + ✓/✗
개발팀 구현 요청 포인트
- C2와 동일 구조. 임계값만 다름
- 임계값 상수화 필수 (스테이지별 개별 튜닝 가능성 대비)
엣지 케이스
- C2 충족 시 C3도 자동 충족 (HP=MaxHP는 ≥70% 만족). 논리상 문제 없음, 같은 슬롯에 중복 배치만 피하면 됨
P17 배타 조합
- (입문 1~6) C1 ∧ C3 동시 배치 금지
3-4. C6 — 포션 절제 (포션 사용 ≤ N)
정의
스테이지 내 포션(회복 아이템) 사용 횟수가 임계값 이하. "미사용"은 N=0 케이스.
달성 판정 로직 (의사코드)
OnPotionUsed(potionType):
potionUseCount += 1
OnStageClear:
if potionUseCount <= C6_threshold:
condition_C6_satisfied = true
else:
condition_C6_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 | 리셋 시점 |
|---|---|---|---|
potionUseCount |
int | 스테이지 내 포션 사용 누적 | 스테이지 시작 시 0 |
UI 표시
- 스테이지 진입 시: "포션 사용 N회 이하" 뱃지
- 플레이 중: 포션 슬롯 UI에 남은 허용 횟수 표시
- 스테이지 종료 시: 실제 사용 vs 임계값 + ✓/✗
개발팀 구현 요청 포인트
- "포션"의 정의 명확화: HP 포션·MP 포션·기타 소모품 중 어느 것을 카운트할지
- 기획팀장 초안: HP 회복계 물약만 카운트 (메테오·전체 기절 같은 전투용 물약은 별도 조건으로 다룰지 추후 논의)
- 패시브로 발동되는 회복 효과는 카운트 제외
엣지 케이스
- 물약 빌드와의 충돌: 물약 사용 시 추가 효과가 있는 카드(메테오·7.5초 무적·전체 기절)를 플레이하면 C6 달성 불가 → P17-2 배타 "C6 ∧ 물약 사용 유도 조건"으로 방지
- 회복 빌드와의 충돌: 힐 카드 패시브 회복은 포션 사용이 아니므로 영향 없음
P17 배타 조합
- C6 ∧ 물약 사용 유도 조건 동시 배치 금지
- C6 ∧ N4(쉴드 하한) 동시 배치 금지 — 회복 빌드 외 빌드 배제
3-5. C9 — 보스 집중 (보스 대상 유효 공격 ≥ N)
정의
스테이지 내 보스 몬스터를 대상으로 한 유효 공격 횟수가 임계값 이상. "처치 우선순위를 보스에 둔 플레이"를 유도.
※ "유효 공격"의 정의·임계값은 Phase 3 재개 후 시뮬로 확정. 본 문서는 판정 틀만 제시.
달성 판정 로직 (의사코드)
OnAttackLanded(attacker, target, damage):
if attacker == pc and target.type == MonsterType.Boss and damage > 0:
bossHitCount += 1
OnStageClear:
if bossHitCount >= C9_threshold_of_stage(stageID):
condition_C9_satisfied = true
else:
condition_C9_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 |
|---|---|---|
bossHitCount |
int | 스테이지 내 보스 피격(플레이어→보스) 누적 |
UI 표시
- 스테이지 진입 시: "보스에 N회 이상 공격" 뱃지
- 플레이 중: 카운터 표시 (권장)
- 스테이지 종료 시: 실제 vs 임계값 + ✓/✗
개발팀 구현 요청 포인트
- "유효 공격" 정의:
- 기획팀장 초안: 데미지 > 0인 공격만 카운트 (빗맞힘·회피된 공격 제외)
- 무적·반사 상태 몬스터 대상 공격의 카운트 여부 결정 필요
- Shield 흡수된 공격: HP에 들어간 데미지가 0이라도 Shield에 데미지가 들어갔다면 카운트해야 함 (개발팀 판단 필요)
- DOT (도트 데미지) 처리: 독·화상·처형 같은 지속 데미지 틱을 카운트할지 여부
엣지 케이스
- 보스가 여러 체인 경우 (Stage 20 등 3체): 각 보스별 카운트를 합산
- 보스 미등장 서브맵 + 보스 등장 서브맵 혼재: 전체 스테이지 합산이므로 문제 없음. 단, 보스 미등장 서브맵 비율이 너무 높으면 임계값 달성 불가
- 단독 보스 스테이지 (Stage 7·10·13): P17-5로 C9 배치 금지
P17 배타 조합
- C9 ∧ 단독 보스·보스 미등장 스테이지 동시 배치 금지
- 맵 패턴 재검증 필요 (맵패턴_사전분석_v1 §1·§2 참조)
연동 작업
- 보스 혼용 등장 패턴 설계 (맵패턴_사전분석_v1 §2) 완료 후 임계값 재튜닝
3-6. C12 — 회피 주도 (회피 횟수 ≥ 서브맵수 × 3 이상)
정의
스테이지 내 PC의 회피 발생 횟수가 (해당 스테이지 서브맵 수 × 3) 이상. PD님 지침 "유지 이상"으로 재도전 유도 강도 고수위.
달성 판정 로직 (의사코드)
OnAttackMissed(attacker, target):
if target == pc and miss_reason == "Avoid":
avoidCount += 1
OnStageClear:
requiredAvoid = submap_count_of_stage(stageID) * 3
if avoidCount >= requiredAvoid:
condition_C12_satisfied = true
else:
condition_C12_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 |
|---|---|---|
avoidCount |
int | 스테이지 내 회피 발생 누적 |
submap_count_of_stage(stageID) |
int | 해당 스테이지 서브맵 총 수 (고정 데이터) |
UI 표시
- 스테이지 진입 시: "회피 X회 이상" (X = 서브맵수 × 3) 뱃지
- 플레이 중: 카운터 표시 권장
- 스테이지 종료 시: ✓/✗
개발팀 구현 요청 포인트
- "회피"의 정의:
Avoid_M/Avoid_R스탯에 의한 미스만 포함. 빗맞힘(Miss)과 구분 필요 - 몬스터 공격에 대한 PC 회피만 카운트. PC 공격이 몬스터에게 회피된 것은 N1(빗맞힘 절제)의 "빗맞힘"에 해당 (별도 조건)
- 서브맵 수는 스테이지별 고정 데이터 (
CreateMapConfig.json또는 유사)에서 조회
엣지 케이스
- 서브맵 수 이상 스테이지 (Stage 7=4, 13=4, 16=3 등): 임계값이 낮아져 달성이 쉬워질 수 있음 — PD님 지침 "유지 이상"에 따라 스테이지별 추가 상향 검토 여지
- 회피율 극대화 빌드: 회피 빌드와 시너지가 극도로 강함. P17에 "회피 빌드 유도 조건"과의 배타 조합이 필요한지는 추후 판단 (현재 미등재)
P17 배타 조합
- 현재 P17 7종 배타 조합에 C12는 포함되지 않음
- 단, N1(빗맞힘 절제)과 구조 유사점 있음. 동시 배치 시 혼동 가능성 UI 점검 필요
4. N 계열 조건 상세 명세 (6종)
4-1. N1 — 빗맞힘 절제 (빗맞힘 ≤ N)
정의
스테이지 내 PC의 공격 빗맞힘(Miss) 횟수가 임계값 이하. "정확도 플레이"를 유도.
달성 판정 로직 (의사코드)
OnAttackMissed(attacker, target):
if attacker == pc and miss_reason == "Miss": // Hit 판정 실패
missCount += 1
OnStageClear:
if missCount <= N1_threshold:
condition_N1_satisfied = true
else:
condition_N1_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 |
|---|---|---|
missCount |
int | 스테이지 내 PC 공격이 빗맞은 횟수 |
UI 표시
- 스테이지 진입 시: "빗맞힘 N회 이하" 뱃지
- 플레이 중: 카운터 (권장, 선택적)
- 스테이지 종료 시: ✓/✗
개발팀 구현 요청 포인트
Miss스탯 vsAvoid스탯을 명확히 구분해 판정 (공격자 Hit 실패 = Miss, 수비자 회피 성공 = Avoid)- 몬스터의 회피 성공(Avoid_M/R) 때문에 PC 공격이 빗나간 경우 — 이것은 "Miss"가 아니라 "Avoided"로 구분해야 함. 구분 불가능한 경우는 C9·C12와 상호 모순 발생 가능성 → 개발팀 점검 필요
엣지 케이스
- 빗맞힘이 극히 드문 빌드 (높은 명중률 빌드): N1 달성이 거의 자동 → 임계값을 낮춰 난이도 확보 필요
- C12와의 구분 UI: "회피"와 "빗맞힘" 용어 혼동을 방지하는 UI 문구 필요
P17 배타 조합
- 현재 없음
4-2. N2 — 피격 제한 (피격 ≤ 서브맵수 × 1 이하)
정의
스테이지 내 PC가 피격받은 횟수가 (서브맵수 × 1) 이하. Shield·HP에 데미지가 들어간 모든 피격 카운트.
달성 판정 로직 (의사코드)
OnDamageReceived(target, damage):
if target == pc and damage > 0:
hitCount += 1
OnStageClear:
maxHits = submap_count_of_stage(stageID) * 1
if hitCount <= maxHits:
condition_N2_satisfied = true
else:
condition_N2_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 |
|---|---|---|
hitCount |
int | 스테이지 내 PC 피격 누적 |
UI 표시
- 스테이지 진입 시: "피격 X회 이하" (X = 서브맵수 × 1) 뱃지
- 플레이 중: 카운터 표시 필수 — 피격 1회마다 긴장감 고조
- 스테이지 종료 시: ✓/✗
개발팀 구현 요청 포인트
- "피격"의 정의:
- 기획팀장 초안: Shield 흡수 피격 + HP 데미지 피격 모두 카운트 (의도된 방어가 있었든 없었든 "맞았다"는 사실만)
- Avoid된 공격은 카운트 제외
- 반사·무적으로 무효화된 공격: 카운트 제외 (피해 발생 없음)
- DOT는 데미지 틱마다 카운트하지 않고 "최초 부착 시 1회"만 카운트 (초안). 대안: 틱마다 카운트. 개발팀과 협의 필요
엣지 케이스
- 서브맵 수 이상 스테이지: C12와 동일. 임계값 재튜닝 여지
- 최종 보스 단 1체 스테이지: 피격이 집중되므로 N2 달성 난이도 급증
P17 배타 조합
- C2 ∧ N2 동시 배치 금지
4-3. N3 — 치명타 처치 (치명타로 처치 ≥ N)
정의
스테이지 내 치명타 공격으로 몬스터를 처치한 횟수가 임계값 이상. 치명타 빌드와 시너지.
달성 판정 로직 (의사코드)
OnMonsterKilled(killer, target, killBlow):
if killer == pc and killBlow.isCritical == true:
critKillCount += 1
OnStageClear:
if critKillCount >= N3_threshold:
condition_N3_satisfied = true
else:
condition_N3_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 |
|---|---|---|
critKillCount |
int | 치명타로 처치한 몬스터 수 |
UI 표시
- 스테이지 진입 시: "치명타 처치 N회 이상" 뱃지
- 플레이 중: 카운터 + 치명타 발생 시 시각·음향 강화 (기존 크리 연출 활용)
- 스테이지 종료 시: ✓/✗
개발팀 구현 요청 포인트
- "처치 타격" 판정: 몬스터 HP를 0으로 만든 최종 타격이 치명타였는지 확인. 중간 치명타는 카운트 안 됨
- DOT로 처치 시: 최종 틱이 치명타 판정을 가지는 경우 처리 방법 결정
- 처형·관통 같은 특수 스킬의 치명타 판정 여부 확인
엣지 케이스
- 치명타율이 매우 낮은 빌드 (치명타 빌드 아닌 경우): 임계값 달성이 거의 불가능 → 입문 구간 배치 부적합
- P17-6 "(입문 1~6) N3 단독 배치 금지" — 치명타 빌드 미형성 구간이라 달성 곤란
P17 배타 조합
- (입문 1~6) N3 단독 배치 금지
4-4. N4 — 쉴드 보존 (Shield ≥ MaxShield × 30%)
정의
스테이지 종료 시점에 PC의 Shield가 MaxShield의 30% 이상. "쉴드 관리 플레이"를 유도.
달성 판정 로직 (의사코드)
OnStageClear:
shieldRatio = pc.currentShield / pc.maxShield
if shieldRatio >= N4_threshold: // 초안 0.3
condition_N4_satisfied = true
else:
condition_N4_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 |
|---|---|---|
pc.currentShield / pc.maxShield |
float | Shield 비율 |
UI 표시
- 스테이지 진입 시: "Shield 30% 이상 유지" 뱃지
- 플레이 중: Shield 바에 30% 마커
- 스테이지 종료 시: ✓/✗
개발팀 구현 요청 포인트
- Shield 시스템 구조 확인: 재생 Shield / 1회성 Shield / 성소 Shield의 구분과
pc.currentShield/pc.maxShield계산 방식 - MaxShield가 동적인가: 카드·장비·각성으로 MaxShield가 변하는지 확인
- Shield 보유 불가능 빌드: PC나 빌드에 따라 MaxShield=0인 경우 본 조건 배치 금지 (단독 스테이지 특성 필요)
엣지 케이스
- MaxShield = 0: 판정 시 0으로 나누기 방지. 해당 상황은 N4 배치가 부적절한 스테이지
- Shield 회복 카드 있는 경우: Shield 회복계 카드가 자연 배치되면 N4 달성 쉬워짐
P17 배타 조합
- C6 ∧ N4 동시 배치 금지 — 회복 빌드 외 배제
4-5. N5 — 후열 선공 (서브맵마다 최초 공격 대상이 후열)
정의
각 서브맵마다 PC가 처음 가하는 공격의 대상이 '후열 몬스터'. 스테이지 내 모든 서브맵에서 성공해야 충족.
달성 판정 로직 (의사코드)
OnSubmapStart(submapID):
firstAttack_submapID = submapID
firstAttack_registered = false
OnAttackLanded(attacker, target, damage):
if attacker == pc and damage > 0 and firstAttack_registered == false:
if target.position == Position.Rear:
firstAttack_N5_success[submapID] = true
else:
firstAttack_N5_success[submapID] = false
firstAttack_registered = true
OnStageClear:
if all firstAttack_N5_success[submap] == true for all submaps:
condition_N5_satisfied = true
else:
condition_N5_satisfied = false
측정 변수
| 변수명 | 타입 | 설명 |
|---|---|---|
firstAttack_N5_success[submapID] |
bool | 서브맵별 성공 여부 |
firstAttack_registered |
bool | 서브맵 내 최초 공격 확정 여부 |
UI 표시
- 스테이지 진입 시: "모든 서브맵에서 후열부터 공격" 뱃지
- 서브맵 시작 시: "후열 선공" 힌트 표시
- 최초 공격 후: 성공/실패 즉시 피드백 아이콘
- 스테이지 종료 시: ✓/✗
개발팀 구현 요청 포인트
- 몬스터의 전열/후열 판정:
MonsterPatternList.json/ApprearMonsterPattern.json의 배치 정보 또는 런타임 위치로 판정 - 서브맵에 후열 몬스터가 없는 경우: N5 달성 불가 → 해당 스테이지·서브맵에 N5 배치 금지
- "공격"의 정의: 자동 공격만 카운트? 스킬 공격도 포함? — 기획팀장 초안: 모든 데미지 발생 공격
엣지 케이스
- 후열 몬스터 미등장 서브맵: 해당 서브맵 때문에 스테이지 전체 실패 → 배치 전 서브맵별 몬스터 구성 점검 필수
- 정합성 검증: 기획팀 CLAUDE.md "등장 패턴과 3성 조건의 정합성" 항목과 직결. 맵 패턴 확정 후 N5 배치 가능 스테이지 재식별 필요
P17 배타 조합
- N5 ∧ N6 동시 배치 금지 — 타겟팅 자유도 박탈·논리 모순
4-6. N6 — 전열 선공 (서브맵마다 최초 공격 대상이 전열)
정의
각 서브맵마다 PC가 처음 가하는 공격의 대상이 '전열 몬스터'. N5의 거울상.
달성 판정 로직 (의사코드)
(N5의 후열 → 전열 치환. 나머지 동일)
if target.position == Position.Front:
firstAttack_N6_success[submapID] = true
측정 변수
N5와 동일 구조 (변수명만 N6).
UI 표시
- N5와 동일 구조 (문구만 "전열 선공")
개발팀 구현 요청 포인트
- N5와 동일. 단 전열 몬스터 부재 서브맵 없음이 일반적이나 확인 필요 (보스 전용 서브맵 등 예외)
엣지 케이스
- 후열만 등장하는 서브맵이 있다면 N6 배치 불가 — 흔치 않으나 확인 필요
P17 배타 조합
- N5 ∧ N6 동시 배치 금지
5. 공통 설계 원칙·횡단 이슈
5-1. 임계값 관리 원칙
- 조건별 임계값은 스테이지 단위로 테이블화:
StageStarCondition.json(가칭) 또는 기존 스테이지 테이블 확장 - 기본값 + 스테이지별 오버라이드 체계: 전역 기본값을 두고 특정 스테이지만 덮어쓰기 가능
- 임계값 튜닝은 Unity MCP 시뮬 실측 결과 기반 (Phase 3 재개 후)
5-2. 달성 판정의 공통 요구사항
- 모든 조건 판정은 스테이지 종료 시점에 최종 결정
- 중간 실패 확정 조건(C2·C3·N4 등 HP/Shield 기준)도 UI는 실시간 경고, 최종 판정은 종료 시점
- 중간 포기 (방 나가기·재시작) 시: 해당 런의 조건 기록 모두 폐기
5-3. 측정 변수의 저장 구조
재개 시점에 개발팀이 구현해야 할 런타임 상태 컨테이너:
class StageConditionTracker {
// 시간
float stageTimer_elapsedSec;
// HP / Shield
// (실시간 pc 객체 참조로 충분)
// 카운터
int potionUseCount;
int bossHitCount;
int avoidCount;
int missCount;
int hitCount;
int critKillCount;
// 서브맵 단위 bool
Dict<submapID, bool> firstAttack_N5_success;
Dict<submapID, bool> firstAttack_N6_success;
bool firstAttack_registered_current;
// ... 등
}
5-4. Unity MCP 시뮬 실측 검증 시 확인 항목
개발팀의 Unity MCP EditMode 시뮬 환경(Assets/Sim/) 구축 이후, 각 조건에 대해:
- 동일 입력으로 Unity MCP 시뮬과 Unity 실 빌드의 조건 판정 결과가 일치하는가
- 측정 변수의 스테이지 종료 시점 값이 일치하는가
- 엣지 케이스 (Shield 흡수, DOT, 동시 처치 등)에서 판정 기준이 일치하는가
6. 조건 판정 검증 체크리스트 (Phase 3 재개 시 활용)
6-1. 조건별 단위 테스트 매트릭스
| 조건 | 테스트 1 (명확 통과) | 테스트 2 (명확 실패) | 테스트 3 (경계값) | 테스트 4 (엣지) |
|---|---|---|---|---|
| C1 | 임계값 - 1초 완주 | 임계값 + 1초 완주 | 임계값 정확히 | 포즈 시간 제외 검증 |
| C2 | HP=MaxHP | HP=MaxHP-1 | HP=MaxHP(회복 후) | MaxHP 동적 변화 중 |
| C3 | HP=MaxHP×1.0 | HP=MaxHP×0.69 | HP=MaxHP×0.70 | MaxHP 동적 변화 |
| C6 | 포션 0 사용 | 포션 임계값+1 | 임계값 정확히 | 비 HP 포션 구분 |
| C9 | 임계값+1 공격 | 임계값-1 | 정확히 | Shield 흡수 공격 |
| C12 | 서브맵수×3+1 | 서브맵수×3-1 | 정확히 | Avoid와 Miss 구분 |
| N1 | 0 빗맞힘 | 임계값+1 | 정확히 | 몬스터 Avoid 제외 |
| N2 | 서브맵수-1 피격 | 서브맵수+1 | 정확히 | 반사 무효화 피격 |
| N3 | N+1 치명타 처치 | N-1 | 정확히 | DOT 처치 |
| N4 | 30%+1 Shield | 30%-1 | 정확히 | MaxShield=0 가드 |
| N5 | 모든 서브맵 후열 선공 | 1개 서브맵 실패 | - | 후열 부재 서브맵 |
| N6 | 모든 서브맵 전열 선공 | 1개 서브맵 실패 | - | 전열 부재 서브맵 |
6-2. 통합 검증
- 21개 스테이지 × 슬롯2·슬롯3 가상 배치로 조건 판정이 오류 없이 작동하는지 전수 실측
- 맵 패턴 사전분석 v1 §3-3 체크리스트를 이 단계에서 실제 적용 (현재는 틀만 준비됨)
7. 개발팀 요청서 초안 (구조만)
※ 정식 요청서는
공유/기획팀→개발팀/폴더에 날짜·REQ번호 부여하여 생성. 본 문서는 내용 초안만 제공.
요청 개요
- 제목: 수상한 잡화점 ★ 조건 12개 판정 로직 구현 요청
- 배경: Phase 2 §5 PD님 3차 승인으로 조건 풀 12개 확정. Unity MCP EditMode 독립 어셈블리(
Assets/Sim/BurningTimes.Sim.asmdef) 기반 구현 - 선행 조건: 본 설계 문서(
3성조건_12개_상세명세_v1.md) 개발팀 리뷰 완료
요청 내용 (요약)
- §3·§4의 조건별 판정 로직을 C# 런타임에 구현
- §5-3의
StageConditionTracker(또는 상응 구조) 설계 - Unity MCP 시뮬 어셈블리와 실 빌드 간 공통 코드 경로 확보 (동일 판정기 사용)
- §6-1의 단위 테스트 매트릭스를 자동 테스트로 구축
- 임계값은 테이블 구동 — 코드 내 하드코딩 금지 (스테이지별 튜닝 가능성 대비)
우려 사항·문의
- §3·§4 각 조건의 "엣지 케이스"에 대한 개발팀 판단 필요
- N7 방어 성공 조건이 추후 13번째 조건으로 추가될 가능성 —
StageConditionTracker를 확장 가능한 구조로 설계 권장
8. 변경 이력 (P18 요구 사항)
| 일자 | 변경 | 근거 |
|---|---|---|
| 2026-04-14 | 초안 작성 (v1) | PD님 재량 위임 지시 (Phase 3 HOLD 중 가능 작업) + Phase 2 §5 PD님 3차 승인 조건 풀 12개 |
향후 예정 변경:
- Phase 3 재개 후 시뮬 기반 임계값 확정 → v2
- N7 방어 성공 조건 추가 결정 시 → §4에 추가 + v2
- 개발팀 리뷰 피드백 수령 후 반영 → v1.1 or v2
9. HOLD 준수 확인
본 문서가 Phase 3 HOLD 영역을 침범하지 않음
| 체크 항목 | 상태 |
|---|---|
| 성장 요소(각성·진화·장비·인장) 기여도 측정 | 미수행 ✓ |
| 시뮬레이션 실행 | 미수행 ✓ |
| 카드 수치 조정 제안 | 미수행 ✓ |
| 조건별 구체적 임계값 수치 확정 | 미수행 (초안 값은 Phase 2 §5 원안 인용에 한정) ✓ |
| 데이터 테이블 변경 | 미수행 ✓ |
| 스테이지별 슬롯 배치 확정 | 미수행 ✓ |
본 문서가 수행한 것
- 기존 PD님 3차 승인 조건 풀 12개의 설계 명문화 (P18 의무 이행)
- 조건별 판정 로직 의사코드 수준의 구현 요구 정의
- 개발팀과의 협업 문서 초안 (Phase 3 재개 시 즉시 활용)
10. 참조 문서
프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md§5 (조건 풀 12개 PD님 3차 승인)프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md§1·§2 (C9·N5·N6 배치 제약)프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md§2-5 (조건 판정 재검증 항목 22~25)프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md§4 (N7 보류·N8 변형 채택).claude/skills/BurningTimes-코어룰/SKILL.mdP17 (배타 배치 규칙 7종) + P18 (설계 문서화 의무)공유/조직공지/Phase 3 HOLD 공지 (HOLD 범위 준수)- 방향 전환 이력: 방향전환 히스토리 아카이브 §3성조건 12개
작성 완료: 2026-04-14 상태: P18 설계 문서화 의무 이행용 초안 / Phase 3 재개 후 임계값 확정 및 v2 전환 예정