2026. 1. 7. 23:41ㆍ본 캠프

QTE라고 부르기엔 좀 민망하지만 기반이 될 수 있는 로직을 통해 기능구현하는데는 성공했다.
아직까지 기획상으로는 Hold형식이나 로스트아크의 여러 키보드 누르기 형식 같은 기획은 없어서 단순 연타로 만들어놨다.
QTE기능을 구현하면서 제일 고민됐던 부분은 InputManager를 갈아 엎어야할까? 에 대한 부분이었다.
다른 팀의 발표 중 InputManager에서 SO를 통해 각 모드 별로 등록 추가만 하면
바로 작동할 수 있도록 만들었던 걸 보고 감탄했었는데 나는 아직까지 코드상으로만 4가지의 모드를 다루고 있으니
이러다가 점점 너무 비대해지는 거 아닌가 걱정이 됐었다.
QTE자체를 처음 해보기도 해서, 일단은 기능구현에 중점을 두고 UI를 통해서 입력에 대한 피드백을 받을 수 있는 부분이기에
동시에 진행을 했어야 했다.

QTE enum을 설정하고 QTEConfig 를 통해서 타입과 시간제한 그리고 얼마나 입력할지를 받을 설정 값을 Struct 형태로 보관해
추후에 죄수들의 종류에 따라 다르게 적용할 수 있도록 구성했다.
사실 지금 단계에서는 실제 QTE 기능중에 일정시간 입력없을 시 게이지가 줄어든다던지 잘못눌렀을 때 게이지가 줄어드는 등의 기능은 들어가 있지 않고 순수 최댓값까지 누르도록 유도하는 방식이기 때문에 입력에서 오는 피드백이 많이 심심한 편이다.
막상 개발자의 시선으로 이런 기능을 만들어보니 내가 그동안 게임에서 체험했던 기믹들이 어떤 구성이었는지를 되돌아보게 되고
'아 이렇게 만든 이유는 플레이어가 입력했을 때 크게 반응이 없어서 추가한거구나' 라는 생각을 자연스럽게 하게된다.


로스트아크만 해도 '비아키스 아재패턴' 부터 '격돌' 도 전부 QTE의 형식을 하고 있다.
제한시간에 입력해야 하고 이 경우에는 하나만 틀려도 처음부터 다시 시작해야하는 구성으로 되어 있다.
격돌의 경우는 한번 실패하면 바로 fail 처리가 되는등 여러 분기가 나뉘어져 있고
하나의 기능을 만들 때 어떤 요소를 추가할지 고민하고 어떻게 연결할 것인지에 대한 고민을 많이 하게 되는데
지금 내가 단순하게 만든 QTE 시스템만 봐도 반응성이나 실패에 대한 UI 연출처리가 없어서 아무래도 더 크게 느껴지는 거 같다.
일반적으로 UI연출 구조는 Input - UI - 판정 식으로 만들게 되는데
이렇게 되면 QTE 처럼 입력 즉시 반응해야하는 UI연출에 있어서 반응성이 굉장히 떨어지게 된다.
UI프레임에 의존되기 때문이면서 판정 로직 자체가 UI에 묶이게 되는 경우가 많다.

그래서 Input - QTEController -> Event -> UI 형식으로 중간 계층을 추가해서 같은 프레임 내에 같은 콜 스택이 처리되고
UI는 결과를 출력해서 표시만 하기 때문에 QTEController같은 중간계층이 꼭 필요했었다.
내일은 팀원이 준 죄수 애니메이션을 토대로 연출과 실패시 UI연출을 조금 추가해서 QTE기능을 좀 더 고급화 해봐야겠다.
'본 캠프' 카테고리의 다른 글
| [내일배움캠프 본 캠프 72일차] SO를 통한 상태 변경 (0) | 2026.01.09 |
|---|---|
| [내일배움캠프 본 캠프 71일차] QTE_3 (0) | 2026.01.08 |
| [내일배움캠프 본 캠프 69일차] QTE_1 (0) | 2026.01.06 |
| [내일배움캠프 본 캠프 68일차] HUD UI (0) | 2026.01.05 |
| [내일배움캠프 본 캠프 67일차] 중간발표의 날 (0) | 2026.01.02 |