본문 바로가기
그냥 논다!/Star Citizen

스타시티즌 게임스타 스타시티즌의 기술들

by Laeng 2017. 7. 18.

스타시티즌 3.0 정보가 담긴 독일 게임 잡지 Gamestar 의 컬럼을 Reddit 에 영문으로 kruben95님께서 요약 번역해주셨습니다. 영문 요약 번역본은 여기에서 보실 수 있습니다.



GameStar: The technique behind Star Citizen


스타시티즌의 기술들


  • 크리스 로버츠에게 자주하는 질문은 "당신은 당신의 게임을 완성할 수 있다고 믿나요?" 입니다. 이러한 질문을 하는 이유는 큰 규모의 게임이며 기술적으로 만만치 않기 때문입니다. 크리스 로버츠와 그의 팀들은 완성할 수 있다고 확신합니다.
  • 열정과 노하우가 대단히 인상적입니다.
  • 모든 목표는 현재의 기술로 가능하다고 크리스로버츠는 말합니다.
  • 하지만 모든 목표와 아이디어가 실현되야 하기 때문에 계획된 방식으로 구현되지 않는 것은 즐겁지 않거나 좋은 방법은 아닙니다.
  • 기반 구축을 위해 팀은 엄청난 시간을 투자하였습니다. (게임 엔진 변경 등...)
  • 마르코 콜베타와 카스텐 웬젤(전 Crytek 직원, 현 2년차 CIG 직원)은 스타시티즌이 사용하는 엔진은 크라이엔진이라 할 수 없다고 말했습니다. 사용중인 게임엔진에는 크라이엔진 코드 50% 와 나머지 50%는 새로 만든 코드를 사용하며 실질적으로 스타시티즌에 사용되는 코드 중 90%가 새로 만든 코드를 활용합니다.
  • 2 가지 결과가 나온 리팩터 코드: 엄청난 크기의 게임속 우주와 오브젝트와의 상호작용 가능성
  • 거대한 행성들이 포함된 태양계 시스템을 만들려면 엔진이 엄청난 좌표를 처리해야합니다. 이러한 거대한 세계는 64bit 환경에서만 구현가능합니다.
  • 이러한 변화를 주기 위해 1년이라는 시간이 걸렸습니다.
  • NPC 및 오브젝트와의 많은 상호작용이 이루어 질 수 있도록 Job Management System 을 다시 만들어야 했습니다. 그래서 이제는 이 시스템이 메인 쓰레드를 막지 않습니다. 수많은 게임속 엔티티들을 처리하기 위해 이제는 CPU 의 모든 코어를 최대한 활용합니다. 
  • 크라이엔진의 단점을 극복하여 새로운 엔진은 모든 엔티티들은 다른 구성요소를 가질 수 있게되었습니다. 함선은 비행 제어 시스템을 구성요소로 가지게 되었고 생명유지 구성요소를 추가할 수 있었습니다.
  • 이것을 아이템 2.0 시스템이라고 각각의 구성요소들을 독립적으로 테스트 할 수 있습니다.
  • 크리스 로버츠의 말에 따르면 이러한 확장가능성 높은 시스템이 네트워크를 통해 게임세계를 쉽게 동기화 할 수 있으며 프로그래밍에서는 매우 현대적인 원칙이라고 하였습니다.
  • 아이템 2.0 시스템을 활용한 첫 번째 계획은 많지않은 플레이어를 수용할 수 있는 인스턴스를 가지고 타 MMO 게임처럼 스타시티즌을 만드는 것 이었습니다. 
  • 3.0 에서 수용가능한 플레이어 수는 기존과 동일합니다. 한 서버에는 최대 24명이 접속이 가능합니다.
  • 게임엔진의 재 작업 또한 네트워크에 영향을 미치며, 수많은 서버 속 수천개의 인스턴스가 플레이어의 정보를 서로 동기화 할 수 있을 것입니다.
  • 물리적 서버에는 32개의 코어가 있으며 8개의 가상머신이 구동되고 있습니다. 왜냐하면 크라이엔진은 4개보다 더 많은 코어를 활용할 수 없기 때문입니다.
  • 그리고 다른 문제로는 코어의 개수와 수용가능한 플레이어 양과 비례하지 않기 때문입니다. 미래에 이 문제는 수정될 것입니다. 
  • 4개의 CPU 코어로 24명을 수용할 수 있습니다. 게임엔진이 활용할 수 있는 최대 CPU 개수가 늘어난다면 한 서버에 100명이상의 플레이어를 수용할 수 있을 것입니다. (역자 주. 현재 4코어 이상의 서버에서도 24명만 받을 수 있고, 이걸 해결하려면 게임엔진 수정이 필요하며, 이 작업이 완료되면 서버 코어 개수에 따라 최대 동접자 수를 증가시킬 수 있다는 말인 것 같습니다.)
  • 서버 네트워크와 서버 간 원활한 전환이 될 때,  모든 플레이어는 실질적으로 한 인스턴스에 있는 것 같은 효과를 낼 수 있습니다. (역자 주. 모든 서버들을 서로 동기화시켜, 단일 서버와 같은 환경을 만들겠다는 내용인 것 같습니다. ) 
  • 이를 향한 커다란 발걸음은 Batch Updateing 입니다. 이 기술을 통해 하나의 Batch 는 모든 코어로부터 함께 처리됩니다. 이로인해 서버간 동기화가 훨씬 쉬워집니다. 특히 피지컬은 이 방법이 훨씬 더 확장성이 좋습니다.
  • 이 기술은 아직 약간 더 시간이 필요하기 때문에 미래에 엄청난 숫자의 NPC 를 처리하기 위해서는 더 많이 처리할 수 있도록 크라이엔진을 수정 하는 것이 중요합니다.
  • 현재 계획으로는 스타시티즌 우주 속 인구 90%를 NPC 들로 채워넣는 것입니다.
  • 게임에서 이러한 모든 요구(거대한 우주, 행성, 함선 역학, 피지컬 그리드)을 만족하기 쉽지 않습니다.
  • 게임 시연에 사용되었던 컴퓨터의 사양은 i7 5930k, GTX 980, 32GB 램 이며 30프레임이 나왔습니다.
  • 엘리베이터 시스템, Ragdoll 시스템, 서버 충돌 문제가 남아 있습니다.
  • 새로운 라이젠 CPU 를 최적화 할 예정입니다.
  • 게임의 최소 사양은 쿼드코어 CPU, 2GB 이상의 그래픽 카드, 8GB 램, SSD 입니다.
  • 그래픽 설정은 여러분의 사양에 맞출 수 있도록 세분화 될 것입니다.
  • 그래픽 설정이 많을 수록 테스트가 많이 필요하므로 20개 이상의 옵션이 제공되지 않을 것입니다. 그러나 게임 성능을 컴퓨터에 맞도록 변경하는 데 충분할 것입니다.
  • 콘솔 지원을 위해 게임 그래픽을 다운그래이드하는 일은 없을 것입니다. 현재의 최고사양의 PC 는 2~3년이 지나면 중간사양으로 되기 때문에 스타시티즌을 플레이하는데 부담이 없을 것입니다.
  • 스타시티즌은 크라우딩 펀드로 개발되는 게임이며 몇달마다 퍼블릭 빌드를 공개하고 커뮤니티의 피드백을 받을 것입니다.
  • 많은 후원자들이 자신의 팀이 시간을 올바른 방향으로 사용하고 있음을 이해해 주어서 크리스 로버츠는 행복합니다. (역자 주. 비록 시간이 걸리지만 게임 완성을 위해 시간을 투자하고 있음을 후원자들이 지지하고 믿어주어서 크리스 로버츠가 행복하다는 의미 인듯합니다.)
  • 내부 테스트는 70여명의 사람들이 진행하며, 그 후 2단계에 걸쳐 커뮤니티와 함께 테스트를 합니다. (에보카디 테스트는 1000명, PTU 는 최대 2만명)
  • 모든 테스트를 거친 버전만이 모든 후원자들에게 공개됩니다.
  • 크리스 로버츠가 말하기는 멀티플레이를 테스트하는 것은 큰 도전이라고 하였습니다. 에디터에서 모든 것을 혼자서 테스트하고 다른 위치에 있는 사람들과 함께 인터넷을 통해 함께 게임세계를 테스트하기 때문입니다.
  • 인터넷으로 서로 동기화 되는 클라이언트를 통해 게임세계의 많은 것들을 추척할 수 있습니다.
  • 큰 문제는 인터넷을 통해 물리엔진을 서로 동기화하는 것이였습니다. 왜냐하면 플레이어들은 서로 다른 중력과 중력방향을 가지고 있기 때문입니다.
  • 3.0 에서 구현되어야 것들이 많이 남아 있어, 지연될 수 있습니다.
  • 게임이 아직 알파단계이지만 개발팀들은 큰 야망을 품고 있습니다.


