🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 09:30 : 데일리 스크럼(AM) — 진행 상황 공유, 오늘 목표 확정
• 09:30 ~ 10:30 : Fog of War(FOW) 구현 방식 리서치·비교(타일/CPU 마스크/RT 누적 등)
• 10:30 ~ 12:30 : URP 2D 세팅 점검, 레이어·소팅 정리(FOWProbe/FOW), 전용 카메라/RT 설계

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심

✅ 오후

• 14:00 ~ 15:00 : FOW 프로토타입 구성(ExplorationCam + RT_Frame/VisitedA/VisitedB)
• 15:00 ~ 16:30 : 오버레이 셰이더·머티리얼 연결, 런타임 바인딩 구현
• 16:30 ~ 17:30 : 디버깅(라이트 블렌드/레이어/컬링 마스크 이슈 추적)
• 17:30 ~ 18:00 : 정리(문제 목록화·대응 전략 메모)

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁

✅ 저녁

• 19:00 ~ 20:00 : 프로토타입 재확인 및 로그 점검(미리보기 UI로 RT 상태 확인)
• 20:00 ~ 20:30 : 레퍼런스 조사(레딧 FOW/LOS 사례)
• 20:30 ~ 21:00 : 저녁 스크럼 — 내일 작업 배분 결정
• 21:00 ~ 21:30 : 내일 에셋 기반 FOW 도입 계획 수립
• 21:30 ~ 21:45 : TIL 작성

✅ 오늘 학습 키워드

• URP 2D, Light2D(Additive vs Multiply), Target Sorting Layers
• RenderTexture 누적(Graphics.Blit, max 합성)
• UI 오버레이 합성 셰이더(현재 시야=투명 / 방문=회색 / 미탐색=검정)
• 카메라 Culling Mask·레이어 분리 전략

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

• “지금 비춘 영역”을 전용 카메라로 RT_Frame에 찍고, 이전 누적과 max로 합쳐 VisitedRT에 쌓는다.
• 화면에는 RawImage 오버레이를 얹고, 셰이더에서 현재 프레임 밝은 픽셀은 완전 투명, 누적 픽셀은 회색, 미탐색은 검정으로 표현하면 플레이 가시성과 진행 흔적을 동시에 확보할 수 있다.
• 핵심은 Additive 전용 Light2D와 Global Light2D의 레이어 분리, 그리고 런타임 머티리얼 텍스처 바인딩이다.

🧩 학습하며 겪었던 문제점 & 에러

1) 프로브 평면이 메인 카메라에 노출됨

• 문제 정의: 게임 화면이 회색 부채꼴로 덮여 실제 월드가 가려짐.
• 내가 한 시도: 오버레이 색/알파 조정.
• 해결 방법: Main Camera의 Culling Mask에서 FOWProbe 해제(ExplorationCam만 보게).
• 새롭게 알게 된 점: 프로브용 평면은 전용 카메라로만 렌더링해야 한다.
• 다시 만나면: 씬 진입 시 카메라-레이어 매트릭스를 우선 점검.

2) 화면이 전부 어두움(오버레이만 보임)

• 문제 정의: 현재 시야가 투명 처리되지 않아 월드가 안 보임.
• 내가 한 시도: 셰이더 임계값 변경.
• 해결 방법: overlay.material = new Material(overlayMat)로 인스턴스화,
• overlay.texture = currentVisited, overlay.material.SetTexture("_CurrentTex", rtFrame) 런타임 바인딩. 컷오프 0.2로 조정.
• 새롭게 알게 된 점: 에디터에서 Texture만 넣으면 동작 불가, 코드 바인딩 필수.
• 다시 만나면: 실행 직후 디버그 RawImage로 RT_Frame/Visited 상태 먼저 확인.

3) RT_Frame가 항상 검정

