안녕하세요. 이번 주 빅토리아 3 개발일지에 오신 것을 환영합니다. 이번에는 성능과 게임 내부 작동 방식에 대해 조금 이야기하겠습니다. 그 과정에서 다소 상세해질 것이며, 1.2에서 개선된 사항에 주로 관심이 있다면 끝까지 찾을 수 있습니다.

저를 모르시는 분들을 위해 말씀드리면 제 이름은 Emil이고 저는 2018년부터 Paradox에 있었습니다. 이전에 다른 프로젝트에서 같은 역할을 맡았던 저는 2020년에 기술 담당자로 Victoria 3 팀에 합류했습니다.

성능이란 ?

우리가 의미하는 바를 먼저 이해하지 않고 성능에 대해 이야기하기는 어렵습니다. 많은 게임에서 이것은 주로 그래픽 설정을 너무 낮추지 않고도 얼마나 높은 fps를 얻을 수 있는지에 관한 것입니다. 그러나 우리가 PDS에서 만드는 것과 같은 시뮬레이션이 많은 게임에서는 또 다른 측면이 작용합니다. 이른바 틱 속도라 부르는 것입니다. 이 단위는 게임 업계에서 fps처럼 통일된 명칭은 없지만, 몇몇 다른 게임에서 Ticks Per Second 또는 Updates Per Second라는 이름으로 익숙하실 겁니다. 여기서는 대신 역 단위를 사용하거나, 틱이 평균적으로 완료되는 데 걸리는 시간(초 또는 밀리초)을 사용합니다. 일부 그래프는 디버그 버전에서, 일부는 출시 버전에서 가져오므로 숫자를 항상 직접 비교할 수는 없습니다.

인게임 시간이라는 측면에서 정확히 틱이 의미하는 바는 조금씩 다릅니다. CK3 및 EU4에서 1틱은 하루이지만 HOI4에서는 1시간입니다. Victoria 3의 경우 1틱은 6시간 또는 하루의 1/4입니다. 그러나 모든 틱이 동일한 것은 아닙니다. 일부 작업은 다른 작업만큼 자주 수행할 필요가 없을 수 있으므로, 우리는 틱을 카테고리로 나눕니다. Victoria 3에는 연간, 월간, 주간, 일일 및 (일반)틱이 있습니다.

1.1이 느리다고 생각했다면, 출시 1년 전에 게임을 봤어야 했는데…

틱의 내용

Victoria 3는 철저히 시뮬레이션에 기반했으며, 따라서 틱마다 발생해야 하는 많은 작업이 있습니다. 코드를 체계적으로 유지하기 위해 틱을 틱 작업이라고 부르는 것으로 분류했습니다. 틱 작업은 게임 상태에서 수행해야 하는 빈도 및 실행이 허용되기 전에 종속되는 다른 틱 작업에 대한 정보와 함께 수행하는 고유한 작업 집합입니다.

게임의 일부 틱 작업에 대한 개요입니다. 콘솔 명령 TickTask.Graph와 함께 사용할 수 있습니다.

많은 틱 작업은 하나 또는 몇 개의 값을 업데이트하는 작은 작업입니다. 반면에 그들 중 일부는 상당히 방대합니다. 실행 빈도와 작동하는 게임 목표에 따라 게임 속도에 미치는 영향이 달라집니다. 게임에서 가장 렉을 많이 유발하는 작업 중 하나는 고용 업데이트이며, 그 다음으로 팝 수요 캐시 업데이트와 변동치 업데이트가 있습니다.

2월 15일자 야간 테스트에서 가장 비싼 틱 작업 상위 10개. 디버그 빌드를 사용하여 여러 번 실행하여 초 단위로 평균을 낸 수치입니다.

위의 그래프에서 볼 수 있듯이 가장 비용이 많이 드는 틱 작업은 매주 실행됩니다. 이는 주간 틱에 모든 일일 및 틱 작업도 포함된다는 사실과 결합되어 일반적으로 시간이 꽤 오래 걸린다는 것을 의미합니다. 그럼 주간 틱 동안 무슨 일이 일어나고 있는지 좀 더 자세히 살펴보겠습니다. 이를 위해 프로파일러를 사용할 수 있습니다. PDS에서 사용하는 프로파일러 중 하나는 주로 게임 개발을 대상으로 하는 오픈 소스 프로파일러인 Optick입니다.