Vulkan VS DirectX

  • DirectX 11를 사용하고 있습니다. DirectX 12 는 윈도우 10에서만 구동될 수 있기 때문에 Vulkan 으로 변경할 예정입니다. 어쩌면 DirectX 11를 완전히 사용 안할 수 도 있습니다.
  • Vulkan 은 코어 활용도가 높기 때문에 그래픽 품질이 향상됩니다.
  • 크라이엔진은 Vulkan 5.4를 이미 지원하지만, 스타시티즌이 사용하는 크라이엔진는 자체 수정한 부분이 많기 떄문에 크라이엔진을 업데이트 할 수 없습니다. CIG 는 이와같은 유사한 계획을 가지고 있지만 많은 구성요소들을 재 작업해야 합니다.
  • 현재는 그래픽 API 보다 게임 개발이 시급하기 때문에 그래픽 API 변경이 늦어질 것입니다. 


크고 아름다운 64bit


  • 가장 큰 도전은 게임엔진을 64bit 로 동작하도록 수정하는 것이였습니다.
  • 크라이엔진과 럼블야드엔진도 하지 않은 것입니다.
  • 32bit 로는 거대한 태양계 시스템을 만들지 못할 것입니다.
  • 몇년동안 CPU 는 64bit 를 지원하고 윈도우즈도 지원했지만 오늘날의 대부분의 게임들은 32bit 로 실행됩니다.
  • 위쳐 3 의 맵은 스타시티즌 우주 속 위성의 한 분화구 안에 배치할 수 있습니다. (역자 주. 위쳐 3 보다 맵이 엄청 크다는 말 같습니다.)


