All Under Heaven 업데이트를 출시했을 당시, 저희는 이곳의 [개발자 일지 #187 - 성능 및 최적화]에서 성능 개선 작업에 관한 소식을 전해드렸습니다. 해당 업데이트에서는 앞으로 크루세이더 킹즈 3에서 이루고자 하는 몇가지 목표와 바람도 함께 소개해 드렸습니다. 그리고 이번 개발자 일지에서는 By God Alone 업데이트를 앞둔 지금, 그 목표들이 어느 정도까지 이루어졌는지 정리해 보려 합니다.

다시 인사드립니다. 저는 크루세이더 킹즈 3 팀의 수석 프로그래머 카를 헨리크입니다. All Under Heaven 출시 무렵, 저는 조만간 로딩 화면의 속도를 높이고 여러 다른 시스템도 개선하겠다고 말씀드렸습니다. 이번 개발자 일지에서는 바로 그 작업에 관해 이야기하고, 이와 함께 일일 시뮬레이션 성능이 어떻게 개선되고 있는지, 그리고 게임을 플레이하는 동안 얼마나 많은 메모리를 점유하는지도 살펴보겠습니다.

이 글은 By God Alone 출시를 몇 주 앞둔 시점에 공개되며, 저희는 지금도 각종 시스템을 더욱 개선하기 위해 열심히 작업하고 있습니다. 이 기간에는 어떤 변화든 일어날 수 있으므로, 여기서 제시하는 수치가 최종 결과와 달라질 수도 있다는 점을 염두에 두시기 바랍니다. 다만 현재 상황은 이렇습니다.

선요약

요약만 보고 싶으시다면 다음과 같습니다.

• 시뮬레이션 속도: 일일 시뮬레이션 성능은 이전 편의성 업데이트인 1.19.0 "Scribe"와 동일한 수준을 달성하는 것을 목표로 하고 있습니다. 현재도 이미 그 수준에 근접했으며, 최종적으로도 비슷한 수준에 도달할 것으로 예상합니다.
• 게임 시작 시 불러오는 데이터의 양이 크게 줄었습니다. 예를 들어 저희의 저사양 테스트 컴퓨터에서는 시작할 때 모든 것을 한꺼번에 불러오는 대신 메시와 일러스트레이션을 스트리밍하도록 변경하면서 메인 메뉴까지 걸리는 시간이 크게 단축되었습니다. 제 컴퓨터에서는 84초에서 16초로 줄었습니다.
• 동일한 장면에서 비디오 메모리 사용량 역시 크게 감소했습니다. 텍스처 품질 설정에 따라 차이가 있지만, 약 3분의 1에서 절반가량 감소했습니다.
• 게임 시작 후 10년이 지난 시점의 시스템 메모리 사용량은 약 6분의 1 감소했습니다.

아래부터는 이에 대한 자세한 설명입니다.

측정

현재 어느 수준에 도달했는지, 그리고 저희의 최적화가 실제로 효과가 있는지를 파악하려면 성능을 신뢰할 수 있는 방식으로 측정해야 합니다.

시뮬레이션 속도는 100년 동안 하루를 시뮬레이션하는 데 걸리는 평균 시간으로 측정합니다. 일관된 테스트 결과를 얻기 위해 1066년부터 측정을 시작하여 적어도 1166년까지 계속 진행합니다. 시간이 흐를수록 갱신해야 할 요소가 점점 늘어나기 때문에, 때로는 게임을 밤새 실행하여 게임 후반부의 성능이 어떻게 변화하는지도 살펴봅니다.

무작위 시드와 모든 개발자가 매일 적용하는 변경 사항 때문에 각 테스트 결과는 이전 테스트와 조금씩 달라집니다. 따라서 측정할 때마다 어느 정도의 편차가 발생하며, 저희는 이를 감안하여 결과를 살펴봅니다.

[게임을 실행하여 메인 메뉴까지 불러오는 데 84초가 걸리는 "이전" 성능 측정]

일일 틱 성능을 측정할 때마다 시작 시간도 함께 확인합니다. 그러던 중 한 가지 발견한 사실이 있습니다. 게임에 더 빨리 들어가 플레이를 시작하고 싶다면 Linux가 Windows보다 훨씬 뛰어나다는 것입니다!

시뮬레이션 속도

그렇다면 하루를 처리하는 데 얼마나 걸릴까요?

저희는 비교적 사양이 낮은 기준 테스트 컴퓨터를 사용합니다. 2012년에 출시된 8코어 CPU와 16GB RAM을 탑재한 컴퓨터인데, 게임이 어느 정도 진행된 이후에도 하루를 처리하는 데는 1초도 채 걸리지 않습니다. 대부분의 날은 평균보다 빠르게 처리되지만, 그중 일부는 처리하는 데 훨씬 오랜 시간이 걸립니다. 바로 무언가 큰일이 벌어지는 날들입니다. 이런 날의 처리 지연은 게임이 전반적으로 느려지는 것이 아니라 순간적인 끊김 현상으로 체감됩니다.

게임 내에서 시간이 흐를수록 처리해야 하는 연산량도 증가합니다. 1070년대에서 1160년대 사이에는 하루를 처리하는 데 필요한 평균 연산량이 1.5배를 조금 넘는 수준으로 증가합니다.

그렇다면 처리 시간은 어디에 쓰일까요? 100년 동안 게임을 실행했을 때를 대략적으로 살펴보면 다음과 같습니다.

• AI의 결단에 하루 처리 시간의 4분의 1을 조금 넘게 사용합니다.
• 각 시스템이 앞으로 어떤 사항을 변경할지 계산하는 병렬 사전 업데이트에는 약 4분의 1을 사용합니다.
• 계산된 변경 사항을 실제로 적용하는 순차 업데이트에는 약 5분의 1을 사용합니다.
• 그리고 이벤트를 발생시키는 데에는 10분의 1을 조금 넘게 사용합니다.

By God Alone의 목표는 이전 편의성 업데이트인 "Scribe" 패치와 동일한 수준의 일일 시뮬레이션 속도를 제공하는 것입니다. 이 글을 작성하는 현재는 그 수준에 충분히 근접했기에 이렇게 공개적으로 말씀드려도 되겠다고 생각합니다. 다만 여기서 구체적인 수치를 제시하지는 않겠습니다. 출시를 앞둔 마지막 몇 주 동안에는 그 수치가 좋아지기도 하고 나빠지기도 하기 때문입니다.

[100년 동안의 항목별 평균 일일 처리 시간]

매일의 처리는 사전 업데이트, 업데이트, AI 업데이트 순으로 이루어집니다.

사전 업데이트에서는 인물과 변화 요소가 가장 큰 비중을 차지하는데, 이는 예상했던 결과입니다. 여러분이 함께하거나 맞서 플레이하는 대상이 바로 이들이니까요! AI 업데이트에서는 인물 상호작용을 평가하는 작업이 가장 큰 비용을 차지하며, 이번 프로젝트를 진행하면서 가장 크게 늘어난 부분이기도 합니다. 7월의 몇 주 동안 교회와 관련된 새로운 상호작용 콘텐츠가 대거 추가되었는데, 새로운 상호작용이 하나 추가될 때마다 모든 인물이 매달 자신이 그 행동을 할지를 추가로 고려해야 합니다. 상호작용 자체가 콘텐츠의 핵심이므로 이를 없앨 수는 없습니다. 대신 각각의 평가에 드는 비용을 줄이는 데 다시 초점을 맞추고 있으며, 디자인 및 스크립트 측에서도 이 작업을 진행하여 좋은 성과를 거두고 있습니다.

코드를 삭제해서 최적화할 부분을 찾아낼 때의 기분은 정말 좋습니다! "Contributing to Great Projects"는 일정 개월마다 한 번씩만 관련 수치를 고려하도록 검사하는 코드가 있었습니다. 의도 자체는 올바랐지만, 문제는 검사 순서였습니다. 게임은 먼저 "이 통치자가 이 중 어느 것에라도 자금을 댈 수 있는가?"를 계산한 다음에야, 이번 달에 애초에 이를 고려해야 하는지를 확인하고 있었습니다. 단순히 자금 지원 여부를 확인하는 검사를 제거하는 것만으로 전체 과정의 처리 비용을 이전의 4분의 1 수준으로 줄일 수 있었으며, 그 결과도 손쉽게 검증할 수 있었습니다.

80만 번이나 진행한 검사

성능 테스트를 위해 상세한 기록을 남기고 있는 덕분에, 한 번 실행하는 데는 매우 짧은 시간밖에 걸리지 않지만 엄청나게 많이 실행되는 특이한 작업들도 찾아낼 수 있습니다.

불과 며칠 간격으로 기록한 두 성능 측정 결과를 비교하던 중, 별다른 이유도 없이 인물 관리자의 처리 속도가 눈에 띄게 느려진 것을 발견했습니다. 원인을 조사해 보니, 통치자가 자신의 봉역법 가운데 하나를 계속 유지할 수 있는지를 확인하는 함수 하나가 문제였습니다. Scribe 출시 버전에서는 이 검사가 한 달에 약 1,500번 실행됩니다. 그런데 새 버전에서는 한 달에 약 85만 번이나 실행되고 있었습니다.

함수 자체에는 아무런 문제가 없었습니다. 단지 스크립트 변경으로 인해 이 함수가 훨씬 자주 실행되는 위치로 옮겨졌을 뿐이었고, 변경 사항만 살펴봐서는 이를 알아차리기도 어려웠습니다. 코드상으로만 보면 상당히 합리적으로 보였으니까요. 원인이 되는 변경 사항을 단 하나의 커밋으로 좁혀낸 덕분에 스크립트 측에서는 구조를 다시 짜는 데 필요한 정보를 정확히 얻을 수 있었고, 그 결과 이 작업이 전체 일일 틱에서 차지하는 비중은 불과 몇 퍼센트 수준으로 줄어들었습니다.

이 사례 하나만으로도 마지막에 한꺼번에 측정하는 대신 지속적으로 성능을 측정하는 데 들이는 노력이 충분히 가치 있다는 것을 알 수 있습니다. 이 문제를 이틀 만에 발견하는 것과 두 달 뒤에 발견하는 것의 차이는 큽니다. 두 달이나 지나면 이미 모든 것에 깊숙이 자리 잡아 버리고, 애초에 왜 그렇게 만들었는지 기억하는 사람조차 없게 되기 때문입니다.

더 작은 질문 던지기

저희는 어떤 결단을 내리는 데 실제로 필요한 것보다 훨씬 많은 연산을 수행하고 있는 경우를 자주 발견합니다.

가장 대표적인 사례는 새로운 교회 콘텐츠에서 끊임없이 등장하는 검사였습니다. "이 특정 통치자가 이 성직자 관할 구역 안에 있는가?"라는 질문입니다. 이에 답하기 위해 게임은 해당 구역에 속한 모든 통치자의 목록을 만들고, 이를 정렬하고, 중복 항목을 제거한 뒤, 완성된 목록을 호출한 쪽에 돌려주었습니다. 그러고 나면 호출한 쪽에서는 자신이 확인하고자 했던 단 한 명의 통치자가 그 목록에 있는지를 다시 찾아봤습니다. 이 모든 과정은 올바르게 작동했지만, 어느 것도 필요하지 않았습니다.

그 대신 "이 통치자가 이 구역에 있는가, 아닌가?"라고 직접 질문하도록 바꾸자 처리 비용을 10분의 1 이하로 줄일 수 있었습니다.

두 신앙을 비교할 때도 똑같은 형태의 문제가 발견되었습니다. 이전에는 게임이 두 신앙의 교리로 각각 표를 만든 다음, 그 전체를 훑으면서 차이점을 찾았습니다. 하지만 한 신앙에 대해서만 표를 만든 뒤 다른 신앙의 교리를 그 표와 대조하도록 바꾸어도 동일한 작업을 수행할 수 있으며, 속도는 약 3분의 1 더 빨라졌습니다. 이 두 방법 모두 특별히 영리한 것은 아닙니다. 그저 둘 다 불필요한 작업을 덜 할 뿐입니다.

충돌 방지를 위한 비용

이번 사례에서 흥미로운 부분은 애초에 왜 이런 비용이 발생하고 있었느냐는 것입니다.

게임 속의 요소들은 서로를 참조합니다. 인물은 자신의 주군을, 작위는 그 작위의 소유자를 참조하는 식입니다. 게임 충돌이 발생하는 흔한 원인 가운데 하나는 이미 소멸한 대상을 가리키는 참조를 따라가는 것입니다. 이런 문제로 플레이어의 게임이 충돌하도록 내버려 두는 대신, 모든 객체에는 저희가 "nullobject"라고 부르는 작은 식별 표식이 붙어 있습니다. 어떤 참조가 여전히 유효한지를 확인하려면 이 표식이 온전한지를 검사합니다. 그리고 이 검사는 엄청나게 많이 이루어집니다.

기존에는 이 검사를 수행하기에 앞서 컴퓨터가 자신이 다루고 있는 객체가 어떤 종류인지 먼저 찾아봐야 하는 방식으로 구현되어 있었습니다. 이러한 간접 참조 단계를 제거하자 상당한 성능 개선이 이루어졌습니다. 검사가 하는 일도, 내놓는 답도 이전과 똑같지만, 이제는 검사를 시작하기 전에 먼저 길을 물어볼 필요가 없어진 셈입니다. 100년 전체를 실행하는 동안의 모든 연산을 기준으로 약 3%의 성능을 개선할 수 있었습니다. 이번 프로젝트에서 단일 변경 사항으로 거둔 성과 가운데 큰 편에 속하며, 게임의 동작 방식은 전혀 바뀌지 않았습니다.

다른 대가를 치른 수정

얼마 전, 매 틱마다 임시 인물 변화 요소를 정리하는 작업을 병렬 처리 구간에서 빼내 단일 스레드에서 실행하도록 변경하여 충돌 문제 하나를 수정했습니다. 충돌을 없애기 위한 방법으로서는 지극히 합리적이었고, 실제로 문제도 해결되었습니다. 하지만 그 대가로 전체 성능의 약 4%를 조용히 소모하고 있었습니다. 해당 정리 작업 자체는 처리 비용이 매우 낮지만, 모든 작업을 단 하나의 CPU 스레드에서만 처리하도록 제한되어 있었기 때문입니다.

이 작업을 병렬로 실행할 수 없었던 근본적인 이유는 여기에 사용된 메모리 할당자가 여러 스레드에서 동시에 호출해도 안전하도록 만들어져 있지 않았기 때문입니다. 메모리 할당자를 여러 스레드에서도 안전하게 사용할 수 있도록 만들고, 객체를 파괴한 뒤 다시 생성하는 대신 기존 객체를 재사용하도록 변경하자 충돌 문제가 재발하지 않으면서도 작업을 다시 병렬로 처리할 수 있게 되었습니다. 그 결과 해당 틱 처리 단계에 걸리는 시간을 거의 절반으로 줄였습니다.

여기서 얻을 수 있는 교훈은 충돌 문제를 수정할 때 성능에 미치는 영향도 확인해야 한다는 것입니다. 이러한 수정은 대개 시간에 쫓기는 상황에서 이루어지기 때문에, 당장의 문제를 해결하는 방법이 반드시 최선의 방법인 것은 아닙니다.

이 부분을 살펴보던 중에는 인물의 기억, 가문, 의견 등 여러 곳에서 게임이 아주 긴 목록에 있는 수많은 항목을 하나씩 제거하고 있다는 사실도 발견했습니다. 항목 하나를 제거할 때마다 그 뒤에 있는 모든 항목을 한 칸씩 앞으로 옮기고 있었습니다. 이를 한 번의 순회로 모두 제거하도록 변경하는 작업은 오후 한나절이면 끝낼 수 있고, 어떤 그래프에서도 눈에 띄지 않을 정도로 작은 개선이지만, 한 번 적용하고 나면 이후에는 아무런 추가 비용 없이 계속해서 이득을 얻을 수 있는 종류의 개선입니다.

바라보는대로 불러오는 세계

제가 작업을 시작하겠다고 말씀드렸던 부분이 바로 로딩 화면이었으며, 이번 성능 개선에서 가장 눈에 띄는 변화는 이제 게임을 시작하기 전에 모든 것을 불러오지 않는다는 점입니다.

이전에는 실제로 보게 될지 여부와 관계없이 게임에 존재하는 모든 3D 모델을 시작 과정에서 불러오고, 구성한 뒤, 그래픽 카드에 업로드했습니다. 이제는 실제로 어떤 요소가 모델을 필요로 하는 순간에 처음으로 해당 모델을 불러오며, 공간이 필요하면서 해당 모델이 한동안 화면에 그려지지 않은 경우에만 다시 메모리에서 해제합니다.

그러니 세상에 존재하는 유아론자 여러분께서는 기뻐하셔도 좋습니다. 이제 저희 게임은 사물의 영속성에 따라 무언가가 시야에서 사라지는 순간 더 이상 존재하지 않게 되는(메모리상에서 말이죠) 올바른 세계의 형이상학을 정확하게 시뮬레이션하도록 만들었으니까요. ; )

