개발자노트 #001: PvE

안녕하세요, SY입니다. 첫 개발자노트로 인사드리게 됐습니다.

콘텐츠 업데이트나 개발 상황에 대해 궁금하셨던 분들이 많았던 것 같습니다. 기다리시는 입장에서는 아무 소식이 없으면 답답하게 느껴지실 수 있다는 점도 충분히 공감하고 있습니다.

어떻게 개발 소식을 전해드려야 플레이어 여러분들이 기대감을 현실적인 선에서 유지하며, 동시에 과한 예측이나 억측을 예방할 수 있을지 많이 고민했습니다. 이전에 디스코드를 통해 단순한 스크린샷을 공유를 한적이 있는데, 부족한 정보전달로 좋은 소식통이 되지 못한거 같아, 고민 끝에 개발 로그를 통해, 지금 내부에서 어떤 작업이 진행되고 있는지 최대한 자세하게, 하지만 편하게 공유드려보려고 합니다.

요즘 저는 “콘텐츠를 만드는 일”보다는, 그 콘텐츠를 가능하게 만드는 기반을 만드는 작업에 더 집중하고 있습니다. 지금 당장은 눈에 보이는 변화가 적을 수 있지만, 이 작업이 어느 정도 정리되면 앞으로는 더 다양한 콘텐츠와 메커니즘을 훨씬 안정적으로, 그리고 꾸준하게 보여드릴 수 있을 거라고 생각하고 있습니다.

좋은 소식으로는, 새로 합류한 개발자 MIN도 빠르게 적응하고 있다는 것입니다. 현재 스택도 빠르게 따라오고 있고, 덕분에 앞으로는 업데이트나 소통도 지금보다 더 안정적으로 이어갈 수 있을 것으로 예상됩니다. 저는 구조 설계나 시스템 쪽 작업 위주로 집중하고, MIN과 기존 팀원들은 버그 수정이나 기존 시스템 개선, 그리고 이미 만들어진 기반 위에서 콘텐츠를 확장하는 역할을 맡는 방향으로 잡게 됐습니다.

파이브엠 개발과 환경

본격적인 PvE 이야기를 하기 전에, 첫 개발자노트인만큼 지루하더라도, FiveM 개발 환경에 대한 이야기를 먼저 드리고 싶습니다.

FiveM은 커스텀 런타임과 게임 엔진 사이를 이어주는 역할을 하지만, 엔진 전체를 직접 다룰 수 있는 환경은 아닙니다. Unreal이나 Unity처럼 개발자용 도구가 충분히 갖춰져 있는 구조도 아닙니다.

PvE 기준으로 말씀드리면, 기존 AI를 그대로 사용하는 방식은 생각보다 안정적으로 제어하기 어렵습니다. 겉으로 보기에는 ped에게 전투 태스크를 주면 알아서 판단하고 움직일 것처럼 보이지만, 실제로는 원하는 행동만 골라서 세밀하게 제어하기가 쉽지 않습니다. 공격, 이동, 엄폐, 추적 같은 행동들이 내부적으로 어떻게 판단되는지 직접 들여다볼 수 없고, 특정 상황에서 왜 멈췄는지, 왜 다른 행동으로 넘어갔는지, 왜 갑자기 전투를 포기했는지 추적하기 어려운 경우가 많습니다.

추적만 하기 어려울 경우가 많다면 다행이지만, 사실 파이브엠 환경에서 연결이 제대로 안됐거나, 미완성된 기능들이라 작동조차 하지 않을 때가 상당히 자주 많습니다.

그래서 기존 AI를 그대로 사용하면 결국 "잘 동작해주길 바라는" 방식에 가까워집니다. 기본 AI 자체가 불안정하게 동작하는 경우도 있고, ped 관련 네이티브들 중에는 특정 상황에서만 작동하거나, 네트워크 환경에서 싱크가 어긋나거나, 문서상으로는 가능해 보이지만 실제로는 기대한 결과가 나오지 않는 것들이 많습니다. 실제로 파이브엠에게 AI를 맡길 경우, 적이 이유 없이 디스폰되는 이유가 상당히 자주 발생했습니다. 그렇기 때문에, FiveM에서는 R&D가 선택이 아니라 거의 필수에 가깝습니다. 단순히 "이 기능이 존재하나?"를 보는 것이 아니라, 실제 플레이 환경에서 클라이언트가 이 부하를 버틸 수 있는지, 여러 플레이어가 동시에 보고 있을 때 같은 결과로 보이는지, 네이티브가 반복 사용해도 안정적으로 동작하는지까지 계속 확인해야 합니다. 개발 과정 자체가 "쓸 수 있는 것과 없는 것, 정상 작동는 것과 작동하지 않는 것을 구분하는 과정"으로 시작된다고 봐도 될 것 같습니다.