출시 버전에서 1890년경 주간 틱의 Optick 캡처.

위의 스크린샷에는 많은 일이 진행되고 있으므로 조금만 분해해 보겠습니다. 왼쪽에는 우리가 보고 있는 스레드의 이름이 표시됩니다. 먼저 게임 로직의 메인 스레드인 네트워크/세션 스레드가 있습니다. 시뮬레이션을 실행하고 플레이어 명령에 따라 행동하는 일을 담당합니다. 그런 다음 기본 작업 스레드가 있습니다. CPU의 코어 수에 따라 엔진이 다른 수의 태스크 스레드를 생성하므로 이 수는 머신마다 다릅니다. 여기서는 읽기 쉽도록 인위적으로 8개로 제한했습니다. 작업 스레드는 병렬화할 수 있는 작업을 담당합니다. 그런 다음 기본 스레드가 있습니다. 이것은 게임이 시작될 때 운영 체제에서 생성되는 초기 스레드이며 인터페이스 및 그래픽 업데이트 처리를 담당합니다. 그런 다음 실제 렌더링을 수행하는 렌더 스레드가 있고 마지막으로 보조 작업 스레드가 있습니다. 기본 로직과 비슷하지만 일반적으로 그래픽 업데이트 지원이나 게임 저장과 같은 비게임 로직을 담당합니다.

텍스트가 있는 모든 색상 상자는 프로파일러에 표시할 만큼 충분히 흥미롭다고 생각한 코드의 다른 부분입니다. 더 깊이 있는 정보를 원한다면 Superluminal 또는 VTune과 같은 다른 프로파일러를 대신 사용하여 기능 수준 또는 어셈블리를 직접 볼 수 있습니다.

분홍색 막대는 스레드가 무언가를 기다리고 있음을 나타냅니다. 작업 스레드의 경우 이는 일반적으로 더 많은 작업을 기다리고 있음을 의미하는 반면 세션 스레드의 경우 일반적으로 인터페이스 또는 그래픽 업데이트를 읽어야 하기 때문에 게임 상태 수정이 중단되었음을 의미합니다.

틱 속도를 볼 때 우리는 주로 세션 스레드와 기본 작업 스레드에 관심이 있습니다. 여기에서 세션 스레드를 확장하여 주간 틱에서 무슨 일이 일어나고 있는지 확인할 수 있습니다. 여기서 눈에 띄는 것이 있습니다.

먼저 일반적으로 발생하는 빨간색 CScopedGameStateRelease 블록이 있습니다. 인터페이스와 그래픽이 가능한 한 60fps에 가까운 렌더링을 유지하기 위해 필요한 데이터를 읽을 수 있도록 업데이트를 잠시 중단해야 할 때입니다. 그러나 이것은 어디에서나 발생할 수 없으며 틱 작업 사이 또는 틱 작업 내부의 특정 단계 사이로 제한됩니다. 이는 국가 예산의 절반만 업데이트된 경우 인터페이스가 데이터를 가져오지 않도록 데이터 일관성을 보장하기 위한 것입니다.

다음으로 눈에 띄는 것은 위의 그래프에서 볼 수 있는 UpdateEmployment 틱 작업입니다. 여기서 우리는 조금 더 많은 정보를 얻습니다. 얼핏 보면 (적어도) 두 부분으로 나뉜다는 것을 알 수 있습니다. 하나의 병렬 및 하나의 직렬. 이상적으로 우리는 최신 CPU를 더 잘 활용할 수 있기 때문에 모든 작업이 병렬로 수행되기를 원합니다. 아쉽게도 고용 중에 진행되는 모든 작업을 병렬로 수행할 수는 없습니다. 팝 개체 생성 및 소멸, 스크립트 실행과 같은 전역 작업을 수행해야 하기 때문입니다. 그래서 직렬 부분을 최대한 줄이기 위해 가능한 한 병렬 사전 단계로 나누었습니다. 실제로 여기 사이에 너무 빨라서 볼 수 없는 세 번째 단계가 있습니다.

