Search Unity

2D 픽셀 퍼펙트: Unity로 레트로 16비트 게임 제작하기

, 8월 2, 2019

이전에 포스팅한 첫 번째 2D 픽셀 퍼펙트 가이드에서는 Unity로 레트로 게임을 제작하기 위한 2D 픽셀 퍼펙트 툴 설정 방법과 과거의 8비트 그래픽스 제작 방식을 소개했습니다. 이번 포스팅에서는 16비트 시대로 넘어가서, Mega Cat Studios와 함께 Unity 설정, 그래픽스 구조, 컬러 팔레트를 사용하여 Sega Genesis(또는 Mega Drive)와 Super NES 스타일 게임 아트를 제작하는 방법을 소개합니다.



Mega Cat Studios 는 고도로 정교화된 레트로 게임 제작 과정을 예술의 경지에 올려놓았습니다. 실제로 이 스튜디오에서 작업한 타이틀 중 몇 가지는 카트리지 형태로 구입하여 Sega Genesis와 같은 레트로 콘솔에서 플레이할 수 있습니다.

레트로 게임에 2D 픽셀 퍼펙트 사용하기

이번 포스팅을 참고하기 전에, 2D 픽셀 퍼펙트 설정과 8비트 형식 그래픽스를 재현하는 방법을 소개한 이전 포스팅을 읽어보시기 바랍니다.

Unity 2019.2버전부터는 경량 렌더 파이프라인(LWRP) 패키지의 2D 렌더러에 2D 픽셀 퍼펙트가 포함되어 있습니다. 또한 2D 픽셀 퍼펙트는 LWRP를 사용하지 않는 크리에이터를 위해 독립형 패키지(기능 동일)로도 제공됩니다. 이 포스팅에서는 LWRP에서 프로젝트를 설정하는 방법을 소개합니다.

Unity 2019.2 LWRP에서 프로젝트 설정

  1. Unity Hub에서 ‘새로 생성’을 클릭하고2D를 선택한 다음 프로젝트 이름을 설정합니다.

2. 2D 픽셀 퍼펙트 패키지를 임포트하려면 툴바의 Window 메뉴를 클릭하고 Package Manager를 선택합니다. 팝업 창에서 Lightweight RP 패키지를 선택하여 버전 6.9.0 이상인지 확인합니다.

3. 다음으로 에디터에서 2D 렌더러를 구성하고 새로운 파이프라인 에셋을 생성합니다. 프로젝트(Project) 창에서 에셋(Assets) 뷰를 마우스 오른쪽 버튼으로 클릭하고 Create > Rendering > Lightweight Render Pipeline > Pipeline Asset순서로 선택합니다.

4. 프로젝트 창의 에셋 뷰를 마우스 오른쪽 버튼으로 클릭하고 Create > Rendering > Lightweight Render Pipeline > 2D Renderer를 차례로 선택하면 새로운 2D 렌더러를 생성할 수 있습니다.

5. 생성한 파이프라인 에셋을 선택합니다. General을 선택하고 Renderer Type을 Forward Renderer에서 Custom으로 변경합니다.

6. 생성한 2D 렌더러를 데이터 필드에 할당합니다.

7. Graphics 설정에서 새로 생성한 파이프라인 에셋을 사용하도록 Scriptable Render Pipeline Settings를 설정합니다.

이제 2D 픽셀 퍼펙트 카메라를 비롯한 2D 렌더러 구성이 완료되었습니다.

Unity 2019.2에서는 2D 스프라이트에 “Sprite-Lit” 머티리얼을 포함하여 2D 조명 상태에 반응할 수 있습니다. 프로젝트에서 2D 조명을 사용하지 않는 경우, 2D 조명이 없어도 스프라이트가 보이는 머티리얼이 있는지 확인하고 머티리얼을 “Sprites-Default”로 변경합니다.

16비트 그래픽을 위한 픽셀 퍼펙트 설정

