Rougelike-EndWalker — 기획 문서 초기 착수 스냅샷
1. 주요 변경사항
- 프로젝트 컨셉 문서(
README.md) 신규 작성. 장르(2D 디스토피아 로그라이트 Co-op), 코어 루프 4 페이즈, 시스템 목록 4 종, 레퍼런스, 리스크 표, 마일스톤 스켈레톤을 담음. Visualizer Doc/BattleMap logic Visualizer.md신규. Critical Path 우선 생성 + 사이드 분기 + 루프 클로징의 3 Phase 알고리즘과 그리드 규칙, 제약 조건(경계 마진 · Deadend 고립) 을 상세 기술.Visualizer Doc/Stage Nod Visualizer.md신규. Stage 1~6 각 열별 노드 배치 규칙과 BO 쿨다운, Stage 5 분기, Stage 6 히든 루트 플로우를 ASCII 다이어그램으로 시각화.Visualizer Doc/Multiplay Visualizer.md신규. 세션 생성/참가 흐름, 공유 시드 기반 맵 생성, 개인/공유 보상 구분을 도식화.- 총 4 파일 / 774 라인 추가. 실제 코드(.cs, .unity, .asmdef 등) 변경은 전무.
- 커밋 메시지는
Feat/ReadMe.md,Feat/Visuzlizer_Doc&Fix_README.md로 브랜치 네이밍 컨벤션을 흉내냈으나 오타(Visuzlizer) 가 남아있음.
2. 코드 품질 리뷰
현 커밋 범위에는 C# / Unity 자산이 전무하여 코드 품질(평가 축 1·2) 과 네트워킹 구현(축 3) 에 대해서는 평가할 대상이 없다. 따라서 이 섹션은 문서의 설계 논리 자체가 향후 코드 품질에 끼칠 영향 을 중심으로 평한다.
BattleMap 문서의 알고리즘 설계는 이 시점의 학생 프로젝트로서는 이례적으로 탄탄하다. Phase 1.5 에서 max_possible 을 계산해 조기 재시도를 결정하는 최적화, 20 회 재시도 후 역순 탐색 fallback, Phase 2.5 루프 클로징을 후처리로 분리해 트리 구조 불변성을 지키는 구성은 “맵 생성이 왜 실패하는가” 를 선제적으로 고민한 흔적이다. 용어 정의표(cp_dist_min vs deadend_dist 구분 명시) 도 구현 단계에서 자주 발생하는 혼동을 막는 장치로 잘 작동할 것이다. 칭찬할 만한 사전 설계다.
반면 우려는 수치의 근거 공백 이다. max_retries=20, 전체 재시도=30, loop_prob=0.4, max_loops=2, BO 쿨다운 2 스테이지 등 핵심 파라미터가 “왜 이 값인지” 에 대한 근거 없이 단정적으로 제시된다. 구현자가 튜닝할 때 무엇을 기준으로 조정해야 할지 알 수 없게 된다. 최소한 “기대 맵 크기 대비 재시도 비용 상한” 같은 한 줄의 근거가 각 상수 옆에 있어야 향후 밸런싱 토의가 가능하다. 또한 Stage Nod 문서의 확률 노드 “가중치 확률(AT > FR > BO > RF)” 은 순서만 있고 수치가 없어, 이 상태 그대로 코드화하면 개발자의 자의적 판단이 개입한다 — 구현 전에 %가 확정되어야 한다.
멀티플레이 설계는 권한 모델의 관점에서 경고 신호 가 보인다. “노드 진입은 호스트 전용 — 참가자는 노드에 진입할 수 없으며 호스트만 노드를 플레이한다” 는 서술은, Co-op 게임이라고 하면서 실제로는 호스트만 플레이하고 게스트는 관전한다는 의미로 읽힌다. README 3-3 의 “호스트 주도하에 게임은 진행” 과 맞물리면 이는 설계 공백이거나 Co-op 의 의미 축소 중 하나인데, 어느 쪽인지가 문서에서 드러나지 않는다. 네트워킹을 구현하기 전에 “게스트는 어떤 입력·행동을 서버에 보낼 수 있는가” 가 표로 정리돼야 한다. 또한 스택(Mirror / Netcode for GameObjects / Photon 중 무엇) 에 대한 결정이 전혀 없어, 권한 모델을 코드화하는 순간 번복 비용이 크다.
3. 진행도 평가
첫 리포트 기준 12% 로 평가한다. Unity 프로젝트 스캐폴드조차 repo 에 부재하고, 실제 산출물은 기획/시각화 문서 4 종에 국한된다. 2D 디스토피아 로그라이트 Co-op 이라는 스코프(랜덤 맵 생성 2 종, 멀티플레이, 분기 엔딩, 6 스테이지 + 히든) 는 15 기 교육 과정 프로젝트로는 공격적인 편이며, 특히 “멀티플레이 + 매판 랜덤 생성 + 엔딩 분기” 의 결합은 개별 난이도보다 상호작용 디버깅 비용 이 크다. 지금 문서 단계에서 권한 모델과 시드 동기화가 명시된 것은 긍정적이나, 마일스톤(M2~M5) 일정이 전부 — 로 비어있어 남은 기간 대비 스코프 타당성을 판단할 근거가 없다. 다음 리포트까지의 최우선은 ① 스코프 확정 + 일정 과 ② Unity 프로젝트 커밋(빌드 가능한 빈 씬이라도) 이다. 커밋 메시지 형식은 type/scope 를 흉내낸 브랜치 스타일이나 오타(Visuzlizer) 와 & 혼합으로 일관성이 낮다 — Conventional Commits 같은 간단한 규약을 조기에 도입할 것을 권한다.
4. 다음 권장사항
- Unity 프로젝트 스캐폴드 커밋 — 지금 상태로는 리뷰어/협업자가 실행할 대상이 없다. 빈 씬 + .gitignore + Assembly Definition 수준이라도 확보해야 다음 리뷰가 코드 축에 접근 가능해진다.
- 멀티플레이 권한 모델 문서화 — “노드 진입 = 호스트 전용” 의 의미를 게스트가 할 수 있는 행동 표로 환원하고, Mirror/NGO/Photon 중 스택을 결정해 근거와 함께 기록. 코드 전에 결정해야 번복 비용이 적다.
- 확률·상수 수치 확정 — Stage Nod 의 AT/FR/BO/RF 가중치 %, BattleMap 의 재시도 상수·루프 파라미터에 구체 수치와 한 줄 근거 부여. 튜닝 가능한 테이블로 만들면 이후 밸런싱 회의의 입력이 된다.
- spec 문서 신설 — 레시피(아이템)·적·노드 타입별 수치 테이블을
specs/에 별도 파일로 분리. README 하나에 모든 걸 담으면 문서가 금세 거대화된다. - 마일스톤 일정 확정 + 커밋 컨벤션 정리 — M2~M5 의 예상일과 산출물을 채우고, 브랜치/커밋 메시지 포맷(오타
Visuzlizer같은 사례 방지) 을 README 또는 CONTRIBUTING 에 1 쪽으로 고정.
5. 문서화 상태
design: 6/10. README 가 GDD 의 스켈레톤으로는 쓸만한 수준이다. 코어 루프 4 페이즈, 시스템 목록, 레퍼런스(Binding of Isaac / Enter the Gungeon / Arknights) 와 각 참조 내용, 리스크 표까지 갖춘 구성은 _sample/docs 의 컨셉 문서와 유사한 골격을 따라간다. 다만 1-5 아트/UI 섹션은 [예: Hi-Bit 픽셀 아트 …] 같은 placeholder 가 그대로이며, 1-4 “핵심 인물” 표의 비고 칸과 “핵심 사용자 경험” 한 줄이 컨셉의 차별점을 충분히 설명하지 못한다. “왜 이 선택인가” 측면에서 로그라이트 반복성의 해결책으로 “사서와의 계약”·“멀티엔딩” 을 든 것은 좋으나, 구체적으로 어떤 플레이어 감정을 어떤 주기로 유발하려는지는 비어있다.
technical: 5/10. BattleMap Visualizer 는 알고리즘 문서로는 거의 spec 에 가까운 밀도이며, Multiplay Visualizer 는 아키텍처 레벨의 개략도를 제공한다. 그러나 “기술 문서” 관점에서 핵심이 누락돼 있다: (1) 씬 구조 / 주요 MonoBehaviour 계층 / 매니저 구성, (2) 네트워크 스택 선정과 권한 모델, (3) 저장·세이브 포맷, (4) 빌드·배포 절차. 신규 합류자가 이 문서만으로 코드 구조를 머리에 그리기 어렵다. docs/technical.md 를 별도 문서로 독립시키고, BattleMap/Multiplay Visualizer 는 거기서 참조되는 하위 문서로 위치시키는 편이 확장성이 좋다.
spec: 2/10. 엄밀한 의미의 사양서는 부재하다. _sample/docs 의 레시피·레벨 사양서처럼 “필드 스키마 + 테이블 + QA 체크리스트” 를 갖춘 문서가 없다. BattleMap Visualizer 가 부분적으로 spec 역할을 하나 이는 맵 생성 알고리즘에 한정되며, 레시피(아이템/유물)·적·노드 이벤트 타입별 테이블은 언급조차 없다. specs/ 디렉토리를 신설하고 최소한 “노드 타입 사양서”, “유물 사양서” 두 건을 착수하는 것이 시급하다.
6. Backlog
- Unity 프로젝트 자체가 repo 에 부재 — 문서만 있고 실행 가능한 빌드 경로 없음.
- 사서·기록자·최종 보스 등 핵심 인물의 특성·밸런싱 수치 미기재 — 현재는 역할 설명 수준.
- Multiplay 스택(Mirror / NGO / Photon) 결정 및 근거 문서화 누락 — 권한 모델 코드화 전 필수.
- 확률 노드 가중치·BO 쿨다운 2 스테이지 등 상수의 근거 수치 부재 — 튜닝 기준 불명확.
- 아트/UI 컨셉 테이블에 placeholder(
[예: Hi-Bit ...]) 잔존 — 컨셉 확정 전 단계 노출. - 마일스톤(M2~M5) 예상 일정 미정 — scope 관리 기준 없음.
- README 작성자 표기
차영록과차용록혼용 — 승인자/작성자 중 한쪽이 오타로 의심.