절차적 생성...

  • 언젠가 스타시티즌에 100개의 항성계와 300개의 위성과 행성을 우주에 포함시켜야합니다.
  • 모든 행성과 위성은 플레이어가 직접 걸을 수 있어야합니다.
  • 크리스 로버츠는 처음 런칭때 5 ~ 10 개 항성계를 구현하는 것으로 목표로 합니다.
  • 목표를 달성하기 위해 절차적 행성 시스템을 개발했습니다.
  • 이것은 개발자가 행성 베이스를 만들기 위해 사용되는 도구 입니다.
  • 여러분이 방문할 행성들은 절대 절차적으로 생성되지 않습니다. (역자 주. 행성 베이스를 절차적 생성을 통해 만든 다음 개발자들이 행성의 특성에 맞게 수정하고 오브젝트를 추가합니다. )
  • 절차적 행성 시스템은 새 행성에 수많은 바이옴과 레이어를 생성합니다. 숲, 돌, 호수, 바다등과 같이 여러 바이옴을 생성합니다. (우리는 이미 바다를 보았습니다.)
  • 크리스 로버츠는 이것을 큰 붓으로 그림을 그리는 것이라고 말했습니다.
  • 그러나 모든 행성과 달에 특정 장소를 만들기 위해 개발자들이 많은 검토를 할 것입니다.

모든 데이터가있는 곳

  • 여러분이 게임 세계를 여행하려 할 때, 여러분의 PC 는 미리 데이터를 준비한 다음 화면에 띄어줍니다.
  • 항성계와 실제 행성을 구현하는 것은 기술적 도전이며, 이 방대한 데이터들을 매우 효율적으로 스트리밍 해야합니다.
  • 이 문제를 해결하기 위해 Object Container Streaming 라는 것을 개발했습니다.
  • Object Container는 그룹화 된 오브젝트들을 표시하기 위한 데이터를 포함하며 이것은 우주 정거장이나 플레이어가 돌아다닐 수 있는 우주 정거장 속 구역이 될 수 있습니다.
  • 스타시티즌은 어떤 오브젝트가 필요할지 식별하여 데이터를 적시에 불러옵니다. 이것이 가능한 이유는 계층 구조를 통해 가장 중요한 데이터를 선별하여 먼저 불러오기 때문입니다.
  • 멀티 코어 시스템으로 더 나은 데이터 스트리밍을 지원합니다.
  • 이러한 기술들을 보다 더 잘 활용하기 위해서는 SSD 와 많은 용량의 램을 가지고 있는 것이 좋습니다.
  • 현재 행성과 달에는 4~5개의 특별 구역이 있습니다.
  • 곧 Object Container Streaming 을 사용할 수 있을 것입니다.


번역 Laeng  



반응형