• 문제 정의: 누적 자체가 진행되지 않음.
• 내가 한 시도: 카메라/RT 재설정.
• 해결 방법: FOW 전용 Light2D를 Additive로 전환, Target Sorting Layers=FOW만, Global Light2D에서 FOW 타겟 해제.
• 새롭게 알게 된 점: Multiply 라이트는 마스크 소스로 부적합.
• 다시 만나면: 라이트 Blend/Target Layers부터 체크.

📝 메모

• 내일은 FOW 에셋 기반으로 재구현(기능: 누적/감쇠/미니맵 연동 검토) → 데모 씬 확인 후 프로젝트 통합.
• 내일 담당
  • 재은: Fog of War 에셋 도입·통합
  • 혜현: 적 상태
  • 도현: 컨디션(스태미나)
  • 현수: 맵 제작
  • 유경: UI 제작
• 추가 아이디어: 방문 영역 감쇠(decay), 가장자리 블러, 세이브/로드 포맷 정의 및 미니맵 동기화.

오늘 하루는 플레이어가 라이트를 비췄던 자리를 회색으로 남기는 기능을 만들고싶었다 하지만.. 실패 ㅠㅜ 그리고 검색을 하다보니 Fog of War이라는 에셋을 찾았다.. 완전히 내가 원하는 기능! 그래서 내일은 이 에셋을 적용시켜보려고 한다! 쉽지는 않겠지만 화이팅!!!

🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 10:00 : 데일리 스크럼(업무 분담, 핵심 루프 목표 합의)
• 10:00 ~ 11:30 : 레퍼런스 게임 Intravenous 2 플레이 & 분석
• 11:30 ~ 12:50 : 차별점/시야 시스템 논의, 역할 확정 메모

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심

✅ 오후

• 14:00 ~ 15:30 : MissionManager 이벤트(+1/–1) 연결, MissionEntityHook 부착
• 15:30 ~ 16:30 : 레이어/레이어마스크 정리(AssassinationTarget, Enemy)
• 16:30 ~ 17:30 : 카메라 감쇠/민감도 튜닝 검토(프로토타입 적용 준비)
• 17:30 ~ 18:00 : 타이틀 화면 이미지 프롬프트 6안 정리

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁

✅ 저녁

• 19:00 ~ 20:30 : 프로토타입 플레이테스트
• 20:30 ~ 21:30 : 피드백 정리(적 AI/시야/카메라/맵 정보/목표 탐색 등)
• 21:30 ~ 22:00 : 저녁 스크럼(내일 작업 분배·마일스톤 확인)
• 22:00 ~ 22:20 : TIL 정리/기록

✅ 오늘 학습 키워드

• 이벤트 기반 MissionManager (타깃/적 카운트, Escape 전환)
• 시야(Vision) 제한 & 지나간 길 노출(Fog of War)
• 카메라 스무딩/감쇠 튜닝 (어지러움 최소화)
• AI 의심→수색 전이, 거리 기반 탐지 속도
• 원킬/피격 반응(피격 방향 바라보기, 상태 전환)
• 맵 정보 제공(미니맵/테두리 하이라이트)

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

https://dev-jen.tistory.com/entry/DesignPattern-이벤트-버스Event-Bus-패턴

• 목표 체크는 씬 전역에서 폴링하지 않고, 적/암살 타깃이 활성/비활성 이벤트를 던질 때 카운트만 정확히 올리고 내리는 방식이 가장 깔끔했다. 이렇게 하니 타깃이 0이 되는 순간을 안정적으로 잡아 Escape 단계로 전환할 수 있었다.
• 레퍼런스는 훌륭했지만, 우리 색은 제한 시야 + 지나간 길 누적 정보에서 만들어야 한다. “한 화면 정보 과다” 대신 “정보를 따서 쌓는 재미”를 핵심으로 삼자.
• 카메라 스무딩은 멋있지만 조준에는 방해가 된다. 빠르게 멈추는 감쇠와 근거리 민감도 완화가 필요했다.
• 전투 이슈(원킬/피격 반응, 의심→수색 텀 등)는 작은 파라미터와 명확한 시각 피드백(느낌표, 테두리)로 플레이 감각을 크게 바꿀 수 있다.

