사례 연구 - SONAR, HTML5 게임 개발

Sean Middleditch
Sean Middleditch
홈페이지

소개

지난 여름 저는 SONAR이라는 상용 WebGL 게임의 기술 리드로 일했습니다. 프로젝트를 완료하는 데 약 3개월이 걸렸으며, 완전히 처음부터 JavaScript로 완료하였습니다. SONAR을 개발하는 과정에서 우리는 아직 테스트되지 않은 새로운 HTML5 환경에서 발생하는 여러 문제에 대한 혁신적인 솔루션을 찾아야 했습니다. 특히 단순해 보이는 문제에 대한 솔루션이 필요했습니다. 플레이어가 게임을 시작할 때 70MB가 넘는 게임 데이터를 어떻게 다운로드하고 캐시할까?

다른 플랫폼에도 이 문제에 대한 솔루션이 있습니다. 대부분의 콘솔과 PC 게임은 로컬 CD/DVD 또는 하드 드라이브에서 리소스를 로드합니다. Flash는 게임이 포함된 SWF 파일의 일부로 모든 리소스를 패키징할 수 있으며 Java는 JAR 파일에서도 동일한 작업을 수행할 수 있습니다. Steam 또는 App Store와 같은 디지털 배포 플랫폼은 플레이어가 게임을 시작하기도 전에 모든 리소스를 다운로드하고 설치할 수 있도록 합니다.

HTML5는 이러한 메커니즘을 제공하지 않지만 자체 게임 리소스 다운로드 시스템을 구축하는 데 필요한 모든 도구를 제공합니다. 자체 시스템을 구축하면 필요한 제어 권한과 유연성을 모두 확보하고 니즈에 정확히 맞는 시스템을 구축할 수 있다는 장점이 있습니다.

검색

리소스 캐싱을 하기 전에는 간단한 체이닝 리소스 로더가 있었습니다. 이 시스템을 통해 상대 경로를 통해 개별 리소스를 요청할 수 있었고, 결과적으로 더 많은 리소스를 요청할 수 있었습니다. 로딩 화면은 얼마나 더 많은 데이터를 로드해야 하는지 측정하는 간단한 진행률 미터를 표시했으며, 리소스 로더 큐가 비어 있는 후에만 다음 화면으로 넘어갔습니다.

이 시스템을 설계한 덕분에 패키징된 리소스와 로컬 HTTP 서버를 통해 제공되는 느슨한 (비패키징) 리소스 간에 쉽게 전환할 수 있었으며, 이는 게임 코드와 데이터를 모두 신속하게 반복하는 데 있어 중요한 역할을 했습니다.

다음 코드는 체이닝된 리소스 로더의 기본 디자인을 보여주며, 오류 처리 및 가독성을 유지하기 위해 제거된 고급 XHR/이미지 로딩 코드가 포함되어 있습니다.

function ResourceLoader() {
  this.pending = 0;
  this.baseurl = './';
  this.oncomplete = function() {};
}

ResourceLoader.prototype.request = function(path, callback) {
  var xhr = new XmlHttpRequest();
  xhr.open('GET', this.baseurl + path);
  var self = this;

  xhr.onreadystatechange = function() {
    if (xhr.readyState == 4 && xhr.status == 200) {
      callback(path, xhr.response, self);

      if (--self.pending == 0) {
        self.oncomplete();
      }
    }
  };

  xhr.send();
};

이 인터페이스의 사용 방법은 매우 간단하지만 매우 유연합니다. 초기 게임 코드는 초기 게임 레벨 및 게임 객체를 설명하는 데이터 파일을 요청할 수 있습니다. 예를 들어 간단한 JSON 파일일 수 있습니다. 그런 다음 이러한 파일에 사용되는 콜백은 해당 데이터를 검사하고 종속 항목에 대한 추가 요청 (체이닝된 요청)을 할 수 있습니다. 게임 객체 정의 파일에 모델과 재료가 나열되면 머티리얼 콜백이 텍스처 이미지를 요청할 수 있습니다.

