새로운 일주일은 새로운 출발입니다. 지난주에서 이번 주로 넘어오며 발로란트 가족과 커뮤니티가 기하급수적으로 늘어났습니다. 한국과 라틴 아메리카, 브라질 플레이어 여러분께서 클로즈 베타에 참여하시는 모습을 보니 매우 기쁩니다! 환영합니다! 이제 발로란트를 플레이해보셨으니 수많은 궁금증이 생겼을 텐데요. 앞으로 차차 풀어드리도록 하겠습니다.

오늘은 큼직한 주제 세 개를 다루고자 하니 서론은 짧게 하겠습니다. 첫 번째 주제는 저희의 주요 관심사인 피커스 어드밴티지입니다. 구체적으로는 모퉁이 뒤에서 나타난 적이 달리는 중인데도 정확하게 사격하는 것처럼 보이는 상황을 살펴보고자 합니다. 발로란트의 기술 엔지니어링 리드 데이비드 스트레일리가 이러한 현상에 대해 설명해드립니다.

안녕하세요! 바로 시작해보겠습니다.


========================================================================


---- 피커스 어드밴티지 ----
인류가 빛의 속도보다 빠르게 움직이는 방법을 발견하지 않는 한 피커스 어드밴티지는 불가피합니다. 모든 게임에서 발생하는 보편적인 현상입니다. 하지만 발로란트에서는 최대한 줄이는 게 목표입니다. 철학적 관점에서는 피커스 어드밴티지가 덜 발생할수록 더욱 전술적인 메타가 형성되리라고 생각합니다.

피커스 어드밴티지는 어떻게 측정하나요?

계산식: <상대의 클라이언트 프레임률> + <상대의 단방향 네트워크 지연> + <서버 프레임률> + <플레이어의 단방향 네트워크 지연> + <네트워크 보간 지연>

여기서 일부 수치는 고정되어 있습니다.

네트워크 보간 지연 = 7.8125밀리초 (화면에 출력되는 적의 위치가 부드럽게 바뀌도록 해주는 작업에서 발생하는 지연 시간입니다. 인터넷 연결이나 대역폭이 이상적이지 않으면 설정 화면에서 ‘네트워크 버퍼링’으로 조정할 수 있습니다.)

서버 프레임률 = 7.8125밀리초 (1/128초, 128틱 서버)

다른 수치는 가변적입니다.

단방향 네트워크 지연은 게임 서버의 위치, 플레이어와 상대의 지리적 위치, 라이엇 다이렉트의 라우팅 경로에 따라 달라집니다. 지연 시간이 17.5밀리초 미만인 플레이어가 전체의 70%를 차지하는 수준을 목표로 하고 있는데요. 클로즈 베타는 테스트와 개선을 위한 시간이며 현재 목표 달성에 점점 가까워지는 중입니다.

클라이언트 프레임률은 사용하시는 컴퓨터의 속도에 따라 다르며 프레임률 최적화를 위해 개발자로서 할 수 있는 노력을 다하고 있습니다.

위의 수치를 모두 더하면 각도를 확보한 플레이어가 상대에게 접근할 때 우위를 누릴 수 있는 시간이 나옵니다. 해당 시간 동안은 상대에게 보이지 않는 채로 상대를 볼 수 있죠.

연구 결과(영문 링크)에 따르면 인간의 평균 반응 속도는 약 247밀리초라고 합니다. 발로란트에서 피커스 어드밴티지는 평균 40~70밀리초 수준이지만, 아무리 낮더라도 여전히 한 쪽이 유리하다는 점은 마찬가지죠.

---- 이동 사격 ----
플레이하다 보면 간혹 달리고 있는 듯한 상대에게 처치당하는 상황이 발생할 수 있습니다. 하지만 상대는 사실 서버상에서뿐만 아니라 상대의 관점에서도 정지한 상태입니다.

이러한 문제가 있다는 점을 인지하고 있으며 현재 개선 방법을 모색하는 중입니다.