메인 카메라에 픽셀 퍼펙트 카메라 컴포넌트를 추가해야 합니다. Run In Edit Mode를 선택할 것을 권장합니다.

Sega Genesis 콘솔의 해상도는 320×224픽셀(또는 8×8픽셀 타일 40×28개로 구성된 그리드)로, NTSC 버전입니다. Super NES의 해상도는 NTSC 버전에서 256×224(8×8픽셀 타일 32×28개)입니다.

두 그래픽 형식 모두 224픽셀의 높이 해상도를 사용하고 에셋을 8PPU로 설계할 것을 권장합니다.

레퍼런스 스프라이트(Sega Genesis의 Sonic the Hedgehog에 사용된 풀스크린 320×224 이미지 참조)를 사용하면 단위당 8픽셀(PPU)의 스프라이트가 동일한 해상도와 PPU를 갖는 씬(Scene) 뷰에 적용되는 모습을 확인할 수 있습니다.

2D 픽셀 퍼펙트 카메라 컴포넌트에서 각 옵션이 하는 역할은 이전 레트로 게임 블로그 포스팅을 참조하시기 바랍니다.

Genesis 스타일 아트워크 제작

이번에는 NES 블로그 포스팅에서 다룬 바와 같이 다양한 콘솔 디자인을 모방하는 아트워크를 생성하는 방법을 소개합니다. Genesis는 8비트 프로젝트에 비해 제약이 적고 컬러 면에서도 더 많은 자유를 제공하지만 나름의 한계가 있습니다. 따라서 하드웨어의 작동 원리를 살펴본 후 이러한 한계를 나만의 레트로 프로젝트에 적용해 봅시다.

팔레트 하위 팔레트

8비트 콘솔에서 16비트 콘솔로 넘어가면 보다 정교한 하드웨어에서 더 많은 옵션이 제공됩니다. 하지만 멋진 NES 아트워크를 제작하기 위한 기본 원리는 변하지 않습니다. 예를 들어 모든 그래픽은 8×8 타일로 저장된 다음 스프라이트나 배경 요소 등 더 큰 이미지로 조합됩니다. 16비트는 어떤 면에서 팔레트를 더 자유롭게 사용할 수 있도록 하지만, 여전히 공통 투명 컬러가 포함된 제한적인 하위 팔레트를 사용하게 됩니다. 일반적으로 16비트 콘솔에는 8비트 콘솔과 달리 하드 코딩된 컬러 팔레트가 없어 NES보다 훨씬 다양한 컬러를 사용할 수 있습니다.

다음으로, Genesis는 스프라이트 투명도와 레이어 투명도에 사용되는 공통 컬러 외에도 15가지 컬러로 구성된 하위 팔레트를 갖추고 있습니다. 하지만 Genesis 아트 디자인의 약점 중 하나가 바로 하위 팔레트입니다. 하위 팔레트를 스프라이트나 배경 타일에 자유롭게 할당할 수 있지만 Genesis에서는 한 번에 4개의 하위 팔레트만 사용할 수 있습니다. 이로 인해 아티스트는 하위 팔레트에서 컬러 선택에 유의하여 스프라이트와 배경의 컬러 구성을 최대한 다양화해야 합니다. 모든 요소를 깔끔하게 표현하기 위해 Genesis의 하위 팔레트에는 보통 배경과 스프라이트 모두에 사용되는 컬러가 포함되어 있습니다.

위는 Genesis 씬이며, 아래는 사용된 하위 팔레트입니다.

16비트 플랫폼용으로 제작하려면 색인 팔레트로 작업해야 합니다. Photoshop 대신 오픈 소스인 Gimp를 사용하면 색인 팔레트를 다양하게 조작할 수 있습니다.

Gimp에서 색인 팔레트를 생성하려면 Image > Mode > Indexed로 이동합니다.

Indexed Color Conversion 창이 표시됩니다.

Maximum number of colors를 15로 설정합니다. 자동 디더링 패턴을 사용할 수도 있지만, 보통 직접 생성하는 경우 디더링 패턴 품질이 더 좋습니다.

