티스토리 뷰




수 년 간에 걸친 거의 전적인 기술 드라이브 추세 이후, 게임 이면의 추진력은 마침내 게임 콘텐츠 자체에 작용하기에 이르렀다. 대대적인 기술 도약도 서로 차별화된 게임을 만들어내기에는 충분치
못했다.


게임 콘텐츠 역시 매년 AAA 등급 게임이 폭증하면서 지속적으로 더욱 커지고 복잡해질 것이다. 하지만 아티스트와 디자이너 자신을 위한 하드웨어 업그레이드는 없으므로 콘텐츠는 더 이상 빠른 속도로 만들어지지 않을 것이다. 성공적인 게임은 일류 콘텐츠를 제공해야 하며, 그것을 제공하는 최선의 방법은 아티스트나 디자이너가 가급적 쉽고 빠르게 새로운 콘텐츠를 생성, 검토, 추가 및 채택할 수 있도록 콘텐츠 파이프라인을 최적화하는 것이다.


콘텐츠 파이프라인은 컨셉 단계에서 게임 다운로드에 이르기까지 모든 게임 자산이 따르는 경로이다. 게임 자산에는 코드가 아닌 모든 것들(모델, 텍스처, 재료,사운드, 애니메이션, 영화, 스크립트 등)을 포함한다. 파이프라인을 지나는 과정에서 자산은 변환되고 최적화되며 비트단위로 나뉘거나 합쳐지지만, 최종 게임 버전으로 출시될 포맷으로 탄생한다. 콘텐츠 파이프라인을 정할 때 처음으로 고려해야 할 문제는 바로 효율성이다. 대규모의 아티스트와 디자이너 팀들이 게임 콘텐츠를 생성 및 채택함에 따라 콘텐츠 파이프라인이 한계 경로가 되어가고 있다.


변경이 이뤄지는 시간부터 게임으로 볼 수 있는 시간까지의 1분과 같은 사소한 비효율성이라도 프로젝트 과정에서 수 천 시간에 달하는 작업 시간을 허비하게 만들 수 있다. 대신 콘텐츠 크리에이터가 자주 작업을 미리 검토하지 않으면 전반적인 게임 품질이 난관에 부딪칠 것이다.


고려해야 할 또 다른 주요 관점은 견고성이다. 콘텐츠 파이프라인은 프로젝트의 급소 정맥이다. 이것이 파손될 경우 프로젝트 자체가 파괴될 수 있는 것이다. 30명에 달하는 이들이 파이프라인을 고칠 때 까지 기다리게 하거나 그것으로 작업하느라 결과적으로 작업 시간의 절반을 허비하게 할 겨를이 없다. 무슨 일이 벌어지든 파이프라인은 항상 정상적으로 작동해야 한다.


거시적인 파이프라인 관찰자산 파이프라인의 모양은 어떠한가?
이것은 프로젝트에 달려있다. 일부 프로젝트의 경우 파이프라인이 미니멀하고 변칙적이다. 자산이 도구에서 직접 익스포트돼 게임으로 로드된다. 소형 게임에는 충분할지 모르지만 대규모 프로젝트에는 충분치 못하다. 많은 사람들이 작업할 수 있도록 파일을 어디에 저장할 것인가? 복수 플랫폼의 경우 자산을 어떻게 취급해야 할까? 리소스 포맷을 쉽게 변경할 수 있는 방법은 무엇인가? 잉여 프로세스를 어떻게 적용할 수 있을까?


스펙트럼의 다른 쪽에서는 파이프라인이 매우 심오하고 정교할 수 있다. 신규자산을 게임에 추가하려면 파이프라인 전문가에게 찾아가 신규 콘텐츠를 추가해 달라고 부탁해야 하는데, 턴어라운드 시
간이 엄청나게 소요된다.