큰 상자에 섞여 있는 여러 제조사의 블록들 중에서, 깨지지 않은 것들을 하나씩 골라서 서로 제대로 맞는지 확인해보는 과정이라고 보면 조금 더 와닿을 것 같습니다.

왜 PvE를 다시 만드는가

산타가 이단으로 변하기 전의 상황

아마 "왜 PvE를 다시 처음부터 만드냐"는 생각이 드실 수도 있을 것 같습니다.

2025년 크리스마스 이벤트에서 처음으로 PvE 보스를 선보였는데, 솔직히 말씀드리면 그건 Proof of Concept에 가까운 콘텐츠였습니다. 커스텀 네트워크 코드와 장판 스킬 처리 방식이 실제 환경에서 어떻게 동작하는지를 확인하는 게 가장 큰 목적이었습니다.

당시에 이미 AI 관련 네이티브들이 거의 활용하기 어려운 상태였다 판단이 된 상태였기 때문에, RPG 스타일의 AOE 기반 구조로 접근했습니다.

덕분에 많은 데이터를 얻을 수는 있었지만, 그때의 시스템을 재사용하기는 힘들었습니다. 의사결정 구조가 있는 게 아닐뿐더러, 코드 구조 또한 전체적으로는 "하드코딩에 가까운 구조"로, 다양하게 확장하기는 힘들었습니다.

재작업의 과정

산타가 이단이 된 이후

사용 가능성을 확인하기 전에 과투자를 방지하기 위해, 크리스마스 이단 산타는 위에 말씀드린거처럼 하드코딩에 가까운 구조였습니다. 똑같이 일자로 공격하는 스킬을 다른 이펙트로 만들거나, 데미지와 함께 폭발도 보내려면, 코드베이스가 금방 더러워지거나, 같은 역할을 하는 코드를 두번 세번씩 반복해서 썼어야 했습니다.

더 다양한 스킬을, 다양하게 설정할 수 있게 구조를 만들고, 실제 플레이를 모니터링한 결과, 클라이언트간 싱크나 코드베이스 재정립이 필요했습니다. 추가적으로 기존에 발생했던 문제들도 해결하기 위해서는 다시 만드는게 더 좋겠다는 판단을 했습니다.

초기에는 크리스마스 이벤트 시스템을 기반으로 네트워크 구조를 개선하고, 스킬을 재사용 가능하게 만들고, 싱크를 안정화시키는 작업을 먼저 진행했습니다.

네트워크 코드를 재정립하고, 가장 먼저 만든 것은 다양한 결과를 기대할 수 있는 스킬 구조였습니다. 이전에는 썰매를 던지는 스킬을 만들었다면, 이제는 여러 방향으로 투사체를 쏘는 스킬을 만들었다고 생각해주시면 될 것 같습니다.

첫 번째 문제 – AOE(장판) 마커

문제는 지면에 붙는 AOE(장판)를 만들면서 시작되었습니다.

크리스마스 이벤트에서는 원형 마커를 사용했는데, 일정 개수를 넘기면 FiveM이 더 이상 마커를 그리지 않는 문제가 있었습니다.

이로 인해 일부 공격이 아예 보이지 않는 상황이 발생했고, 특히 난이도가 올라갈수록 “보이지 않는 공격에 맞는” 상황이 생기게 되었습니다. 이단 산타 때도 여러 스킬이 동시에 겹치면 이 현상이 드러났었습니다.

이를 방지하기 위해, 필요하다면 사각형 형태의 AOE를 만드는 방식으로 바꾸려고 했습니다. 안타깝게도, 네모를 그리는 단순한 것조차 네이티브가 존재하지 않아, 삼각형 2개를 붙여서 그려야 했습니다.

하지만 여기서 또 다른 문제가 생겼습니다. 직선으로 그린 사각장판은 지형에 가려지거, 바닥과 어긋나는 현상이 발생했습니다. 아무리 위치를 조정해도, 너무 떠 보이거나 너무 파묻혀 제대로 인지하기 어려웠습니다.

지형 맞추기 문제 해결