이는 이번 업데이트에서 로딩 시간을 단축한 단일 변경 사항 가운데 가장 큰 것입니다. 저희의 저사양 테스트 컴퓨터에서는 스트리밍을 통해 메인 메뉴까지 걸리는 시간이 약 3분의 2 감소했습니다. 다른 방식으로 측정해 보면, 게임을 시작할 때 구성하는 머티리얼의 수가 이전의 약 3분의 1로 줄었습니다. 나머지는 나중에 실제로 필요할 때 구성되며, 아예 필요하지 않다면 끝까지 구성되지 않습니다.

[메시 스트리밍 디버거: 현재 불러온 항목과 마지막으로 화면에 그려진 후 얼마나 시간이 지났는지를 보여줍니다. 이는 게임의 내부 빌드에서만 사용할 수 있습니다.]

그래픽을 스트리밍하면 팝인 현상이 발생할 위험이 있습니다. 화면을 바라본 뒤 잠시 지나서야 에셋이 나타나는 현상입니다. 저희는 두 가지 방법으로 이 문제에 대응하고 있습니다.

첫째, 이제는 그래픽 카드에 여유 비디오 메모리가 있는 동안 모델을 계속 메모리에 유지합니다. 이전처럼 그래픽 카드에 공간이 얼마나 남아 있는지와 관계없이 정해진 시간이 지나면 해제하지 않습니다. 일반적인 플레이에서는 메모리 사용량이 최신 그래픽 카드가 감당할 수 있는 수준보다 훨씬 낮은 선에서 안정되며, 덕분에 화면을 스크롤할 때 반복해서 시야에 들어왔다 나가는 에셋을 매번 새로 구성할 필요가 없습니다.

