AI 쌀먹을 포기하고 조금 노가다를 해보도록 하자

페이퍼 아트 스톱 모션 리듬 생성 게임의  핵심 코어 루프 PoC 기술 설계 보고서 (Part 2)

1. 프로젝트 개요 및 핵심 설계 목표

1.1. 게임 컨셉 및 비전 요약 (Paper Art Rhythm Generator)

본 프로젝트는 아날로그적인 페이퍼 아트 미학과 스톱 모션 애니메이션 기법을 결합한 2D 리듬 생성 게임입니다. 게임 플레이의 핵심은 화면 멀리서 다가오는 드럼 연주자의 동작 스프라이트가 화면 하단의 활성화 선(Activation Line)에 도달하는 순간에 맞춰, 플레이어가 하단의 Kick, Hihat, Snare 버튼을 탭하여 리듬을 창조하는 것입니다. 이 독창적인 접근 방식은 플레이어에게 시각적 매력과 즉각적인 청각적 만족감을 동시에 제공하는 것을 목표로 합니다.

1.2. 핵심 설계 제약 조건: BGM 비동기식, 플레이어 주도 리듬 구조

본 게임의 기술적 설계에서 가장 중요한 부분은 플레이어의 입력이 곧 시각적 및 청각적 출력의 원천이 된다는 점입니다. 이는 일반적인 리듬 게임이 배경 음악(BGM)의 타임라인에 맞춰 노트를 동기화하는 방식과 근본적으로 다릅니다. 이 게임은 플레이어의 입력 타이밍 그 자체가 리듬의 박자감을 형성하므로, 기술 설계 시 두 가지 핵심 제약 조건을 만족시켜야 합니다.

첫째, 극도의 저지연(Ultra-Low Latency)이 필수적입니다. 플레이어가 버튼을 탭하는 순간, 해당 드럼 사운드 재생과 캐릭터의 애니메이션 상태 변경이 지연 없이 즉각적으로, 가급적 단일 프레임 내에서 동시에 트리거되어야 합니다. 입력 지연이 조금이라도 발생하면 플레이어가 인식하는 '박자감'이 무너져 게임 경험이 치명적으로 저해됩니다.

둘째, 고성능 동시 오디오 재생(High Concurrent Audio Playback) 능력이 요구됩니다. 특히 하이햇(Hihat)과 같이 빠른 연타가 예상되는 드럼 요소는, 기존 사운드가 재생 중일 때 새로운 사운드 재생 요청이 들어와도 클리핑(Clipping)이나 끊김 현상 없이 여러 클립이 동시에 출력되어야 합니다. 이 성능 요건을 충족하기 위해 Audio Source Pooling 아키텍처의 채택은 선택 사항이 아닌 필수적인 설계 요소로 간주됩니다.   

1.3. 기술 스택 확정 및 아키텍처 개요

본 프로젝트는 Unity 2D 환경을 기반으로 개발되며, 핵심 메커니즘은 C# 스크립트를 통해 구현됩니다.

영역	핵심 요구 사항	채택 기술	기술적 근거
시각적 미학	페이퍼 아트 질감, 스톱 모션 느낌	URP 2D Lighting, Normal Map, Custom Animation Update Script	낮은 프레임으로 불연속성 확보, 조명 상호작용으로 2D 질감 극대화
2D 접근 효과	부드러운 원근감 시뮬레이션	Transform.localScale 및 position 제어 (EaseOutExpo), Time.deltaTime 사용	비선형 Easing을 통한 현실적인 가속도 표현
오디오 성능	고성능, 저지연, 동시 다중 재생	Audio Source Pool (Object Pooling)	단일 AudioSource의 클리핑 문제 해결 및 입력 지연 최소화
입력 동기화	극도의 저지연 즉각적 반응	Input.GetTouch(TouchPhase.Began) 처리, Script Execution Order 우선순위 설정	입력 순간 C#에서 Audio 및 Animator 동시 트리거, Animation Event 사용 배제

  