본 글에서는 다수의 각기 다른 프로젝트에서 도입해 필요에 맞게 변경할 수 있는 일반적인 파이프라인을 제시하도록 한다. 꽤 부담이 없고 빠른 턴어라운드 시간을 제공하지만 여러 가지 값비싼 단계들이 수행되는 것을 허용한다. 이것은 현재 엑스박스 타이틀‘MECHASSAULT 2’ 를 위해 데이 1 스튜디오에서 사용하고 있는 파이프라인이다. 이 파이프라인의 전신은 최초의 MECHASSAULT에 사용됐다. 이제 막 신규 프로젝트를 시작했거나 현재 상황을 파악할 수 있는 일부 아이디어를 채택할 수 있다면 좋은 출발점이 될것이다.



소스 자산

계층 정보와 메시, 마루점 데이터를 비롯한 MECHASSAULT 2의 모델은 XML 파일로 익스포트 됐다.


소스 자산은 대개 아티스트 및 디자이너들이 전문 도구(내부 도구나 상용 기성도구)를 사용해 생성한다. 소스 자산은 파이프라인에 배치하고 사람의 개입 없이 최종 자산으로 변환할 수 있다. 핵심 아이디어는 소스 자산이 게임에 올바르게 추가되는 데 필요한 모든 정보를 담고 있어야 한다는 것이다.재료는 지정된 반사 매개변수를 모두 가지고 있어야 하며, 모델은 게임이 발사체를 발사할 지점을 알 수 있도록 무기창에 모든 플래그를 갖추고 있어야 한다. 이렇게 해야 나중에 파이프라인을 자동화시킬 수 있다.


소스 자산이 생성되는 방법은 크게 달라질 수 있다. 가끔은 각기 다르고 매우 전문화된 도구(모델링용, 텍스처 생성용, 게임 정보 지정용, 레벨 배치용 등) 세트를 통해 생성되기도 한다. 또 어떤 경우에는 하나의 대형 도구(종종 모델 편집 프로그램에서 플러그인 역할을 하기도 한다)를 사용해 모든 자산을 생성하고 전체 레벨을 익스포트하기도 한다. 소스 자산에는 게임 내 최종 자산에 필요한 모든 정보가 들어있으므로 매우 조심해서 다뤄야 하며 손실되거나 우발적으로 덮어쓰기 하는 일이 없도록 해야 한다.


버전 제어 프로그램을 사용하면 모든 자산 위치를 집중시켜 서로의 작업 위에 덮어쓰기하는 것을 방지하며, 각 자산의 이전 버전 내역을 지켜준다. 가끔 각 소스 자산 파일이 수백 메가바이트에 달할 정도로 커질 경우가 있으므로 버전 제어 프로그램을 실행하면 이진파일로 잘 처리할 수 있다는 사실을 명심해야 한다. 사전에 렌더링 처리한 동영상과 사운드 역시 게임 자산이지만 크기가 상당하기 때문에 주로 다르게 취급한다. 콘텐츠 파이프라인 통과 경로가 약간 다를 수 있다. 동영상은 버전 제어로 보호할 수 없거나 대부분의 최신 버전이 데이터베이스에서 보관된다.



중간 자산

 

중간 자산은 대개 생성 도구를 통해 소스 자산으로부터 직접 익스포트 된다. 상용 도구를 사용하고 있다면 익스포터의 형태로 약간 더 많은 플러그 인 작업이 필요하다.

중간 자산은 판독과 분석이 매우 쉽고 후방 호환성을 손상시키지 않으면서 확장 할 수 있는 포맷으로 돼있다. 이러한 자산은 프로젝트 종료 전에 버려야 할 것이 있더라도 앞으로 필요할지 모르는 모든 정보를 담고 있어야 한다. 이 점에서 로딩 성능은 중요하지 않다. 최종 자산까지는 남겨둬야 할 자산인 것이다.



일반 텍스트야말로 우리의 요구사항과 완벽하게 일치한다. 더불어 XML은 이러한 텍스트를 구축하는 데 특히 매력적인 옵션이며, 정보를 계층적으로 표시해야할 경우 더욱 그러하다. 이 경우 도구 및 API 범위 전체가 제공돼 최소한의 노력으로 파일을 편집, 분석, 변환할 수 있을 것이다. XML 파일이 필요에 비해 과다할 경우에는 INI 파일과 같이 보다 단순한 포맷을 사용하거나 최소의 노력으로 자체 쓰기를 하면 된다.