🧩 학습하며 겪었던 문제점 & 에러

1) MissionManager 폴링(UPDATE 스캔) → 이벤트 전환

• 문제정의
• Update()에서 씬의 오브젝트를 스캔하거나 레이어 카운트를 매 프레임 갱신하려다 보니, 풀링/활성화 타이밍에 따라 누락·중복 카운트가 발생하고 퍼포먼스도 불필요하게 사용됨.
• 시도
• FindObjectsOfType/레이어 스캔 주기로 재계산 → 특정 프레임에서 놓치는 케이스가 여전히 존재.
• 해결 방법

  // MissionManager.cs (핵심만)
  public void TargetActivated()   { remainingTargets++; OnTargetsChanged?.Invoke(remainingTargets); EvaluatePhase(); }
  public void TargetDeactivated() { if (remainingTargets>0) remainingTargets--; OnTargetsChanged?.Invoke(remainingTargets); EvaluatePhase(); }
  
  public void EnemyActivated()    { remainingEnemies++;  OnEnemiesChanged?.Invoke(remainingEnemies); }
  public void EnemyDeactivated()  { if (remainingEnemies>0) remainingEnemies--; OnEnemiesChanged?.Invoke(remainingEnemies); }
  

  // MissionEntityHook.cs (각 적/타깃 프리팹 루트에 부착)
  private void OnEnable()  { if (kind==AssassinationTarget) mission.TargetActivated(); else mission.EnemyActivated(); }
  private void OnDisable() { if (kind==AssassinationTarget) mission.TargetDeactivated(); else mission.EnemyDeactivated(); }
  

• 이벤트 기반으로 전환: 각 엔티티가 활성/비활성 시점에만 ±1 호출.
• 새롭게 알게 된 점
• “상태 변화 시점 이벤트”가 폴링보다 정확·간결하고, 풀링/활성화 패턴과도 찰떡.
• 다시 만나게 된다면
• 카운트가 필요한 다른 시스템(예: 아이템/트리거)도 OnEnable/OnDisable 이벤트 패턴으로 통일.

2) 구독/생명주기 레이스(매니저보다 훅이 먼저 켜지는 이슈)

• 문제정의
• 씬에 따라 MissionEntityHook.OnEnable()가 MissionManager 초기화보다 먼저 실행되어 첫 +1을 놓치는 경우 발생 가능.
• 시도
• 훅에서 FindFirstObjectByType<MissionManager>() 시도했지만 타이밍에 따라 실패.
• 해결 방법
  1. 실행 순서 지정 + 2) 지연 보정 추가.

  // 권장: 실행 순서
  [DefaultExecutionOrder(-500)] public class MissionManager : MonoBehaviour {}
  [DefaultExecutionOrder(-400)] public class MissionEntityHook : MonoBehaviour {}
  
  // 보정: 훅에서 Start 재시도
  private bool registered;
  private void OnEnable() { TryRegister(); }
  private void Start()    { if (!registered) TryRegister(); }
  private void OnDisable(){ if (!mission) return; /* ...deactivate... */ registered=false; }
  
  void TryRegister() {
      if (!mission) mission = FindFirstObjectByType<MissionManager>();
      if (!mission) return;
      if (kind==AssassinationTarget) mission.TargetActivated(); else mission.EnemyActivated();
      registered = true;
  }
  

• 새롭게 알게 된 점
• DefaultExecutionOrder와 재시도 지점을 두면 씬별/프레임별 레이스를 안전하게 흡수.
• 다시 만나게 된다면
• 매니저에서 씬 시작 시 **초기 스냅샷(한 번만 스캔)**을 수행해 이미 켜진 훅들을 재등록.

📝 메모

