126 lines
7.6 KiB
Markdown
126 lines
7.6 KiB
Markdown
|
---
|
||
|
|
type: 응답서
|
||
|
|
from: 개발팀장
|
||
|
|
to: 총괄PM / 기획팀장
|
||
|
|
subject: Phase 0-C Q-P1/Q-P2 개발 관점 응답 + 시뮬레이터 전략 업데이트
|
||
|
|
date: 2026-04-17
|
||
|
|
status: 완료
|
||
|
|
related:
|
||
|
|
- 프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md
|
||
|
|
- 프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md
|
||
|
|
- 프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md
|
||
|
|
depends_on:
|
||
|
|
- PD 지시 #5-B (Phase 0-C Q-P 응답)
|
||
|
|
- PD 지시 #28 (Unity MCP 전환)
|
||
|
|
---
|
||
|
|
|
||
|
|
# Phase 0-C — Q-P1/Q-P2 응답 + 시뮬레이터 전략 업데이트
|
||
|
|
|
||
|
|
## 0. 본 문서 범위
|
||
|
|
|
||
|
|
기획팀이 `Phase0_1_앵커전투시뮬레이션_v1.md §6` 에 남긴 질의 2건에 대한 개발 관점 응답 + **2026-04-17 PD님 Unity MCP 전환 지시(#28)를 반영한 시뮬레이터 전략 재설정**.
|
||
|
|
|
||
|
|
개발팀 PD 지시 로그 #5-B의 "Q-P1/P2/P3" 표기는 실제로 Q-P1(질의 1건) + Q-P2(서브 질의 3건)의 편의 표기였음. 본 응답서는 기획팀 원문 기준으로 Q-P1·Q-P2를 대응한다.
|
||
|
|
|
||
|
|
## 1. Q-P1 응답 — "4마리 노드 초반 위험도는 의도된 설계인가?"
|
||
|
|
|
||
|
|
### 1-1. 기획팀 질의 요지
|
||
|
|
> "카드 0장 상태에서 4마리 노드가 '터치 방어 없이는 위험'한 현재 상태는 의도된 설계? (=터치 방어를 자연스럽게 가르치기 위함?)"
|
||
|
|
|
||
|
|
### 1-2. 개발팀 응답 (실증 기반)
|
||
|
|
**개발팀 단독 답변 불가 범주**. 이유:
|
||
|
|
1. "의도된 설계 여부"는 **기획 의도의 영역**이며 개발팀은 결정권이 없음 (C7·C11 구분)
|
||
|
|
2. 개발팀이 제공할 수 있는 것은 **코드 실측**(터치 방어 유무에 따른 생존 시나리오) + **구조적 힌트**(초기 4마리 노드가 카드 풀 구성 규칙과 맞물려 있는지)
|
||
|
|
|
||
|
|
### 1-3. 개발팀이 제공 가능한 근거
|
||
|
|
- `Assets/Script/InGame/Actor/PCActor.cs` L37: `eActorStatus.Defecne` + `InGameInfo.Ins.Set_PCBlock` → 터치 방어는 PC(플레이어 캐릭터) 상태 효과로 실체화되어 있음
|
||
|
|
- 카드 0장 상태의 실측 DPS·EHP는 개발팀 Unity MCP 시뮬레이션으로 제공 가능 (§3 전략 참조)
|
||
|
|
|
||
|
|
### 1-4. 권장 진행 방향
|
||
|
|
- 기획팀이 **의도 명확화 선언** → 개발팀이 Unity MCP로 해당 설계가 수치적으로 성립하는지 검증
|
||
|
|
- 구체적으로: 기획팀이 "터치 방어 없이 4마리 처리 가능 여부"의 목표 비율(예: 80% 생존)을 수치화 → 개발팀이 시뮬레이션으로 현 수치가 목표를 만족하는지 응답
|
||
|
|
|
||
|
|
## 2. Q-P2 응답 — "터치 방어 메커닉 정확도"
|
||
|
|
|
||
|
|
### 2-1. 기획팀 질의 요지
|
||
|
|
1. 터치 1회 = 다음 공격 1회 피해 50% 감소?
|
||
|
|
2. 터치 유지 중 계속 50% 감소?
|
||
|
|
3. 쿨다운?
|
||
|
|
|
||
|
|
### 2-2. 개발팀 응답 (코드 실증 기반, 미확인 항목 명시)
|
||
|
|
|
||
|
|
**확인된 사실** (실제 `PCActor.cs`·`Actor.cs` 실측):
|
||
|
|
- 터치 방어는 `eActorStatus.Defecne`(원문 오타 `Defecne`) 상태 효과로 모델링
|
||
|
|
- `InGameInfo.Ins.Set_PCBlock` 을 통해 블록 스프라이트·상태를 설정
|
||
|
|
- "블록(Block)" 용어와 "방어(Defense)" 용어가 **혼용**되어 있음 (현 구조의 약점)
|
||
|
|
|
||
|
|
**미확인 — 정밀 코드 리뷰 필요**:
|
||
|
|
- 50% 감소 수치의 실제 테이블 위치 (Actor·Effect·Card 중 어디에 기록?)
|
||
|
|
- 감소 비율이 **고정값인지 카드·장비·인장 옵션에 따라 변동**하는지
|
||
|
|
- 쿨다운 존재 여부·값
|
||
|
|
- "1회성"인지 "지속형"인지 (상태 효과 duration 필드가 별도 관리되는지)
|
||
|
|
|
||
|
|
**개발팀 차기 조치** (본 응답서 발신 후 즉시 착수 가능):
|
||
|
|
1. `Actor.cs`·`PCActor.cs`·관련 `Effect*.cs` 정밀 리뷰하여 수치 위치 식별
|
||
|
|
2. 기획팀 `StatusEffect` 마스터 테이블 확인
|
||
|
|
3. Q-P2 3문항 각각에 **코드·테이블 실측 근거 포함 2차 응답서** 제출
|
||
|
|
|
||
|
|
### 2-3. 본 응답의 한계
|
||
|
|
본 응답은 **초벌 스캔 결과**이며, 50% 감소·쿨다운 확정 수치는 미확정. Q-P2는 **2차 응답서로 완결** 필요 (C23 정직 보고).
|
||
|
|
|
||
|
|
## 3. 시뮬레이터 전략 업데이트 (07 문서 후속)
|
||
|
|
|
||
|
|
### 3-1. 배경 변경
|
||
|
|
- **PD님 2026-04-17 직접 지시 (#28)**: 기획팀 시뮬레이션 작업은 **Unity MCP 기반**으로 전환
|
||
|
|
- Python 시뮬 파일은 **소실 확정 — 폐기 사안**
|
||
|
|
- 교차 검증 축 이원화 방침 폐기 → **Unity MCP 단일 축**으로 확정
|
||
|
|
|
||
|
|
### 3-2. 재설정된 시뮬레이션 전략
|
||
|
|
|
||
|
|
| 항목 | 결정 |
|
||
|
|
|------|------|
|
||
|
|
| 시뮬레이션 실행 환경 | Unity Editor + Unity MCP (`mcp__unity-mcp__*`) |
|
||
|
|
| 결과 취득 방법 | `execute_code`·`run_tests`·`manage_editor` 등으로 플레이 모드 제어 + 로그/결과 수집 |
|
||
|
|
| 시뮬레이션 코드 위치 | `Assets/Script/Server/`·`Assets/Script/InGame/` 등 기존 프로젝트 내부 (별도 시뮬레이터 레포 불필요) |
|
||
|
|
| 성능 모드 | Headless 불필요 — 기획팀 밸런싱은 시각적 피드백 포함이 유리. 배치 검증 시에만 PlayMode 자동화 |
|
||
|
|
| 결과 저장 | `기획팀/.cache/` 또는 `공유/시뮬결과/` (기획팀 결정) — 개발팀은 실행 환경 제공까지 |
|
||
|
|
|
||
|
|
### 3-3. 개발팀이 제공할 인프라 (Phase 0-C 잔여)
|
||
|
|
1. **시뮬레이션 진입점 스크립트**: 전투만 격리 실행 가능한 `SimulationRunner.cs` 프로토타입 (PlayMode 의존 최소화)
|
||
|
|
2. **파라미터 외부화**: 앵커 전투 시나리오(몬스터 구성·PC 상태·카드 0장 등)를 JSON/ScriptableObject 외부 입력으로 받도록 리팩토링 포인트 식별
|
||
|
|
3. **결과 수집 포맷**: 시뮬레이션 1회 결과를 `{timestamp, scenario_id, turns, dmg_taken, survived, ...}` 구조화 JSON 출력
|
||
|
|
4. **Unity MCP 호출 템플릿**: 기획팀장이 `Task` 또는 `/게임플레이` 에이전트 호출 시 바로 쓸 수 있는 MCP 호출 스니펫 (3종: 단일 실행 / 파라미터 스윕 / 배치 비교)
|
||
|
|
|
||
|
|
**작성 예정 산출물** (본 응답서 뒤 착수):
|
||
|
|
- `공유/소통/개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_인프라_설계_v2.md` — 상기 4종 인프라의 구체 설계
|
||
|
|
- 기존 `공유/소통/개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md` (이미 존재, #28 참조) 위에 **실행 인프라 단계** 추가
|
||
|
|
|
||
|
|
### 3-4. 기획팀 작업 재개 조건
|
||
|
|
- 위 3-3의 인프라 4종 중 최소 (1)·(3)·(4)가 완료되면 기획팀이 앵커 전투 시뮬레이션 작업 재개 가능
|
||
|
|
- (2) 파라미터 외부화는 병행 진행 가능 (선택사항)
|
||
|
|
|
||
|
|
## 4. 기각안 (P24)
|
||
|
|
|
||
|
|
- **기각안 A: 전투 메커닉 전수 자동 리버스 엔지니어링 + 본 응답서에 통합 수록** — 작업량 막대 + 본 응답서 범위 초과. Q-P2 2차 응답서로 분리
|
||
|
|
- **기각안 B: Python 시뮬레이터 복구 시도** — PD님 "폐기 사안" 확정(#28 비고란). 복구 시도 자체가 지시 위반
|
||
|
|
- **기각안 C: Unity 외 3rd-party 시뮬레이터 도입 검토** — PD님 Unity MCP 단일 방향 확정. 검토 대상 아님
|
||
|
|
- **기각안 D: Q-P1에 "의도된 설계로 추정됨" 단정 응답** — 개발팀 의사결정 권한 외. C23 위반 회피
|
||
|
|
|
||
|
|
## 5. 후속 작업 · 블로커
|
||
|
|
|
||
|
|
### 5-1. 개발팀 즉시 착수 항목 (본 응답서 발신 후)
|
||
|
|
1. Q-P2 정밀 2차 응답 (코드·테이블 실측)
|
||
|
|
2. §3-3 인프라 4종 (1)·(3)·(4) 구현
|
||
|
|
3. Unity MCP 호출 스니펫 문서화
|
||
|
|
|
||
|
|
### 5-2. 기획팀 필요 액션
|
||
|
|
1. Q-P1에 대한 **기획 의도 선언** (의도된 설계? 개선 필요?)
|
||
|
|
2. §3-3 시뮬레이션 결과 저장 위치 결정
|
||
|
|
3. Q-P2 정밀 응답 수령 후 터치 방어 정책 재확인
|
||
|
|
|
||
|
|
### 5-3. PM 조율 필요
|
||
|
|
- 없음 (팀 자율 진행 가능 범위, C29-1 정합)
|
||
|
|
|
||
|
|
## 부록. 변경 이력
|
||
|
|
- **v1 (2026-04-17)**: 초판. 개발팀장 Phase 0-C Q-P 응답 + Unity MCP 전환 반영 시뮬레이터 전략 v2 초안 작성.
|