이러한 중간 자산 포맷을 갖추는 이유는 무엇일까? 가장 중요한 이유는 소스 자산과 최종 자산 간에 완충 장치를 제공하는 것이다. 최종 자산은 눈부신 속도로 로드되도록 최적화되지만 그 결과 포맷이자주 변경되고 이전 버전을 무용지물로 만든다.


모든 소스 자산을 최종 자산 포맷으로 자동 익스포트하는 것이 가장 이상적이다. 불행히도 우리는 그처럼 이상적인 세계에 살고 있지 않으며, 그리 실용적이지도 않다. 모델링과 텍스처 생성에 사용되는 대다수의 도구는 명령줄로 수천 개의 모델을 동시에 일괄적으로 재 익스포트하도록 쉽고 효율적으로 실행되지 않는다. 프로젝트 진행 과정에서 중간 포맷은 그리 크게 변할 것 같지 않으므로 항상 최종자산을 생성하기 위한 출발점으로 활용하면 된다.


이 같은 중간 포맷을 구축하는 또 다른 이유는 메시 최적화(mesh optimization)나 라이트맵 생성과 같이 복잡하고 시간이 많이 소요되는 작업은 익스포트시에 실행하는 대신 차후로 연기하기 위함이다.


또한 우리는 현재 처리하고 있는 각 플랫폼의 최종 자산 세트 생성을 끝내기도 한다. 중간 포맷이 없다면 아티스트는 각각의 플랫폼 세트를 익스포트하면서 서로 일치하는지 확인해야 하고, 자산이 변경될 때마다 각 자산 세트가 변환 및 최적화 되는 동안 기다려야 할 것이다. 중간 포맷은 최소한 프로그래머에게 디버깅과 실험을 위한 뛰어난 포인트를 제공한다. 중간 포맷은 매우 쉽게 읽히는 포맷으로 돼 있어 누구나 자산의 콘텐츠를 보고 테스트 및 디버깅을 위해 재 익스포트하지 않고 사소한 변경까지 할 수 있어야 한다.


MECHASSAULT 2의 경우 전체 모델을 XML 파일로 익스포트하고 있다. 계층 정보와 메시, 마루점(vertex) 데이터 및 재료가 하나의 대형 XML 파일로 포함된다. 세부 모델의 경우 파일 하나의 크기가 쉽게 3~4MB에 달하고는 한다. 실질적으로 일반 텍스트가 작업하기 좋은 텍스트인 만큼, 텍스처를 텍스트 포맷으로 익스포트하는 일은 과도할 것이다.


텍스처의 경우 아티스트가 포토샵 내에서 지정한 정보(색상, 디더링(dithering), 밉-맵핑 옵션 등)를 모두 담고 있는 코멘트 필드의 맞춤 정보를 통해 32비트 TIFF 파일로 익스포트한다. 이 포맷의 장점은 전체 32비트에서 익스포트된 이후에도 모든 이미지가 그대로 있다는 것이며, (비록 조만간 비대해진 컬러 채널을 걱정해야 하지만 말이다) TIFF 파일을 표시하는 프로그램으로 이미지를 관찰할 수 있다. 다시 한 번 말하지만 밉-맵핑, 색상 변경 및 디더링은 로드 시간 중에 수행하려는 사소한 작업이 아니며, 이 모두를 나중으로 미룰 것이다. (이를테면 전환점 직전의 신속한 변경이나 우리가 실행하려는 변경이 도구의 플러그인을 통해 노출되지 않는 등의) 여러가지 이유로 중간 자산을 직접 수정하는 것도 매력적일 수 있다. 우리는 첫 MECHASSAULT에서 바로 이것을 해냈고 아쉬워하는 일도 없었다. 우리는 맞춤 재료 유형에 우수한 플러그 인을 제공할 시간으로 인해 상당한 압박을 받고 있었으므로, 아티스트들은 중간 자산에서 직접 재료 매개변수를 수정했다. 이러한 매개변수는
다음에 누군가가 모델을 익스포트할 때 덮어 씌워지고 손수 재입력해야 했다.