둘째, 여러 부분에서 에셋이 화면에 표시되기 전에 미리 준비되어 있도록 했습니다. 예를 들어 알현실을 표시하기 전에 필요한 에셋이 모두 준비되어 있도록 하는 식입니다.

필요할 때 불러오는 일러스트레이션

텍스처에도 같은 방식을 적용했습니다.

크루세이더 킹즈 3에는 이벤트 일러스트레이션, 유물 아이콘, 초상화 세부 마스크 등 매우 많은 2D 아트가 존재합니다. 이전에는 실제로 화면에 표시되는지 여부와 관계없이 이 모든 것이 게임을 플레이하는 내내 비디오 메모리에 상주했습니다. 일러스트레이션 스트리밍을 적용하면서 이제는 무언가가 해당 이미지를 필요로 할 때 불러오고, 화면에 표시되지 않게 된 뒤 얼마 지나지 않아 다시 메모리에서 해제합니다. 이벤트 그림은 여러분이 이벤트를 읽는 동안에만 화면에 표시되며, 그것이 해당 그림이 존재해야 하는 시간의 전부입니다.

[메모리 사용량을 추적하기 위해 추가한 비디오 메모리 사용 현황 시각화 도구]

특히 두 가지 사례는 그것만으로도 작업한 보람이 있었습니다. 이전에는 모든 유물 아이콘을 불러와 VRAM에 저장하고 있었습니다. 화면에 표시할 필요가 있어서가 아니라, 아이콘 하나가 누락되었을 경우 그 사실을 오류로 로그에 기록하기 위해서였습니다. 단순히 파일이 존재하는지만 확인해도 정확히 같은 오류를 표시할 수 있으며, 여기에는 사실상 아무런 비용도 들지 않습니다.

