섬세한 균형

스텔라리스는 복잡한 코드의 집합입니다. 마치 미카도나 젠가와 같은 복잡한 게임처럼요. 모든 부분이 각기 다른 부분과 연결되어 있습니다. 무언가를 추가하면 연결이 더 늘어납니다. 조심스럽게 추가한다면 소수의 연결이 늘어나고, 급하게 추가하면 더 많은 연결이 발생합니다. 이는 계획되지 않은 특징(다시 말해, 버그)을 나타냅니다. 또한 실제 게임 내에서 작동하는 것을 보면, 새로운, 그리고 예기치 못한 방향으로 작동해 더 많은 계획되지 않은 기능을 만들어내기도 합니다.

일단 우리가 현재 상황을 깨닫고 난 이후엔, 우린 더욱 조심하기 시작했습니다. 어쩌면 너무 조심스러웠을 수도 있습니다. 너무 많은 곳을 너무 자주 체크하며, 일어나서는 안 될 상황이 정말로 일어나지 않게 만드는 일에요. 지금은 안되고, 나중에도 안되고, 절대로 안되고.

그래서 당신이 계획되지 않은 기능을 제거했지만, 그래도 게임은 어...조심스럽습니다. 그러니까, 느리단 소리죠.

그래서 여러분은 몇몇 확인 기능을 제거했습니다. 은하계 전체를 순환시킬 필요가 없음을 깨닫고, 단지 작은 하나의 행성만을 순환시키는 겁니다. 그리고 한걸음 더 나아가, '음, 글쎄. 3주에 한번만 확인하는건 어때? 그리고 계산에 필요한 확인들은 바뀌기 전 까지 이쪽에 저장해두자고'라는 생각을 해 보세요.

이제 게임은 더이상 '조심스럽지' 않습니다. 그리고 이제, 다시 계획되지 않은 기능의 영역으로 돌아가보죠. 그러나 캐싱 과정이 서로 다른 시간에 다른 곳에서 발생한다면, 이는 결과의 변동을 불러옵니다.(개발자가 커피를 마시기 전에 부탁받은 것과 커피를 마신 후 부탁받은 과제의 결과물의 차이와 같이요)

약간의 다른 결과는 곧 OOS(역주:서비스 장애를 말하는 것 같음)가 넘쳐난다는 소리입니다! 클라이언트와 서버는 0.0001의 차이를 가지고 있으며, 시간이 지나면 명령은 서버에는 입력되지만 클라이언트엔 입력되지 않습니다.

그래서 당신은 '스마트'한 알고리즘을 제거하고, 정확한 알고리즘으로 대체합니다. 이전의 두 단계에서 얻어낸 결과물을 잃게 되고, 또다른 버그가 생겨납니다. 어쩌면 말이죠. 이걸 끝없이 반복합니다.

하지만 끝없이 반복되는 건 제 아침 일상으로 충분합니다! 다른 부분에 대해 이야기해보죠.

성능

스텔라리스의 팬들은 C++ 프로그래머와도 같습니다. 성능은 항상 그들의 머릿속을 멤돌고 있죠. 공정히 말해서, 우리도 최근에 이 부분을 신경써서 적용하고 있습니다. 우리도 이게 끝이 아니라는 걸 압니다. 특히 후반부 게임과, 더 큰 은하계에선 말이죠. 그 점을 염두에 두고, 우리는 평소에 하던 것 보다 더 많은 싱경을 써서 성능을 향상시키고 있습니다. 우린 무엇이 가장 많은 계산을 필요로 하는지 살펴봤으며, 모두가 알고 있듯...

POP

POP이 스텔라리스에서 가장 많은 계산을 요구하는 이유는 여러가지가 있으나, 중요한 것은 후반부 게임에는 너무 많은 POP이 존재한다는 것입니다. 너무 너무 너무 너무 많죠. 그리고 POP은 많은 것을 합니다! 매일마다 어떤 직업에서 자신의 성능을 최대로 발휘할 수 있을지를 행성의 모든 이들과 경쟁하며 확안하고, 윤리관을 가지는 것을 확인해야 합니다. 파벌에 가담하는 건 얼마나 행복한 일인지요. 여기선 얼마나, 저기선 또 얼마나 행복할까요?