이 구조는 일반적인 리듬 게임 개발에서 요구되는 BGM 동기화 대신, 입력 이벤트가 모든 출력의 마스터 클럭이 되는 구조를 지원하도록 설계되었습니다.

2. 시각적 자산 및 스톱 모션 구현 사양

2.1. 페이퍼 아트 스타일 렌더링 최적화 및 셰이더 요구 사항

페이퍼 아트 스타일의 완성도를 높이려면, 평면적인 2D 스프라이트 사용을 넘어 종이의 물리적인 질감을 시뮬레이션해야 합니다. 이를 위해 Unity의 Universal Render Pipeline (URP)을 채택하여 2D 환경에서 효율적인 조명과 그림자 효과를 구현합니다.

핵심은 2D 노멀 맵(Normal Map) 활용입니다. Sprite 이미지와 함께 Normal Map 및 Mask Map을 제작하고 임포트하여 , 종이의 미세한 주름이나 질감에 2D 조명이 반응하도록 만듭니다. 이 조명 상호작용은 실제 스톱 모션 환경에서 볼 수 있는 물리적인 텍스처와 깊이감을 2D 화면에 부여합니다. 나아가, 고급 시각 효과를 위해 2D 셰이더를 사용하여 종이가 구겨지거나 왜곡되는(Warping and Distortion) 효과를 추가하여 미학적 요소를 극대화할 수 있습니다.   

2.2. 스프라이트 시트(Sprite Sheet) 임포트 및 분할 절차

드럼 연주자의 모든 동작(Idle, Kick, Hihat, Snare)은 프레임별 시퀀스로 제작된 Sprite Sheet를 기반으로 합니다.

1. 임포트 설정: 아트워크 파일을 프로젝트로 가져온 후, Inspector 창에서 Sprite Mode를 'Single'에서 'Multiple'로 변경합니다 .
2. Sprite Editor 분할: Sprite Editor를 열어 Sprite Sheet를 구성하는 각 애니메이션 프레임을 Grid By Cell Count 또는 Automatic 방식으로 정확하게 분할한 후 적용합니다 .
3. 애니메이션 클립 생성: 분할된 개별 Sprite들을 Project 창에서 선택하여 Scene 또는 Hierarchy 창의 GameObject에 드래그하여 놓습니다. 이 과정에서 Unity는 자동으로 GameObject에 Animator 컴포넌트를 추가하고, 선택된 스프라이트 시퀀스를 기반으로 Animation Clip을 생성하며, 해당 클립을 관리하는 Animator Controller를 할당합니다 .

2.3. 드럼 동작 애니메이션 클립 생성 및 설정 상세

드럼 연주자의 애니메이션은 총 4가지 상태로 구성되며, 이는 Animator Controller를 통해 관리됩니다. 애니메이터는 Idle 상태를 기본 상태로 설정하며, 플레이어의 입력이 있을 때 Trigger 파라미터를 사용하여 즉각적으로 해당 드럼 동작 애니메이션으로 전이됩니다. 애니메이션 재생 완료 후에는 Idle 상태로 즉시 복귀하도록 Transition 설정 시 Has Exit Time을 비활성화해야 합니다.   

애니메이션 상태 (State)	트리거 파라미터	Sprite 프레임 수	애니메이션 재생 속도 (Samples/FPS)	Stop Motion 구현 전략
Idle (대기)	- (Default)	1~4 프레임	6 FPS	낮은 프레임으로 느린 움직임 시뮬레이션
Kick (발동)	TriggerKick	4~6 프레임	12~15 FPS	플레이어 입력 시 즉시 재생 (단발)
Hihat (발동)	TriggerHihat	4~6 프레임	12~15 FPS	플레이어 입력 시 즉시 재생 (단발)
Snare (발동)	TriggerSnare	4~6 프레임	12~15 FPS	플레이어 입력 시 즉시 재생 (단발)

2.4. 스톱 모션 효과의 기술적 구현