• 오늘 프로토타입 테스트에서 재미의 골자는 분명했다: 조심스러운 각 클리어(CQB). 이제 **정보 설계(시야/미니맵)**와 **조작성(카메라/이동 속도)**을 다듬으면 된다.
• 금요일까지 “타이틀→로비→핵심 루프→종료”가 돌아가도록, 각자 파트를 작게라도 끝까지 꽂아보자. 작은 완성이 큰 방향성을 만든다.
• 오늘도 고생했다 내읻로 화이티잉!!!!

🗓️ 오늘 하루 일정

✅ 오전

• 10:00 ~ 10:30 : 오전 데일리 스크럼 — 진행 상황 공유, 오늘 작업 범위 정의
• 10:30 ~ 12:00 : Shooter 발사 흐름 정리 (Shoot → SpawnBullet → VFX/SFX) 및 스프레드/쿨다운 점검

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심시간

✅ 오후

• 14:00 ~ 17:50 : 머즐 플래시 프리팹·스크립트 제작/연결(OnEnable 랜덤 스프라이트, 0.05초 유지)
  • SFX 피치 랜덤화 검토 → 보류(단일 사운드 유지, 간결성 우선)

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁시간

✅ 저녁

• 19:00 ~ 종료 : 오후 데일리 스크럼 — 오늘 작업 회고, 내일 계획 합의(소음기 권총용 트레이서 구현부터)

✅ 오늘 학습 키워드

• Shooter 발사 로직 정리, fireRate 쿨다운
• 탄 퍼짐(Spread) 계산
• 머즐 플래시(랜덤 스프라이트, 짧은 수명)
• SFX 전략(단일 샷 사운드 유지, 피치 랜덤화는 차후)
• 다음 작업: 소음기 권총 트레이서(탄 궤적/잔광)

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

• 발사 흐름을 간단하고 읽히게 재정렬했다: Shoot()에서 입력 처리와 스프레드, SpawnBullet()에서 초기화, 그 뒤 VFX/SFX 호출로 관심사 분리가 선명해졌다.
• 머즐 플래시는 호출부를 가볍게 유지하기 위해 프리팹 OnEnable에서 랜덤 스프라이트를 고르고 짧게 노출 후 제거하는 방식으로 확정했다.
• 샷 SFX는 오늘은 단일 클립 고정으로 두고, 피치 랜덤화는 오디오 풀 도입 시 함께 적용하는 게 전체 성능/관리성에 유리하다고 판단했다.
• 내일은 “소음기 권총” 특성에 맞춰 짧고 얇은 트레이서 + 낮은 플래시/볼륨으로 차별화할 계획이다.

🧩 학습하며 겪었던 문제점 & 에러

1) PlayClipAtPoint의 피치 한계

• 문제 정의: PlayClipAtPoint는 pitch 제어 불가 → 소리 한 종류만 쓰면 단조로울 수 있음.
• 시도: 임시 AudioSource 생성해 pitch 랜덤 재생 검토.
• 해결 방법(오늘 선택): 단순성 유지(기존 그대로). 추후 오디오 소스 풀 도입 때 함께 적용.
• 새롭게 알게 된 점: 잦은 발사에서 오브젝트 생성/파괴는 GC 스파이크 위험.
• 다시 만나면: 풀에서 꺼낸 AudioSource로 원샷 + pitch = Random.Range(0.96f, 1.06f).

2) 머즐 플래시 생성/파괴 비용

• 문제 정의: Instantiate → 0.05s → Destroy가 연사 시 누적 비용 가능.
• 시도/결정: 현재는 구현 단순성을 우선.
• 대안 메모: 나중에 풀링 전환 후 SetActive(true/false) 토글 + 짧은 알파 페이드로 전환하기.

📝 메모

• 생각보다 간결함이 힘이 됐다. 구조를 정리하니 다음 작업(소음기 트레이서) 진입이 훨씬 수월해졌다.
• “모르는 걸 부끄러워하지 말자.” 오늘은 과하게 욕심내지 않고 핵심 흐름부터 단단히 묶었다.
• 다음주도 화이팅!!!