기본 ResourceLoader 인스턴스에 연결된 oncomplete 콜백은 모든 리소스가 로드된 후에만 호출됩니다. 게임 로드 화면은 다음 화면으로 전환하기 전에 해당 콜백이 호출될 때까지 기다릴 수 있습니다.

물론 이 인터페이스를 사용하면 훨씬 더 많은 작업을 할 수 있습니다. 독자를 위한 연습으로 진행률/비율 지원 추가, 이미지 로드 추가 (이미지 유형 사용), JSON 파일 자동 파싱 추가, 오류 처리 등 조사해 볼 만한 몇 가지 추가 기능을 살펴보겠습니다.

이 기사의 가장 중요한 기능은 baseurl 필드로, 이를 사용하면 요청하는 파일의 소스를 쉽게 전환할 수 있습니다. 매개변수가 설정되지 않은 경우 캐시 시스템을 사용하면서, 게임의 기본 HTML 문서를 제공한 동일한 로컬 웹 서버 (예: python -m SimpleHTTPServer)가 제공하는 URL의 리소스를 URL에 있는 ?uselocal 유형의 쿼리 매개변수에서 요청할 수 있도록 핵심 엔진을 쉽게 설정할 수 있습니다.

패키징 리소스

리소스 체인 로드의 한 가지 문제는 모든 데이터의 전체 바이트 수를 얻을 수 있는 방법이 없다는 것입니다. 결과적으로 다운로드를 위한 간단하고 신뢰할 수 있는 진행률 대화상자를 만들 방법이 없습니다. 모든 콘텐츠를 다운로드하고 캐시할 것이므로 대규모 게임의 경우 다소 시간이 오래 걸릴 수 있으므로 플레이어에게 멋진 진행 대화 상자를 제공하는 것이 매우 중요합니다.

이 문제를 가장 쉽게 해결하는 방법은 (몇 가지 다른 이점도 제공) 모든 리소스 파일을 단일 번들로 패키징하는 것입니다. 이 번들은 단일 XHR 호출로 다운로드합니다. 이렇게 하면 진행률 표시줄을 표시하는 데 필요한 진행 이벤트가 제공됩니다.

맞춤 번들 파일 형식을 빌드하는 것은 그리 어렵지 않으며 몇 가지 문제도 해결할 수 있지만 번들 형식을 만들기 위한 도구를 만들어야 합니다. 대안은 이미 도구가 있는 기존 보관 파일 형식을 사용한 다음 브라우저에서 실행할 디코더를 작성해야 하는 것입니다. HTTP는 이미 gzip 또는 deflate 알고리즘을 사용하여 데이터를 압축할 수 있으므로 압축된 보관 형식이 필요하지 않습니다. 이러한 이유로 TAR 파일 형식을 정했습니다.

TAR은 비교적 간단한 형식입니다. 모든 레코드 (파일)에는 512바이트 헤더가 있고 그 뒤에 512바이트로 패딩된 파일 콘텐츠가 있습니다. 헤더에는 목적에 따라 관련이 있거나 흥미로운 필드가 몇 개밖에 없으며, 주로 파일 형식과 이름만 헤더 내의 고정된 위치에 저장됩니다.

TAR 형식의 헤더 필드는 고정된 위치에 저장되며 헤더 블록에는 고정된 크기가 있습니다. 예를 들어 파일의 마지막 수정 타임스탬프는 헤더 시작 부분으로부터 136바이트에 저장되며 그 길이는 12바이트입니다. 모든 숫자 필드는 ASCII 형식으로 저장된 8진수로 인코딩됩니다. 필드를 파싱하기 위해 배열 버퍼에서 필드를 추출합니다. 숫자 필드의 경우 원하는 8진수 밑을 나타내기 위해 두 번째 매개변수를 전달하여 parseInt()를 호출합니다.