절대적으로 중간 자산을 반드시 수정해야 한다면 소스 자산으로의 완전 재 임포트 기능을 제공하는 방안을 고려해보는것이 좋다. 하지만 대개는 이것도 사소한 작업이 아니다. MECHASSAULT 2에서
는 소스를 변경하고 훨씬 향상된 플러그인 지원을 제공하는 데 주력하고 있으며, 훨씬 원활하게 작업이 진행되고 있다. 이 중간 포맷이 매우 유연하다고 해도, 기회는 후방 호환성을 파기하는 데 필요한 프로젝트 기간 동안 다가올 것이다. 그것과 싸우려 들지 말고 그것에 대비해야 한다. 반드시 포맷의 일부로 버전 작업을 수행하고 익스포트된 모든 중간 자산을 통해 쉽게 스크립트를 실행할 수 있어야 하며, 그것을 신규 포맷으로 변환할 수 있어야 한다. XML과 같이 쉽게 분석할 수 있는 포맷을 선택하게 될 것이므로, 변환 프로세스는 고통이 거의 없을 것이다.



최종 자산

 

최종 자산은 대상 플랫폼에서 가급적 효율적으로 로드 및 사용될 수 있도록 고도로 최적화됐다. 최종 자산은 하루에도 여러 번 재생성될 것이기 때문에 특정 파일 포맷은 특별히 견고하거나 다수의 포맷 변경을 견딜 필요가 없었다. 여기서 제1의 목표는 속도이다.


이상적으로는 이 리소스가 게임의 로드과정에서 자리하게 될 포맷의 직접 메모리 이미지가 돼야 한다. 그래야 분석 과정 없이 직접 로드할 수 있다. 최적화에 관한 표준 주의 사항은 여기에도 적용된다. 무턱대고 모든 것을 최적화 시켜서는 안 되며, 가장 이득이 되는 자산에 시간을 투입해야 한다.
멀티플랫폼 개발 작업을 할 경우, 모든플랫폼마다 한 개의 최종 자산 세트를 갖추길 원할 것이다. 이런 식으로 엑스박스 텍스처는 자체 포맷으로 자리잡을 수 있고 PS2 텍스처를 다르게 패키지하고 포맷할 수 있다.


데이 1 스튜디오에서는 엑스박스용만을 개발했지만 두 가지 리소스 세트를 갖추고 있었다. 하나는 엑스박스 용으로 게임에 사용됐고, 또 다른 하나는 PC 용으로 PC 기반 도구에 사용됐다. 이 단계에서 실행된 작업 유형 범위는 단순한 포맷 변경에서부터 밉-맵 생성이 나 디더링, 압축과 같이 비용이 많이 드는작업, 그리고 라이트맵 생성이나 메시 최적화 등 정말로 많은 시간이 소요되는 작업에 이르기까지 광범위했다. 이 시점에서는 작업을 수행하는 데 소요되는 시간에 그리 큰 신경을 쓰지 않는다. 최종 결과물과 최종 자산의 최적화 정도에만 신경을 쓸 뿐이다. 이러한 단계를 거친 결과 일부 자산을 다른 자산으로 분할할 수 있고(일례로 우리의 모델 XML 파일은 마루점과 색인 데이터를 담고 있는 여러 개의 작은 파일로 나뉘어진다), 가끔은 여러 개의 자산을 하나의 큰 자산으로 결합할 수 도 있다(텍스처 세트를 하나의 커다란 텍스처로 패키지화).


데이 1 스튜디오에서는 이 단계가 중간 자산 세트를 채택하고 최종 자산을 생성하는 명령줄 변환 도구로 실행됐다. 실제 변환은 DLL로 실행되는 변환 플러그인 세트를 통해 이뤄지는데, 특정 유형의 리소스 변환을 담당한다(파일 확장명이나 파일 자체의 헤더로 식별한다). 변환 플러그인으로 처리되지 않는 모든 리소스는 일체의 수정 없이 곧바로 복사된다. 모든 게임 리소스 자산에 대한 완전 자산 변환 실행 경고는 시간이 상당히 많이 소모되는 과정이다. 파일 수가 간단히 수백 수천 개에 달할 수 있고 각각 개별적으로 로드, 분석, 변환해 새 포맷으로 저장 해야 한다.