그리고 의복과 문장 장식의 세부 표현에 사용되는 원본 아트 가운데 거의 1GB에 달하는 초상화 패턴 마스크도 이제 활성 메모리에 계속 유지하는 대신 필요할 때마다 스트리밍하도록 변경했습니다.

비디오 메모리

이것이 특정 하드웨어 구성에서 원인을 찾기 어려운 수많은 성능 저하와 심지어 충돌까지 일으키던 문제였습니다.

All Under Heaven 이후에도 저희는 계속해서 에셋을 추가했고, 이들은 모두 게임을 시작할 때 미리 불러오고 있었습니다. 게임 자체의 규모가 커지기 때문에 업데이트를 거듭할수록 콘텐츠도 늘어나지만, 미리 불러오는 방식을 사용하면 실제로 화면에 표시되는지 여부와 관계없이 그 비용을 그래픽 카드가 부담하게 됩니다. 어느 한계를 넘어서 게임이 요구하는 비디오 메모리보다 적은 용량의 비디오 메모리를 갖춘 그래픽 카드는 매 프레임마다 버스를 통해 데이터를 계속해서 주고받기 시작해야 합니다. 이런 상황이 발생하면 성능은 서서히 저하되는 것이 아니라 그야말로 곤두박질칩니다. 저사양 컴퓨터에서는 프레임률이 한 자릿수까지 떨어지기도 했습니다. 때로는 아무런 경고도 없이 바탕 화면으로 튕기기도 했습니다. 이 정도면 제대로 플레이할 수 있는 환경이 아닙니다.

바로 이 문제를 두 가지 스트리밍 시스템이 해결하며, 이것이 이번 개발자 일지에서 소개하는 개별적인 최적화 작업보다 이 두 시스템이 더욱 중요한 이유입니다. 동일한 장면에서 두 시스템을 켰을 때와 껐을 때를 비교해 보면 비디오 메모리 사용량이 약 3분의 1에서 절반까지 감소하며, 이러한 감소 비율은 모든 텍스처 품질 설정에서 비슷하게 유지됩니다.