🗓️ 오늘 하루 일정

✅ 오전

• 10:00 ~ 10:30 : 데일리 스크럼 진행(금일 작업 범위 확정)
• 10:30 ~ 12:30 : 공용 사격 API 설계(Shoot(Vector2 dir) 한 함수로 통일)

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심시간

✅ 오후

• 14:00 ~ 16:00 : Shooter2D 제작(플레이어/적 공용), Bullet 정리
• 16:00 ~ 17:30 : 레이어 분리 및 Physics2D 충돌 매트릭스 정리(태그 사용 제거)
• 17:30 ~ 18:00 : 트레일 렌더러(총알 궤적) 적용 및 기본 튜닝

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁시간

✅ 저녁

• 19:00 ~ 20:20 : 사격 테스트(권총/라이플 SO), 피격 전달 점검
• 20:20 ~ 21:00 : 리팩터링 메모 정리 & TIL

✅ 오늘 학습 키워드

• 2D 탑뷰 사격 시스템, 공용 사격 API(Shoot(dir)), ScriptableObject(GunData)
• Rigidbody2D + Trigger 충돌, 레이어 충돌 매트릭스, LayerMask
• TrailRenderer(궤적 이펙트), 발사 속도(fireRate)·스프레드(spread) 튜닝
• 인터페이스 기반 데미지 전달(IDamageable) vs SendMessage 비교

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

사격 로직을 플레이어/적에서 각각 구현하지 않고, 한 함수(Shoot(Vector2 dir))로 공용화했다. 총의 스펙은 SO(GunData)로 분리하여 데미지/속도/연사/스프레드를 데이터만 바꿔도 다르게 동작하도록 만들었다. 충돌 판정은 태그 의존을 제거하고, 레이어 분리 + Physics2D 충돌 매트릭스로 관리해 아군 오사/셀프히트를 깔끔하게 막았다. 총알 비주얼은 TrailRenderer만으로도 충분히 가볍고 예쁘게 만들 수 있어 우선 적용했고, 이후 필요하면 머즐플래시/피격 이펙트도 단계적으로 붙일 계획이다.

🧩 학습하며 겪었던 문제점 & 에러

1. 데미지 중복 적용 가능성

• 문제정의
• Bullet.OnTriggerEnter2D에서 SendMessage("TakeDamage")와 IDamageable.TakeDamage를 둘 다 호출할 여지가 있음.
• 내가 한 시도
• 먼저 IDamageable을 시도하고, 성공 시 SendMessage를 생략하도록 분기.
• 해결 방법 (코드)
• private void OnTriggerEnter2D(Collider2D other) { if (other.gameObject.layer == ignoreLayer) return; var target = other.GetComponent<IDamageable>(); if (target != null) { target.TakeDamage(dmg); } else { other.SendMessage("TakeDamage", dmg, SendMessageOptions.DontRequireReceiver); } Destroy(gameObject); }
• 새롭게 알게 된 점
• 인터페이스가 있으면 강타입/빠른 호출이 가능하고, 없을 때만 SendMessage로 느슨한 결합을 보완하면 구조가 깔끔해진다.
• 다시 만나게 된다면
• IDamageable을 프로젝트 공통 인터페이스로 정착시키고, SendMessage는 임시 호환용으로만 제한하겠다.

2. 아군/자기 자신 피격 이슈

• 문제정의
• 발사자와 같은 레이어 오브젝트에 총알이 맞는 케이스가 간헐적으로 발생.
• 내가 한 시도
• 총알 생성 시 총알의 레이어를 명시 세팅하고, Physics2D 충돌 매트릭스에서 PlayerBullet↔Player를 비활성화.
• 해결 방법 (코드)
• // 스폰 시 var go = Instantiate(bulletPrefab); go.layer = LayerMask.NameToLayer("PlayerBullet"); // 혹은 EnemyBullet var bullet = go.GetComponent<Bullet>(); bullet.Init(gunPoint.position, dir, speed, damage, life, ignoreLayer: LayerMask.NameToLayer("Player"));
• 새롭게 알게 된 점
• 레이어/충돌 매트릭스만 잘 잡아도 복잡한 태그 분기 없이 안전한 피격 처리가 가능하다.
• 다시 만나게 된다면
• 기능 추가 전 레이어 설계 문서를 먼저 쓰고, 매트릭스를 표로 관리하겠다.