이 프로세스는 최대 수 시간이 걸리는 데다가 CPU와 하드드라이브를 급속하게 잠식할 수 있다. 이 시간을 최소화하면 전반적인 턴어라운드 시간에 도움이 되므로, 변환 프로그램의 윤곽을 그려 명백한장애를 찾아내는 것이 좋다. 또 다른 해결책으로 점진적인 변환(마지막 빌드 이후 변경된 파일만 변환)과 분산 빌드 수행(각자 하위 리소스 세트를 담당하는 기기 창고 보유)이 포함된다.


이 과정이 진행되는 동안 필요한 오류 및 경고 메시지도 생성해야 한다. 가끔 자산이 성공적으로 변환될 요건을 충족시키지 못할 경우가 있다(예를 들어 텍스처가 필수 밉-맵으로 표시됐지만 2의 배수가 아닌 차원을 갖고 있는 경우). 처음부터 무효 자산이 생기는 것을 방지해 그것이 이처럼 깊숙이 파이프라인에 흘러들지 않도록 하는 것이 더 낫지만, 그래도 여전에 그에 대한 대비는 해야 한다. 실패한 변환과 경고 메시지에 대한 로그를 모두 보관해 아트 및 디자인 책임자들이 무엇이 문제인지 신속하게 파악해 다음 빌드에서 그것을 교정하도록 해야 한다.


집행해야 할 리소스 간에 특정한 종속성이 있을 경우(예를 들어 특정 모델에 대한 텍스처와 패키지 이전에 변환돼야 하는 텍스처를 모두 한데 결합하는 경우)ㅡMake나 Jam 등의 기존 종속 관리 도구
를 사용할 수도 있다.



카탈로그 파일


파이프라인의 최종 단계는 느슨한 최종 자산 파일 모두를 커다란 카탈로그 파일로 묶는 것이다. 카탈로그 파일은 다른 파일들을 내부에 담고 있는 커다란 파일에 지나지 않으며, 이름과 계층 정보까지 포함할 수 있다. 카탈로그 파일을 사용할 경우의 이점은 매우 분명하다. 파일 열기/닫기 작업의 수 가 줄어들고 파일간의 물리적 근접성이 발휘되며, 보다 효율적인 자산 분포가 가능하고 디렉토리 분석 작업도 한층 빨라진다. 놀랍게도 현대적인 게임이라고 해서 모두 카탈로그 파일에 자산을 제공하지는 않는다(대개 원인은 엄청나게 긴 로드 시간이나 설치 시간이라고 할 수 있다).


이미 생성, 로드, 보기를 위해 만들어진 도구가 있기 때문에 .ZIP, .CAB, .WAD등의 표준 카탈로그 파일 포맷을 사용하는 것이 편리하다. 반면 원하는 만큼 그것들을 제어하기는 힘들다(예를 들면 최적의 DVD 성능을 찾기 위한 특정 파일 얼라인먼트나 순서 집행).


이 단계에서는 각 플랫폼마다 최종 자산이 별도의 파일로 패키지 된다. 각 레벨마다 별도의 카탈로그를 원할 수도 있고 나머지 자산에서 별도의 카탈로그 파일에 사운드와 음악을 갖출 수도 있다. 이러한 전략은 게임에 필요한 리소스 로드 정도에 좌우된다. 이러한 카탈로그 파일이 생성되면 네트워크로 복사해 대역폭만 충분하다면 모두가 로컬 기기로 다운로드하거나 네트워크에서 직접 작업할 수 있다. 게임 및 도구는 이러한 파일을 직접 판독할 수 있어야 하며 내부의 리소스를 투명하
게 로드해야 한다.



빠른 경로