이러한 절감 효과는 사실 텍스처 해상도 자체보다는 게임 콘텐츠 가운데 얼마나 많은 양이 한꺼번에 메모리에 상주하느냐와 관련되어 있습니다. 그리고 동시에 메모리에 상주하는 콘텐츠의 양은 어떤 품질 설정을 사용하든 대체로 비슷합니다. 이는 또한 이러한 개선의 효과가 정확히 가장 필요한 곳에서 가장 크게 나타난다는 뜻이기도 합니다. 여유 메모리가 충분했던 컴퓨터가 아니라, 이미 여유 메모리를 모두 소진했던 컴퓨터에서 말입니다.

실제로 비디오 메모리 사용량만 놓고 보면 중간 품질과 낮은 품질 텍스처 사이에는 별다른 차이가 없는 것으로 보입니다. 자유롭게 그래픽 설정을 이것저것 조정해 보시고 어떻게 느껴지는지 알려주세요.

렌더 타깃

렌더 타깃은 정적인 초상화나 화면의 프레임 버퍼처럼 무언가를 그리는 데 사용하기 위해 확보해 두는 VRAM 공간입니다. 이 부분은 스트리밍과는 별개로 VRAM 사용량을 최적화할 수 있는 영역입니다.

게임이 한 프레임을 렌더링할 때는 여러 개의 전체 화면 버퍼를 사용합니다. 장면 자체를 위한 버퍼, 앰비언트 오클루전 처리, 여러 블러 및 후처리 단계 등이 이에 해당합니다. 기존에는 이 모든 버퍼가 각 픽셀을 4개의 16비트 부동소수점 값으로 저장하는 고정밀 형식을 사용했습니다. 고해상도에 안티앨리어싱까지 적용하면 이것들이 합쳐져 상당한 양의 비디오 메모리를 차지하며, 이 메모리는 순전히 작업을 위한 임시 공간으로만 사용됩니다.

하지만 이러한 정밀도의 대부분은 실제로 사용되지 않고 있었습니다. 지도는 먼저 렌더링한 뒤 나중에 밝기를 높이는 방식이므로, 저장되는 값은 사용 가능한 범위의 아래쪽 절반에 머뭅니다. 따라서 데이터가 실제로 존재하는 범위에 정밀도를 집중하는, 크기가 절반인 형식만으로도 충분하다는 것을 확인했습니다. 가장 큰 버퍼들의 크기를 절반으로 줄이는 것만으로도 렌더러가 점유하는 비디오 메모리 가운데 상당한 부분을 절감할 수 있습니다. 또한 스트리밍과 달리 팝인 현상이라는 대가도 전혀 없습니다.

물론 코드 한 줄만 바꿔서 끝나는 작업은 아니었습니다. 이 부분은 함께 커피라도 한잔하면서 이야기해 드리고 싶은 대목이네요. 형식을 변경하자 전장의 안개가 망가졌습니다. 정확히 안개가 가장 어두운 부분에서 블록처럼 뭉개져 보이기 시작했습니다. 가장 먼저 떠오르는 설명은 어두운 부분에서 정밀도가 부족해졌다는 것이었지만, 그 설명은 틀렸습니다. 저희는 한동안 그것이 원인이 아니라는 사실을 확인하는 데 시간을 보냈습니다.

실제로 벌어지고 있던 일은 지도가 구름 그림자와 구름을 동일한 픽셀 위에 서로 별개의 두 단계로 그린다는 것이었습니다. 이 때문에 첫 번째 단계의 결과가 낮아진 정밀도로 버퍼에 기록된 다음, 두 번째 단계에서는 그 값을 다시 읽어 시작점으로 사용하고 있었습니다. 고정밀 형식에서는 이렇게 한 번 기록했다가 다시 읽어오는 과정에서 사실상 손실이 발생하지 않습니다. 하지만 더 작은 형식에서는 양자화가 두 차례 일어나며, 하필이면 전장의 안개가 가장 어두운 부분에서 그 현상이 발생하고 있었습니다.

[메모리 사용량을 줄이기 전과 후의 지도]

해결책은 두 패스를 하나로 합치는 것이었습니다. 이렇게 하면 셰이더 내부에서 합성 결과를 최대 정밀도로 계산한 뒤 한 번만 저장하게 됩니다. 또한 전체 화면을 그리는 작업 하나가 사라지기 때문에, 기존 방식보다 처리 비용도 약간 줄어듭니다.

이와는 별개로 지면의 안개에서 발생하던 오래된 밴딩 현상도 있었습니다. 이는 고정밀 형식에서도 존재했지만, 저희가 그동안 알아차리지 못했을 뿐입니다. 이 문제는 프레임 처리의 마지막 단계에서 아주 약간의 디더링을 추가하는 방식으로 해결했습니다.

작업 과정

가끔 제가 어떻게 작업하는지에 관한 질문을 받곤 합니다. 보통은 현재의 일일 틱 처리 속도가 느려지는 과정을 추적하는 일이 그다지 흥미롭지는 않습니다. 업데이트에 새로운 기능이 빠르게 추가되고 있기 때문에 자연스럽게 처리해야 할 작업도 늘어나기 때문입니다. 하지만 업데이트 출시가 가까워질수록 하루하루가 더욱 치열해집니다. 저는 우선 밤새 게임을 실행해서 얻은 로그 파일부터 가져옵니다. 이렇게 실행된 게임 내 시간은 짧게는 600년, 길게는 1,000년에 달하기도 합니다.

