📘TIL - 붉은 사막 사례 기반 입력 / 상호작용 / AI 오발동 이슈 분석

문제 인식

붉은 사막 관련 사용자 편의성 이슈에 대해서 알아보고 언리얼 엔진일 경우 어떤식으로 수정할 수 있을지에 대해서 분석하는 방향으로 공부를 진행했다.
큰 이슈 위주로 분석을 했다.

1. 키매핑 이슈

2. 물리적 상호작용 오발동 이슈

출시 이후 사용자 피드백을 보면
단순히 “조작이 어렵다” 수준이 아니라

• 입력이 상황에 따라 다르게 반응하는 느낌
• 상호작용 대상이 의도와 다르게 선택되는 경우
• NPC나 전투 대상이 예상과 다르게 반응하는 문제

같은 케이스들이 반복적으로 언급되고 있다.

이걸 단순 UX 문제라기보다
엔진 내부에서 입력 → 판정 → 반응 흐름이 어긋난 결과가 아닐까라는 관점으로 접근해봤다.

---

전체 흐름 기준으로 바라보기

문제를 하나씩 따로 보기보다
전체 파이프라인으로 보면 구조가 더 잘 보였다.

[Player Input]
      ↓
[Input Interpretation]
      ↓
[Target Selection]
      ↓
[Action Commit]
      ↓
[AI Reaction]
      ↓
[Result (Player 체감)]

이 중 어디 하나라도 어긋나면
유저 입장에서는 전부 “조작감 이상”으로 느껴질 수 있다.

---

1. 입력 단계에서의 문제 가능성

피드백 중 “키가 상황마다 다르게 느껴진다”는 부분은
입력 정의 자체보다 입력 허용 조건이 정리되지 않았을 가능성이 크다고 느꼈다.

---

추측되는 구조 문제

문제 유형	발생 가능 원인
입력 씹힘	여러 Context가 동시에 활성화
다른 동작 실행	Mapping Priority 충돌
상황별 입력 다름	상태 기반 필터 없음
이상한 타이밍 발동	Trigger 중복 (Tap / Hold 등)

---

구조 비교

기존에 흔히 발생하는 구조

Key Input
 ├─ Attack
 ├─ Interact
 ├─ Dodge
 └─ UI Confirm
→ 상황 구분 없이 실행 시도

개선 방향으로 생각해본 구조

[Current State]
   ├─ Exploration
   ├─ Combat
   ├─ Interaction
   └─ UI
        ↓
[Allowed Input Only]
        ↓
[Execute Action]

---

적용해볼 수 있는 방식 (언리얼 기준)

• Mapping Context를 상태 단위로 분리
• Context Priority를 명확하게 정의
• 입력 실행 전에 “허용 여부”를 체크하는 계층 추가

간단히 정리하면

입력 → 바로 실행 ❌
입력 → 상태 확인 → 실행 ⭕

이렇게만 바꿔도
키 충돌 문제는 상당 부분 줄어들 것 같다는 생각이 들었다.

---

2. 상호작용 오발동 문제 분석

이 부분은 실제로 많이 겪는 문제라 더 익숙하게 느껴졌다.

“문을 열려고 했는데 옆에 있는 아이템이 선택된다”
→ 거의 대부분 Trace 방식 문제다.

---

기존 구조 (문제 발생 패턴)

Camera Forward
      ↓
Line Trace
      ↓
First Hit Actor
      ↓
Interact

이 구조는 단순하지만
유저 의도를 반영하지 못한다는 한계가 있다.

---

개선 구조로 추측한 방식

[Multi Trace]
      ↓
[Candidate List]
      ↓
[Filter]
 - 거리
 - 시야(FOV)
 - 상태
      ↓
[Score 계산]
      ↓
[Best Target 선택]

---

후보 선택 기준 정리