결국 이 부분은 생각보다 훨씬 복잡하게 접근해야 했습니다.

겉으로 보면 “바닥에 사각형 하나 그리면 되는 거 아닌가?”라고 생각할 수 있지만, 파이브엠에는 이걸 해소해주는 네이티브나 도구가 전혀 존재하지 않습니다.

프로젝션을 통해 지형에 맞게 자동으로 붙여주는 기능도 없고, 메쉬를 바닥에 맞춰주는 기능도 없습니다. 장판은 직접 그린 좌표 그대로 나올 수 밖에 없었고, 실제 지형은 대부분 평평하지 않아, 단순하게 사각형을 삼각형으로 그린다고 문제가 해결되지 않았습니다. 그래서 단순한 사각형은 실제 환경에서는 계속 깨질 수밖에 없었습니다.

그래서 장판 하나를 "가상의 공간"으로 보고 접근했습니다. 시작점과 끝점 사이를 여러 구간으로 나누고, 각 지점에서 바닥 높이를 샘플링했습니다.

그 다음 가상의 공간을 여러 개의 작은 세그먼트로 나누고, 각 조각을 바닥에 맞게 정렬한 뒤, 작은 삼각형들로 그렸습니다.

겉으로 보면 하나의 평면처럼 보이지만, 실제로는 수많은 조각이 이어진 구조입니다.

보스 & 물리 시스템

AOE 문제를 해결한 이후, 처음 소개하려고 기획된 미치광이 화학자 숀과 외계 생명체 같은 보스들을 구체화해서 만들기 시작했습니다.

미치광이 화학자에게는 튕기는 폭탄 패턴을 넣고 싶었고, 외계 생명체에겐 운석 공격을 넣고 싶었습니다.

튕기는 폭탄을 만들기 위해, 일반적인 엔진이라면 질량, 탄성, 힘을 주고 단순 곡선 유도를 하여 물리로 해결하면 되지만, FiveM에서는 그런 제어가 불가능합니다. 엔진이 내부적으로 크기를 기반한 값을 계산하고 적용합니다. 무언가 원하는 방식으로 움직이게 하는 것은 게임 개발에서 가장 기본적이지만, 파이브엠 환경에서는 너무나도 먼 꿈이었습니다. 설령 물리를 그대로 사용하여 구현이 되는 움직임이더라도, 네트워크 오브젝트들에 대한 클라이언트 간 싱크가 맞지 않습니다. LAC 대부분의 설치형 아이템이 고정이 되어 있는 이유 중 하나이며, 돌진 스킬이 불가피하게 싱크가 종종 맞지 않는 이유 또한 여기에 있습니다.

그래서 결국 구현을 포기하거나, 튕기는 물리에 대한 시뮬레이터를 만들어야 했습니다.

스킬을 사용할 때, 클라이언트에서 주변 환경을 샘플링해, 미리 계산된 값을 전달하고, 각 클라이언트가 동일한 방식으로 로컬에서 주어진 같은 값으로 시뮬레이션을 실행하게 설계했습니다.

이 방식으로 싱크 문제를 해결하고, 투사체 움직임을 직접 제어할 수 있게 되었습니다.

문제 인식

일주일 정도 작업을 진행하면서 여러 시스템을 만들었지만, 플레이어 입장에서 테스트를 해보니 한 가지 문제가 명확하게 보였습니다.

결국 또 “장판 피하기” 느낌이었습니다. 이게 나쁜 건 아니지만, 적어도 환경을 인지하며 스킬을 사용하고, 모든 적들이 스킬을 난사하는 것 보다는, 일반적인 전투형 적들도 함께 출현시키고 싶었습니다.

문서상으로는 마법 같고, 제대로 작동된다면 이 과정을 건너 뛸 수 있게 도울 네이티브는 존재했지만. 앞서 말씀드렸다시피, 아쉽게도 어떠한 상황에서도 디싱크나 디스폰이 너무 자주 발생하여, 사용할 수 없어서 눈물을 닦으며 뇌를 직접 만들기로 결정을 내리게 되었습니다.

초기 발전 단계

처음에는 단순하게 시작했습니다.

플레이어를 감지하고, 살아있는지 확인하고, 직선으로 따라가는 정도였습니다.

그 다음에는 따라오고 거리내에 있으면 단순히 공격을 하고, 멀어지면 다시 따라가고.