불행히도 지금까지 설명한 프로세스는 정확히 말해 속도감이 없다. 변경을 하고 게임에서 그것을 확인하려면 다음과 같은 단계를 따라야 한다. 소스 자산을 수정하고 중간 자산을 익스포트한 후 버전 제어로 확인하고 리소스 변환을 시작한 후 새로운 카탈로그 파일이 준비될 때까지 몇 시간 동안 기다리면 된다. 그렇다고 해도 빠른 턴어라운드 시간이라는 처음의 요건은 충족되지 않는다.


해결책은 시간이 소모되는 단계를 생략하는 빠른 도구 및 게임 경로를 제공하는 것이다. 우리의 경우 도구와 게임 모두가 중간 자산 뿐 아니라 최종 자산까지 로드 할 수 있도록 했다. 업데이트된 텍스처가 게임에서 보이는 모습을 확인할 경우 아티스트는 중간 자산을 익스포트하고 게임이나 도구가 찾을 수 있는 디렉토리에 복사한 후 게임을 실행하기만 하면 된다.


게임을 올바른 레벨로 런칭하는 것을 비롯해, 이 모든 단계를 한 번에 수행할 수 있는 매크로나 버튼까지 제공할 수 있다. 아티스트는 변경 작업을 하고 버튼을 누르며 게임에서 신규 자산을 확인하기만 하면 된다. 그보다 쉬운 방법은 제시하지는 못하겠다. 카탈로그에 있는 파일 대신 로컬 파일
이 로드되는 과정은 정확히 어떨까? 이것은 파일 관리자의 마술 영역이다. 도구 및 게임이 연관되는 한 다른 이들과 마찬가 지로 파일을 열기만 한다. 하지만 우리의 파일 관리자는 카탈로그 파일보다 로컬 파일을 우선시해 카탈로그 파일 내의 유사 항목을 대체한다.


게임이 해당 파일을 열 때마다 파일 관리자는 로컬 파일로 방향을 선회시킨다. 그렇지 않을 경우 여느 때처럼 카탈로그로부터 로드했을 것이다. 우리는 중간 포맷을 설계했으므로 분석과 수정이 쉬웠다. 하지만 로드 속도는 빠르지 않았다. 그렇다면 로딩 수준이 거의 기는 수준으로까지 늦춰지지는 않을까? 레벨의 모든 리소스가 중간 포맷으로 돼 있으면 아마도 그럴 것이다. 즉 아티스트 및 디자이너들이 동시에 작업하고 있는 자산만이 중간 포맷으로 국지적으로 발견 될 것이므로, 로드 시간은 아주 조금 늘어 나는 데 그칠 것이라는 얘기다.


이 접근법 역시 게임과 모든 도구에 중간 포맷으로 돼있는 자산의 로드 및 분석을 위한 코드가 있어야 한다. 적은 분량의 코드는 아니지만, 이미 변환 도구의 일부로 만들기 위해 이미 덮어 쓰기한 그것이 바로 기회이다. 하지만 최종적으로 납품될 게임에서는 이 코드를 제거할 것이므로, 이것을 말끔하게 분리하고 제거가 쉽도록 조건부 컴파일 명세서(conditional compilation statement)로 둘러싸야 한다.


이렇게 빠른 로드 경로를 사용하면서 깨우친 한 가지 교훈이 있다. 반드시 빠른로드 경로와 정상 경로 모두 (나머지 파이프라인을 따라) 동일한 결과를 산출하도록 해야 한다는 것이다. 그렇지 않을 경우 자산 확인을 거쳤는데도 다르게 보이는 이유를 확신하지 못한 아티스트가 대단히 당황하게 될 것이다. 우리는 느린 경로에서 텍스트 변환용 라이브러리 한 개를 사용하고 빠른 경로에서는 다른 라이브러리를 사용했다. 종종 결과는 유사했지만, 가끔 의문이 제기될 정도로 달라지기도 했다. 가능하면 두 경로 모두 동일한 코드를 사용하는 것이 좋다.


 

모두 한 곳으로 모으기