스톱 모션의 시각적 불연속성을 확실하게 구현하기 위해, 단순히 애니메이션 클립의 샘플 속도(Samples/FPS)를 낮추는 것 외에, 시스템 레벨에서 Animator의 업데이트 방식을 제어하는 것이 필요합니다. Unity의 기본 애니메이션 시스템은 프레임 사이에 보간(Interpolation)을 적용하여 부드러운 움직임을 만드려는 경향이 있습니다. 스톱 모션은 이러한 보간을 배제하고 불연속적인 프레임 전환을 특징으로 합니다.

따라서, 에서 제시된 것처럼, 별도의 C# 스크립트를 작성하여 Animator 컴포넌트의 업데이트를 고정된 간격(예: 8FPS에 해당하는 시간 간격)으로만 강제로 실행하도록 제어할 수 있습니다. 이 기술을 적용하면, 게임의 전역 FPS가 높더라도 캐릭터 애니메이션은 의도적으로 끊기면서 페이퍼 아트 스톱 모션의 거친 질감을 시각적으로 극대화하게 됩니다.

3. 2D 원근감 시각 효과 구현 상세 (Approaching Effect)

화면 멀리서 드럼 동작 요소가 다가와 활성화 선에 도달하는 시각적 효과는 2D 환경에서 깊이감을 시뮬레이션하는 중요한 기술 요소입니다.

3.1. 오브젝트 '접근' 효과의 수학적 모델링 (Scale-Position 관계)

2D 스프라이트 오브젝트가 카메라에 다가오는 느낌을 주기 위해, 오브젝트의 Transform 컴포넌트 내 localScale(크기)과 position(위치)을 동시에 제어합니다. 이는 2D 공간 내에서 Z-축의 변화를 시뮬레이션하는 것과 같습니다.   

• 원근감 정의: 오브젝트가 멀리 있을 때 (D=1.0): 크기는 작고(Scale${Far}),화면상단에위치합니다(PosY{Far}$). 오브젝트가 가까이 있을 때 ($D=0.0$): 크기는 크고(Scale${Near}),화면하단(활성화선)에위치합니다(PosY{Near}$).
• 비선형 보간 적용: 원근감은 본질적으로 비선형적입니다. 카메라에 가까워질수록 크기와 위치의 변화율이 급격하게 증가합니다. 선형 보간을 사용할 경우 다가오는 느낌이 부자연스럽고 느리게 인지될 수 있습니다. 따라서 플레이어에게 긴장감을 유발하고 타이밍 파악을 돕기 위해, 접근 정도를 나타내는 거리 변수 D를 기반으로 스케일과 위치를 업데이트할 때 지수형(EaseOutExpo) 등의 비선형 Easing 함수를 적용하여 마지막 순간에 급격히 가속되는 듯한 시각적 속도감을 주어야 합니다.

3.2. C# 스크립트를 이용한 Transform 조작 (localScale 및 position 제어)

ApproachingObject.cs 스크립트에서는 Time.deltaTime을 사용하여 프레임 속도에 독립적인 이동 및 크기 조절을 처리합니다. 이는 기기 성능에 관계없이 일관된 노트 속도를 보장하여 UX를 안정화하는 데 필수적입니다.   

핵심 로직은 다음과 같습니다:

1. 시간 흐름 제어: currentDistanceFactor 변수(1.0에서 0.0으로 감소)를 approachSpeed * Time.deltaTime만큼 매 프레임 업데이트하여 오브젝트의 전진을 시뮬레이션합니다.
2. Easing 적용: 계산된 currentDistanceFactor에 Easing 함수를 적용하여 비선형적인 이동 곡선을 얻습니다.
3. 변환 업데이트: Vector3.Lerp 함수를 사용하여 정의된 Far 상태와 Near 상태 사이를 Easing 함수 결과에 따라 보간하여 transform.localScale과 transform.position을 설정합니다.   

3.3. 충돌/트리거 영역(Activation Line) 판정 로직 설계