이제 이미지 컬러 색인이 완료되었습니다. 이 정보는 자동으로 이미지와 함께 저장되어 컬러 색인을 사용할 수 있습니다. 색인에서 컬러의 순서를 변경하려면 컬러 맵을 마우스 오른쪽 버튼으로 클릭하고 Rearrange Colormap을 선택합니다.

팝업 메뉴에서 드래그 앤 드롭을 통해 컬러를 새로운 순서로 배치할 수 있습니다.

더 풍부한 색심도를 구현하기 위해 흔히 사용되는 방법 중 하나는 지정된 래스터 라인을 따라 팔레트를 제어하여 NES의 패럴랙스 스크롤과 같은 효과를 내는 것입니다. Genesis는 지정된 래스터 라인을 기준으로 하위 팔레트 구성을 변경할 수 있습니다. 이러한 방식은 레벨 일부가 물에 잠긴 것과 같은 효과를 구현하기 위해 자주 사용됩니다. 완전히 별도의 하위 팔레트 구성에 “수중” 컬러가 추가된 후, 특정 래스터 라인이 스크린에 렌더링되면 하위 팔레트 구성이 로드됩니다.

하드웨어에 타일 저장 로딩

일반적으로 16비트 콘솔이 그래픽스 타일을 로드하는 방식은 8비트 콘솔과 다릅니다. 8비트 콘솔은 처리 용량을 절약하기 위해 스프라이트와 배경 타일을 큰 데이터 단위로 개별적으로 로드하는 반면 16비트 콘솔의 처리 용량은 더 유연합니다. 16비트 콘솔은 개별 타일을 즉시 로드하고 교체할 수 있어 필요할 때 원하는 그래픽만 로드할 수 있습니다. 따라서 게임의 단일 레벨이나 스크린에서 더 다양한 아트워크를 사용할 수 있습니다.

Genesis/Mega Drive의 또 다른 고유한 특성은, 게임 실행 시 콘솔의 VRAM에 그래픽 타일과 팔레트 데이터만 로드되는 것이 아니라는 점입니다. 특정 시간에 메모리에 로드될 수 있는 그래픽 타일의 개수는 게임에서 진행되고 있는 여러 요소들에 따라 달라지기 때문에 콘솔을 위한 아트 제작이 까다로울 수 있습니다. 일반적으로 대부분의 게임에는 최대 약 1000개의 타일을 로드할 수 있는 공간이 있으며 동적 요소가 있는 경우에는 타일을 언제든지 자유롭게 교체할 수 있습니다.

이전 씬에서 메모리로 로드된 타일. 가운데에 있는 커다란 빈 공간과 하단의 아티팩트는 메모리에 적과 기타 게임 요소를 할당하기 위한 공간입니다

VRAM에 더 많은 가용 타일을 한 번에 로드할 수 있지만 대부분 추가 공간은 스프라이트를 위해 비워두어 더 다양한 애니메이션과 스프라이트 유형을 한 번에 스크린에 구현할 수 있도록 합니다. 따라서 배경이 가용 공간을 너무 많이 차지하지 않도록 반복되는 타일 세그먼트를 사용한다는 기본적인 디자인 원칙이 16비트 아트에서도 여전히 유효합니다. NES, Genesis, SNES의 해상도는 모두 매우 유사하기 때문에 이러한 종류의 디자인은 16×16 세그먼트로 시작되는 경우가 많습니다.

아티스트는 배경에서 이동 가능한 공간의 대부분을 깔끔한 32×32 블록 패턴을 사용하여 구현했습니다.

배경 레이어 작업

Genesis/Mega Drive에서는 한 번에 2개의 배경 레이어를 스크린에 활성화할 수 있습니다. 따라서 배경을 디자인할 때 레이어 요소를 더 쉽게 사용할 수 있습니다. 하지만 2개의 레이어에 불과하기 때문에 아티스트와 개발자는 씬의 뎁스를 더욱 풍부하게 구현하기 위해 래스터 라인 기법을 사용해야 합니다. 다행히도 이러한 모든 요소를 두 번째 레이어에 배치할 수 있기 때문에 디자이너는 그래픽 효과를 유지하면서 전경 오브젝트를 배경 앞에 배치할 수 있습니다.