이제 파이프라인 전체가 제자리를 잡았으면 프로세스 자동화를 본격적으로 생각 해볼 수 있다. 비교적 솔직하게 스크립트를 생성해 소스 제어를 통해 최신 소스나 중간 자산을 확보하고 이 모두에 대한 변환 프로세스를 실행하며, 그것들을 카탈로그 파일로 묶어야 한다. 펄 & 파이손 (Perl & Python) 언어가 이러한 종류의 작업에 알맞은 글루언어 (glue language)이다. 스크립트 중 가장 까다로
운 측면은 오류(네트워크 다운, 버전 제어 서버 다운 등)를 처리해 시작부터 그것을 잘 관리할 수 있을 정도로 견고하게 만드는 것이다. 이러한 스크립트가 마련되면 리소스 빌드를 하루에 한 두 차례, 또는 새로운 소스가 필요할 경우 필요에 따라 자동으로 실행할 수 있다.


콘텐츠 파이프라인을 자동화 할수록 피드백이 더욱 중요해진다. 사람들이 모든 파이프라인 단계를 지켜보지는 않을 것이므로 중요한 정보를 모두 수집해 그것에 관심 있는 이들에게 전달해야 한다. 모든 오류 및 경고 수집과 더불어, 메모리 풋프린트나 텍스처 소요량, 또는 간략한 성능 통계 등의 기타 정보까지 수집하는 것이 좋다. 이렇게 하면 최신 리소스로 게임 속 의 각 레벨을 실행하기 위한 최종 리소스 빌드 단계가 완료된다. 부수적 혜택으로, 매우 간략한 빌드 스모그 테스트 역할까
지 수행한다.


견고성은 처음부터 파이프라인의 목표에 속한다. 여기에는 패키징 도구가 완전하게 작동하고 모든 오류를 올바르게 보고하도록 하는 작업이 포함된다. 또 다른 부분은 게임 및 도구가 불량 리소스로 인해 사용이 불가능한 상태로 남아있지 않도록 하는 것이다. 보존해야 할 좋은 철학은 불량 데이터
가 게임이나 도구를 파손하지 않으며, 아티스트나 디자이너가 게임을 망쳐놓을 일이 없다는 생각이다. 다소 급진적으로 들릴 수도 있지만 목표를 위해서는 가치가 있다. 여기에 소요되는 엔지니어링 시간은 자산이 전속력으로 게임에 추가되는 즉시 보상받을 수 있다. 레벨을 로드할 경우에는 시간을 내어 로딩 내지 초기화 오류를 보고하고 문제가 있는 개체를 해제한 후 그것을 옮겨야 한다. 더불어, 초기화에 실패한 개체를 대신해 추하게 생긴 디버깅 모델(우리의 경우 커다란 핑크색 롤리팝 형태였다)을 배치하는 것도 도움이 된다.



추가 파이프라인 작업

 

턴어라운드 시간은 이미 상당히 호전됐지만 그보다 더 단축하려 한다. 게임으로 하여금 변경된 자산을 탐지하고 실행 중에 로드하도록 하려는 것이다. 이렇게 하면 특히 특정 위치에 도달하는 데 상당한 시간이 소요되는 불연속 레벨 게임에 유익하다.


MECHASSAULT 2의 전체 리소스 빌드에는 최대 한 시간 반이 소요될 수 있다. 우리는 분산 빌드의 가능성을 추가로 조사하려 한다. 오픈 소스와, 프로세스에 쉽게 추가할 수 있는 일반적인 분산 작업
수행용 프레임워크가 있다. 또한 견고성을 추가하기 위해 아파치 앤트(Apache Ant)와 같은 빌드 시스템과의 통합도 모색할 수 있다. 게임은 제각기 매우 다르며 팀도 다르게 구성되므로, 콘텐츠 파이프라인도 프로젝트별로 크게 다르다. 주어진 게임의 자산과 그에 대한 작업, 작업 주체 및 작업이 이뤄질 개발 단계를 파악하는 것이 중요하다. 가급적 특정 필요에 가장 적합하게 작용하는 파이프라인을 사용하고 그것을 자동화하는 것이 좋다. 팀 내의 디자이너와 아티스트들은 그에 대한 사의를 표할 것이고 마침내는 보다 나은 게임을 완성할 수 있게 될 것이다.


<Copyright CMP Media LLC>

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함