우선 배경 설명부터 드리겠습니다.

움직임과 피해량 데이터 사이에는 네트워크 보간 지연으로 인해 (앞선 부분의 첫 단락을 참고해주세요) 7.8125밀리초의 간격이 발생합니다. 달리 말해 처치당했을 때 보이는 상대의 위치는 사격이 실제로 이루어진 순간이 아니라 7.8125밀리초 전의 위치입니다.

이러한 현상 때문에 상대가 가만히 서서 사격했음에도 불구하고 이동 중 사격한 것처럼 보일 수 있습니다. 이동 중 순간적으로 정지해 사격하는 기술을 효과적으로 사용하는 경우 더 두드러지는 문제입니다. 보통 정지한 직후 몇 프레임 내로 사격하도록 근육 기억이 단련되어있기 때문이죠.

그렇다면 개발자로서 어떤 조치를 하고 있나요?

A) 문제의 원인을 이해하기 위해 움직임 및 사격 정확도와 관련된 요소를 전체적으로 검토하고 있습니다. 달리면서 사격하는 기술을 연습하면 정확도를 지나치게 빠르고 큰 폭으로 향상할 수 있어서 발생하는 문제인지, 특정 상황에서 이동 사격 시 정확도가 의도한 수준보다 실제로 높아지는지 등을 살펴볼 예정입니다. 변경사항이 준비되면 패치 노트에서 확인하실 수 있습니다.

B) 애니메이션 블렌딩 처리를 개선하는 작업을 진행하고 있습니다. 플레이어가 멈췄을 때 ‘달리기’ 애니메이션에서 ‘정지’ 상태로 전환되는 속도를 높이고자 하는데요. 지금은 애니메이션이 ‘실제 상황’보다 뒤처지는 경우가 가끔 발생합니다.

C) 사망하는 순간의 프레임에서는 (보통) 캐릭터 모델이 적을 가리기 때문에 사망 직후 상대가 무엇을 하는지 볼 수가 없습니다. 다음이나 다다음 패치에서 이를 수정해 적을 계속 시야에 둘 수 있도록 하고자 합니다. 그러면 적이 움직이다가 실제로 멈췄는지 확인하는 데 도움이 되겠죠.

D) ‘사망’ 알림은 보통 시간별 움직임 데이터보다 일찍 플레이어의 컴퓨터에 도착합니다. 사망을 몇 밀리초 ‘지연’하면 처치당했을 때 상대가 (서 있었는지 등) 실제로 무엇을 하고 있었는지 볼 수 있습니다. 다만 단점은 이러한 ‘지연’ 시간 동안... 삶과 죽음의 경계에 놓여 이미 사망했음에도 불구하고 시간의 흐름을 동기화하기 위해 삶이 거짓으로 연장된다는 점입니다.

E) 클라이언트에 원격 보간 지연을 ‘비활성화’하는 설정을 추가하는 방안도 고려해볼 수 있습니다. 그러면 7.8125밀리초의 지연을 없앨 수 있지만, 패킷 손실로 인한 ‘플레이어 순간이동’이 잦아진다는 대가가 따릅니다. 평균적인 패킷 손실률은 상황에 따라 다르지만, 1~3% 정도는 흔하게 발생합니다. 그 정도에서는 최대 1초에 한 번꼴로 순간이동이 발생할 수 있습니다. 이상적이지 않죠. 우선 A와 B 안을 시도해보고 (추가로 기타 작은 조정도 살펴볼 수 있습니다) 결과를 살펴본 뒤 E 안처럼 극단적인 조치가 필요한지 검토할 계획입니다.

글이 장편 소설만큼 길어질 위험을 무릅쓰고 한 가지 더 말씀드리고자 합니다.

---- 핑이 높은(지연 시간이 긴) 플레이어가 피커스 어드밴티지를 악화시키나요? ----
예. 안타깝게도 인터넷의 원리상 그럴 수밖에 없습니다.