또한 두 번째 레이어가 있기 때문에 전경 오브젝트를 만들 때 스프라이트의 우선 순위를 크게 고려할 필요가 없습니다. 이제는 스프라이트 우선 순위를 신속하게 반복적으로 변경하지 않고도 플레이어 앞에 두 번째 배경 레이어를 표시하도록 설정할 수 있습니다. 물론 이보다 고급 레이어링의 경우에는 여전히 스프라이트 우선 순위를 빠르게 조정해야 할 수 있습니다. 또한 두 번째 배경 창에는 헤드업 디스플레이(HUD)에 사용할 수 있는 하위 창이 있습니다. 하위 창은 제자리에 고정되며 스크롤되지 않습니다.

Due to the game’s top-down view, special tiles needed to be created for the tree in order to manipulate Sprite layer order.

스프라이트의 한계

16비트에서는 스프라이트로 작업하기가 더 자유롭습니다. Genesis/Mega Drive에서는 새로운 스프라이트 렌더링이 중지될 때까지 스크린상 동시에 80개, 그리고 단일 수평선상 약 20개의 스프라이트가 허용됩니다. 이 한계를 넘어서면, 스프라이트는 더 이상 개별 8×8 타일로 계수되지 않습니다. Genesis는 여러 타일로 구성된 단일 스프라이트를 생성할 수 있습니다. 이러한 단일 스프라이트의 크기는 작게는 타일 한 개부터 크게는 4×4 타일까지 다양하며, 이보다 큰 경우에는 여러 스프라이트로 구성되어야 합니다.

최종 보스는 애니메이션 배경 요소, 레이어, 스프라이트를 많이 사용합니다. 이는 8비트 플랫폼에서는 구현할 수 없습니다.

디더링 패턴 대비

16비트 시대 아트워크의 뚜렷한 특징 중 하나는 디더링을 사용한다는 점입니다. 이 시대의 게임은 화면의 픽셀이 서로 번지는 경향이 있던 CRT 모니터에 송출되었습니다. 따라서 당시 아티스트는 디더링 패턴을 사용하여 한 픽셀이 반복적인 패턴으로 다른 픽셀로 번질 때, 실제로 주어진 컬러보다 다양한 컬러 효과를 구현했습니다. 현재는 디스플레이가 많이 발전했지만 픽셀 아트의 정확한 심미적 효과를 유지하기 위해 여전히 디더링을 사용하고 있습니다.

디더링은 16비트에서 많이 사용되었습니다. CRT에서는 픽셀의 패턴이 한데 섞여, 다른 방식으로는 구현이 불가능한 새로운 컬러나 투명 효과를 구현했습니다.

2가지 주요 16비트 콘솔 중 Genesis/Mega Drive는 컬러의 대비를 훨씬 더 풍부하게 표현합니다. 이는 하위 팔레트 선택 시에도 고려해야 할 사항입니다. 하드웨어에서 실제로 이미지를 렌더링하는 경우, 침침하고 단조로운 톤을 적용하면 원하는 디자인이 구현되지 않습니다. 일반적으로 최종 결과가 아티스트의 원래 의도와 일치하려면 고대비 컬러 팔레트를 사용하여 아트를 생성해야 합니다.

SNES 스타일 아트워크 제작

Super NES 프로젝트의 경우 여전히 8×8픽셀 크기의 타일/그리드로 작업하기 때문에 반복 가능한 타일로 작업하는 것이 좋습니다. 일반적으로 이러한 타일은 8의 배수인 경우가 많습니다.

컬러 팔레트