이 모든 것들이 모디파이어 계산을 유발시킵니다. 이전 개발 일지를 기억한다면, 스텔라리스에서 POP보다 많은 것은 모디파이어 뿐만이라는 것을 알고 있을 것입니다. 그리고 모디파이어는 상호간에 의존관계를 만들어냅니다. 그걸 모두 계산하는 것은 실타래를 잡아당겨 스웨터 전체를 끌고오는 것과 같습니다.

좋아, 그럼 정말로 뭐가 변했는가?

우선, 우린 '새로운 일자리가 언제 추가될지 모르니까 직업 분배는 매일 해야 한다'라는 생각이 너무 고집 센 생각이었다는 것을 인정하겠습니다. 우리는 이 부분을 재검토했으며, 이제 일자리는 수요에 의해 이루어질 것입니다. 이제 더 적은 반복이 수행될 것입니다.

우리는 또한 하나 이상의 노예가 있는지, 퇴폐적인지, 종족 수준에서 확인할 것이 있는지를 찾기 위해 제국의 모든 POP을 체크하는 몇가지 트리거를 찾아냈습니다. 이러한 부분을 POP단위가 아닌 종족 단위로 체크하도록 몇가지 트리거를 만들었습니다. 같은 방식으로, 함대를 확인하기 위해 모든 함선을 체크하는 트리거도 있었으므로 함대를 찾아낼 수 있는 트리거를 추가했습니다.

또한 POP이 윤리관을 바꿀 수 있는지, 파벌에 들어갈 수 있는지를 확인하는 새로운 방식을 연구했습니다.

마지막으로, 우리는 더 많은 멀티스레드를 사용할 수 있는 방법을 찾았습니다.

이 영상은 아래 세이브(개발일지 하단에 있음)를 실행시, 2.5.1과 2.6을 비교한 영상입니다. 내 업무용 컴퓨터(Intel Core7-7900X @ 3.30Ghz, 10 cores and 20 threads, and AMD R9 Fury)에서 실행한 결과입니다. 반드시 같은 결과가 나오진 않으며, 정확한 성능의 차이는 컴퓨터마다 다를 것이며, 정확한 상황은 여러분의 세이브 상황마다 달라지겠지만요. 평균적으로 15~30%의 성능 향상이 나타났습니다.

이 세이브는 POP 계산 성능 향상을 확인하는데 이상적입니다.

평균적으로 어느정도나? 어떻게 알았는가?

우리는 매일 밤마다 밤새도록 게임을 합니다. 그리고 아침에, 게임이 얼마나 진행되었는지 확인합니다. 또한 얼마나 많은 오류가 생겼는지, 최종 상태가 어떤지, 얼마나 많은 OOS가 나타났는지, 그리고 테이블과 그래프에 다양한 색으로 정리해서 나타냅니다. 그리고 신스를 지우고 나면, 그들은 영혼과 그 외에 대한 성가신 질문이 사라집니다.

결론

비록 우리가 성능을 염두에 두며 성능을 합리적으로 유지하기 위해 최선을 다 했으나, 우리는 이 문제에 대해 깊이 파고들 기회를 가져서 기쁩니다. 이 변화가 우리에게 주었던 만큼의 기쁨을 여러분에게 주길 바라며, 여러분의 피드백을 기다리겠습니다.

다음주에는 여러분 모두가 기다리던 것에 대한 또다른 개발일지가 나올 것입니다. 더 많은 오리너구리요!

추신

우리가 사용한 저장 파일은 커뮤니티 중 하나인 성능 스레드에서 가져왔습니다. 그러나 정확히 어디서 얻었는지는 모릅니다. 만일 당신이 이 세이브를 알아본다면, 혹은 당신의 것이라면, 우리가 당신에게 감사를 표할 수 있도록 알려주셨으면 합니다.

https://forum.paradoxplaza.com/forum/index.php?threads/stellaris-dev-diary-170-performance-and-other-technical-issues.1335134/&utm_source=launch-steam&utm_medium=launcher&utm_content=post&utm_campaign=fede_stpc_20200220_for_dd