(역주: 툴에서 'export'니 가급적 그대로 씁니다.)
가끔 Export project 옵션이 완료되기까지 몇 분쯤 걸리는 걸 보셨을 겁니다. 특히 큰 프로젝트일수록 그렇습니다. 이는 Construct 2가 프로젝트를 최적화하기 위해, 즉 다운로드 크기와 메모리 사용량을 가능한 한 많이 줄이기 위해 열심히 일하고 있기 때문입니다. 이 튜토리얼에서는 Construct 2가 export시 정확히 뭘 하고 있는지, 더불어 export settings가 어떤 영향을 미치는지 다루고, 몇 가지 시간 절약 팁으로 마무리합니다.
1단계: 이미지 데이터 중복 제거 (deduplication)
프로젝트에 중복되는 이미지들이 있는 것은 비교적 흔합니다. 예를 들어 하나의 오브젝트 타입을 통째로 복제했거나(cloned), 아니면 애니메이션의 여러 군데에서 같은 프레임을 재사용하는 경우(예: A B A C A D 형태)가 있습니다. 이런 경우 프로젝트 폴더 내에 중복된 이미지 파일들이 있을 수 있습니다. 미리보기(preview)를 빠르게 하기 위해, 중복된 이미지들은 미리보기 시에는 제거되지 않습니다. 하지만 내보내기(export)할 때는, Construct 2가 중복된 이미지들을 찾아내고 제거합니다. 이는 다운로드 크기 와 메모리 사용량을 줄이는 데 도움이 됩니다. 똑같은 이미지를 2번 다운로드하거나 메모리로 2번 불러오는 것 은 의미가 없기 때문이죠.
참고로 이미지의 크기는 여전히 계산됩니다. 10x10 픽셀의 새까만 이미지는 11x11의 새까만 이미지와 다른 것으로 여겨집니다. 한 쪽이 제거되어도 프로젝트가 똑같이 보이고 동작할지 보장할 수가 없기 때문입니다.
엔진의 한계로 인해, 이 과정에는 두 가지 기이한 점이 있습니다. 첫째로, JPEG 포맷으로 export되도록 한 이미지들은 중복 제거가 되지 않습니다. 둘째로 스프라이트(Sprite) 오브젝트와 다른 오브젝트 사이에서는 중복 제거가 되지 않는데, 이는 스프라이트 오브젝트의 이미지들은 스프라이트시트화 되고(spritesheeted) 다른 오브젝트들은 아니기 때문입니다. 예를 들면, 똑같은 이미지로 된 하나의 스프라이트와 타일 배경(Tiled Background)은 여전히 두 개의 이미지로 export되지만, 똑같은 이미지로 된 2개의 스프라이트나 2개의 타일 배경은 하나의 이미지만을 export하게 됩니다. 이런 건 주로 극단적인 경우고 그리 심각한 문제는 아닐 겁니다.
2단계: 스프라이트시트화(化) (spritesheeting)
이미지들은 프로젝트 안에 개별 파일로 저장됩니다. 예를 들어 10개의 애니메이션 프레임으로 된 스프라이트가 있으면 10개의 개별 이미지 파일들이 프로젝트 폴더 안에 있습니다. 만약 애니메이션들이 다 이런 식으로 export된다면, 몇 가지 문제점들이 생길 수 있습니다. 각 이미지는 브라우저 게임에서 개별적으로 다운로드되어야 하고, 이는 즉 10번의 개별 HTTP 요청을 의미하며, 각 HTTP 요청은 일정량의 추가 비용이 드는 셈입니다(extra overhead). 스프라이트에는 주로 수많은 비슷한 부분들로 된 애니메이션 프레임이 있고, 이 이미지 데이터가 매 애니메이션 프레임 파일마다 중복될 것입니다. 또 많은 시스템들이 실제로 이미지를 2의 거듭제곱 크기(power-of-two size)의 표면 메모리로 취급합니다(예: 128x128, 256x256, 512x512 등). 만약 모든 이미지가 130x130이면, 시스템은 이들 모두를 개별로 256x256 표면 메모리로 놓고, 이러면 기기의 메모리가 바닥날 가능성이 많아집니다.
스프라이트시트화(spritesheeting)는 수많은 애니메이션 프레임들을 하나의 커다란 이미지로 만드는 과정입니다. 이로써 위의 모든 문제들이 해결됩니다. 브라우저 게임에서 HTTP 요청이 더 적어지고, PNG나 JPEG 압축은 애니메이션 프레임들 간 이미지의 유사한 부분들을 제거할 수 있어 다운로드 크기를 더 작게 만들 수 있고, 또 Construct 2는 항상 2의 거듭제곱 크기(power-of-two size)의 스프라이트시트를 써서 메모리 낭비를 최소화합니다. 여기 Space Blaster에서 플레이어의 우주선 스프라이트시트가 어떻게 생겼는지 보시죠.
하나의 오브젝트를 위한 통합된 스프라이트시트는 300kb의 다운로드로 2mb의 메모리를 먹습니다. 스프라이트시트 없이 개별 이미지들은 460kb 다운로드에 약 3mb의 메모리를 먹었습니다. 그러니 전체 프로젝트에 적용된다면 절약되는 양이 상당히 클 겁니다.
오직 스프라이트 오브젝트의 이미지들만이 스프라이트시트화 됩니다. 이것의 주된 이유는 이 기능이 처음 나왔을 때, 만일 다른 오브젝트들에도 적용될 경우 서드파티 플러그인들을 망가뜨릴 수 있었기 때문입니다. 하지만 대개 스프라이트 애니메이션 프레임들이 프로젝트 내 이미지의 대부분을 구성하고, 또 이미지들 중에서 가장 중복성(반복성, redundancy)이 높기 때문에, 여전히 많은 절감이 됩니다. Construct 2는 또한 두 개의 다른 오브젝트를 같은 스프라이트시트에 섞지 않습니다. 이는 스프라이트시트를 가능한 한 256색 이하로 만들어 PNG-8로 재압축(recompression)할 수 있게 하기 위함이고, 또 일반적으로 다른 오브젝트 타입간에는 주로 중복성이 적기 때문입니다. (recompression에 관해서는 나중에 좀더 자세하게 설명합니다.)
스프라이트시트의 최대 크기는 2048x2048인데, 이것이 모바일 기기를 포함해 모든 하드웨어에서 폭넓게 지원되는 최대 크기이기 때문입니다. 또, 인접한 이미지들의 색이 다른 프레임들로 "번지거나(bleeding)" "퍼지는(fringing)" 것을 막기 위해, Construct 2는 스프라이트시트에서 모든 프레임들 사이에 1픽셀의 공간을 남깁니다. 즉 하나의 256x256 스프라이트시트 안에 128x128 이미지 4장이 딱 맞아떨어지지 않는 겁니다. 그러므로 스프라이트 애니메이션 프레임들은 반드시 2의 거듭제곱 크기 아래가 되도록 해야 합니다. 최적의 크기는 2의 거듭제곱 크기보다 2픽셀 작은 크기로, 예를 들면 30x30, 126x126 또는 254x254 등입니다. (참고로 Tiled Background는 반면에 보통 정확히 2의 거듭제곱 크기일 때 가장 잘 적용됩니다.)
또 약 1000x1000을 넘는 이미지를 쓰는 것은 피해야 하는데, 이런 것들은 장치 메모리를 매우 낭비하게 만들고 스프라이트시트에 맞추기에도 곤란해질 것이기 때문입니다. (만일 Construct 2가 오브젝트를 스프라이트시트에 맞추지 못하면, 그냥 다시 개별적인 이미지들로 export해버리고, 스프라이트시트화의 이점도 모두 놓치게 됩니다.)
Construct 2의 우선순위는 실행 중 메모리 사용을 최소화하는 것인데 주로 이것이, 특히 모바일 기기들에서 가장 중대한 문제이기 때문입니다. 이를 위해 Construct 2는 이미지들이 맞춰진다면 더 작은 크기의 스프라이트시트 2~3장으로 내보내기를 택합니다. 예를 들어 만약 이미지들이 2~3장의 512x512 스프라이트시트에 맞춰진다면, 하나의 1024x1024 스프라이트시트 대신에 그렇게 두세 장으로 내보냅니다. 그쪽이 메모리를 덜 먹기 때문이죠. 몇몇 경우 이것이 사실상 다운로드 크기를 좀더 크게 만들 수 있습니다 - 약간 더 중복되는 이미지 데이터들이 저장됩니다.
하지만 보통 메모리 사용을 최소화하는 것이 다운로드 크기를 몇 퍼센트 절감하는 것보다 더 중요한 일입니다.
대부분의 이미지들이 2의 거듭제곱 크기가 되는 것에는 또다른 장점도 있습니다. 일부 플랫폼에서는, 특히 모바일에서는, 오로지 2의 거듭제곱 크기인 소스 이미지로만 밉매핑(mipmapping)을 지원합니다. 밉매핑은 기본적으로 고품질의 축소(downscaling)를 가능하게 하는 렌더링 기술로, 작게 크기를 줄인 오브젝트들에 실제 앤티앨리어싱을 사용해 더 보기 좋게 합니다. 이는 다시 말해 export 후 일부 플랫폼에서 더 나은 렌더링 품질로 몇몇 스프라이트들이 작게 조정될 수 있다는 것입니다.
참고로 project property의 Downscaling을 'High quality'로 하면, 두 개의 작은 렌더링 문제를 완화하기 위해 스프라이트시트의 이미지들이 항상 2의 거듭제곱 크기로 맞춰집니다. 이것은 스프라이트시트의 메모리 절약을 무효화시키므로 아무 이유없이 쓰여서는 안 됩니다. 더 자세한 정보는 메모리 사용을 참조하세요.
3단계: 이미지 재압축 (recompression)
일단 Construct 2가 모든 이미지들을 스프라이트시트로 정리하고 나면, 그 다음은 다운로드 크기를 가능한 한 작게 만드는 일에 집중하게 됩니다. 여기에는 몇 가지 요령이 있습니다. 이것은 단연코 가장 집중적인 단계로, 주로 export 시간의 거의 대부분을 차지할 것입니다.
무엇보다, Construct 2는 어떤 이미지든지 우리가 Image Format 대화 상자에서 설정해둔 포맷을 존중합니다. 모든 이미지는 편집 중 품질저하를 막기 위해 프로젝트 내에 무손실 PNG-32 파일로 저장되어 있습니다. 이 중 어떤 이미지가 JPEG나 PNG-8 포맷으로 쓰기로 지정된다면, 그것들은 이 시점에서 재압축됩니다(recompressed). 만일 256색 이상을 쓰는 이미지로 JPEG나, PNG-8을 선택했다면 이것은 손실되는(품질이 저하되는) 작업입니다. 참고로 이는 Construct 2 자체에 JPEG나 PNG-8을 import하는 것은 의미가 없다는 뜻입니다. - Construct 2는 여전히 단순하게 어떤 import된 이미지라도 PNG-32로 변환하고, 또 우리가 Image Format 대화 상자에서 정한 원하는 포맷으로 재압축해 export할 때까지 기다릴 것입니다. 그러므로 이미지의 불필요한 품질 저하는 막고, Construct 2에는 항상 PNG-32 이미지를 import하고, 그 후 Image Format 대화 상자에서 의도하는 포맷을 지정하십시오.
또 참고로 이미지들은 렌더링 직전에 압축이 풀리므로, 파일 포맷은 (PNG-32, PNG-8 또는 JPEG 어느 걸 선택하든) 실행 중 메모리 사용에 아무런 영향도 미치지 않습니다 - 오직 다운로드 크기에만 영향이 갑니다. 하지만 항상 그림이 크고, 자세한 장면(scenery)일 경우에는 JPEG 포맷을 고르는 것이 중요한데, 이렇게 하면 다운로드 크기를 상당히 줄일 수 있기 때문입니다. 단지 JPEG는 투명색을 지원하지 않음을 주의하세요 - 만약 JPEG로 쓰기로 지정한 이미지의 어떤 부분이 투명색이면, 그 투명한 부분은 불투명한 검정색으로 변합니다.
이제 Construct 2는 전체 프로젝트를 위한 스프라이트시트를 만들고, 모두 우리가 의도한 포맷대로 쓰게 합니다. 하지만 아직 할 게 많아요! 다음은 아직 PNG-32로 쓰도록 지정된 모든 스프라이트시트들에 색상이 몇 개나 쓰였는지 카운트합니다. 이것들 중 하나라도 256색 아래로 쓰인 것이 나오면, 자동으로 PNG-8로 재압축됩니다. 이미지가 256색 안에 맞춰지므로 무손실이고, 종종 그 이미지의 다운로드 크기를 절반이나 1/3까지도 줄일 수 있습니다. 흔히 이는 Image Format 대화 상자에서 PNG-8로 세팅조차 할 필요 없이 다운로드 크기가 막대하게 축소된다는 뜻입니다.
모든 256색 이상의 스프라이트시트들도 여전히 가공됩니다 - 이것들은 PNGCrush라는 툴로 들어가는데요, 이 툴은 이미지를 압축하기 위해 다른 수많은 방법들을 시도하고, 어느 결과든 가장 파일 크기가 작아지는 방법을 택합니다. 이로써 보통 자동적이고 손실 없는 10-15%의 다운로드 크기 절감이 됩니다.
만약 export 때 PNG recompression 세팅에서 None을 선택하면, 색상수 계산과 PNGCrush 단계는 건너뛰어집니다. 이것은 export를 매우 빠르게 해줄 수 있지만, 동시에 다운로드 크기를 심각하게 크게 만들 수 있습니다. 만약 Brute를 선택하면, PNGCrush 단계가 상당히 더 긴 시간을 들여가며 최선의 압축 방식을 찾아낼 겁니다. 이렇게 하면 export 시간을 상당히 늘리게 되지만, 흔히 고작 몇 퍼센트 정도의 추가 절감 효과밖에 얻지 못합니다. 그러니 대체로 보통 Standard를 쓰는 것이 가장 좋습니다.
보셨다시피, Construct 2의 프로젝트 이미지 재압축은 비교적 정교합니다. Image Format 대화 상자에서 손실이 심한 포맷을 명백히 지정하지 않는 한은 완전히 무손실입니다(정확히는 이미지의 품질을 보존합니다). 결과적으로, 보통 export 후 다른 이미지 압축 툴이나 서비스를 사용해야 할 필요가 없습니다. Construct 2가 export 중 스스로 잘 압축하도록 믿고 맡기면 됩니다. (그리고 앞서도 말했듯, Construct 2 에디터로 import할 때도 그런 툴을 쓸 필요가 전혀 없습니다. 어차피 즉시 PNG-32로 변환되고 불필요하게 이미지의 품질을 낮췄을 수도 있으니까요.)
4단계: 스크립트 최소화 (minification)
마지막으로, 결과적인 javascript 코드가 Google Closure Compiler의 'advanced' 모드를 써서 최소화됩니다. 이것으로 javascript 코드 내의 가능한 모든 것들을 가장 짧은 이름으로 바꿔, 스크립트 크기를 줄이고 더 빨리 다운로드할 수 있게 만듭니다. 또 이는 export된 프로젝트에 대한 리버스 엔지니어링을 엄청나게 어렵게 만든다는 좋은 부가 효과도 있는데, 스크립트에서 이전에 유용했던 용어들이 전부 의미없는 말들이 되어버리기 때문입니다. 또한 이것이 결과적 javascript를 약간 더 효과적으로 만들기도 하는데, inlining과 쓰이지 않는 코드 제거와 같은 기본적인 최적화 방안들을 이용하기 때문입니다.
일부 드문 경우, 특히 서드 파티 플러그인에서, 최소화(minifying)가 버그를 초래할 수도 있습니다. 그러한 문제의 해결을 돕기 위한 진단책으로 이 기능을 끄는 옵션이 기본적으로 있습니다. 또 최소화기능을 수행하려면 Java가 필요합니다. 그러니 어쩌다 Java를 설치하지 않았거나 버그를 조사 중인 게 아닌 한은, 항상 최소화(minification) 기능을 켜 두어야 합니다. (이건 그저 최소화 기능의 혜택만을 위해서라도 설치할 만한 가치가 있습니다.)
오디오 파일 누락 (Omission of audio files)
모든 플랫폼에서의 오디오 재생 지원을 위해, AAC와 OGG Vorbis 두 가지로 모든 사운드와 음악을 이중 인코딩(dual-encode)할 필요가 있습니다. 보통 Import Audio 대화 상자에서 다루어집니다. WAV 파일을 import하는 경우, Construct 2는 역시 이것들을 프로젝트 안에 남겨두어서 혹시나 나중에 다른 품질 수준으로 재압축하거나, 음원에 다른 가공처리를 할 때를 대비합니다.
압축된 AAC와 OGG Vorbis 포맷은 모든 플랫폼을 커버하고 항상 WAV에 비해 상당히 작아서, WAV 파일은 Construct 2에서 사실상 결코 export될 일이 없습니다. 또 Construct 2는 만일 선택된 플랫폼의 지원되는 포맷이 미리 알려져있다면 AAC나 OGG Vorbis 파일 둘 중 하나를 누락시킵니다. 예를 들어 패키지된 Chrome Web Store 앱, 패키지된 Firefox Marketplace 앱 그리고 node-webkit 앱은 언제나 오직 Chrome이나 Firefox로만 실행되는데, 둘 다 OGG Vorbis를 지원하고, 따라서 이 경우 AAC 파일들은 쓰일 일이 없으니 건너뛰어집니다. 이와 유사하게 Windows 8이나 Windows Phone 8로 export하는 경우, 이 플랫폼은 오로지 AAC만 지원하고 OGG Vorbis 파일들은 쓰일 일이 없으므로 OGG Vorbis 파일들은 건너뛰어집니다. 반면에, HTML5 웹사이트, 호스팅된 앱, 또는 Scirra Arcade로 export하는 경우에는 양쪽 포맷이 다 필요하다는 뜻인데, 이는 모든 웹 브라우저들을 커버하는 하나의 포맷이 없기 때문입니다.
요컨대, 프로젝트를 export할 때 오디오 파일들을 수동으로 지워야 할 필요는 전혀 없습니다 - Construct 2가 항상 WAV 파일은 누락시키고, 또 가능하면 한쪽 세트의 파일들을 자동적으로 누락시킬 것입니다.
멀티 코어 프로세싱
데이터 중복 제거와 재압축 단계는 export 속도를 높이기 위해 가능한 모든 CPU 코어에서 진행됩니다. (스프라이트시트화와 몇몇 다른 export 작업들은 여전히 싱글 스레드 방식이지만(single-threaded), 보통 그런 작업들은 큰 프로젝트에서라도 매우 빠릅니다.) 예를 들어 쿼드 코어 장치에서 Construct 2는 4개의 이미지를 한 번에 병렬처리로 재압축해, 그 단계를 4배 빠르게 할 수 있을 것입니다. 혹시 export에 시간이 오래 걸린다면 새 컴퓨터를 살 때가 된 것입니다. CPU 코어가 많은 걸로요!
결론
Construct 2는 export 시에 많은 일들을 합니다. 주요한 것들은
- 중복되는 이미지에 대해서 걱정하지 마세요 - 자동으로 지워집니다.
- 이미지 포맷(예: PNG-8, PNG-32, JPEG)은 오로지 다운로드 크기에만 영향을 미치며, 실행 중 메모리 사용에는 영향이 없습니다.
- 될 수 있으면 스프라이트 이미지를 2의 거듭제곱 크기 바로 밑으로 해서, 스프라이트시트에 효율적으로 통합될 수 있게 하세요. 하지만 Tiled Background는 정확히 2의 거듭제곱 크기로 만들도록 하세요.
- Construct 2 에디터에 손실되는(lossy) 이미지 파일을 import하지 마세요(예: PNG-8이나 JPEG). 이것들은 export할 때 Image Format 대화 상자에서 직접 지정한 포맷대로 변환되기 전까지는 항상 무손실 PNG-32로 저장되어 있습니다.
- 에디터로 import한 스프라이트시트를 Construct 2가 분리된 파일들로 찢어놓는다는 사실에 대해 걱정하지 마세요. export 시에 가장 메모리에 효율적인 방식으로 다시 스프라이트시트화하는 겁니다.
- export된 이미지 파일들을 다른 압축 툴이나 서비스를 통해 정돈하려 노력하지 마세요. Construct 2가 벌써 잘 해놨을 겁니다.
- 스크립트 최소화(script minification)를 위해 Java를 설치하세요.
- export하기 전 오디오 파일들을 수동으로 삭제하려고 하지 마세요. Construct 2가 export에서 확실히 필요치 않은 파일들을 자동으로 삭제합니다.
- export가 느리면, CPU 코어가 더 많은 새 장치를 구해보세요!
export 시 Construct 2가 하는 일을 알고 있으면 Construct 2를 이용한 효율적인 작업에 도움이 되고, 쓸데없는 일들을 피할 수 있습니다.