가장 중요한 필드 중 하나는 유형 필드입니다. 레코드에 포함된 파일의 유형을 알려주는 한 자리 숫자 8진수입니다. 이 목적으로 흥미로운 두 가지 레코드 유형은 일반 파일 ('0')과 디렉터리 ('5')뿐입니다. 임의의 TAR 파일을 다루는 경우 심볼릭 링크 ('2')와 하드 링크 ('1')도 고려할 수 있습니다.

각 헤더 다음에는 헤더에 설명된 파일의 콘텐츠가 바로 옵니다 (디렉터리와 같이 자체 콘텐츠가 없는 파일 형식은 제외). 그런 다음 파일 콘텐츠 뒤에 패딩이 이어서 모든 헤더가 512바이트 경계에서 시작되도록 합니다. 따라서 TAR 파일 내 파일 레코드의 총 길이를 계산하려면 먼저 파일의 헤더를 읽어야 합니다. 그런 다음 헤더에서 추출한 파일 콘텐츠의 길이에 헤더의 길이 (512바이트)를 더합니다. 마지막으로 오프셋을 512바이트로 정렬하는 데 필요한 패딩 바이트를 추가합니다. 이는 파일 길이를 512로 나누고 최대치에 512를 곱하여 쉽게 수행할 수 있습니다.

// Read a string out of an array buffer with a maximum string length of 'len'.
// state is an object containing two fields: the array buffer in 'buffer' and
// the current input index in 'index'.
function readString (state, len) {
  var str = '';

  // We read out the characters one by one from the array buffer view.
  // this actually is a lot faster than it looks, at least on Chrome.
  for (var i = state.index, e = state.index + len; i != e; ++i) {
    var c = state.buffer[i];

    if (c == 0) { // at NUL byte, there's no more string
      break;
    }

    str += String.fromCharCode(c);
  }

  state.index += len;

  return str;
}

// Read the next file header out of a tar file stored in an array buffer.
// state is an object containing two fields: the array buffer in 'buffer' and
// the current input index in 'index'.
function readTarHeader (state) {
  // The offset of the file this header describes is always 512 bytes from
  // the start of the header
  var offset = state.index + 512;

  // The header is made up of several fields at fixed offsets within the
  // 512 byte block allocated for the header.  fields have a fixed length.
  // all numeric fields are stored as octal numbers encoded as ASCII
  // strings.
  var name = readString(state, 100);
  var mode = parseInt(readString(state, 8), 8);
  var uid = parseInt(readString(state, 8), 8);
  var gid = parseInt(readString(state, 8), 8);
  var size = parseInt(readString(state, 12), 8);
  var modified = parseInt(readString(state, 12), 8);
  var crc = parseInt(readString(state, 8), 8);
  var type = parseInt(readString(state, 1), 8);
  var link = readString(state, 100);

  // The header is followed by the file contents, then followed
  // by padding to ensure that the next header is on a 512-byte
  // boundary.  advanced the input state index to the next
  // header.
  state.index = offset + Math.ceil(size / 512) * 512;

  // Return the descriptor with the relevant fields we care about
  return {
    name : name,
    size : size,
    type : type,
    offset : offset
  };
};

기존 TAR 리더를 찾아보았지만 다른 종속 항목이 없거나 기존 코드베이스에 쉽게 적합한 리더는 몇 개 찾았습니다. 그래서 직접 쓰기로 결정했습니다. 또한 로드를 최대한 최적화하고 디코더가 아카이브 내에서 바이너리 데이터와 문자열 데이터를 모두 쉽게 처리할 수 있도록 하기 위해 시간을 할애했습니다.

먼저 해결해야 했던 문제 중 하나는 실제로 XHR 요청에서 데이터를 로드하는 방법이었습니다. 저는 원래 '바이너리 문자열' 접근법으로 시작했습니다. 불행히도, 바이너리 문자열을 ArrayBuffer와 같이 더 쉽게 사용할 수 있는 바이너리 형식으로 변환하는 것은 간단하지 않으며 이러한 변환도 특히 빠르지 않습니다. Image 객체로 변환하는 작업도 마찬가지입니다.