UpdateEmployment 틱 작업을 자세히 살펴보십시오.

변동치(모디파이어)는 느립니다

PDS 게임 전체에서 공통적인 한 가지 개념은 변동치이며 Victoria 3도 예외는 아닙니다. 정반대로, 크킹3와 비교할 때 변동치 설정은 훨씬 더 복잡합니다. 이를 관리하기 위해 변동치 노드라고 하는 Stellaris와 유사한 시스템을 사용합니다. 본질적으로 그것은 변동치를 더티로 표시하고 그것과 그것에 의존하는 다른 변동치만 재계산할 수 있게 해주는 종속성 관리 시스템입니다. 변동치를 다시 계산하는 데 다소 비용이 많이 들기 때문에 이는 매우 유용합니다.

그러나 이 시스템은 매우 단일 스레드였기 때문에 틱의 상당 부분이 여전히 변동치를 업데이트하는 데 사용되었습니다. 이 개발일지 상단의 그래프를 보면 2022년 초에 성능이 상당히 빠르게 향상되었음을 알 수 있습니다. 이에 대한 주요 원인 중 하나는 변동치 노드 계산의 병렬화였습니다. 어떤 노드가 어떤 노드에 의존하는지 알고 있으므로 각 배치가 이전 배치에만 의존하는 배치로 노드를 나눌 수 있습니다.

RecalculateModifierNodes 틱 작업을 자세히 살펴보십시오.

국가는 모든 규모에서 이용됩니다.

한 틱 안에 진행되는 많은 작업이 세계의 모든 국가에서 수행되어야 합니다. 그러나 룩셈부르크와 같은 작은 나라와 러시아와 같은 큰 나라 사이의 엄청난 규모의 차이로 인해 일부 작업은 때때로 다른 나라에 비해 한 나라에서 100배 이상 오래 걸릴 것입니다. 일련의 작업을 수행할 때 모든 작업이 발생해야 하고 어떤 작업을 먼저 수행하는지는 실제로 중요하지 않기 때문에 이것은 실제로 중요하지 않습니다. 그러나 병렬화를 시작할 때 너무 많은 큰 국가가 동일한 스레드에 있는 문제에 직면할 수 있습니다. 즉, 모든 스레드가 작업을 완료한 후에도 이 마지막 스레드가 완료될 때까지 기다려야 합니다. 이 문제를 해결하기 위해 우리는 틱 작업이 업데이트의 각 부분에 대한 휴리스틱 비용을 지정할 수 있는 시스템을 마련했습니다.

이것이 큰 차이를 만드는 한 곳은 국가 예산 업데이트입니다. 중국, 러시아 및 영국이 모두 동일한 스레드에서 업데이트되지 않아도 예산 업데이트에 필요한 시간이 크게 줄어듭니다.

(그리고 이것이 세계 정복을 플레이하는 동안 게임이 느리게 실행되는 이유이기도 합니다!)

WeeklyCountryBudgetUpdateParallel 틱 작업을 자세히 살펴보십시오. 비싼vs값싼 작업이 어느것인지에 유의하세요.

1.2의 개선 사항

많은 분들이 관심을 갖고 계신 부분이 아닐까 추측해 봅니다. 크고 작은 많은 개선이 있었습니다.

지금까지 오픈 베타에 주의를 기울였다면, 건설 대기열과 관련된 몇 가지 인터페이스 변경 사항을 알아차렸을 것입니다. 얼마나 많은 사람들이 게임을 하느냐에 따라 대기열이 상당히 커질 수 있습니다. 불행하게도 여기의 이전 인터페이스는 요소를 적절하게 배치하기 위해 모든 요소의 크기를 계산해야 하는 위젯 유형을 사용하고 있었습니다. 화면에 보이지 않는 요소를 포함해서요.

새로운 건설 대기열 인터페이스.

이 문제를 더욱 복잡하게 만드는 것은 대기열에 있는 건설이 완료될 때까지의 시간과 같은 것을 계산하기 위해 서로 많은 종속성을 가졌습니다. 이 문제도 해결되었으며 오늘의 베타 버전에서 사용할 수 있습니다.