Genesis/Mega Drive와 SNES 간 첫 번째 본질적인 차이는 컬러 팔레트입니다. Mega Drive와 마찬가지로, SNES에는 하드 코딩된 컬러 팔레트가 없기 때문에 컬러를 직접 선택할 수 있습니다.

SNES에서 난감한 부분은 현재는 보기 힘든 픽셀당 5비트(5BPP) 컬러를 사용한다는 점입니다. 이 문제를 해결하려면, Gimp로 아트워크를 생성한 다음 이미지를 32개의 RGB 색조로 단순화하여 이미지를 5BPP 컬러로 저장하지 않아도 5BPP 컬러로 처리되도록 합니다. 이렇게 하면 이미지 컬러가 콘솔에 정확하게 나타납니다.


Gimp에서 Colors > Posterize… 로 이동하면 이 옵션을 찾을 수 있습니다. 팝업 창이 나타나면 Posterize levels를 32로 설정하여 5BPP에 호환 가능한 컬러를 구현할 수 있습니다.

스크린 해상도

두 시스템 간에 다음으로 큰 차이점은 스크린 해상도입니다. SNES가 NES의 뒤를 이었기 때문에 두 시스템의 스크린 해상도는 유사합니다. SNES의 내부 해상도는 256×224입니다. 따라서 렌더링되는 이미지가 대부분 CRT 텔레비전의 안전한 영역에 표시되므로 이미지가 잘리지 않습니다. 이 해상도는 절대 변경되지 않으므로 아티스트는 이 이미지 크기를 레퍼런스로 사용해야 합니다.

이 이미지는 대부분의 스크린 모드에서 사용되는 SNES의 풀스크린 해상도를 사용하도록 설정되어 있습니다.

하드웨어의 스크린 모드

이 섹션에서는 다양한 스크린 모드가 제공하는 기능을 간략히 소개합니다.

두 시스템 간 가장 큰 차이점은, SNES는 배경 그래픽을 7가지 스크린 모드로 렌더링할 수 있다는 점입니다. SNES는 특정 스크린 모드에서 단일 하위 팔레트로 한 번에 스크린에 총 256가지 컬러를 렌더링할 수 있습니다. 가장 자주 사용되는 스크린 모드의 예는 다음과 같습니다.

  • 모드 1: SNES에서 가장 흔히 사용되는 스크린 모드로, 콘솔 기능을 평균적으로 가장 잘 보여줍니다. 모드 1은 3개의 배경 레이어를 허용하는데 그 중 2개에는 자체적인 16컬러 하위 팔레트가, 나머지 1개에는 4컬러 하위 팔레트가 있습니다.
  • 모드 3: 타이틀 스크린, 또는 스토리 스크린과 같이 비교적 큰 규모의 정적 이미지에 흔히 사용되는 모드입니다. 2개의 배경 평면을 제공합니다. 첫 번째 평면은 전체 256컬러 하위 팔레트를, 두 번째 평면은 16컬러 하위 팔레트를 사용합니다.
  • 모드 7:이 모드는 SNES의 주요 특징 중 하나였습니다. 대부분의 SNES 콘솔 홍보 자료에 등장한 모드 7을 통해 최초로 가정용 콘솔이 실시간으로 이미지를 변환하여 배경 평면에서 이미지 확대/축소, 회전, 늘이기, 왜곡이 가능하게 되었습니다. 모드 7은 많은 SNES용 자동차 경주 및 비행 게임에서 유사 3D 효과를 구현하는 데 사용되었습니다.

모드 7의 단일 배경 평면은 여러 기능을 수행하기 위해 나머지 스크린 모드와 다른 방식으로 처리됩니다. 먼저, 작업할 수 있는 256컬러 배경 평면이 하나밖에 없기 때문에 모든 스프라이트는 배경 평면의 하위 팔레트와 컬러를 공유합니다. 다음으로, 모드 7의 배경 평면은 일반적인 SNES 스크린 크기가 아니라 1024×1024픽셀 크기입니다. 하지만 디자이너가 원하는 크기에 맞게 스크린을 조정할 수 있습니다.

