NINI
17 KiB
자석 영웅과 자연 배경 제작 계획
진행 방식
영웅과 자연 소품의 원본을 각각 완성한 뒤, 사용자에게 구 몸체·기사 장비와 세 풍경을 검토받는다. 명시적인 승인 후 한 담당자가 실제 게임에 연결한다. 연결된 장면에서 조작과 외형을 함께 확인하고 필요한 수정 후 최종 Android 앱을 검증한다. 모델링용 원본과 런타임 자산, 검수 자료를 구분하여 보존한다.
새 프로젝트 초기화나 패키지 업그레이드는 필요 없다. 시작 전에 대상 모듈의 AGENTS.md와 docs/standards.md, docs/engineering-notes.md, docs/architecture.md, docs/operations.md를 읽고 기존 소스·GUID·자산 해시와 검증 증거를 확인한다. 초기 전체 builder는 실행하지 않는다.
T1 — Blender 영웅 원본과 게임용 모델
목표와 계약: R01·R02·R03·R06·R07에 따라 구 몸체 자체의 메시·재질과 투구·짧은 칼·방패를 제작한다. 편집 가능한 실제 .blend와 Unity용 FBX, 필요한 텍스처를 제공한다. 구 하나의 크기와 중심을 유지하고 장비는 별도 수량이나 입력 대상이 없는 묶음별 부착물로 만든다. 현재 얼굴 여섯 표정·마스크·리본 망토와 공존할 공간을 확보한다.
작업 대상: SourceAssets/Models/Heroes/, tools/models/의 영웅 전용 제작·내보내기 도구, Assets/MagnetismHeroes/UnityRuntime/Presentation/Models/의 영웅용 파일과 필요한 Textures/ 파일. 해당 원본 영역에 별도 provenance를 두어 기존 SourceAssets/Models/provenance.json과 과거 자산 이력을 덮지 않는다.
제작 판단의 근거: 구 배열이 영웅의 몸이라는 기존 학습 표현을 유지하면서 기사 장비로 정체성을 강화한다. 모든 구를 개별 무장 캐릭터로 바꾸거나 팔·다리와 보행 애니메이션을 새로 만드는 방식은 채택된 모습과 다르다. 반사와 장식의 디테일은 작은 화면에서 먼저 읽히는 큰 형태를 위해 조정한다.
검증: Blender에서 원본을 실제로 열어 메시·재질·피벗·장비 구성을 확인하고 정면·옆면·뒷면 렌더와 내보내기 해시를 남긴다. FBX 내보내기 성공과 실제 존재·크기·메시 정보를 확인한다. T3의 사용자 검토에 제출하고 최종 Unity 적용 검수는 T4·T5에서 수행하며 원본 렌더만으로 게임 품질 합격을 주장하지 않는다.
공유 파일 처리: 프리팹·씬·StageAsset·공통 재질·자산 등록 문서는 수정하지 않는다. 영웅 원본·내보내기 범위만 소유한다. Blender 파일을 저장하고 내보내는 실행은 실행 담당자가 관리한다.
T2 — Blender 자연 세계 원본과 게임용 소품
목표와 계약: R01·R04·R05·R06·R07에 따라 초원·꽃 언덕·바위 언덕에 필요한 지면·언덕·원경, 나무·수풀·풀·꽃·바위·자갈을 제작한다. 가까운 구조물의 가림·빈틈과 기존 구 초기 위치를 고려하여 기존 아치·단차의 자연 풍경용 대체 외형도 제공한다. 소품 변형과 배치 밀도는 실제 비용과 반복감을 보며 조정한다.
작업 대상: SourceAssets/Models/Meadow/, tools/models/의 자연 세계 전용 제작·내보내기 도구, Assets/MagnetismHeroes/UnityRuntime/Presentation/Models/의 자연 세계용 파일과 필요한 Textures/ 파일, 별도 원본 provenance. 기존 PlaygroundProps.blend와 13개 FBX 원본 이력을 보존한다.
제작 판단의 근거: 요청한 밝은 언덕·평야를 전체 게임의 새 배경으로 만든다. 세 풍경은 서로 다른 세계가 아니라 식생·지형의 비중이 다른 같은 카툰 세계다. 수량을 헷갈리는 구형 캐릭터 소품이나 새 놀이 장치를 추가하지 않는다.
검증: 원본 파일의 편집 가능성과 메시·UV·노멀·다중 재질, 실제 바닥 피벗·축·내보내기 파일을 확인한다. 소품 목록 렌더와 세 풍경 구성 미리보기를 남긴다. 구멍을 가진 구조물의 메시가 실제 빈틈을 유지하는지 확인한다. T3의 사용자 검토에 제출하고 실제 구 발견·가림·입력은 T5에서 확인한다.
공유 파일 처리: T1과 다른 원본·텍스처·내보내기 파일명을 사용한다. 영웅 파일·프리팹·씬·StageAsset·공통 재질·자산 등록 문서는 수정하지 않는다. 원본 저장·내보내기 실행의 소유자는 한 명으로 유지한다.
T3 — 완성 모델 제시와 사용자 검토·승인
목표와 계약: R10에 따라 T1·T2의 모델링 결과가 모두 준비되면 구 몸체·기사 장비·초원·꽃 언덕·바위 언덕을 사용자에게 제시하고 명시적인 승인을 받는다. 이 단계는 자료 생성만으로 끝나지 않으며 사용자 승인까지 완료되어야 T4를 시작할 수 있다.
작업 대상: artifacts/verification/VisualUpgrade/ModelReview/의 실제 Blender 렌더·검토 목록·파일 해시·승인 기록과 사용자 검토 대화. 구 몸체 단독 모습과 장비를 갖춘 영웅의 정면·옆면·뒷면, 세 풍경의 전체 장면과 주요 소품 상세 모습, 편집 가능한 원본 링크를 한 묶음으로 제공한다. 승인 기록은 검토 대상 원본·게임용 파일의 경로·SHA-256, 해당 자료에 대한 사용자 답변과 확인 시각을 연결한다.
검토와 수정: 사용자에게 귀여운 기사 모습·구 몸체·장비·세 풍경의 형태·색·재질·전체 조화를 검토받는다. 수정 요청이 있으면 대상만 보정하여 변경본과 갱신된 해시를 다시 제시한다. 이전 버전의 승인을 변경본에 재사용하지 않는다. 일부 승인이나 무응답 상태에서는 이 단계를 미완료로 유지하고 모든 대상의 승인까지 게임 적용을 기다린다.
검증: 구 몸체·기사 장비와 세 풍경 모두에 대해 최신 파일과 대응하는 명시적 사용자 승인이 있어야 완료다. 에이전트의 자체 평가·자동 검사·문서 승인으로 대체하지 않는다. 승인된 파일 목록을 T4에 인계한다. Blender 모델 검토와 이후 실제 게임의 시각·조작 검증은 각각 수행한다.
공유 파일 처리: 검토 대기 중 후보 원본·내보내기·검토 자료만 관리하고 기존 Main 씬·게임 프리팹·StageAsset 참조와 런타임 채택 상태를 유지한다. 후속 APK 검증은 시작하지 않는다. 이 승인 대기는 사용자가 요청한 모델 검토 단계이며 자동 진행으로 우회하지 않는다.
T4 — Unity 장면과 30개 스테이지 적용
목표와 계약: R01R06·R08·R10에 따라 T3에서 승인된 T1·T2의 자산을 실제 게임에 적용한다. 적용할 파일의 해시가 승인 기록과 일치하는지 확인한다. 대표 구에 영웅 장비 한 벌이 붙고 모든 구의 몸체가 개선된 모델·재질로 표시된다. 세 풍경이 110·1120·2130과 해당 자유 놀이에 연결된다. 장비 표시와 배경 연결에 필요한 표현 코드만 변경한다.
작업 대상: Assets/MagnetismHeroes/Editor/의 대상 한정 import·적용 경로, UnityRuntime/Presentation/의 재질·필요 텍스처·모델 import 설정·프리팹, GroupBadge.cs, BallView.cs, BoardPresenter.cs, 필요 시 BoardEnvironment.cs, Bootstrap/GameApp.cs, StageAssets/Stage01.asset~Stage30.asset, Assets/MagnetismHeroes/Scenes/Main.unity의 관련 표현 연결. 실제 변경이 필요한 파일만 수정한다.
보존 계약: 구 루트 크기·SphereCollider 반지름 0.5·ID·초기 위치·수학 목표를 유지한다. 영웅 장식에는 Collider를 붙이지 않는다. 묶음 얼굴·숫자·장비의 대표 위치와 수명을 맞추고 취소·합체·분리·재입장을 확정 상태에서 구성한다. 내부 테마 값 Garden·Cloud·Workshop과 기존 Stage·GameApp GUID를 유지한다. 승인 얼굴 여섯 표정·44개 음성·글꼴·UI·Mixer 참조를 보존한다.
배경 계약: 먼 지형·하늘과 가까운 식생까지 새 풍경으로 연결한다. 앞 소품의 실제 가림을 보존하되 구 발견과 입력을 막지 않도록 배치·Collider를 조정한다. 배경 가림을 무시하는 Raycast 우회로를 만들지 않는다. 아치 빈틈을 유지하고 저장된 구 배열을 새 배경에 맞추려고 재배치하지 않는다.
검증: Unity 실제 import와 초기화에서 누락 참조·셰이더·재질·좌표·피벗·축·GUID·콜라이더를 확인한다. 적용 전후 StageAsset의 비시각 필드와 음성·얼굴·글꼴 파일 해시를 대조한다. Main 씬에서 단일 구와 합체 묶음, 세 풍경과 자유 놀이를 실제 표시하고 초기 캡처를 남긴다. 변환 중 입력 간섭이나 구 수량 문제가 나오면 관련 변경을 멈추고 증거를 남긴다.
공유 파일 처리: 씬·프리팹·StageAsset·공통 재질·메타데이터는 이 단계의 한 작성자가 Unity API로 생성·수정·저장한다. ProjectBootstrap.Prepare/ConnectApp, CompositionAssets.Build, PersistenceAssets.Build, ContentAssets.Build, PresentationAssets.Build를 일반 준비 절차로 실행하지 않는다. 원본과 파일 생성은 T1·T2 결과를 사용한다.
T5 — 시각 품질과 조작 회귀 검증·수정
목표와 계약: R03·R04·R05·R07·R08·R10에 따라 실제 연결된 프리팹과 장면에서 귀여운 기사와 세 풍경의 품질을 확인한다. 장식과 배경이 숫자·계수·선택·발견·분리·취소·저장 복원을 해치지 않아야 한다. 관찰한 결함은 최소 범위로 수정하고 영향을 받은 사례를 재검증한다. 승인된 형태·색·재질·풍경 구성을 눈에 띄게 바꾸는 수정은 해당 변경본을 사용자에게 다시 제시하고 승인 후 채택한다.
작업 대상: Assets/MagnetismHeroes/Tests/EditMode/ContentAssetTests.cs, PresentationAssetTests.cs, 필요 시 다른 영향받은 자산 검사, Tests/PlayMode/ContentPlayTests.cs, CompositionPlayTests.cs와 필요한 실제 프리팹 검사, Editor/PresentationProof.cs 또는 대상 한정 시각 증거 수집, tools/android/의 영향받은 배경·장비 검증, T1·T2·T4의 필요한 보정 파일, artifacts/verification/VisualUpgrade/.
검사 갱신: 기존 Decorations.Count == 7이나 옛 소품 이름·픽셀을 고정한 기대를 새 제작 목록에 맞춘다. 단순 존재 확인으로 낮추지 말고 각 풍경의 필수 자산 연결과 실제 구 발견·숫자 가독성을 계속 검사한다. 내부 테마 값이 유지되므로 이름 변경을 위한 제품 기능 수정은 하지 않는다. 기존 합체·분리·저장 검사를 없애거나 제품 판정을 완화하지 않는다.
구체 사례: 단일 구, 2+3 합체, 5의 떨어진 양 끝 두 구를 골라 2+3 분리, 10개 한 묶음과 10개 개별 구, 대표 변경, 취소·핀치·영역 이탈, 화면 이동·재입장·이어하기, 세 풍경의 0~10개 자유 놀이 공급·반납. 각 안정 묶음의 장비·얼굴·숫자가 하나인지와 모든 수집 구의 실제 Collider 선택 가능성을 확인한다.
시각 자료: 각 풍경의 대표 스테이지와 자유 놀이를 기본·회전·확대 시점, 스마트폰·태블릿 가로 비율에서 캡처한다. 검토표에는 실루엣·법선·UV·재질·관통·얼굴/숫자/계수 가독성·배경 경계·색과 빛의 조화에 대한 실제 관찰과 수정 결과를 적는다. 그림이 예쁜 것만으로 조작 가능성을 대신하지 않는다.
모바일 비용: 최대 구 상태의 메시 삼각형·텍스처 해상도/메모리·공유 재질·측정 가능한 렌더링 비용을 기록하고 과한 부분을 줄인다. 측정 도구와 환경, 측정 못한 항목을 명시한다. Editor 통계와 AVD를 실기기 성능 증거로 바꾸지 않는다.
검증: 영향받은 EditMode·PlayMode 사례가 실제로 평가되고 통과해야 한다. 색상이나 단순 재질 조정마다 구현을 복제하는 새 단위 검사를 작성하지 않는다. 시각 검토표와 원본/게임 화면 대조를 완료하고 발견한 수량·복원 결함이 없음을 확인한다. 최종 소스의 전체 네 단계와 APK는 T6에서 확정한다.
공유 파일 처리: Unity Editor·테스트 실행·캡처·ADB는 한 실행 담당자가 순서대로 관리한다. 보정으로 T1·T2·T4 파일이 바뀌면 원본·내보내기·Unity 연결·해시를 함께 갱신하고 R10의 재검토 경계를 따른다. 최종 APK 검증을 먼저 하고 제품 파일을 나중에 수정하지 않는다.
T6 — 최종 Android 검증과 채택 이력·납품
목표와 계약: R06·R07·R08·R09에 따라 완성된 제품 소스의 네 단계 검증과 새 Android 설치본·시각 증거를 연결한다. 실제 제작 결과와 사용 조건을 문서에 반영하고 원본·게임 화면·시험용 APK를 납품한다.
작업 대상: 기존 tools/verify.ps1와 관련 Android 검증 경로의 실행, artifacts/verification/Final/, artifacts/verification/VisualUpgrade/, artifacts/android/Final/MagnetismHeroes.apk, artifacts/android/MagnetismHeroes.apk, docs/asset-register.md, docs/tracking/decisions/0005-hybrid-assets.md와 필요 시 관련 결정 기록, docs/operations.md, docs/tracking/status.md, 실제 재현 문제가 남을 때 docs/tracking/findings.md, 새 자산 provenance의 최종 검수 대응.
실행: 기존 Final 증거를 별도 사본과 해시로 보존한다. 최종 제품 변경이 반영되고 tracked 변경이 없는 검증 소스에서 아래 명령을 순서대로 실행한다. 소스 준비·커밋 등 Git 처리는 실행 단계의 절차를 따른다. 현재 문서 작성 단계에서는 커밋하지 않는다.
pwsh -NoProfile -File tools/verify.ps1 -Phase EditMode -Milestone Final
pwsh -NoProfile -File tools/verify.ps1 -Phase PlayMode -Milestone Final
pwsh -NoProfile -File tools/verify.ps1 -Phase AndroidBuild -Milestone Final
pwsh -NoProfile -File tools/verify.ps1 -Phase AndroidSmoke -Milestone Final
Unity Editor와 배치 검사가 같은 프로젝트를 동시에 사용하지 않게 한다. 전용 API37 AVD의 상태와 boot 완료를 확인하고, 실제 이용자 데이터를 초기화하지 않는다. 정상 30개 순차 진행은 완료 기록 주입 없이 검증한다. 각 단계 실제 종료 코드와 XML/JSON 평가 결과, 소스·APK·설치 해시, 실행 시각, 로그와 Android 화면을 보존한다. 승인 44개 음성과 필요한 고지의 실제 APK 포함을 기존 절차로 확인한다.
검증: 네 단계 종료 0과 필수 사례 실패·건너뜀·미확정 0, 실제 APK 설치·진행·복원·오프라인 재생, 새 세 풍경의 Android 화면, 새 자산의 원본→게임 파일→검수 해시 대응을 확인한다. 새로운 제품 수정이 생기면 영향을 받은 검사와 최종 빌드를 갱신한다. 문서만 변경했을 때 제품 파일 동일성을 확인한다. 원본·캡처·검토표·APK 링크와 실기기 미검증 범위를 최종 보고한다. 실행 불가나 해결 불가를 완료로 표현하지 않는다.
공유 파일 처리: 이 단계가 공통 자산 등록·운영·상태 문서의 최종 작성자다. 이전 단계는 해당 문서 대신 자기 자산의 provenance와 검수 자료를 남긴다. 원격 push·스토어 게시·유료 구매는 실행하지 않는다.
요구사항과 작업의 대응
| 요구사항 | 구현·확인 작업 |
|---|---|
| R01 미술 방향 | T1, T2, T4, T5 |
| R02 구 몸체와 기사 | T1, T4, T5 |
| R03 합체·분리와 표현 수명 | T1, T4, T5, T6 |
| R04 세 풍경과 30개 스테이지 | T2, T4, T5, T6 |
| R05 자연 소품과 조작 | T2, T4, T5, T6 |
| R06 원본·게임 파일·출처 계약 | T1, T2, T4, T6 |
| R07 시각 품질 합격 | T1, T2, T5, T6 |
| R08 규칙·저장·음성·필수 검증 | T4, T5, T6 |
| R09 변경 경계와 완료 보고 | T6 |
| R10 완성 모델 사용자 검토·승인 | T3, T4, T5 |
Execution Graph
T1·T2는 서로 다른 원본과 내보내기 파일을 제작하므로 독립이다. 파일 준비를 병행하더라도 Blender 저장·내보내기 실행은 한 소유자가 관리한다. T3는 두 제작 결과를 사용자에게 제시하며 모든 대상의 명시적 승인 전에는 완료되지 않는다. 실행 담당자는 승인 대기를 자동 검사나 작업 완료 보고로 대체하지 않고 T4~T6을 시작하지 않는다. T4는 승인된 자산을 실제 게임에 연결하고, T5는 연결된 게임을 검증·보정하며, T6은 보정된 최종 제품 소스와 증거를 확정한다. 전체 재생성 명령은 없고 각 제작의 내보내기·import는 해당 작업 안에서 처리한다.
tasks:
- id: T1
depends: []
risk: RISKY
- id: T2
depends: []
risk: RISKY
- id: T3
depends: [T1, T2]
risk: RISKY
- id: T4
depends: [T3]
risk: RISKY
- id: T5
depends: [T4]
risk: RISKY
- id: T6
depends: [T5]
risk: RISKY
regen_barriers: []