기존 건설 대기열과 새 건설 대기열을 나란히 비교해봅시다.

틱 속도에 대한 한 가지 큰 개선 사항은 그래픽 업데이트에 대한 변경 사항의 결과입니다. 후반 게임에서 지도를 업데이트하는 데 많은 시간이 걸리고, 게임 로직이 그래픽 업데이트를 많이 기다려야 하는 경우가 있습니다. 그래픽 업데이트에 필요한 시간을 줄이기 위해 엔진이 개선되고 게임의 코드가 변경되었습니다. 여기에는 지도 이름 업데이트의 스레딩 개선, 공중 엔티티//구름 같은거// 업데이트 최적화, 도시 그래픽에서 건물이 표시되어야 하는 위치를 찾는 데 필요한 작업 감소가 포함됩니다.

최적화 전/후 그래픽 업데이트.

위에서 언급했듯이 고용 업데이트는 성능에 상당한 영향을 미칩니다. 이것은 게임의 팝 수와 매우 밀접한 관련이 있습니다. 총 인구가 아니라, 개체 수(팝 집단 수)에 따라서요. 특히 게임 후반에 고용 업데이트를 극도로 느리게 만드는 많은 수의 작은 팝이 넘쳐나는 상황으로 수렴할 수 있습니다. 이 디자인을 완화하기 위해서, 후반 게임 성능을 개선하기 위해 작은 팝을 더욱 공격적으로 병합하도록 조정했습니다. 모더의 경우 POP_MERGE_MAX_WORKFORCE 및 POP_MERGE_MIN_NUM_POPS_SAME_PROFESSION 정의를 이용하여 변경할 수 있습니다.

1.2에서 수행한 또 다른 개선 사항은 클라우제비츠 엔진에서 메모리 할당을 수행하는 방식을 변경한 것입니다. 특별한 경우(풀 할당자, 게임 개체 "데이터베이스" 등)를 위한 전용 할당자가 항상 있었지만 운영 체제에 따라 기본 할당자로 끝나는 할당이 여전히 많았습니다. 특히 Windows에서는 속도가 느릴 수 있습니다. 이를 해결하기 위해 이제 mimalloc이라는 라이브러리를 사용합니다. 매우 성능이 뛰어난 메모리 할당자 라이브러리이며 기본적으로 운영 체제에서 제공하는 기능을 대체합니다. Unreal Engine과 같은 다른 대형 엔진에서 이미 사용되고 있습니다. 위의 두 가지만큼 중요하지는 않지만 1년 동안 타임라인의 약 2/3에서 측정했을 때 게임 실행 속도가 약 4% 더 빨라졌습니다.

이러한 더 큰 변경 사항 외에도 많은 작은 개선 사항이 함께 추가되었습니다. 전체적으로 게임은 아래 그래프에서 볼 수 있듯이 1.1에 비해 1.2에서 눈에 띄게 빨라야 합니다. 불행히도 하룻밤 사이에 진행한 1.1 테스트는 1.2만큼 안정적이지 않았기 때문에, 명확성을 위해 그래프를 1871에서 잘라냈지만 일반적으로 1.2의 성능 향상은 게임 후반에 훨씬 더 눈에 띕니다.

1.1과 1.2 사이의 틱 시간을 매년 비교하면 1.2가 훨씬 빠릅니다. 숫자는 디버그 빌드를 사용하여 몇 주 동안 여러 야간 테스트의 연간 평균입니다.

이번 주에는 이게 전부입니다. 다음 주에 Nik은 새로운 전략적 목표 기능을 포함하여 1.2에서 전쟁 역학에 적용된 다양한 개선 사항을 알려드릴 것입니다.

스웨덴에도 야근이라는게 존재했음? 충격이다.

뭔가 어려운 용어가 한가득 나와서 솔직히 뭔소린지 잘 모르겠더라. 구구절절한거 빼고 요약하면 게임 후반에 작은 팝들 훨씬 잘 없어지고, 기타 등등 수정으로 렉이 크게 줄어들었다고 함.