3. TrailRenderer 궤적이 너무 길거나 둔탁해 보이는 문제

• 문제정의
• 기본값으로는 궤적이 길고 두꺼워 보여 게임 템포와 맞지 않음.
• 내가 한 시도
• Time, Min Vertex Distance, Width Curve 조정.
• 해결 방법 (권장값)
  • Time: 0.08 ~ 0.15s
  • Min Vertex Distance: 0.05 ~ 0.1
  • Width Curve: 앞부분 0.06 → 뒤 0
  • Material: Additive(URP면 Bloom과 함께 쓰면 광택 증가)

  // 필요 시 코드로도 가능
  var tr = bulletGO.GetComponent<TrailRenderer>();
  tr.time = 0.12f;
  tr.minVertexDistance = 0.08f;
  var curve = new AnimationCurve();
  curve.AddKey(0f, 0.06f);
  curve.AddKey(1f, 0f);
  tr.widthCurve = curve;
  

• 새롭게 알게 된 점
• 짧고 가는 궤적이 탑뷰 캐주얼에 더 잘 어울리고, 퍼포먼스에도 유리하다.
• 다시 만나게 된다면
• 색상 2~3안(노랑/청록/보라) 프리셋을 미리 만들어 맵 분위기에 맞춰 빠르게 교체하겠다.

📝 메모

오늘은 사격 시스템 핵심을 공용 API로 단순화한 게 가장 큰 수확이다. 태그를 과감히 빼고 레이어로만 정리하니 충돌/피격 흐름이 훨씬 명확해졌다. 궤적은 TrailRenderer만으로도 충분히 보기 좋아져서, 당장 게임의 피드백이 살아난 느낌이다. 내일은 머즐 플래시/히트 이펙트를 가볍게 붙이고, 오브젝트 풀링으로 총알 생성 비용을 줄여보겠다.

🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 12:00 : 입력 액션 맵 정리( Move/Run/Interact/Menu/Attack/Look ) 및 PlayerInput( Send Messages ) 세팅

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심

✅ 오후

• 14:00 ~ 16:00 : 2D 탑다운 이동 완성 (Rigidbody2D.Kinematic + MovePosition) / 마우스 에임 바라보기 로직 적용 / InputValue → InputAction.CallbackContext 전환, PlayerInputController partial 분리
• 16:00 ~ 18:00 : 팀 회의(진척 공유, 입력/조준 구조 리뷰)

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁

✅ 저녁

• 19:00 ~ 21:00 : 기획 회의 – 핵심 재미(“발각되지 않고 목표물 획득 후 흔적 없이 사라지는 쾌감”) 확정, 튜토리얼 플로우 초안(시야/각도‧소리‧경보‧탈출 루프) 정리

✅ 오늘 학습 키워드

• Unity Input System / CallbackContext
• PlayerInput Send Messages 규약
• 2D 탑다운 이동: Rigidbody2D.Kinematic + MovePosition
• 마우스 에임 고정 회전(속도 Fallback 제거)
• DOTween UI 이펙트(크로스헤어 펄스)
• 이벤트 허브: TopDownController / 컴포넌트 분리(partial)
• MissingMethodException(메서드명 충돌) 트러블슈팅

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