활성화 선(Activation Line)은 화면 하단, 입력 버튼 바로 위에 위치하는 영역입니다. 이 게임은 박자 기반의 노트 매칭이 아니므로, 다가오는 오브젝트가 이 선에 도달하는 시점(D≈0.0)에 "현재 플레이어가 해당 버튼을 누르는가?"가 판정의 핵심이 됩니다.

판정 로직은 다음과 같이 단순화될 수 있습니다: Input 이벤트 발생 시 (예: Kick 버튼 탭), 시스템은 현재 활성화 선 영역(D<Tolerance)에 존재하는 드럼 오브젝트 중 Kick 타입의 오브젝트가 있는지 확인합니다. 만약 존재한다면, 플레이어는 성공적으로 리듬을 생성하고 해당 오브젝트는 즉시 제거됩니다. 오브젝트가 활성화 선을 지나쳐 D 값이 0 이하로 떨어지면, 이는 판정 실패로 간주되고 오브젝트는 화면에서 제거됩니다.

4. 고성능 사운드 아키텍처: Audio Source Pooling

플레이어의 입력이 곧 드럼 사운드의 원천이 되므로, 끊김 없는 동시 재생 능력이 매우 중요합니다. 특히 하이햇과 같은 악기는 짧은 시간 내에 여러 번 탭될 수 있습니다. Unity의 기본 AudioSource.Play() 기능은 단일 소스에 한 번에 하나의 클립만 재생할 수 있기 때문에, 빠른 연타 시 이전 사운드가 중단되는 클리핑 현상이 발생합니다 .

4.1. Audio Source Pool 패턴의 설계 및 C# 구현 로직 (Object Pooling 기반)

이 문제를 해결하기 위해, 미리 여러 개의 AudioSource 컴포넌트를 준비해두고 요청이 들어올 때마다 사용 가능한 소스를 찾아 할당하는 Audio Source Pool (Object Pooling) 패턴을 채택해야 합니다. 이 패턴은 런타임에 AudioSource를 생성하거나 검색하는 오버헤드를 제거하여 입력 지연(Latency)을 획기적으로 줄이는 데 기여합니다 .

AudioPoolManager.cs 설계 개요

1. Pool 정의: Kick, Hihat, Snare 각 드럼 유형별로 충분한 수(예: 킥 5개, 하이햇 8개, 스네어 6개)의 AudioSource 컴포넌트를 가진 GameObject 프리팹을 게임 시작 시 미리 인스턴스화(Instantiate)하여 풀에 저장합니다. 모든 AudioSource는 2D 공간화(Spatial Blend = 0)로 설정되어야 하며 , 해당하는 AudioClip이 할당되어 있어야 합니다.
2. PlaySound(DrumType type) 메서드: 이 메서드는 요청된 DrumType에 해당하는 풀을 순회하며 AudioSource.isPlaying == false인 (즉, 현재 재생 중이 아닌) 사용 가능한 소스를 즉시 찾아 할당하고 AudioSource.Play()를 호출합니다.

4.2. 사운드 미세 변화(Randomization) 적용

생성된 리듬에 생동감과 입체감을 더하기 위해, AudioPoolManager는 사운드를 재생할 때마다 미세한 볼륨 및 피치 변화(Randomization)를 적용해야 합니다. 예를 들어, AudioSource.pitch를 0.95에서 1.05 사이의 무작위 값으로 설정하고, AudioSource.volume 역시 소폭 조정하여 기계적이고 반복적인 느낌을 제거합니다.

4.3. 입력 지연 최소화 및 동기화 우위 확보

Audio Source Pool 아키텍처는 초기 로딩 시 모든 소스를 준비해두기 때문에, 입력 시점에는 단순히 포인터를 바꿔 Play()만 호출하면 됩니다. 이는 Input Latency를 극도로 낮추는 기술적 의무를 완수하는 핵심입니다. 청각적 지연은 시각적 지연보다 사용자에게 더 민감하게 느껴지므로, 입력 처리 스크립트(InputHandler) 내에서 애니메이터 트리거 호출보다 사운드 재생 호출을 먼저 수행하도록 코드를 구성하여 청각적 피드백이 미세하게라도 우위를 갖도록 보장하는 것이 중요합니다.