로그를 통해 100년 동안의 그래프를 얻을 수 있으며, 더 큰 그림을 살펴볼 필요가 있다면 그보다 긴 기간도 확인할 수 있습니다. 이를 통해 지난번 측정 이후 어떤 시스템 항목에서 변화가 발생했는지를 찾아냅니다. 하나의 시스템은 보통 스크립트와 코드 양쪽으로 이루어져 있으므로, 다음 단계에서는 무엇이 이 수치의 변화를 일으켰을지 파악합니다.

가능성 있는 용의자들의 목록을 만들고 나면 이제 한바탕 탐문에 나설 차례입니다. 이 변화가 의도된 것인지 아닌지를 누가 알까요? 다음에 무엇을 조사해야 할지 판단하는 데 필요한 정보를 누가 제공해 줄 수 있을까요?

이를 통해 더 많은 정보를 얻으려면 코드의 어느 부분을 살펴봐야 하는지 찾아낼 수 있는 경우가 많습니다. 코드 한 줄에도 엄청난 복잡성이 숨어 있을 수 있기 때문에 잠깐 훑어보는 것만으로는 별 도움이 되지 않습니다. 그래도 대부분은 제가 어느 정도 익숙한 부분이라 기본적인 정보는 파악할 수 있습니다.

코드에서 특정 작업만 따로 떼어낼 수 있다면, 이제 이를 직접 측정할 차례입니다. Very Sleepy 같은 외부 샘플링 프로파일러를 사용하면 병목 지점을 찾아낼 수 있는 경우가 많지만, 저에게는 게임 내부에서 사용하는 계측 프로파일러도 있습니다. 계측 방식은 함수 하나를 실행하는 데 정확히 얼마나 시간이 걸리는지를 측정하고 그 결과를 합산할 수 있기 때문에, 특정 코드가 몇 번 호출되었는지와 그 코드에서 총 얼마나 많은 시간을 소비했는지를 모두 확인할 수 있습니다. 그리고 대부분의 경우에는 디자이너를 찾아가 제가 발견한 것을 설명합니다. 그러면 디자이너들은 제가 정확히 무슨 이야기를 하는지 언제나 곧바로 알아듣습니다. 정작 저는 잘 모를 때도 있지만요.

아주 가끔씩은 직접 코드를 조금 다시 작성해서 더 빠르게 만들 기회까지 생깁니다!

시스템 메모리

RAM의 경우 동일한 컴퓨터에서 게임 시작 후 10년이 지난 시점을 기준으로 측정했을 때, 이 프로젝트를 시작했을 때보다 사용량이 약 6분의 1 감소했습니다. 엄청난 수치는 아니지만, 브라우저나 채팅 클라이언트를 게임과 함께 실행할 수도 있는 상황에서 1GB가 넘는 메모리를 절약한 셈입니다. 최소 메모리 용량을 갖춘 컴퓨터에서는 여유롭게 게임을 실행하는 것과 스와핑이 발생하는 것의 차이를 만들 수 있는 정도입니다.

한 가지 개선은 애니메이션 데이터에서 이루어졌는데, 알고 보니 동일한 움직임 데이터를 여러 번 중복해서 저장하고 있었습니다. 애니메이션을 한 스켈레톤에서 다른 스켈레톤으로 리타기팅할 때, 이전에는 리타기팅된 사본이 모든 키프레임 데이터를 복제했습니다. 실제로는 동일한 동작 데이터가 동일한 방식으로 저장되어 있는데도 말이죠. 이제는 원본의 데이터를 읽고 샘플링할 때 팔다리 비율의 차이를 적용하는 방식으로 변경했습니다. 이와 별개로, 여러 스켈레톤이 동일한 애니메이션 파일을 사용하는 경우에도 이전에는 각 스켈레톤마다 파일을 디스크에서 따로 읽어 들였으며, 그 결과 메모리에 서로 똑같은 사본이 각각 생성되고 있었습니다.

또 다른 절감은 이와 거의 같은 방식으로 처리되고 있던 애니메이션 메타데이터에서 이루어졌습니다. 그 결과 메모리 사용량이 1,200MB에서 약 12MB로 감소하여, 이전의 100분의 1 수준으로 줄었습니다.

각종 통계에서 확인할 수 있었던 흥미로운 사실 하나는 캠페인을 시작하고 약 5년이 지나면 메모리 사용량이 거의 일정한 수준에 도달한다는 것입니다. 게임이 메모리에 보관하는 데이터는 플레이 도중 계속 누적되기보다는 거의 모두 게임 시작 시 불러오기 때문에, 장기간 진행한 캠페인이라고 해서 짧게 진행한 캠페인보다 유의미하게 더 많은 메모리를 사용하는 것은 아닙니다.

애니메이션 데이터를 비롯한 여러 시스템에는 이 밖에도 흥미로운 개선의 여지가 있으며, 앞으로도 이를 살펴볼 예정입니다.

시작 시간

필요한 것만 스트리밍하도록 변경한 것이 시작 시간을 단축하는 데 가장 큰 역할을 했지만, 그것이 전부는 아닙니다. 나머지 개선 작업은 대부분 게임이 굳이 할 필요가 없는 작업을 찾아내는 것이었습니다.

가장 큰 단일 항목은 시스템이라고 할 만한 것도 아니었습니다. 함수 하나가 문제였습니다. 1,000개가 넘는 파일에 나뉘어 있는 게임의 텍스트, 즉 현지화 데이터를 불러오는 작업은 다른 CPU 코어들이 아무 일도 하지 않고 놀고 있는 동안 단일 스레드에서 파일을 하나씩 처리하는 방식으로 이루어지고 있었습니다. 저사양 테스트 컴퓨터에서는 이것이 전체 시작 과정의 프로파일에서 가장 큰 단일 항목이었으며, 여러분이 로딩 화면을 바라보며 보내는 시간의 상당 부분을 차지했습니다. 이제 이 파일들을 병렬로 읽은 다음 정해진 순서대로 병합하도록 변경하면서, 여기에 걸리는 시간은 반올림하면 사라질 정도로 줄었습니다.