---- 핑이 높은 플레이어가 유리한가요? ----
간단히 말씀드리자면, 유리하지 않습니다. 거의 모든 상황에서 핑이 낮은 쪽이 유리합니다. 지연 시간이 더 짧은 플레이어의 행동이 상대의 행동보다 먼저 게임 서버에 도달하기 때문이죠.

다만, 핑이 높은 플레이어가 있다면 모든 플레이어가 심한 피커스 어드밴티지를 겪습니다. 핑이 높은 플레이어가 그렇듯 핑이 낮은 플레이어도 핑이 높은 상대를 먼저 볼 가능성이 똑같이 생기는 거죠.

즉, 경쟁 조건이 공평하기는 하지만, 모두의 게임 경험이 악화됩니다. (** 아래에서 예외를 참고해 주세요.)

팁: 플레이어간 핑의 차이가 큰 게임에서는 공격적인 플레이를 하세요.

핑이 높은 상태에서 게임을 플레이하는 것이 이상적인 상황은 아니지만, 클로즈 베타 플레이어의 수가 제한적이고 아직 기반 시설을 준비해가는 중이기 때문에 단기적으로는 이 상황이 계속될 것입니다. 저희는 모든 플레이어 여러분이 낮은 핑으로 게임을 플레이하시길 바라고 있으며 이를 위해 앞으로 계속해서 개선 작업을 이어가고자 하니 지켜봐 주시길 바랍니다.

** 참고: 피커스 어드밴티지는 핑이 높은 플레이어의 지연 시간이 양방향으로 대칭적일 때 모두에게 똑같이 적용됩니다. (즉, 클라이언트->서버의 지연 시간과 서버->클라이언트의 지연 시간이 같을 때를 말합니다.)

서버까지 도달하는 지연 시간이 긴 반면 클라이언트에 도달하는 지연 시간은 짧은 경우, 해당 플레이어가 피커스 어드밴티지로 더 유리할 수 있습니다.

발로란트 개발팀에서는 이 상황이 바람직하지 않다고 생각합니다. 비대칭적 지연 시간은 부분적으로는 라이엇이 개선해야 하는 영역(저희 게임 서버로 도달하는 라우팅 경로를 더 최적화할 필요가 있습니다)이며, 부분적으로는 렉 스위치 등의 플레이어 부정 행위로 초래되는 현상이기도 합니다.


========================================================================



아직 안 가셨군요! 그럼 이제 발로란트 경쟁전 팀의 프로덕트 매니저 이안 필딩이 발로란트의 랭크 게임에 대한 정보를 말씀드리고 라이엇 게임즈 직원이라면 익숙한 질문에 답해드리고자 합니다.

발로란트의 랭크 게임에서 사전 구성 팀의 인원수에 제한이 없는 이유는 무엇인가요? 왜 진정한 개인전은 없나요? (한국 지역에도 곧 경쟁전 모드가 도입될 예정입니다.)

발로란트의 대전 검색에서는 팀플레이가 핵심이어야 한다고 생각합니다. 게임의 전반적인 숙련도에서 팀으로 플레이하는 능력이 중요한 부분을 차지한다고 믿기 때문입니다. 함께 좋은 성적을 내는 팀원이 있는데 의욕을 잃게 하고 진정한 실력은 개인전에서 드러난다는 분위기가 형성되는 상황을 피하고자 했습니다.

개인 랭크 게임이 있으면 해당 모드가 실력을 시험하는 ‘공인’ 수단이자 경쟁적인 플레이를 즐기는 주된 수단으로 자리 잡을 가능성이 큽니다. 그렇게 하지 않고 사전 구성 팀의 인원수에 제한을 두지 않기로 했습니다. 또한 경쟁전을 위한 좋은 팀원을 지금 찾을 수 있으면 나중에 큰 대회가 열렸을 때 이미 믿을 수 있는 팀원이 있다는 장점이 있습니다.