TAR 파일을 XHR 요청에서 직접 ArrayBuffer로 로드하고, 청크를 ArrayBuffer에서 문자열로 변환하는 작은 편의 함수를 추가하는 작업을 완료했습니다. 현재 이 코드는 기본적인 ANSI/8비트 문자만 처리하지만 브라우저에서 더 편리한 전환 API를 사용할 수 있게 되면 이 문제를 해결할 수 있습니다.

이 코드는 레코드 헤더를 파싱하는 ArrayBuffer를 간단히 스캔합니다. 여기에는 모든 관련 TAR 헤더 필드와 관련이 없는 몇 개의 헤더 필드와 ArrayBuffer 내 파일 데이터의 위치와 크기가 포함됩니다. 또한 코드는 선택적으로 데이터를 ArrayBuffer 뷰로 추출하여 반환된 레코드 헤더 목록에 저장할 수 있습니다.

이 코드는 https://github.com/subsonicllc/TarReader.js에서 친숙한 오픈소스 라이선스에 따라 무료로 제공됩니다.

파일 시스템 API

파일 콘텐츠를 실제로 저장하고 나중에 액세스하기 위해 FileSystem API를 사용했습니다. 이 API는 새로운 API이지만 훌륭한 HTML5 Rocks 파일 시스템 도움말을 비롯한 훌륭한 문서가 이미 포함되어 있습니다.

FileSystem API에는 주의사항이 있습니다. 우선 이벤트 기반 인터페이스로, API를 비블로킹으로 만들어 UI에 유용하면서도 사용하기 불편한 API입니다. WebWorker의 FileSystem API를 사용하면 이러한 문제를 완화할 수 있지만 전체 다운로드 및 압축해제 시스템을 WebWorker로 분할해야 합니다. 이 방법이 가장 좋은 접근 방식일 수도 있지만 시간 제약으로 인해 선택한 방식이 아니기 때문에 (아직 WorkWorkers에 익숙하지 않음) API의 비동기 이벤트 기반 특성을 처리해야 했습니다.

우리는 주로 파일을 디렉터리 구조에 쓰는 것에 중점을 둡니다. 이를 위해서는 파일마다 일련의 단계를 거쳐야 합니다. 먼저 파일 경로를 가져와 목록으로 변환해야 합니다. 경로 구분 문자 (URL과 같이 항상 포워드 슬래시)에서 경로 문자열을 분할하면 쉽게 수행할 수 있습니다. 그런 다음 마지막에 대해 결과 목록 저장의 각 요소를 반복하고 로컬 파일 시스템에 디렉터리 (필요한 경우)를 재귀적으로 생성해야 합니다. 그런 다음 파일을 만들고 FileWriter를 만들고 마지막으로 파일 콘텐츠를 작성할 수 있습니다.

두 번째로 고려해야 할 중요한 사항은 FileSystem API의 PERSISTENT 스토리지 파일 크기 제한입니다. 영구 스토리지를 원하는 이유는 사용자가 제거된 파일을 로드하려고 하기 직전에 게임을 플레이하는 동안을 포함하여 언제든지 임시 스토리지를 삭제할 수 있기 때문입니다.

Chrome 웹 스토어를 타겟팅하는 앱의 경우 애플리케이션의 매니페스트 파일에서 unlimitedStorage 권한을 사용하면 저장용량 제한이 없습니다. 하지만 일반 웹 앱에서도 실험용 할당량 요청 인터페이스를 사용하여 공간을 요청할 수 있습니다.

function allocateStorage(space_in_bytes, success, error) {
  webkitStorageInfo.requestQuota(
    webkitStorageInfo.PERSISTENT,
    space_in_bytes,
    function() {
      webkitRequestFileSystem(PERSISTENT, space_in_bytes, success, error);      
    },
    error
  );
}