[언리얼 페스트 2024 서울] 《스텔라블레이드》 발표 요약
《스텔라블레이드 개발 노하우》
전투 시스템
- ShowMaker Interface 툴을 써서 기획 사운드 아트 작업자들의 작업 효율성을 증대시켜줌
- 장점:
- 특정 항목에 의존적이지 않음
- 블루프린트 없이도 연출을 재생할 수 있음(툴 내부에서 자동생성해주나?)
- 리소스 관리 용이
- 단점: 툴 러닝커브가 생김
타격 판정
스텔라 블레이드에서 타격 판정은 2가지로 이루어졌다함
- 소켓을 연결한 Triangle-Hitbox Intersection
- ShapeComponent 활용한 Hitbox Sweep Trace 첫번째 방식은 플레이어의 얇은 무기에 적용한 것 같고, 두번째 방식은 둔기 등 넓은 범위를 요하는 무기나 덩치 큰 적들의 타격 판정에 사용한 것으로 보임.
프롬소프트웨어의 게임들도 대부분 캡슐 콜리전을 활용한 타격 판정을 하는 것 같아서 익숙했음
Triangle-Hitbox Intersection
- 프레임 기반 타격 판정이라, 프레임이 낮아지거나 공격 모션이 빠를 경우 트레이싱 중간이 비게 되는 문제가 있었다고 함
- 시프트업은 이 문제를 애니메이션 시퀀스의 RawAnimationData를 가져다가 소켓의 부모 뼈 Transform 사이 보간처리를 해 속도 관계 없이 더 자세한 트레이싱 처리가 되도록 개선했다 함
경사면에서의 공격
아무런 추가 처리 없이 그대로 두면 경사면에서의 공격이 땅, 혹은 허공을 향하게 됨.
- 시프트업은 이 문제를 LookAt IK 노드를 만들어서 지정된 뼈들이 특정 위치를 바라보게 처리하여 어색함을 줄였고,
- 실제 공격 트레이싱도 Transform 높이 차이를 구해 보간처리하여 해결했다고 함
공격 궤적 프레임 문제
마찬가지로 검 궤적 이펙트도 위에서 살펴본 것처럼 속도 기반 트레일링을 하다보니 부드러운 원이 아니라 뚝뚝 끊기는 다각형으로 표현됐다고 함
시프트업은 완성도를 위해 트레일링에도 보간처리를 해 자연스러운 궤적 이펙트를 만들었다 함
.gif&w=2048&q=75)
적 AI
역시나 Behavior Tree를 사용한 모습(뎁스보소 ㄷㄷ)
타겟 감지는 소리-시야 영역을 두고 그 밖에 탐색 가능 영역을 뒀다고 함
AI의 이동은 다음과 같이 플레이어 중심의 55 단위 크기의 셀 맵을 만들고
- 이동 가능 여부 판단을
- NavMesh 검사
- 오브젝트 정보, 캐릭터 정보 판별로 판단함
- 이동 경로는
Theta*(AStar의 개선 알고리즘 중 하나인가봄)로 생성 - AI 캐릭터의 위치 선점 위 로직을 통해 이동시키게 했다 함
캐릭터 충돌
캡슐 컴포넌트를 사용했고, 캐릭터간 충돌은 Overlap으로 검출했다 함.
만약 충돌을 Block으로 설정하면 움짤 좌측 상단처럼 공격못하고 겉도는 아이들이 생기는데
Overlap으로 설정하고 공격 상태의 우선순위를 높게 설정하면 누구 하나 소외되지 않고 골고루 공격하며 우선순위가 낮은 아이들이 뒤로 자연스럽게 밀린다고 함
기타
이 글에 담은 내용 말고도 최적화 관련해서 좋은 인사이트가 많이 남아있으니 영상을 통해 확인해보자
- 비용 비싼 처리들 구별해서 스레드 분산 처리로 성능 향상
- 캐릭터의 Rigid body에서 무기를 제외한 부분은 캡슐 컴포넌트로 대체해 비용을 절약했고
- 루트모션이 멀티스레드로 동작하지 못한다는 점을
- 애니메이션에서 직접 이동, 회전 값 추출해 루트모션 데이터로 저장해놓고
- 애니메이션과 루트모션데이터를 동시에 재생해 현재 재생시간에 맞는 이동값을 사용하도록 처리해 GameThread를 효율화함
- 다수의 몬스터 캐릭터가 등장하면 CharacterMovement가 여러번 호출되는데, Movement Tick이 순차적으로 직렬 처리되기 때문에 CPU를 많이 잡아먹는 문제가 있었음
- 이를 MovementTick을 분해해서 움직임 처리만 병렬로 먼저 처리하고, Overlap과 Physics연산은 미리 처리된 Move 값을 활용해 기존처럼 순차 처리되도록 개선했다 함
- 이렇게 하려고 Movement Manager Class도 만들었다 함
- 근데 이렇게 하니까 플레이어가 트램같은 곳에 Attached되면 카메라가 흔들리는 현상이 발생했다고 함
- 이유는 Move 로직을 병렬처리할 때 기존의 우선순위를 고려하지 않고 처리했기 때문이라고 함
- 그래서 이 경우만 예외를 두어 순차처리하도록 한 듯
- 스텔라블레이드에선 현실감을 위해 공격에 따라 몬스터들이 절단되는 효과를 구현했는데, 전통적인 모델링 교체방식은 딱봐도 별로기 때문에 실시간 절단 방식을 구현하기로 했다 함
- 장점으로는
- 추가 모델링 작업 없음
- 절단 Mesh와 RagDoll 상태 스켈레탈 Mesh의 자연스러운 표현
- 안정적인 성능이 있고
- 단점으로는
- 당연히 비용이 증가함(Vertex Skinning)
- 절단 면도 표현하고 절단된 Mesh의 형상도 표현해줘야하는데 이게 까다로웠다고 함
- 처음엔 언리얼 기본 함수인 SliceProceduralMesh를 써서 만들려고 했는데, 이러면 RagDoll을 활용 못해서 석상 잘리듯이 잘렸고,
- 기본 함수가 스켈레탈 Mesh를 복제한 Procedural Mesh를 또 생성해서 모든 Vertex를 복사해 비용이 증가하는 문제가 있었다고 함
- 그래서 개선 아이디어를 다음과 같이 냈다고 함
- 절단 부위 정해주기
- 스켈레탈 + Procedural 혼용
- Vertex Skinning
- 장점으로는
노하우 야미미