혼자 또는 두세 명의 팀원과 함께 플레이하시는 경우 대전 검색 시 되도록 비슷한 크기의 사전 구성 팀과 매칭되게 했습니다. 또한 최고 랭크 외에서는 랭크 상승 또는 하락에 약간의 영향을 끼치는 ‘성적’ 점수가 적용됩니다. 따라서 특별히 좋은 성적을 내서 팀의 승리에 매우 크게 기여했다면 랭크 상승이 빨라집니다.

높은 성적을 받으려면 KDA(킬/데스/어시스트 비율)를 극대화해야 한다고 느끼는데 그렇게 해도 팀이 승리하지 않는 상황이 있다고 우려를 보내주신 플레이어도 있었습니다.

여기서 랭크에 가장 큰 영향을 미치는 요소는 게임의 승패라는 점을 명확히 하고 싶습니다. 승리 외 다른 목표(KDA와 같은 목표)를 추구하다가 대전에서 계속 패배할 경우 랭크는 하락세를 보일 겁니다.

경쟁전 모드가 도입되었는데 이후 계획은 어떻게 되나요?

발로란트 클로즈 베타 중 초기에 경쟁전 대전 검색을 도입하고자 했던 이유 중 하나는 플레이어 여러분과 소통하며 게임 모드를 함께 만들어나가는 과정을 시작하고 싶었기 때문입니다. 벌써 좋은 피드백을 많이 받았으며 올여름 경쟁전 모드의 정식 출시 때 적용할 변경사항을 적극적으로 살펴보고 있습니다.

현재 단기적으로 집중하고 있는 부분은 배치 게임을 친구와 함께 플레이하기 쉽게 하는 작업과 랭크 아이콘의 명확성을 개선하는 작업입니다. 장기적으로는 랭크 진척도와 더불어 보내주시는 피드백을 참고해 다른 추가 기능도 살펴볼 계획입니다. 여기에 대해서는 이후 더 자세히 말씀드리겠습니다!



========================================================================


마지막으로 뱅가드에 대해 이야기하길 좋아하는 발로란트의 부정행위 방지 리드 폴 체임벌린이 이번 주 플레이어 여러분의 의견에 어떻게 귀 기울이고 있는지 공유해 드립니다.

보안에 대한 뱅가드의 접근법이 지나치게 엄격하다는 플레이어 여러분의 의견을 듣고 다른 접근법을 시도하고 있습니다. 지난주부터 취약 소프트웨어 패키지와의 호환성이 확대되었습니다. 몇몇 드라이버는 여전히 차단되고 있지만, 지금까지 뱅가드가 차단했던 소프트웨어 중 대부분이 뱅가드가 설치된 컴퓨터에서 제대로 작동하게 될 것입니다.

앞으로는 가능한 범위 내에서 보안 문제에 대해 공격적이지 않은 방법을 우선하려고 합니다. 뱅가드, 발로란트, 그리고 희귀한 RGB 드라이버가 함께 공존할 수 있는 방법을 찾으면서 말이죠. 이 모두가 함께 작동할 수 있는 방법을 찾을 수 없다면 플레이어의 다른 소프트웨어들을 비활성화하기보다는 발로란트를 비활성화할 것입니다. 플레이어의 컴퓨터에서 다른 소프트웨어를 비활성화하는 경우는 정말 최악의 상황에서만 발생할 것입니다.

저희는 계속해서 뱅가드를 개선하고 있으며 좋은 결정을 내리기 위해서는 여러분의 의견이 필요합니다. 발로란트의 부정행위 방지 노력에 대해 어떻게 생각하시는지 들려주세요. (부정행위자들을 제외한) 모든 플레이어 여러분을 만족하게 해 드리기 위해 최선을 다하겠습니다.


========================================================================


오늘은 알려진 문제 부분을 생략하고자 합니다... 글 전체가 알려진 문제를 다루었으니까요. (클라이언트 초당 프레임 수 감소 문제는 적극적으로 해결 방법을 모색 중입니다!) 그럼 다음 주에 뵙겠습니다! :)