또한 이전에는 게임이 파일 체크섬을 연달아 두 번 계산했습니다. 첫 번째 계산이 끝날 때까지 기다렸다가 그 결과를 버리고 두 번째 계산을 시작하는 식이었습니다. 이 문제는 수정되었으며, 이제 남은 한 번의 체크섬 계산도 메인 메뉴가 나타나기 전에 실행하는 대신 메인 메뉴가 표시된 뒤에 실행됩니다. 덕분에 메인 메뉴에 더 빨리 도달할 수 있으며, 체크섬 계산이 끝나기를 기다리지 않고 싱글플레이 게임을 시작할 수도 있습니다. 다만 멀티플레이 게임 버튼은 계산이 끝날 때까지 기다려야 합니다. 체크섬은 두 플레이어가 동일한 버전의 게임을 실행하고 있는지를 확인하는 데 사용되기 때문입니다.

[시작 시간 프로파일링 전후 비교(Scribe 84초 vs By God Alone 16초)]

대규모 디렉터리의 경우 각각의 검색에서 조금씩 다른 정보를 찾고 있다는 이유로 파일을 두 번 이상 검색하고 있었으며, 실제로는 그중 한 언어만 불러오면서도 게임을 시작할 때 지원되는 9개의 현지화 언어를 모두 열거하고 있었습니다.

Vulkan과 윈도우

동일한 컴퓨터에서 Vulkan 렌더러는 DirectX 11보다 시작하는 데 약 1.8배 더 오래 걸렸는데, 알고 보니 그 원인은 코드 한 줄에 있었습니다. 한 스레드가 텍스처를 그래픽 카드에 업로드하면 자신의 업로드가 끝날 때까지 기다리는 대신 그래픽 큐가 완전히 빌 때까지 기다리고 있었습니다. 그 결과 8개의 에셋 처리 스레드가 각각 나머지 7개 스레드의 작업까지 모두 떠안고 있었습니다. 올바른 작업이 끝나기를 기다리도록 수정하면서 두 렌더링 백엔드의 성능은 다시 비슷한 수준에 가까워졌습니다.

또 한 가지 발견한 사실은 Linux에서는 동일한 컴퓨터에서 Windows를 실행할 때보다 메인 메뉴까지 불러오는 속도가 일관되게 두 배 정도 빠른 것으로 보인다는 점입니다. 파일 시스템 코드에는 이를 설명할 만한 구체적인 차이가 없으므로, 그저 한쪽이 다른 쪽보다 더 잘 작동하는 그런 경우 가운데 하나인 듯합니다.

설정

새로운 스트리밍 옵션은 설정에 그대로 남겨둘 예정입니다. 예상치 못한 문제가 발생하더라도 이전처럼 모든 것을 미리 불러오는 방식을 사용할 수 있습니다. 하지만 저희로서는 발생하는 문제를 해결하여 새롭고 더 빠른 시스템이 모든 플레이어에게 제대로 작동하도록 만드는 쪽을 선호합니다.

현재 상황

저희는 게임의 규모가 계속 커지는 동안에도 시뮬레이션 속도를 안정적으로 유지하는 한편, 5년에 걸친 개발 과정에서 점차 늘어난 메모리 사용량과 로딩 시간을 다시 줄여 나가고자 합니다. 전자의 경우 저희가 측정에 사용하는 컴퓨터에서는 Scribe 업데이트의 성능에 근접했으며, 최종적으로도 그와 비슷한 수준에 도달할 것으로 예상합니다. 후자의 경우 게임이 요구하는 비디오 메모리는 상당히 줄었고 시스템 메모리도 눈에 띄게 감소했으며, 저사양 컴퓨터에서는 이전에 걸리던 시간의 몇 분의 일만에 메인 메뉴에 도달할 수 있게 되었습니다. 고사양 컴퓨터에서도 빨라졌지만, 그쪽에서는 차이를 체감하기가 조금 더 어렵습니다.

물론 이 모든 작업이 끝나려면 아직 멀었습니다! 일부 작업은 제가 이 글을 쓰는 지금부터 여러분이 직접 플레이하게 될 때까지도 계속 진행되고 있습니다. 캐릭터 상호작용의 처리 비용은 줄었지만 아직 여름 초의 수준까지 돌아가지는 못했으며, 어떻게 개선해야 할지도 이미 알고 있는 수많은 애니메이션 데이터가 작업을 기다리고 있습니다. 나머지는 늘 하던 일과 같습니다. 계속 개발되는 게임에는 최적화해야 할 새로운 요소도 계속 추가될 것이며, 이는 전혀 문제가 되지 않습니다. 덕분에 저도 앞으로 한동안은 계속 바쁘겠네요!

진짜 수치는 게임이 출시되면 나오게 됩니다. 모든 플레이어가 직접 측정할 수 있을 테니까요. 결과가 굉장하든, 훌륭하든, 그저 괜찮은 정도이든 여러분의 결과를 들을 날을 기대하고 있습니다.

빠르게 플레이하세요!

시스템 요구 사항

테크 리드 "Divine"입니다. 슬쩍 끼어들어 앞으로 출시될 패치의 시스템 요구 사항에 관한 소식을 간단히 전해드리겠습니다.

