Rougelike-EndWalker — 배틀맵 로직 도입 스냅샷
1. 주요 변경사항
- 기존
UI/*,Player/*중심 폴더를App/Core/Model/Presenter/View구조로 재배치했다. 방향 자체는 명확해졌고 어셈블리도 단순화됐다. CreateAttritoStageMap,BattleMapPresenter,BattleMapView가 추가되어 전투 맵 생성과 표시의 1차 흐름이 생겼다.attrito_config.json으로 스테이지별 레이아웃 크기, CP 거리, 최소 방 수를 데이터화했다.NodeSelect에서Game씬을 additive로 로드하는 흐름과NodeSelectSession임시 상태 전달이 추가됐다.- 사각형 방과 road 프리팹이 추가되어 시각화 기반은 마련됐으나 아직 프로토타입 에셋 성격이 강하다.
2. 코드 품질 리뷰
가장 큰 위험은 CreateAttritoStageMap.Generate()의 무한 재시도 구조다. 맵 생성 조건이 서로 충돌하거나 특정 seed 흐름에서 최소 방 수를 계속 만족하지 못하면 런타임이 멈춘다. 이는 단순 품질 문제가 아니라 플레이 중 진행 불가로 이어지는 핵심 버그다. 최대 시도 횟수, 실패 결과 타입, fallback stage config를 반드시 둬야 한다.
while (true)
{
InitGrid();
if (!TryBuildCriticalPath(ref rng)) continue;구조적으로는 Presenter-Model-View 분리가 시작된 점은 좋다. 특히 맵 생성 로직을 Model.Battle로 빼고 View는 그리기에 집중시키려는 방향은 칭찬할 만하다. 다만 BattleMapView 내부 DrawBattleMap은 프리팹 딕셔너리 구성, 클리어, 배치, 연결선 계산을 모두 갖고 있어 테스트가 어렵다. 좌표 변환과 연결선 계산은 순수 계산 클래스로 분리하면 검증 비용이 크게 줄어든다.
에러 처리도 아직 약하다. AttritoInfo.Load()는 Resources.Load 실패, JSON 필드명 불일치, 빈 stages를 모두 정상 경로처럼 취급한다. NodeMapContainer도 GetComponent<RectTransform>(), GetComponent<INodeButton>()가 없을 때 즉시 NullReference가 난다. 프로토타입 단계라 해도 팀 개발에서는 이런 실패를 로그 한 줄로 원인 추적 가능하게 만드는 습관이 필요하다.
3. 진행도 평가
이번 변경은 “배틀맵 로직을 실제 씬에 연결하기 시작했다”는 점에서 분명한 전진이다. 이전보다 폴더 구조도 정리됐고, 단순 UI 노드 선택에서 전투 씬 진입까지 범위가 넓어졌다. 다만 아직 완성된 게임 루프라기보다 생성기와 시각화의 1차 연결 상태다.
진행도는 약 38%로 본다. 핵심 루프 일부는 보이지만 전투 종료, 씬 복귀, 데이터 검증, 자동 테스트, 밸런싱 근거가 부족하다. 특히 커밋 메시지는 기능 단위가 보이긴 하나 FIx)LoadScene-to-Async처럼 표기 일관성이 떨어져 추적성이 낮다.
4. 다음 권장사항
CreateAttritoStageMap.Generate()에 최대 재시도 횟수와 실패 반환을 추가한다. 실패를 숨기지 말고 호출부에서 stage config 문제로 드러나게 해야 한다.AttritoInfo.Load()와BattleSceneController에 Resources/JSON/스테이지 누락 방어 코드를 넣는다.- additive로 로드한
Game씬의 종료, 언로드,NodeSelectUI/카메라 복귀 흐름을 완성한다. - 맵 생성 테스트를 작성한다. seed 100개 이상으로 방 수, 연결성, 데드엔드 격리 조건을 검증하는 수준이면 충분하다.
- 프리팹과 필수 컴포넌트 누락 시
Debug.LogError와 안전한 중단 경로를 만든다.
5. 문서화 상태
design은 4점이다. 게임 방향과 일부 시스템 명칭은 드러나지만, 이번에 추가된 Attrito 배틀맵이 플레이 경험에서 어떤 역할을 하는지 문서 근거가 부족하다.
technical은 3점이다. 폴더 구조 개편과 MVP식 분리는 코드에서 보이나, 신규 유입자가 App/Core/Model/Presenter/View 의존 방향과 씬 전환 흐름을 문서만 보고 이해하기 어렵다.
spec은 3점이다. attrito_config.json에 수치는 생겼지만 왜 layout_size 7~15, min_rooms 8~20인지 검증 기준이 없다. _sample/docs 수준처럼 스키마, 제약 조건, QA 체크리스트가 필요하다.
6. Backlog
- 테스트 코드·플레이모드 검증 절차 부재는 여전히 남아 있다. 이번 변경은 생성기 성격이 강해 자동 검증 필요성이 오히려 커졌다.
- 확률 노드 가중치·BO 쿨다운 2 스테이지의 근거 수치는 이번 커밋에서도 확인되지 않는다.
- 사서·기록자·최종 보스 등 핵심 인물 특성·밸런싱 수치도 문서 갱신 근거가 없다.
- README의 아트/UI placeholder와 작성자 표기 혼용은 이번 변경 범위에서 해결되지 않았다.