• 입력 레이어를 PlayerInputController(partial)로 깔끔히 분리하고, 실제 이동/회전은 TopDownMovement가 이벤트로만 받도록 만들어 의존성을 낮췄다.
• 회전은 오직 마우스 에임만 기준으로 하여, 이동 방향에 영향을 받지 않도록 했다(스텔스 조작감에 더 적합).
• UI 크로스헤어는 캔버스 기준으로 마우스를 추적하고, Attack 시 DOTween으로 작아졌다 커지는 펄스를 주어 타격감을 확보했다.
• SendMessages는 런타임에 메서드명을 리플렉션으로 찾기 때문에 이름 충돌을 만들지 않는 것이 핵심. 입력 수신자는 OnMove/OnLook만 두고, 나머지 컴포넌트는 Handle*로 구독하게 했다.

🧩 학습하며 겪었던 문제점 & 에러

1. MissingMethodException: Method 'OnLook' not found

• 문제 정의: PlayerInput(Send Messages)가 같은 오브젝트의 OnLook/OnMove를 호출하려다, 다른 컴포넌트에도 동일한 이름이 있어 충돌 발생.
• 시도: 시그니처 정리만 했더니 여전히 예외 발생.
• 해결 방법: 입력 수신자만 OnMove/OnLook(CallbackContext) 유지, 나머지는 이름 변경.
• 핵심 코드
• // TopDownMovement.cs private void OnEnable() { controller.OnMoveEvent += HandleMoveInput; controller.OnLookEvent += HandleLookInput; } private void HandleMoveInput(Vector2 v) => moveInput = v; private void HandleLookInput(Vector2 v) => lastLookDir = v.normalized;
• 새롭게 알게 된 점: Send Messages는 메서드명 일치가 절대적.
• 다시 만나면: 초기에 “입력 클래스 전용 On* / 나머지는 Handle*” 네이밍 규칙을 문서화.

2. 마우스 방향으로 안 돌아가는 문제

• 문제 정의: 이동 방향으로 회전하는 Fallback 때문에 마우스 에임이 무시됨.
• 해결 방법: 회전은 lastLookDir만 기준으로, 에임은 매 프레임 마우스 위치로 갱신.
• // 회전부 var dir = lastLookDir; float ang = Mathf.Atan2(dir.y, dir.x) * Mathf.Rad2Deg - 90f; rb.MoveRotation(Mathf.MoveTowardsAngle(rb.rotation, ang, rotationSpeed * Time.fixedDeltaTime));
• 배움: 스텔스 조작감은 시선 고정이 중요. 이동/시선 역할을 분리하니 컨트롤이 깔끔해졌다.

3. 크로스헤어 UI 위치가 어긋남(카메라 모드별)

• 문제 정의: Screen Space - Camera에서 RectTransform.position만 쓰면 오차.
• 해결 방법: RectTransformUtility.ScreenPointToLocalPointInRectangle 사용.
• if (RectTransformUtility.ScreenPointToLocalPointInRectangle(canvasRect, screen, uiCam, out var local)) crosshair.anchoredPosition = local;

📝 메모

오늘은 입력/조준/이펙트까지 “핵심 조작감” 뼈대를 깔끔히 잡았다. 팀 회의로 기획 방향도 선명해졌고, 내가 구현한 구조가 그 방향과 잘 맞아서 뿌듯했다.

내일은 나머지 플레이어 공격에 대한 조작과 애니메이션을 추가해봐야겠다 재밌는 게임이 완성될듯하다!! 내일도 화이팅!!!!

🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 10:00 : 최종 팀 빌딩 확정 & 팀원 소개
• 10:00 ~ 12:00 : 레퍼런스/코어루프 공유, 게임 콘셉트 얼라인

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심

✅ 오후

• 14:00 ~ 16:30 : 게임 개요 문서 초안 정리 (장르/핵심경험/진행구조/비주얼·오디오 콘셉트)
• 16:30 ~ 18:00 : 플레이어 기획 1차 작성(조작키·스탯·이동·피격/시야·공격·상호작용)

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁

✅ 저녁

• 19:00 ~ 20:00 : 개발 역할 분담 확정(플레이어 담당 배정)
• 20:00 ~ 21:00 : 세부 TODO 정리 & 문서 다듬기