위에서 Carl-Henrik이 여러 수치가 다양한 방면에서 인상적인 속도로 줄어들고 있는 모습을 설명해 드렸습니다. 그렇다면 이 모든 것이 게임의 최소 하드웨어 사양에는 어떤 의미가 있을까요? 반가운 점은 새로운 확장팩에 수많은 콘텐츠와 기능이 추가되었음에도 게임의 낮은 최소 하드웨어 사양을 이전 패치 버전과 동일하게 유지할 수 있다는 것입니다. 위에서 설명한 멋진 기술들은 10년 된 하드웨어에서도 최신 게임을 계속 플레이할 수 있도록 만드는 데 큰 역할을 합니다.

Silk and Silver에서는 앞으로의 개발을 더욱 원활하게 지원할 수 있도록 게임과 코드베이스를 미래에 대비시키는 작업을 시작하고 있습니다. 코드베이스를 C++20 표준과 호환되도록 작성할 수 있도록 더욱 현대적인 컴파일러 툴셋으로 전환하고 있습니다. 이에 따라 Linux와 Mac 플레이어에게 요구되는 운영체제 버전을 업데이트해야 합니다. 따라서 올해 말 Silk and Silver 패치가 출시되면 게임에는 Ubuntu 24.04 LTS(기존 Ubuntu 18.04 LTS)와 macOS 15 Sequoia(기존 macOS Catalina)가 필요합니다. 새롭게 지정한 운영체제 버전은 앞으로 수년간 지원할 예정이며, 그 이후에야 새로운 컴파일러 툴체인으로의 업데이트를 검토할 계획입니다.

후기

지난 몇 년 동안 Studio Black에서는 Black Forge Jam이라는 게임 잼을 개최해 왔습니다. 회사의 역사를 생각해 보면, 저 자신의 Paradox 경력도 Mega Drive 게임을 개발하는 것으로 시작했으니 Mega Crusader Kings를 만드는 것보다 더 어울리는 일이 또 어디 있겠습니까?

성능과 메모리 최적화를 위한 궁극의 도전이죠!

그리고 실제로 작업을 시작했다는 사실을 알려드리고 싶습니다. 지난 12월, 저는 며칠 동안 처음부터 68000 어셈블리로 Crusader Kings를 Sega Mega Drive에 "포팅"했습니다. 그런데 우스운 점은 이게 실제 CK3 데이터를 읽는다는 것입니다. 영지 작위 파일과 영지 지도는 오프라인에서 압축된 테이블로 변환되어 카트리지에 그대로 내장되며, 콘솔은 부팅할 때 이를 이용해 유럽의 정치 지도를 재구성합니다. 59개 국가에 걸친 1,028개의 백작령이 각각 사용할 수 있는 16가지 색상 가운데 가장 가까운 색상으로 표시되며, 방향 패드로 지도를 이리저리 움직일 수도 있습니다. HUD 프레임도 있고, 여러분을 바라보는 해럴드 고드윈슨의 초상화도 있습니다.

[에뮬레이터에서 실행 중인 Mega Crusader Kings. 지도에는 실제 CK3 데이터가 사용되었습니다]

게임 자체는 없습니다. 시뮬레이션도, 텍스트도, 소리도 없습니다. 사운드 칩은 부팅할 때 꺼지고 다시는 켜지지 않습니다. 그리고 위의 비디오 메모리 부분을 읽은 분이라면 익숙하게 느껴질 문제에 부딪혔습니다. Mega Drive는 한 번에 1,536개의 고유 타일만 저장할 수 있는데, 지도에는 약 6,000개가 필요합니다. 그래서 유럽을 그리다가 도중에 그냥 멈춰 버립니다. 마지막 커밋에 제가 남겨 놓은 메모의 전문은 다음과 같습니다. "VRAM을 더 아껴야 함."

기술적으로는 모든 국가와 지역의 명칭이 메모리에 들어 있어 언제든 표시할 준비가 되어 있고, 게임을 실행하는 동안 백작령을 한 국가에서 다른 국가로 옮기는 것도 가능합니다. 하지만 아직 실제 게임플레이는 구현되어 있지 않습니다. 알고 보니 16비트 게임이라고 해도 근무일 기준으로 일주일도 채 안 되는 시간으로는 부족하더군요. 이 프로젝트를 더 작업할 시간이 생길지는 모르겠지만, 현실적으로 어떤 기능을 구현할 수 있을지에 관한 제안은 얼마든지 환영합니다!

ROM은 약 4MB까지 사용할 수 있으며, 커스텀 카트리지를 사용한다면 그중 일부를 RAM과 맞바꿀 수도 있습니다. RAM은 64KB, VRAM도 64KB입니다. 현재 ROM의 크기는 104,024바이트입니다. 흔히 볼 수 있는 저사양 PC에서 크루세이더 킹즈 3를 최대 속도로 실행하려고 하는 것과는 조금 다른 도전이죠.

🔥 실시간 네티즌 베스트 반응

• ㅇㅇ하 좋다..
• ㅇㅇ빅3의 일지는 대체...
• ㅇㅇ컨텐츠가 늘어나는데 성능도 개선된다고? goat
• ㅇㅇ빅좆팀이랑 개발력차이 봐라; 똑같이 휴가갔는데.....
• ㅇㅇ여긴 기획만 병신인거고 나머진 괜찮은데 빅은....
• ㅇㅇ재미없지만 가장 필요한 일지
• 란즈크네츠패독에서 이쪽 코딩하는 애들은 실력자임 ㅇㅇ
• ㅇㅇ빅좆과 수준차이가 ㅅㅂㅋㅋㅋ
• 연운빅좆좆하곤 클라스가다르네
• ㅇㅇ이제 이벤트 많이 떠야 한다는 강박만 좀 더 줄이자~ 할아버지, 아버지, 아들 셋 다 같은 이벤트 뜨면 재미 있겠냐고~