7.6 KiB

Raw Blame History

type

from

subject

date

status

depends_on

응답서

개발팀장

총괄PM / 기획팀장

Phase 0-C Q-P1/Q-P2 개발 관점 응답 + 시뮬레이터 전략 업데이트

2026-04-17

완료

프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md

프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md

프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md

PD 지시

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. 개발팀 응답 (실증 기반)

개발팀 단독 답변 불가 범주. 이유:

"의도된 설계 여부"는 기획 의도의 영역이며 개발팀은 결정권이 없음 (C7·C11 구분)
개발팀이 제공할 수 있는 것은 코드 실측(터치 방어 유무에 따른 생존 시나리오) + 구조적 힌트(초기 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회 피해 50% 감소?
터치 유지 중 계속 50% 감소?
쿨다운?

2-2. 개발팀 응답 (코드 실증 기반, 미확인 항목 명시)

확인된 사실 (실제 PCActor.cs·Actor.cs 실측):

터치 방어는 eActorStatus.Defecne(원문 오타 Defecne) 상태 효과로 모델링
InGameInfo.Ins.Set_PCBlock 을 통해 블록 스프라이트·상태를 설정
"블록(Block)" 용어와 "방어(Defense)" 용어가 혼용되어 있음 (현 구조의 약점)

미확인 — 정밀 코드 리뷰 필요:

50% 감소 수치의 실제 테이블 위치 (Actor·Effect·Card 중 어디에 기록?)
감소 비율이 고정값인지 카드·장비·인장 옵션에 따라 변동하는지
쿨다운 존재 여부·값
"1회성"인지 "지속형"인지 (상태 효과 duration 필드가 별도 관리되는지)

개발팀 차기 조치 (본 응답서 발신 후 즉시 착수 가능):

Actor.cs·PCActor.cs·관련 Effect*.cs 정밀 리뷰하여 수치 위치 식별
기획팀 StatusEffect 마스터 테이블 확인
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 잔여)

시뮬레이션 진입점 스크립트: 전투만 격리 실행 가능한 SimulationRunner.cs 프로토타입 (PlayMode 의존 최소화)
파라미터 외부화: 앵커 전투 시나리오(몬스터 구성·PC 상태·카드 0장 등)를 JSON/ScriptableObject 외부 입력으로 받도록 리팩토링 포인트 식별
결과 수집 포맷: 시뮬레이션 1회 결과를 {timestamp, scenario_id, turns, dmg_taken, survived, ...} 구조화 JSON 출력
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. 개발팀 즉시 착수 항목 (본 응답서 발신 후)

Q-P2 정밀 2차 응답 (코드·테이블 실측)
§3-3 인프라 4종 (1)·(3)·(4) 구현
Unity MCP 호출 스니펫 문서화

5-2. 기획팀 필요 액션

Q-P1에 대한 기획 의도 선언 (의도된 설계? 개선 필요?)
§3-3 시뮬레이션 결과 저장 위치 결정
Q-P2 정밀 응답 수령 후 터치 방어 정책 재확인

5-3. PM 조율 필요

없음 (팀 자율 진행 가능 범위, C29-1 정합)

부록. 변경 이력

v1 (2026-04-17): 초판. 개발팀장 Phase 0-C Q-P 응답 + Unity MCP 전환 반영 시뮬레이터 전략 v2 초안 작성.

7.6 KiB Raw Blame History