5. 입력 처리 및 시스템 동기화 로직

5.1. 모바일 터치 입력(Input.GetTouch) 처리 및 영역 매핑

모바일 환경 최적화를 위해 Unity의 Input.GetTouch API를 사용하며, 드럼 입력은 멀티터치를 허용해야 합니다.

1. 터치 감지 및 순회: Update() 함수 내에서 Input.touchCount를 확인하고, 발생한 모든 터치 이벤트를 for 루프를 사용하여 순회합니다.
2. 터치 페이즈 확인: 각 터치에 대해 TouchPhase.Began을 사용하여 손가락이 화면에 막 닿은 순간만 감지하고 처리합니다 . 이 조건문은 길게 누르거나 드래그하는 동작에 의한 오발을 방지합니다.
3. 영역 매핑: Touch.position 데이터와 화면 하단에 정의된 Kick, Hihat, Snare 버튼 영역(UI RectTransform 또는 2D Collider)을 비교하여, 터치가 어떤 드럼 입력 영역에서 발생했는지 판별하고 해당 HandleDrumInput 함수를 호출합니다.

5.2. 입력 -> 애니메이터 -> 사운드 동시 트리거 C# 로직 상세

입력이 감지되면, InputHandler.cs 스크립트는 지연 없이 Animator의 상태와 AudioPoolManager를 동시에 업데이트합니다.

C#

// InputHandler.cs (핵심 동기화 로직)
public void HandleDrumInput(DrumType type)
{
    // 1. Audio Source Pool을 통한 사운드 즉시 재생 (청각적 우위)
    AudioPoolManager.Instance.PlaySound(type); 

    // 2. Animator 트리거 즉시 실행 (시각적 피드백)
    switch (type)
    {
        case DrumType.Kick:
            animator.SetTrigger("TriggerKick");
            break;
        //... (Hihat, Snare 처리)
    }

    // 3. 시각적/촉각적 피드백 즉시 실행
    FeedbackManager.Instance.ApplyFeedback(type); 
}

이 방식은 애니메이션 이벤트(Animation Event)를 통해 사운드를 동기화하는 일반적인 방법을 채택하지 않습니다 . 애니메이션 이벤트는 애니메이션 프레임에 종속되므로 필연적인 지연이 발생할 수 있으나, 이 게임은 입력 시점의 즉각적인 동기화가 가장 중요하기 때문에 C# 스크립트에서 두 시스템을 직접 호출하여 제어하는 방법을 사용합니다.

5.3. 입력 지연 최소화 전략 (Script Execution Order)

입력 처리 및 핵심 동기화 로직의 실행 속도를 보장하기 위해, Unity 엔진의 Script Execution Order 설정을 조정해야 합니다. InputHandler 및 AudioPoolManager와 같은 핵심 로직을 담당하는 스크립트를 기본 실행 순서(Default Time)보다 일찍(Prioritized) 실행되도록 설정합니다. 이는 다른 무거운 프레임 업데이트 로직이 입력 처리를 지연시키는 것을 방지하여 입력 반응 속도를 극대화하는 데 결정적인 역할을 합니다.

6. 사용자 경험(UX) 및 피드백 시스템 설계

6.1. 하단 버튼 영역 UX 디자인 원칙

모바일 세로 모드(Portrait Mode) 게임의 특성을 고려하여, Kick, Hihat, Snare의 세 버튼은 사용자의 엄지 손가락 접근성이 가장 좋은 화면 하단 영역(Thumb Zone)에 배치되어야 합니다 .

• 인체공학적 배치: 일반적으로 연타 빈도가 높은 Hihat은 중앙에, 가장 힘 있는 Kick과 Snare는 그 양 옆에 위치시키는 등, 연주 빈도와 리듬적 무게를 고려하여 버튼 간격을 설정하고 터치 영역(Hitbox)을 최적화합니다.
• 시각적 강조: 버튼 영역은 평소에는 배경과 통합되어 최소한의 정보만 표시하고, 다가오는 노트가 활성화 선에 근접했을 때만 해당 버튼 영역을 시각적으로 강조하여 플레이어가 탭할 준비를 하도록 유도합니다.