이 사무실에는 모드 1에 1개의 하위 팔레트가 사용되었습니다(나머지 두 개는 UI에 사용). Thanks for Playing 화면에는 256컬러 팔레트를 활용할 수 있는 모드 3이 사용되었습니다.

스프라이트 크기

복잡한 배경 스크린 모드에 비해 스프라이트 규칙은 비교적 간단합니다. Mega Drive와 마찬가지로 SNES에는 다양한 스프라이트 모드가 있지만 게임 전체를 통틀어 2가지의 스프라이트 모드만을 사용할 수 있다는 한계가 있습니다.

스프라이트 크기로는 8×8, 16×16, 32×32, 64×64가 있지만 디자이너는 사전 설정된 스프라이트 크기 조합 목록에서 크기를 선택해야 합니다. SNES의 게임에 허용되는 크기 조합은 다음과 같습니다.

  • 8×8, 16×16
  • 8×8, 32×32
  • 8×8, 64×64
  • 16×16, 32×32
  • 16×16, 64×64
  • 32×32, 64×64

크기를 선택하면 그대로 고정되어 게임 내 모든 스프라이트가 이 크기를 따라야 합니다. SNES는 하나의 수평 래스터 라인에 32개의 스프라이트를 동시에 렌더링할 수 있지만 한 번에 스크린에 나타날 수 있는 총 스프라이트 수는 128개에 달합니다. 이를 초과하는 스프라이트는 스크린상에 렌더링되지 않습니다.

Fork Parker의 Crunch-Out에서는 게임 내 모든 스프라이트에 32×32와 16×16의 조합을 사용했습니다.

스프라이트에는 16컬러의 하위 팔레트 8개를 사용할 수 있습니다. 모든 레트로 콘솔과 마찬가지로, 모든 하위 팔레트의 첫 번째 컬러는 투명도를 결정하는 공통된 컬러입니다. 다른 콘솔에 비해 하위 팔레트 수가 많기 때문에 스프라이트 컬러 선택이 더 자유롭습니다. 하지만 256가지 색상으로 제한된다는 점에 유의해야 합니다.

 

향후 계획

Unity 최신 버전에 포함된 2D 픽셀 퍼펙트 기능을 사용하여 8비트와 16비트 레트로 게임을 제작하는 방법에 관한 포스팅이 도움이 되었기를 바랍니다.

Unity 2019.3 버전에서는 정식 제작에 2D 픽셀 퍼펙트의 사용 가능성을 확인하고, 시네머신 2D와의 호환성도 개선할 예정입니다.

2D 포럼을 방문하셔서 2D 픽셀 퍼펙트 프로젝트가 어떻게 진행되고 있는지 알려주시기 바랍니다.

16 replies on “2D 픽셀 퍼펙트: Unity로 레트로 16비트 게임 제작하기”

I find it a bit odd that you discussed the bit depth of the SNES but not the Genesis…. The reason the Genesis “displays its colors with much greater contrast” is because its palette is stored in 3 bits-per-channel format, meaning it had fewer possible shades than the SNES.

Also, “BPP” usually refers to the number of bits per *pixel,* not the number of bits per *palette entry.* For the reader’s reference: SNES uses 5 bits per *channel of a palette entry*, for a total of 15 bits per entry.

Didn’t know about the posterize trick, though. That could be very handy! Now if only I could make it treat 248 as the top of a channel rather than 255….

These 8-bit and 16-bit Pixel Perfect posts are great! Thank you very much for creating them! :D
A question, is there already in Unity a feature to natively (i.e: no use of shaders) indexed palette swapping? If it’s not, is it planned for the (hopefully not too distant) future? :)

There’s a bug where clicking UI elements becomes inaccurate if you use a custom 2D Renderer data in the LWRP Data.

This. Looks. Adorable!! Thanks for taking the time to write about this! Even though I mostly do 3D, I’m definitely gonna save this and look at it later. There’s something magical about this kind of pixel-art/art style… ah…

Comments are closed.