✅ 오늘 학습 키워드

• 2D 탑다운 잠입 코어(시야·빛·소음)
• 플레이어 설계: 조작키/스탯/이동/피격·무적/사망/시야/공격/상호작용
• 팀 역할 분담과 작업 범위 확정

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

• 핵심 재미 정의를 먼저 고정(“들키지 않기”와 “탐욕의 줄타기”). 이 기준으로 모든 시스템(시야·소음·밝기·아이템)을 평가하니 의사결정이 빨라졌다.
• 플레이어 기획은 “도망 우선, 전투는 보조” 원칙으로 통일:
  • 시야: 전방 원뿔(기본 120°)로 정보 제한 → 관찰·경로설계의 재미 강화
  • 이동: 입력 즉시 반응(가감속 없음)으로 조작 손맛 확보, 달리기는 ‘위험을 키우는 선택’으로 사용
  • 피격/무적: 명확한 피드백(색 변화) + 짧은 무적으로 연속즉사 방지
  • 공격: 소음/리스크가 따르는 보조 수단으로 정의(전투 게임이 아님을 문서로 못 박음)
  • 상호작용: F키 단일화, 반경·우선순위 규칙으로 판정 일관성 확보
• 문서화 우선으로 팀 공통 언어를 만들었고, 다음부터는 이 기획서를 기준으로 구현/레벨링을 병행할 수 있게 됐다.

📝 메모

오늘은 전체적으로 팀원들화 회의하며 기획분들과 협업을해서 어느정도의 기획의 기반을 다졌다. 팀원분들도 다 너무 성격이 좋으시고 협업도 너무 잘되고 소통도 잘된다ㅎㅎ 앞으로의 프로젝트가 기대되는구만.. 내일도 화이팅!!!!

🗓️ 오늘 하루 일정

• 최종 프로젝트 팀 빌딩

📝 메모

같이 하고싶은 팀원들이 있는데 어떻게 진행이 될지를 모르겠다ㅠㅜㅜ 내일 아침에 다시 나머지 인원들을 정해준다고 하는데..뭔가 방식이..흠.. 매니저님들도 고심끝에 하신거일테니.. 뭐든지 모두가 만족할 수 있는 방법은 없는거 같다 내일 되어봐야 알지 않을까 싶다

🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 10:30 : 리포지토리 스크립트/폴더 구조 점검, 파일 트리 추출 시도
• 10:30 ~ 12:00 : 프로젝트 구조 스샷 정리 및 실제 구조 대비 표기 규칙 확정

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심시간

✅ 오후

• 14:00 ~ 16:00 : README 초안 뼈대 구성(게임소개, 플레이방법, Features, 설계&디자인패턴, 사용기술&시스템)
• 16:00 ~ 18:00 : 스크립트 하나씩 확인하며 Features ↔ 시스템 ↔ 스크립트 매핑

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁시간

✅ 저녁

• 19:00 ~ 21:00 : 피드백 반영(프로젝트 구조 오표기 교정), 섹션별 문구 다듬기 및 체크리스트화

✅ 오늘 학습 키워드

• README 구조화
• 프로젝트 폴더/스크립트 정합성 검증
• Features–System–Script 매핑 테이블
• Git 기반 파일 리스트 추출

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

문서는 코드와 동기화될 때 가치가 있다. 오늘은 스크린샷/파일트리/실제 폴더를 교차 확인하며 README 섹션을 재정비했다. 핵심은 ① 프로젝트 구조를 있는 그대로 보여주고, ② 사용자 관점의 Features를 개발자 관점의 시스템/스크립트에 정확히 매핑하는 것. 이때 용어·경로·클래스명을 실제 코드 기준으로 통일해야 팀원이 혼동하지 않는다. 앞으로는 문서 수정 전에 자동/반자동 파일 리스트 추출로 검증 단계를 습관화한다.