요소	이유
거리	가까운 대상이 더 자연스럽다
방향	화면 중앙에 있는 대상이 우선
상태	상호작용 가능한 대상만
가시성	벽 뒤 대상 제거

---

점수 기반 선택 개념

Score =
 (거리 가중치)
 + (카메라 방향 가중치)
 + (우선순위 태그)

이 구조를 쓰면
“엉뚱한 대상 선택” 문제는 거의 줄어들 것 같았다.

---

추가로 느낀 포인트

방식	문제
Overlap 기반 선택	대상이 계속 바뀜
단일 Trace	정확도 부족
다중 후보 + 점수	안정적

결국 핵심은

Hit = 선택 ❌
Best Candidate = 선택 ⭕

---

3. NPC / AI 반응 문제 분석

이건 체감이 제일 어색해지는 부분이라 중요하게 보였다.

---

증상 기준으로 보면

체감	내부 문제 추측
다른 적이 반응	타겟 불일치
반응이 늦음	Perception 지연
엉뚱한 행동	Blackboard stale

---

구조적으로 보면

[Client Input]
      ↓
[Client Target]
      ↓
(Server)
      ↓
[Server Target Confirm]
      ↓
[AI Blackboard]
      ↓
[AI Behavior]

여기서
Client Target ≠ Server Target 이 되면
체감이 바로 깨진다.

---

개선 방향으로 생각해본 구조

Client
 - 대상 미리보기
 - UI 표시

Server
 - 최종 타겟 확정
 - 즉시 상태 업데이트

---

중요한 포인트

항목	이유
서버 확정	판정 일관성
Blackboard 즉시 갱신	AI 반응 지연 방지
타겟 고정 구간	중간 변경 방지

---

타겟 고정 개념

Attack Input
   ↓
Target Snapshot 저장
   ↓
Animation 진행
   ↓
Hit 판정

이걸 안 하면
공격 도중 타겟이 바뀌는 문제가 생길 수 있다.

---

4. 물리 상호작용 관점에서 본 문제

이건 입력/타겟 문제랑 같이 엮여있다고 느꼈다.

---

문제 발생 구조

Overlap 발생
 → 바로 상호작용 대상 결정

이 구조는 상황에 따라 계속 대상이 바뀐다.

---

개선 방향

Overlap → 후보만 확보
Trace → 최종 선택

---

Collision 설계도 중요

채널	역할
Interactable	상호작용 대상
Enemy	전투 대상
World	시야 차단
Physics	물리 오브젝트

채널 분리가 안 되어 있으면
Trace 결과 자체가 불안정해질 수 있다.

---

5. 전체 구조 다시 정리

이걸 하나로 묶어보면
문제는 개별 기능이 아니라 흐름 문제였다.

---

Before

Input → 바로 실행
Trace → 첫 Hit 사용
AI → Perception 의존

---

After (추측 기반 개선 구조)

Input → 상태 기반 필터
      ↓
Target → 후보 + 점수 선택
      ↓
Server → 최종 확정
      ↓
AI → 즉시 상태 반영

---

느낀 점 (정리)

이번 내용을 정리하면서 느낀 건
이 문제는 단순히 “버그를 고친다” 수준이 아니라
설계 방식 자체가 결과를 만든다는 점이었다.

특히 인상적이었던 건

• 입력은 많이 받는 게 아니라 제한이 중요하다는 점
• 상호작용은 정확한 판정보다 선택 기준이 중요하다는 점
• AI는 똑똑한 것보다 타이밍이 맞는 게 중요하다는 점

아직 실제 내부 구조를 본 건 아니지만
지금 보이는 증상 기준으로 보면
이 세 축이 동시에 흔들렸을 가능성이 높다고 생각했다.

---

오늘의 정리

• 사용자 편의성 측면에서 중요한 이슈인 조작감 문제는 입력 문제가 아니라
  입력 → 선택 → 반응 흐름이 얼마나 일관되게 이어지느냐의 문제라고 느꼈다.