6.2. 플레이어 입력 성공/실패 시각적 피드백 구현

성공적인 입력은 즉각적이고 차별화된 시각/촉각 피드백으로 보상되어야 합니다.

6.2.1. 스프라이트 플래시 (색상 차등 적용)

각 드럼 입력 타입별로 시각적으로 차별화된 플래시 효과를 연주자 스프라이트에 적용합니다.

• 구현 로직: 입력 성공 시, 드럼 연주자 스프라이트의 SpriteRenderer 컴포넌트에 접근하여 color 속성을 특정 드럼에 해당하는 색상(예: Kick = Deep Red)으로 순간적으로 변경합니다 . 이후 코루틴(Coroutine)을 사용하여 매우 짧은 시간(0.05초∼0.1초) 동안 원래 색상으로 부드럽게 보간(Lerp)하여 되돌립니다.

6.2.2. 카메라 쉐이크(Camera Shake) 시스템 설계 및 입력별 강도 차등 적용

물리적 타격감(Kinesthetic Feedback)을 시뮬레이션하기 위해 Camera Shake 시스템을 구현합니다.   

• 물리적 공명(Kinesthetic Resonance): 드럼 사운드가 갖는 리듬적 '무게'는 카메라 쉐이크의 물리적 속성(진폭, 지속 시간)에 매핑되어야 합니다. Kick 드럼은 저주파수/고에너지 타악기이므로 가장 높은 진폭(Amplitude)과 긴 지속 시간으로 설정하여 묵직함을 부여합니다. Hihat은 고주파수/저에너지 타악기이므로 진폭이 매우 작고 지속 시간이 짧게 설정되어야 합니다.

FeedbackManager.cs는 입력 유형에 따라 미리 정의된 Amplitude 및 Duration 값을 CameraShakeManager.Shake() 함수로 전달하여 이 차별화된 촉각적 공명을 생성합니다.   

Table 2: 드럼 입력-출력 시스템 매핑 (피드백)

입력 버튼/영역	Audio Source Pool 클립	플래시 색상	Camera Shake 강도 (Amplitude)	Camera Shake 지속 시간
Kick (베이스 드럼)	Drum_Kick_01	Red (Deep)	0.8 (High)	0.2초 (느리고 묵직함)
Hihat (하이햇)	Drum_Hihat_01	Yellow (Bright)	0.2 (Low)	0.05초 (빠르고 가벼움)
Snare (스네어 드럼)	Drum_Snare_01	White (Neutral)	0.5 (Medium)	0.1초 (중간 타격감)

6.3. 실패 상태(Fail State) 처리

플레이어의 입력이 활성화 선에 도달하지 않은 노트에 대해 발생하거나, 노트가 활성화 선을 지나친 경우, 이는 실패로 처리됩니다. 중요한 것은 리듬 생성이라는 게임의 핵심을 해치지 않는 방식으로 실패를 처리하는 것입니다. 입력 실패 시 사운드 재생은 완전히 억제되어 플레이어가 생성하려던 리듬이 깨지지 않도록 해야 합니다. 대신, 플레이어가 실수를 인지하도록 돕기 위해 미세한 부정적 시각 피드백(예: 화면 외곽의 회색 플래시 또는 캐릭터의 미세한 움찔거림)만 제공되어야 합니다.

7. 상세 기술 사양 및 구현 결론

7.1. 결론 및 구현 권장 사항

본 게임 컨셉인 'BGM 비동기식, 플레이어 주도 리듬 생성 게임'은 기술적으로 극도의 저지연 입력 처리와 고성능 오디오 관리를 필수적으로 요구합니다. 따라서 일반적인 Unity 2D 게임 개발 방식을 넘어서는 특화된 아키텍처가 필요합니다.

핵심적인 기술적 권장 사항은 다음과 같습니다:

1. Audio Source Pool의 선행 개발: 가장 높은 우선순위로 AudioPoolManager를 구현하여, 플레이 테스트 초기부터 클리핑 없는 동시 오디오 재생 환경을 확보해야 합니다 . 이는 게임의 근본적인 박자감과 만족도를 결정하는 핵심 요소입니다.
2. 비선형 접근 시각화 (Easing): 2D 원근감 시뮬레이션 시 선형 보간 대신 지수형(EaseOut) Easing 함수를 사용하여 노트 접근 속도를 제어해야 합니다. 이는 노트가 가까워질수록 가속되는 시각적 효과를 통해 플레이어에게 정확한 타이밍을 위한 긴장감을 제공하고, 2차원 화면에서의 인지적 문제를 해결하는 데 중요합니다.
3. 애니메이션의 불연속성 강제: 단순한 프레임 속도 설정이 아니라, Animator 컴포넌트의 업데이트 주기를 스크립트로 강제 제어하여 의도적인 스톱 모션 느낌을 확실히 확보해야 합니다 .
4. 스크립트 실행 순서 최적화: InputHandler와 AudioPoolManager 스크립트의 실행 우선순위를 높여, 모든 입력 관련 처리가 시스템 내에서 가장 먼저 이루어지도록 설정해야 합니다.

이러한 아키텍처적 선택은 본 게임이 리듬 매칭이 아닌 리듬 생성이라는 목표를 기술적으로 완벽하게 뒷받침할 것입니다.

7.2. 구현 로드맵 요약

제안된 기술 사양을 기반으로 한 고수준 구현 로드맵은 다음과 같습니다.

1. Phase 1: 기반 구축 및 아트 통합 (2주): URP 2D 프로젝트 설정, Sprite Sheet 임포트 및 분할 , Normal Map 기반 2D Lighting 테스트. 드럼 연주자 4가지 동작의 스톱 모션 애니메이션 클립 및 Animator Controller 설정.   
2. Phase 2: 핵심 메커니즘 개발 (3주): AudioPoolManager.cs 및 드럼 사운드 통합. ApproachingObject.cs 구현 및 비선형 이동 로직 조정. InputHandler.cs 구현 및 모바일 터치 영역 매핑 .
3. Phase 3: 피드백 및 최종 품질 관리 (2주): FeedbackManager.cs (플래시, 카메라 쉐이크) 구현 및 드럼 타입별 강도 차등 적용. 입력 지연(Latency) 측정 및 Script Execution Order 최적화. 모바일 환경에서의 성능 및 리듬 밸런싱 테스트.   

결과물에 대한 개인적인 감상

일단 결정 사항은 인간이 여러가지 측면을 고려해서 내려야 한다.
결정되지 않은 사항에 대해서 AI를 아이데이션에 활용하기보단 제약 사항을 체크하는데 사용하고,
AI가 너무 앞서가는 부분이 있다면 무시해야 한다.
AI가 작성하는 모든 내용을 다 넣는다고 제대로된 게임이 되는 것은 아니다.
언제나 우선순위와 무얼 만들 것인지 인간이 지속적으로 방향을 설정해야 한다.

현재까지 정리된 내용

1. 테마 - 밴드나 댄서 연습생
2. 메커니즘 - 비동기식 리듬게임
   -> BGM에 맞춰서 노트가 내려오는 것이 아니라 그림을 보고 어떤 동작인지 체크해서 버튼을 누르면 해당 구절 음악이 나옴
   -> 박자는 본인이 만들어가는 것. 즉 악기 연주에 더 가까운 방식.
   -> 이게 기존 리듬게임과 다르기 때문에 PoC로 검증해야 되는 부분
3. 비주얼 스타일 - 손그림 + 스톱 모션 + 페이퍼 애니메이션
4. 사운드 - 리얼 톤, 현대적 사운드
5. 조작계 - 원버튼 or 3버튼 (교차 지점은 3개 모두 눌림으로 체크)
   -> 나중에 UI/UX에서 개선해야하는 부분