플레이어가 가까워지면 물러나게, 거리에 따라 행동이 바뀌게끔 상황 인지->행동 태스크들을 만들면서 시작하면서 조금씩 가능성이 보이기 시작했습니다.

기존 네이티브에 의존하지 않고, 어느 정도 직접 원하는 방식으로 제어할 수 있다는 점에서 의미가 있었습니다.

이후 공격이 불가능한 위치면 위치를 재정비하게끔, 가끔은 플레이어의 사각지대로 움직이게 등, 조금씩 인지와 행동을 쌓아 나갔습니다.

복잡도 증가 & 디버깅

하지만 또 다시, 문제는 금방 드러났습니다.

처음 만든 움직임은 기본적으로 직선 이동에 가까웠고, 적들은 벽에 걸리거나, 플레이어에게 접근하는 과정에서 서로 뭉치거나, 같은 위치를 향해 몰려드는 경우가 많았습니다. 겉으로 보기에는 움직이고는 있지만, 실제 전투에서는 금방 “지능이 낮다”는 느낌이 들 수밖에 없었습니다.

그래서 적의 판단에 공간 인식 정보를 추가하기 시작했습니다. 단순히 “플레이어가 어디에 있는가”만 보는 것이 아니라, 적 주변에 타일을 만들고, 플레이어와 적 사이에 시야가 확보되는 위치가 어디인지 확인하고, 주변에 가상의 고리를 만들어 후보 지점들을 평가하는 방식으로 확장했습니다.

쉽게 말하면, 적이 단순히 A 지점에서 B 지점으로 따라가는 것이 아니라, 주변에 어떤 위치들이 있고, 어디로 이동하면 플레이어를 볼 수 있는지, 어디로 가면 너무 가까워지는지, 어디가 더 나은 선택지인지 판단할 수 있도록 정보를 만들어주는 과정이었습니다.

하지만 이 단계부터 시스템은 빠르게 복잡해졌습니다. 적이 보고 있는 후보 위치, 시야 판정 결과, 거리 계산, 이동 가능성, 타겟과의 관계 같은 값들이 한 번에 쌓이기 시작했고, 어느 순간부터는 코드만 보고는 내부에서 무슨 일이 일어나고 있는지 판단하기 어려워졌습니다.

그래서 결국 이 정보들을 눈으로 확인할 수 있는 디버깅 도구까지 만들 수 밖에 없게 되었습니다. 적 주변의 타일, 시야가 확보된 위치, 후보 지점, 현재 판단에 사용되는 값들을 직접 시각화해야만 제대로 테스트하고 수정할 수 있었습니다.

툴이 존재하지 않는 부분이 FiveM 개발에서 특히 피로도가 높은 지점입니다. 단순히 로직만 만드는 것이 아니라, 개발을 하기 위한 개발 도구를 함께 병행해서 개발해야하는 경우가 상당히 많습니다.

마무리

갑작스럽게 작성한 만큼 갑작스럽게 마무리한거 같습니다. 처음이라 생각 정리도 안되고, 준비를 하고 작성한게 아니라 자료도 부족할 뿐더러, 두서도 좀 없었습니다...

공유드리고 싶은 내용이 많아 더더욱 그런거 같습니다. 아직도 이야기드리고 싶은 부분들은 많이 남아 있지만, 너무 길어지면 오히려 읽기 부담이 되고 더더욱 정신 없을 거 같아, 다음부터는 주제를 조금 더 타이트하게 잡고, 좁은 범위안에서 집중적으로 정리해보려고 합니다.

이 글을 쓰는 지금 시점, 미세한 설정값 조절, 그리고 인지, 행동, 그리고 스킬 시스템을 하나로 연결하는 단계까지 와 있고, 실제 환경에서 테스트를 진행하기 직전 단계에 있습니다. 이 부분이 제대로 연결되면, 지금까지 말씀드린 내용들이 실제 플레이 경험으로 이어질 수 있는 구간이 될 것 같습니다.

아직 다듬어야 할 부분들도 남아 있지만, 가까운 업데이트를 통해 직접 경험해보실 수 있도록 준비하고 있습니다.

앞으로도 이런 형태의 개발자 노트를 통해, 종종 진행 상황을 공유드릴 수 있도록 하겠습니다.

긴 글 읽어주셔서 감사드리며, 모두 좋은 주말보내시기 바랍니다.

PS. 내 자신에게 메모: 개발자노트를 위해 초기 개발 단계 스크린샷과 동영상을 평소에 많이 남겨두자...