iPhone에서 만드는 픽셀 아트 세계: 16비트 거장들이 알고 있던 것

Final Fantasy VI의 파티원은 16×24픽셀이고, 전투에서 쓸 수 있는 색은 12가지이며, 최대 181개의 타일로 조립한 46가지 포즈를 가집니다. 그리고 같은 스프라이트가 필드와 월드맵, 모든 전투를 걸어 다닙니다.¹ Pokémon Emerald는 두 개 레이어로 된 16×16 “메타타일”로 모든 마을을 그리고, 맵 한 칸은 16비트입니다. 타일에 10비트, 충돌 판정에 2비트, 높이에 4비트입니다.² Celeste는 세계 전체를 320×180으로 렌더링한 뒤 6배로 확대합니다.³ 이 세 숫자 안에 기술의 핵심이 들어 있습니다. 셀을 정하고, 팔레트를 정하고, 캔버스를 정한 다음에야 그 안에 그리는 것입니다. 저희 앱 Kiradex에도 RealityKit으로 렌더링한 픽셀 광장이 있는데, 이 기준에 비추어 보니 대부분의 항목에서 낙제였습니다. 28개 타일 세트는 임시변통으로 고른 단색 평면이라 램프도 없고, 아웃라인 규칙도 없고, 오클루전도 없고, 보행은 두 프레임이었습니다. 그래서 제대로 조사했습니다. SNES 시대에 관한 출처 있는 보고서 여섯 편, 디컴파일 결과에서 읽어낸 Pokémon의 타일 시스템, 현대의 거장들, 기법 그 자체, Apple의 렌더링 경로, 그리고 사회적 세계로서의 수집형 게임입니다. 이어지는 내용은 제가 갖고 싶었던 바로 그 가이드입니다. 숫자들과, 3배 해상도 iPhone 화면 및 iPhone Duo의 두 디스플레이에서 픽셀을 또렷하게 유지하는 실측 레시피, 그리고 규칙에 따라 세계를 다시 지은 첫 결과를 담았습니다.

TL;DR

• 거장들은 제약에서 출발해 바깥으로 작업했습니다. SNES가 준 것은 16색 타일을 위한 배경 팔레트 8개와 스프라이트 팔레트 8개(각 15색), 8×8 타일, 그리고 주사선당 32개의 스프라이트였습니다. Square의 답은 16×24 셀 하나, 포즈 라이브러리, 그리고 타일 공유였습니다.⁴¹ Game Boy가 준 것은 네 단계의 명암이었고 Pokémon Red의 타일셋은 96타일이었습니다. Game Freak의 답은 32×32 블록과, 그림을 한 장도 더 그리지 않고 수풀에서 발을 가려 주는 우선순위 비트였습니다.⁵⁶
• 픽셀 세계가 하나의 장소로 읽히는지는 세 가지 결정이 좌우합니다. 빛의 방향과 그림자 색조를 하나로 통일할 것(Seiken Densetsu 3 팀은 검정 대신 짙은 파랑과 보라로 음영을 넣었습니다), 모든 스프라이트에 하나의 아웃라인 규칙을 적용할 것(FF VI의 실루엣은 가장자리의 93퍼센트가 거의 검정이고, Secret of Mana에는 검정이 전혀 없습니다), 그리고 밝고 어두운 색견본이 아니라 색상을 이동시킨 컬러 램프를 쓸 것입니다.³³⁸⁹
• 현대의 조명 등급표는 아래쪽은 감당할 만하고 위쪽은 파멸적입니다. Moonlighter는 스프라이트를 겹쳐 빛을 흉내 내고, Celeste는 2048픽셀 아틀라스 한 장에 조명을 마스크로 그리며, Eastward는 모든 애셋의 범프 맵을 손으로 칠합니다. HD-2D는 프로듀서의 표현을 빌리면 “생각보다 비용이 많이 드는” 방식이고, 플레이어들은 피사계 심도를 꺼 버립니다.^10111213
• Apple 플랫폼에서는, 진짜 3D 오브젝트 하나를 품은 2D 세계라면 RealityKit에 머무르고 AR 기본값을 끄십시오. 픽셀 아트에 필요한 모든 기능에는 문서화된 API가 있습니다(nearest 샘플러, 밉맵 없음, 불투명도 임계값, 프레임별 UV 변환). 다만 RealityView는 기본적으로 모션 블러와 HDR 톤 매핑을 적용하므로, 이 레시피는 피사계 심도, 그레인, 안티에일리어싱과 함께 그것들을 끕니다.¹⁴¹⁵¹⁶ 그렇게 하기 전까지 저희 보행 캐릭터는 발을 내딛을 때마다 번졌습니다.
• iPhone에서의 정수 배율은 포인트가 아니라 픽셀로 하는 산수입니다. 3배 환경에서 텍셀 하나가 6픽셀이면 2포인트이므로 16텍셀 타일은 32포인트입니다. iPhone 18 Pro Max는 텍셀당 8픽셀로 10.3×22.4 타일을, 펼친 iPhone Duo는 6픽셀로 29.7×20.9 타일을 보여 줍니다. 현행 iPhone 중 높이가 320으로 나누어떨어지는 기종은 하나도 없으므로, “세로로 정확히 20타일”은 언제나 레터박스를 뜻합니다.¹⁷
• 규칙으로 그린 자기 그림이 깔끔한 길입니다. 미국 저작권청의 2025년 1월 보고서는 저작권 성립에 “프롬프트만으로는 충분한 통제를 제공하지 못한다”고 말합니다. 화풍은 보호되지 않지만 특정 타일과 캐릭터는 보호됩니다. 그래서 저희는 58색 팔레트 하나와 손으로 정한 규칙으로 모든 타일을 그리는 포지(forge)를 만들었습니다. 첫 번째 필드와 다시 지은 광장은 글 끝에 있습니다.¹⁸¹⁹

1. 16비트 거장들이 상대하던 것

Super Nintendo에는 프레임버퍼가 없었습니다. 그래픽 프로세서는 186나노초마다 픽셀 하나를 내보내야 했는데 비디오 메모리의 응답은 100나노초였습니다. 그래서 8×8 타일로 된 맵에서 여덟 픽셀을 미리 가져오고, 수평 귀선 기간 동안 스프라이트를 라인 버퍼에 조립했습니다.⁴ 아티스트들이 한 모든 일은 여기서 비롯됩니다. 16색 타일을 위해 256개 항목의 컬러 메모리는 배경 팔레트 8개와 스프라이트 팔레트 8개로 나뉘었고, 각 팔레트는 15색에 투명 인덱스 하나였습니다. 배경은 컬러 메모리의 앞 절반을, 스프라이트는 뒤 절반을 썼습니다.²¹ 스프라이트는 8, 16, 32, 64픽셀 정사각형으로 나왔고 동시에 쓸 수 있는 크기는 두 가지, 오브젝트 메모리에는 128개까지 들어갔습니다. 하나의 주사선에는 스프라이트 32개 또는 8픽셀 조각 34개까지만 올라가고 나머지는 사라졌습니다.²¹ 대부분의 RPG가 쓰던 모드(Mode 1)의 배경은 16색 레이어 둘과 4색 레이어 하나였고, Mode 7은 256개 타일로 이루어진 1,024×1,024픽셀 타일맵 하나로²² 주사선마다 어파인 변환을 걸어 지평선으로 기울일 수 있었습니다.²³ 비디오 메모리는 전부 합쳐 64KB였고 타일맵, 배경 타일, 스프라이트 타일이 이를 나누어 썼습니다.²⁰

또 하나의 벽은 카트리지 용량이었습니다. Final Fantasy IV는 8메가비트, Final Fantasy V는 16메가비트, Final Fantasy VI는 24메가비트로 출시되었고, Chrono Trigger는 막판에 24에서 확장되어 32메가비트가 되었습니다. Chrono Trigger의 디렉터 도키타 다카시는 첫 숫자의 규모를 이렇게 표현했습니다. “이 카트리지에는 FFIV 네 개가 들어갑니다.” 추가된 8메가비트에 대해서는 디자이너 가마타 야스히코가 “8메가 중 6메가 정도가 그래픽에 쓰였다”고 말했습니다.²⁴²⁵ 사카구치 히로노부는 FF V의 마지막 몇 달을 두고, 스태프들이 “서로에게서 뺏을 수 있는 공간은 다 뺏어 갔다”고 표현했습니다.²⁶

제약이 강제한 것

제가 자꾸 돌아오게 되는 숫자는 포즈 예산입니다. 스프라이트 에디터는 FF VI의 캐릭터마다 애니메이션 17개와 정지 포즈 13개, 모두 46개의 고유 포즈를 열거하며 반전을 포함하면 약 92개가 됩니다. 포즈 하나당 여섯 타일이고 포즈끼리 대량으로 공유합니다. 보행과 나머지 3포즈 애니메이션은 1-2-1-3 순서로 재생되므로 화면에 보이는 주기는 네 프레임입니다.¹ 기타세 요시노리는 FF VI가 FF V의 “두 배가 넘는 패턴”을 가졌다고 말했는데, 바로 그 덕분에 스프라이트 하나가 필드와 전투를 모두 감당할 수 있었습니다.⁷ 표현을 만들어 낸 것은 픽셀이 아니라 프레임이었습니다.

시부야 가즈코의 방법

시부야 가즈코는 Final Fantasy I부터 VI까지의 스프라이트를 그렸고 Pixel Remaster의 다시 그리기를 총괄했습니다. 그가 남긴 증언은 기록에 남은 것 가운데 가장 명료한 방법론입니다. 스프라이트를 어디서 시작하는지에 대해. “원칙적으로 선보다는 면에서 시작한다고 할 수 있습니다.” 그리고 “먼저 큰 면을 대충 채워 넣은 다음, 조각하듯이 조금씩 다듬어 나갑니다.”⁸ 가독성에 대해. “플레이어가 캐릭터를 구분할 수 있어야 하니, 디자인을 보고 가장 특징적인 요소만 담습니다.”²⁹ FF IV의 16×16 스프라이트에 아웃라인이 없었던 이유에 대해. “픽셀 하나하나가 생사의 문제였기 때문에 외곽선에 쓸 여유 같은 건 없었습니다.”⁸ 사카구치 히로노부는 그 결과를 애니메이션 쪽에서 덧붙였습니다. “팔을 높이 들어 올릴 수 없으니, 기쁨을 표현할 방법은 빙글 도는 것밖에 없었죠!”⁸

일러스트레이터와 픽셀 아티스트는 서로 다른 사람이었고, 둘 사이에는 글 한 통이 있었습니다. 사카구치 히로노부의 말입니다. “아마노 씨에게 일러스트를 의뢰할 때는 글로 된 설명으로 합니다.”⁸ Chrono Trigger에서 도리야마 아키라는 “캐릭터 일러스트와 콘셉트 아트만” 맡았고 뒷모습은 한 번도 그리지 않았습니다. 스프라이트 팀의 우치야마는 이렇게 말했습니다. “그냥 추측하는 수밖에 없었습니다.”³⁰ 노무라 데쓰야는 FF VI의 최종 보스를 스케치북에 “화면 단위로” 그린 뒤 스캔해서 그 스캔으로 스프라이트를 만들었습니다.³¹ 1994년에 이미 파이프라인은 혼합형이었습니다. 마법 이펙트는 별도의 3D 도구에서 모델링한 뒤 겹쳐 올렸습니다.³²

세 가지 “결”, 측정하다

평자들은 FF VI, Chrono Trigger, Secret of Mana를 한데 묶어 “SNES다움”이라고 부릅니다. 그러나 실제로는 셋이고, 차이의 대부분은 아웃라인 방침에 있습니다. 저희는 애니메이션 단위로 추출한 팬 아카이브에서 작품마다 주인공 하나씩을 가져와 모두 정확한 2배 확대본임을 확인한 뒤, 서 있는 프레임의 모든 가장자리 픽셀을 거의 검정(모든 채널이 255 중 40 이하), 중간 어두운 색, 밝은 색으로 분류했습니다.⁹

더 부드러운 가장자리는 Mana 시리즈에서 분명한 의도였습니다. 이시이 고이치는 Seiken Densetsu 3에 대해 이렇게 말했습니다. “그림자 같은 데에는 검정의 농담 대신 짙은 파랑과 보라를 써서 부드러운 느낌을 줍니다.” 그리고 스프라이트 담당과 배경 담당은 인물이 장면 안에 자리 잡도록 함께 작업했습니다. “스프라이트를 만들면서 배경을 완전히 무시해 버리면 장면의 방향 감각이 완전히 엉망이 됩니다.”³³ Chrono Trigger는 의도적으로 그 중간에 놓였습니다. 개발 과정에서 화면의 밝기를 Secret of Mana와 Final Fantasy 시리즈 “사이”로 유지했습니다.³⁴ 하나의 규칙을 게임 속 모든 스프라이트에 적용하는 것, 그것이 등장인물들을 하나의 배역진으로 보이게 합니다.

리마스터의 교훈

Pixel Remaster(2021년부터 2022년까지)는 16×24라는 기본 치수를 유지하면서 팔을 뻗고 망토를 날릴 수 있도록 위쪽과 양옆에 여유를 주었습니다. FF VI에서 시부야 가즈코는 1994년에 바라던 그 픽셀을 마침내 얻었습니다. “그때는 위에 딱 한 픽셀만 더 있으면 좋겠다고 간절히 바랐습니다. 이번 리마스터에서 그 소원이 이루어졌습니다.”³⁵ 그림은 “LCD 화면에 표시할 것을 전제로” 다시 그려졌습니다. 원본은 CRT의 번짐을 계산에 넣고 찍은 것이었기 때문입니다.³⁵ 뒤이은 논란은 스프라이트가 아니라 활자에 관한 것이었습니다. 출시 당시 폰트는 가느다란 현대적 서체였고, 뒤이어 나온 픽셀 폰트는 일본어 약 7,500자를 만드는 작업을 필요로 했습니다.³⁶ 반면교사가 되는 사례는 2014년 FF VI 모바일 이식판인데, 매끄럽게 다시 그린 그래픽을 두고 Kotaku는 “실수로 세탁기에 던져 넣은 것 같다”고 평했습니다.³⁷ 출시할 화면에 맞춰 그릴 것, 그리고 폰트를 그림으로 다룰 것입니다.

2. Pokémon의 타일 시스템, 세대별로

Square의 아티스트에게는 16색과 24메가비트 카트리지가 있었습니다. Game Freak의 아티스트에게는 네 단계 명암과 Game Boy가 있었고, 그 제약에 대응하려고 만든 시스템은 이 분야에서 가장 명료한 교재입니다. 이제 그 모든 세대를 pret 디컴파일로 읽을 수 있기 때문입니다. 이어지는 숫자들은 팬 위키가 아니라 소스 파일에서 직접 읽었습니다.³⁸

Game Boy는 160×144 화면을 픽셀당 2비트, 네 단계 명암의 8×8 타일로 그리며, 하드웨어 오브젝트는 40개, 한 주사선에는 열 개까지입니다.³⁹ Pokémon Red는 최대 96타일짜리 타일셋을 불러오고, 4×4 타일로 된 32×32 “블록”으로 세계를 짓고, 마을을 블록당 1바이트로 저장합니다. 게임 안의 어떤 블록셋도 128블록을 넘지 않습니다. 태초마을은 10×9 블록, 즉 320×288픽셀로 정확히 가로 두 화면, 세로 두 화면입니다.⁴⁰ 충돌 판정은 올라설 수 있는 8×8 타일 ID 목록이고, 엔진은 타일 하나, 앞쪽 칸의 왼쪽 아래만 검사합니다.⁴¹ 물은 타일 하나인데 그 16바이트를 오른쪽으로 한 픽셀씩 네 번, 왼쪽으로 네 번 비트 회전시킵니다. 꽃은 타일 하나를 저장된 세 프레임 사이에서 1-1-2-3 순서로 바꿔 끼우는 것이고, 이 애니메이션 체계 전체가 약 스무 프레임마다 작동합니다.⁴² 캐릭터는 8×8 오브젝트 네 개이며, 세 방향 각각의 선 자세와 걷는 자세로 여섯 프레임으로 그려지고, 오른쪽을 향한 프레임은 왼쪽을 뒤집어 만듭니다. 위아래 방향의 보행 주기는 서기, 걷기, 서기, 걷기의 반전이므로 걷는 프레임 하나만 그리면 두 다리가 모두 나옵니다.⁴³ 제가 가장 좋아하는 장치는 비용이 들지 않습니다. 스프라이트가 타일셋의 풀 타일 위에 서면 엔진이 아래쪽 두 오브젝트에 배경 우선순위 비트를 세우고, 풀이 다리 위에 그려집니다.⁶

Gold, Silver, Crystal은 블록 형식을 유지하면서 Game Boy Color의 새 하드웨어를 두 가지에 썼습니다. 타일셋은 두 개의 VRAM 뱅크에 걸쳐 192타일로 늘었고, 모든 타일이 이름 붙은 여덟 팔레트(GRAY, RED, GREEN, WATER, YELLOW, BROWN, ROOF, TEXT) 중 하나를 가집니다. 이 팔레트들은 아침, 낮, 밤, 어두운 곳, 실내에 대해 따로 정의되어 있어서, 성도 지방의 시간대 변화는 64바이트 팔레트 재적재일 뿐 두 번째 그림 세트가 아닙니다.⁴⁴ 충돌 판정은 각 블록의 16×16 사분면마다 유형이 붙은 1바이트(FLOOR, WALL, TALL_GRASS, WATER, DOOR, LADDER 등)로 옮겨 갔는데, 2세대가 32픽셀 블록을 저장하면서도 16픽셀 게임처럼 플레이되는 진짜 이유가 여기에 있습니다.⁴⁴ 다양성은 팔레트에서 나왔습니다. 다섯 개의 “사람” 팔레트는 같은 피부색을 공유하고 단 한 색만 다르므로, 시트 한 장을 다섯 가지로 다시 칠하면 마을 하나가 채워집니다.⁴⁵

Ruby, Sapphire, Emerald는 성숙한 모델이자 현대의 엔진이 본받아야 할 형태입니다. 타일셋은 지방 전체가 공유하는 기본 타일 512개와 마을별 보조 타일 512개, 그리고 둘 사이에 열세 개의 16색 팔레트로 이루어집니다. 메타타일은 16바이트입니다. GBA 스크린 엔트리 여덟 개, 즉 2×2 타일의 두 레이어이고 각 엔트리가 타일 ID와 반전 비트 둘, 팔레트를 담습니다. 속성 워드는 여기에 8비트 동작(수풀, 턱, 문, PC 등 모두 240가지)과 레이어 유형을 더합니다. Normal은 위 레이어가 스프라이트를 덮고, Covered는 아무것도 덮지 않으며, Split은 플레이어가 두 레이어 사이를 걷습니다.² 맵 한 칸은 16비트로, 메타타일에 10비트, 충돌 판정에 2비트, 높이에 4비트이며 높이 15는 다리 위와 아래를 모두 지날 수 있게 합니다.⁴⁶ 필드는 맵을 위해 하드웨어 배경 레이어 셋을 함께 스크롤하고 넷째 레이어는 고정해 텍스트에 씁니다. 그래서 지붕이나 나뭇잎 차양이 플레이어를 가리는 것은 어떤 정렬 처리 때문이 아니라 우선순위가 높은 레이어에 놓여 있기 때문입니다.² 꽃송이마을은 20×20 메타타일, 무궁시티는 30×30, 잿빛시티는 40×60, 백조마을은 80×40입니다.⁴⁷

캐릭터는 16×32, 하드웨어 스프라이트 하나가 되었고 144×32 시트에 아홉 프레임이 들어갑니다. 세 방향과 방향마다 두 걸음이며 동쪽은 서쪽을 뒤집은 것입니다. 보행은 걷기, 서기, 걷기, 서기를 각각 여덟 틱씩 재생하는데, 모두가 기억하는 그 들썩임입니다.⁴⁸ 타일 애니메이션은 프레임 카운터로 돌아갑니다. 열여섯 틱 중 0틱에 꽃, 1틱에 물, 2틱에 모래 가장자리, 3틱에 폭포, 4틱에 뭍과 물의 경계가 갱신되어 다섯 번의 DMA 쓰기가 같은 프레임에 겹치지 않습니다.⁴⁹ 물에 비친 모습은 가장 낮은 우선순위에 둔 스프라이트 복사본을 어파인 행렬로 뒤집고 팔레트를 바꾼 다음, 스프라이트 높이에서 2를 뺀 만큼 내린 것입니다. 그림자는 스프라이트가 공중에 떠 있는 동안, 즉 턱을 뛰어내리거나 자전거로 점프할 때만 존재합니다. 수풀은 이제 해당 칸에 생성되는 다섯 프레임 스프라이트로, 플레이어의 하반신 위에 겹칩니다.⁵⁰

표의 출처는 이 절에서 인용한 pret 저장소들입니다.^4044248

기록에서 두 가지를 더 짚겠습니다. 카드 수집가의 세계에 가장 가까운 조상인 Game Boy Color용 카드 게임은 모든 카드 일러스트를 64×48픽셀, 카드마다 고유한 네 색 팔레트로 그립니다. 팔레트는 타일과 함께 내장되었다가 표시될 때 팔레트 슬롯 하나에 배정되므로, Charizard는 크림색, 주황, 빨강, 거의 검정을 받고 에너지 카드는 흰색, 두 단계 올리브 회색, 거의 검정을 받습니다.⁵¹ 규칙은 크기가 아닙니다. 규칙은 “카드 한 장에 양자화된 팔레트 하나, 고정된 프레임 하나, 줌 배율 하나”입니다. 그리고 이 규율에 대해 책상 위에 붙여 둘 만한 말은 스기모리 겐의 것입니다. “픽셀 아트는 놀랄 만큼 깊습니다. 스프라이트에서 픽셀 하나의 위치만 바꿔도 완전히 다른 인상을 줄 수 있습니다.”⁵² 그의 스프라이트는 본인 표현으로 더 복잡한 디자인을 “이해하기 쉽게” 만든 기호였습니다. 화면이 작았고 저장 공간은 더 작았기 때문입니다.⁵³ Red와 Green은 프로그래머 약 네 명, 아티스트 열 명 미만으로 출시되었습니다.⁵⁴

3. 현대의 거장들, 그리고 “AAA급 픽셀 아트”의 값

2010년 이후 최고의 픽셀 아트 게임들은 한 명에서 스물다섯 명 규모의 팀이 아무런 한계가 없는 하드웨어 위에서 만들었습니다. 그러니 그들이 지킨 제약은 전부 선택입니다. 그 선택들은 몇 갈래로 모입니다.

정수 배율로 확대되는 캔버스를 고정합니다. Celeste의 320×180은 6배로 1080p가 됩니다. Pedro Medeiros의 말입니다. “그게 제가 말하는 게임 캔버스입니다.”³ Sea of Stars는 640×360으로 렌더링하며, 그 “Pixel Perfect” 옵션에 대해 스튜디오의 Steam FAQ 스레드에서 한 플레이어가 이렇게 설명합니다. “화면 둘레에 검은 테두리를 더해서 픽셀이 흐릿하지 않고 또렷하게 보이도록 합니다.”⁵⁵ Animal Well은 320×180이고, 뷰포트가 너무 작아 주사선을 정직하게 그릴 수 없을 때는 스캔라인 필터를 끕니다.⁵⁶ Hyper Light Drifter는 480×270입니다. Alx Preston의 말입니다. “우리 게임은 480p입니다. 저해상도이고, 그것도 아주 의도적으로 그렇습니다.”⁵⁷ Shovel Knight는 NES의 가시 주사선 240줄에 맞추려고 400×240을 골랐고, Yacht Club의 표현으로는 “Shovel Knight의 픽셀 하나는 1080p에서 사실상 4.5×4.5 픽셀”입니다.⁵⁸ Godot 문서는 이제 720p, 1080p, 1440p, 4K 어디에도 레터박스 없이 들어간다는 이유로 640×360을 기준으로 권장합니다.⁵⁹

픽셀 밀도를 절대 섞지 않습니다. Medeiros의 확대 규칙은 이렇습니다. “이건 원본 이미지의 100퍼센트 단위로만 할 수 있습니다.” 그리고 두 밀도를 피할 수 없을 때는 “100퍼센트인 요소와 200퍼센트인 요소는 있을 수 있어도 150퍼센트는 절대 안 됩니다.”⁶⁰ Celeste는 한발 더 나아가 서로 절대 섞이지 않는 세 “세계”를 유지합니다. “Game, UI, Map입니다. 각각 픽셀 아트, 고해상도, 3D이지요.”³ UI는 자기만의 레이어에서 자기만의 배율을 갖고, 세계를 확대한 뒤에 합성됩니다. 초대 Switch의 Octopath Traveler는 휴대 모드에서 세계를 576p로 렌더링하면서 UI는 720p로 유지했는데, 경로는 달라도 같은 분리입니다.⁶¹

조명 등급을 고르고 그 값을 치릅니다. 맨 아래에서 Moonlighter에는 동적 조명이 아예 없습니다. 마을의 밤은 “빛의 인상을 주기 위한 스프라이트의 중첩”입니다.¹⁰ 한 단계 위의 Celeste는 모든 조명을 2,048픽셀 텍스처 한 장에 마스크로 그립니다. 64칸 격자에 조명 하나당 색 채널 하나를 쓰므로 텍스처 한 장에 조명 256개가 들어가고, 셰이더가 색과 마스크를 곱하기 전에 가림막이 스포트라이트에서 그림자를 오려 냅니다.¹¹ 그 위의 Eastward는 “2D 시점을 가진 3D 게임”이며, 평평한 스프라이트를 실제 조명으로 음영 처리할 수 있도록 팀이 모든 애셋에 대해 “범프 맵을 하나하나 손으로 칠했”습니다.¹² Animal Well의 Billy Basso는 매끄러운 그러데이션이 픽셀 아트와 충돌한다는 이유로 엔진의 점광원을 물리치고 자기만의 림 라이트 셰이더를 작성했으며, 연기와 물을 위해 전체 화면 유체 시뮬레이션을 돌립니다.⁶² Dead Cells는 3D 모델을 “아주 작은 크기로, 안티에일리어싱 없이” 렌더링하고 툰 셰이더로 음영을 넣어 노멀 맵을 공짜로 얻습니다.⁶³ 맨 위에서 Sea of Stars는 첫 여섯 달을 “픽셀 아트와 시각적으로 일관되어 보이는” 조명을 만드는 데 썼고, HD-2D는 조명이 들어간 Unreal 장면에 스프라이트 빌보드를 놓고 피사계 심도, 블룸, 색 보정, 렌즈 플레어, 비네트를 겁니다.⁶⁴⁶⁵ HD-2D 게임들을 프로듀싱하는 아사노 도모야는 그것이 “생각보다 비용이 많이 든다”고 말합니다.¹³ 그리고 Octopath Traveler II의 플레이어들은 “화면 가장자리가 흐려져서 길이 가려진다”는 이유로 피사계 심도와 블룸을 끕니다.¹³

생각보다 적은 프레임으로 움직이고, 대신 색을 움직입니다. Dead Cells의 캐릭터는 키가 50픽셀이고, Motion Twin의 3D 애니메이션 작업 흐름은 Dead Cells 이전 시제품 ScarKrow에서 이미 초당 30프레임에 도달해 있었습니다. 픽셀화 단계가 더해진 것은 Dead Cells부터입니다.⁶³ 서브픽셀 애니메이션은 이 기법의 조용한 무기입니다. 작은 스프라이트를 조금 움직이려면 “스프라이트를 움직이지 말고” “그 색을 움직이라”고 튜토리얼은 말합니다. 50픽셀짜리 캐릭터에서는 흐린 여섯 색이면 숨결을 읽히게 하기에 충분했습니다.⁶⁶ Octopath는 Photoshop의 퍼펫 뒤틀기로 동작을 대량 생산한 뒤 픽셀을 손으로 고쳤습니다.⁶⁵ Animal Well은 생물들을 절차적으로 움직이며 각 팔다리가 저마다의 궤적을 그립니다. Basso는 스쿼시 앤드 스트레치와 화면 흔들림을 일부러 피합니다.⁶⁷

팔레트를 고정하고 공유합니다. Raymond Schlitter의 방법은 단계마다 색상을 20도씩 이동한 아홉 색 램프를 만들고 램프 사이는 45도를 띄우는 것입니다. 밝은 쪽에서 채도를 낮추는 이유는 그러지 않으면 “눈을 태우는 듯한 강렬한 색”이 되어 버리기 때문입니다.⁶⁸ Cassette Beasts는 “약 20색의 같은 풀을 공유함으로써” 몬스터 120마리에 통일감을 유지합니다. 플라스틱 종류가 정해진 액션 피규어 제품군과 같습니다.⁶⁹ Shovel Knight는 NES가 세 색만 허용하던 자리에 스프라이트당 네다섯 색에 투명을 더해 씁니다.⁵⁸ 커뮤니티의 고정 팔레트(Resurrect 64, Apollo, Endesga 32)가 존재하는 것은 이 규율이 작동하기 때문입니다.⁷⁰

그림의 규모를 팀에 맞춥니다. Stardew Valley는 한 사람과 16×16 타일입니다. Eric Barone는 차기작에 대해 이렇게 말합니다. “16×16 타일 크기를 유지하면 이렇게 규모가 큰 게임에서도 그림의 양을 감당할 만한 수준으로 묶어 둘 수 있습니다.”⁷¹ Sabotage Studio는 The Messenger의 일곱 명에서 Sea of Stars의 약 스물다섯 명으로 커졌습니다.⁷² Animal Well은 한 사람, 7년, 자체 C++ 엔진, 33메가바이트, 그리고 방 ID가 1바이트이기 때문에 정확히 256개인 방으로 이루어진 세계입니다.⁷³ Eastward의 스튜디오는 창업자 세 명에서 상근 약 열두 명으로 커졌고, 200명이 넘는 캐릭터를 Aseprite로 움직였습니다.⁷⁴ Switch 2는 기존 휴대기의 타협을 없앴습니다. 1080p 휴대 화면과 1080p 또는 4K TV 출력 덕분에 320×180과 640×360 캔버스는 어느 모드에서도 정수 배율이 될 수 있습니다. 다만 4K 출력은 60프레임이 상한입니다.⁷⁵

4. 기법을, 숫자가 붙은 규칙으로

이어지는 내용은 내려다보는 3쿼터 시점 마을의 문법을, 실천가들이 말한 그대로 정리한 것입니다. 어떤 실천을 저희 용도에 맞춰 숫자로 바꾼 곳은 그렇다고 밝혀 두었습니다.

1. 이 시점은 평행 투영의 기울기이지 투시가 아닙니다. LPC 스타일 가이드는 카메라를 “대략 60도”에 두고 원근을 주지 않습니다. Schlitter는 같은 시점을 집을 45도 위에서 보아 “지붕과 정면이 모두 4분의 3쯤 보이는” 상태로 설명하고, 지배적인 한 문장을 덧붙입니다. “통일성이 사실성에 우선한다.”⁷⁶⁷⁷ 수직선은 수직인 채로 두고, 정면은 압축되며, 지붕은 돌리지 않고, 모든 사물이 같은 규칙을 따릅니다.
2. 격자는 16이고 작업 리듬은 32입니다. Schlitter의 말입니다. “16×16픽셀이 아마 가장 흔한 크기이고 픽셀을 제대로 살리기에 확실합니다.”⁷⁸ Stardew와 GBA 게임들도 여기에 동의합니다. Pokémon의 게임보이 블록과 LPC의 격자는 32입니다. 타일 제작과 충돌 판정은 16으로 하고, 집과 큰 나무는 두 타일 단위로 설계하십시오.
3. 키 큰 타일 문제는 레이어로 풉니다. Stardew의 맵 레이어는 뒤에서 앞으로 Back(지형), Buildings(충돌), Paths, Front(“플레이어가 그보다 북쪽에 있으면 위에, 남쪽에 있으면 아래에 그려짐”), AlwaysFront입니다.⁷⁹ Pokémon의 Normal, Covered, Split 메타타일 유형도 같은 발상이며 정렬을 하드웨어 우선순위에 맡깁니다.²
4. 지형 전이는 47타일입니다. blob 세트란 “변 2개, 모서리 2개짜리 Wang 타일셋의 47타일 부분집합”입니다. 비트 가중치는 북이 1, 북동이 2, 동이 4, 남동이 8, 남이 16, 남서가 32, 서가 64, 북서가 128이고, 모서리는 양옆의 변이 모두 있을 때만 셈에 들어갑니다. 이 규칙이 256개의 마스크를 47개의 실루엣으로 접어 넣습니다.⁸⁰⁸¹ 울타리와 생울타리는 16타일짜리 변 세트입니다. Tiled의 terrain set과 LDtk의 규칙 그룹 모두 이를 직접 구현합니다.⁸²⁸³
5. 나무는 줄기 위의 잎 다발이고, 그림자는 그 아래에 둡니다. Schlitter는 기본 단위가 “2×2픽셀의 작은 정사각형”인 다발로 수관을 쌓고 “다발당 네다섯 색”을 쓰며, 나무를 “엇갈려 겹치는 줄로 배치해 빽빽한 숲 패턴을 만듭니다.” 그림자에 대해서는 실용을 먼저 말합니다. “게임 디자인 측면에서는 그림자를 나무 바로 아래 두는 것이 가장 실용적입니다.” 다만 본인은 “더 역동적인 모습을 위해 한쪽으로 치우치게 드리우는” 쪽을 좋아한다고 덧붙입니다. 그림자는 “은은해야 하고 특정 방향으로 길게 뻗지 않아야” 하며, 벽이 드리우는 그림자에 대해서는 “한 타일 길이를 넘어서는 안 된다”고 합니다.⁸⁴
6. 색은 색견본이 아니라 램프입니다. 램프가 밝아지는 쪽으로는 따뜻한 색으로, 어두워지는 쪽으로는 차가운 색으로 단계마다 최대 20도씩 색상을 이동시키십시오. 채도는 램프 중간에서 최고가 됩니다.⁶⁸ LPC의 규칙은 세 단어입니다. “순색은 안 됨!” 그림자는 “가장 가까운 보라 쪽으로”, 하이라이트는 “가장 가까운 노랑 쪽으로”입니다.⁷⁶ 스프라이트 하나당 Schlitter는 음영에 자신이 붙을 때까지 “대략 다섯 색 정도”를 권합니다. 그리고 Cure의 법칙이 통합니다. “네 색으로 좋은 스프라이트를 못 만든다면, 마흔 색을 써도 도움이 되지 않습니다.”⁸⁵⁸⁶
7. 아웃라인 규칙은 하나, 어디에나 적용합니다. LPC는 이렇게 정합니다. 배경 아웃라인은 “현재 색의 더 어두운 버전, 또는 일반적으로 어두운 색이되 검정은 아님”. 캐릭터 아웃라인은 “검정 또는 거의 검정, 선택적 아웃라인은 쓰지 않음”.⁷⁶ 1절의 SNES 표는 스튜디오마다 다르게 고르면 어떻게 되는지를 보여 줍니다. 요점은 한 번 고르는 것입니다.
8. 세 가지 실수에 이름을 붙이고 찾아낼 수 있게 하십시오. 재기(jaggies)는 선의 리듬에서 벗어난 픽셀 하나입니다. 밴딩은 “이웃한 픽셀들이 아래 격자에서 같은 x 또는 y 좌표에서 끝나 버리는” 것입니다. 필로 셰이딩은 빛을 무시한 동심원 띠입니다.⁸⁶ 안티에일리어싱은 길고 완만한 계단에만 걸고 45도나 직선에는 절대 걸지 마십시오. 그리고 부드럽게 하는 처리는 스프라이트 자신의 색 안에 가두고, 뒤에 무엇이 있든 그에 맞춰 하지 마십시오. 배경을 정하는 쪽은 게임이기 때문입니다.⁸⁶⁸⁷ 16픽셀 세계에서 디더링은 거의 쓸 일이 없습니다. Pixel Parmesan의 표현대로 어떤 스프라이트들은 “담을 수 있는 디테일의 양에 비해 디더링하기에는 그냥 너무 작습니다.”⁸⁸
9. 캐릭터는 세 방향을 그리고, 보행은 네 걸음이며, 대기 동작도 움직입니다. Stardew의 농부는 16×32이고 정해진 순서(몸, 바지, 셔츠, 장신구, 머리, 모자, 팔)로 그려지며 모자는 20×20 셀에 들어갑니다. 보행은 고유 프레임 세 장으로 된 네 걸음입니다.⁸⁹⁹⁰ Pokémon Emerald는 걷기, 서기, 걷기, 서기입니다.⁴⁸ Schlitter의 말로는 머리가 “스프라이트 전체의 3분의 1에서 절반을 차지”합니다. 위, 아래, 옆을 그리고 옆은 반전하십시오. 그리고 대기 동작에 대해서는 “말이 될 필요조차 없습니다. 그냥 움직이게 하십시오.”⁹¹⁹²
10. 글자는 그림입니다. 비트맵 폰트는 정수 배율로만 렌더링합니다. Daniel Linssen의 m5x7 페이지에는 “폰트 크기는 16, 32, 48 등을 쓰라”고 적혀 있습니다.⁹³ Pokémon Emerald의 텍스트 창 테두리는 24×24 이미지, 즉 하드웨어 타일 3×3이며 이것이 나인 슬라이스입니다. Aseprite의 슬라이스는 나인 패치의 중앙을 내보내는 JSON까지 가져다줍니다.⁹⁴⁹⁵
11. 고요한 세계에서 주스(juice)는 날씨입니다. 화면 흔들림과 히트스톱을 다룬 대표적인 강연들은 슈팅 게임과 벽돌깨기를 소재로 짜인 것이었습니다. 수집가의 마을에 필요한 것은 Stardew의 날씨 어휘(맑음, 비, 폭풍, 꽃가루나 낙엽이 날리는 바람, 눈)와, 새 그림이 아니라 타일 속성에서 나오는 발소리입니다.⁹⁶⁹⁷⁹⁸
12. 파이프라인은 빌드 단계입니다. Aseprite의 명령줄은 패킹된 시트를 JSON과 함께 내보내며(--sheet-type packed --shape-padding 2 --extrude --format json-array --list-tags --list-slices), 2픽셀 여백과 가장자리 밀어내기가 각 프레임의 테두리를 옆 프레임에서 번져 오는 것으로부터 지켜 줍니다.⁹⁹¹⁰⁰

5. Apple의 방식: 세 가지 아키텍처, 하나의 레시피, 그리고 산수

저희 문제는 서로 반대로 당기는 두 반쪽으로 되어 있습니다. 세계 쪽은 정수 배율로 확대되고 nearest로 샘플링되며 조명을 받지 않는 텍셀이 픽셀 경계에 딱 맞게 놓이기를 원합니다. 그 안에서 유일하게 진짜인 것, 즉 수집가가 가장 아끼는 카드는 음영이 들어간 3D 오브젝트로 평평한 세계에서 솟아올라 자기가 놓인 선반에 가려지기를 원합니다. 다시 말해 타일과 같은 깊이 버퍼 안에 있어야 합니다. 카드를 두 번째 레이어로 합성하는 설계는 그 가림을 잃고 그 순간을 가짜로 만듭니다. 두 반쪽을 모두 담을 수 있는 Apple 아키텍처는 셋이고, 비용은 저마다 다릅니다.

순수한 2D 게임이라면 SpriteKit이 여전히 가장 빠른 길이고, 지원이 중단된 것이 아니라 유지되고 있습니다. 진짜 3D 오브젝트 하나가 필요한 세계에는 RealityKit이 맞는 엔진이며, 픽셀 아트의 모든 요구 사항에 문서화된 API가 있습니다. Metal은 RealityKit이 약속할 수 없는 두 가지, 즉 120Hz와 패널 정확 배율을 위한 비상구입니다. 문서화된 수단은 RealityRenderer로, 같은 엔티티들을 직접 만든 텍스처에 렌더링해 본인이 제시하는 nearest 확대 패스에 넘길 수 있습니다.¹¹⁰

레시피

// One texel is k device pixels, with k a whole number. Pixels, not points.
let pixelsTall = Float(size.height * displayScale)
let k = max(1, (pixelsTall / (20 * 16)).rounded(.down))   // aim for about 20 tiles tall
let worldTall = pixelsTall / k                            // world units are texels
var camera = OrthographicCameraComponent()
camera.scale = worldTall / 2                        // measured: scale is half the view's height
cameraEntity.components.set(camera)

// Nearest sampling, no mipmaps, alpha test instead of blending.
let sampler = MTLSamplerDescriptor()
sampler.minFilter = .nearest
sampler.magFilter = .nearest
sampler.mipFilter = .notMipmapped
let texture = try TextureResource(image: sheet, options: .init(semantic: .color, mipmapsMode: .none))
var material = UnlitMaterial()
material.color = .init(tint: .white, texture: .init(texture, sampler: .init(sampler)))
material.opacityThreshold = 0.5
material.textureCoordinateTransform = .init(
    offset: [Float(col) / Float(cols), 1 - Float(row + 1) / Float(rows)],
    scale: [1 / Float(cols), 1 / Float(rows)], rotation: 0)

// Switch the AR defaults off.
content.renderingEffects.motionBlur = .disabled
content.renderingEffects.depthOfField = .disabled
content.renderingEffects.cameraGrain = .disabled
content.renderingEffects.antialiasing = .none
content.renderingEffects.dynamicRange = .standard

이 코드에 대해 세 가지를 덧붙입니다. Apple이 OrthographicCameraComponent.scale에 대해 적어 둔 것은 “카메라가 엔티티의 크기를 조절하는 데 쓰는 부동소수점 값”뿐이고, 화면 높이의 절반이라는 관계는 저희가 시뮬레이터에서 실측한 것입니다(3배 환경에서 텍셀당 일곱 픽셀일 때 320 월드 단위가 746.67포인트에 해당했습니다. 320 × 7 ÷ 3의 값입니다).¹⁰⁴ opacityThreshold는 픽셀 아트가 원하는 오려 내기 경로입니다. “RealityKit은 opacityThreshold보다 불투명도가 낮은 픽셀을 버리고” 나머지는 완전히 불투명하게 렌더링하므로 가장자리 혼합도, 정렬 순서 문제도 없습니다.¹⁵ 그리고 어떤 샘플러보다도 크게 작용하는 것이 기본값입니다. RealityView는 끄지 않는 한 “가상 오브젝트에 모션 블러를 넣는 효과를 적용”하고 “하이 다이내믹 레인지 효과와 톤 매핑”도 함께 적용합니다.¹⁶ 그렇게 하기 전까지 저희 보행 캐릭터는 발을 내딛을 때마다 번졌습니다. 각 스프라이트의 x와 y, 그리고 카메라는 이징이 끝난 뒤 매 프레임 정수 월드 단위로 반올림합니다. 그래서 텍셀이 픽셀 사이에 끼는 일이 없고, 깊이와 3D 카드의 움직임은 연속적으로 남습니다. 또 포럼에 보고된 투영 버그 때문에, 탭의 월드 좌표는 RealityKit에 묻지 않고 카메라 위치와 k, 디스플레이 배율로부터 직접 계산합니다.¹⁰⁵¹⁰⁷

배율 산수

3배라는 스케일 팩터는 16픽셀 격자와 아무 관계가 없습니다. 중요한 것은 픽셀 수입니다. 16텍셀 타일로 세로 스무 타일쯤을 목표로 한다면 k = floor(pixelsTall ÷ 320)입니다. 나머지를 어떻게 쓰느냐에서 두 가지 전략이 나옵니다. 들어가는 만큼 타일을 넣거나(넓은 화면일수록 세계가 더 보이고 레터박스는 없습니다), 세로를 정확히 스무 타일로 묶고 나머지를 레터박스에 주는 것입니다. 아래 각 행은 Apple의 사양 페이지와 Xcode 27 시뮬레이터 프로파일에서 계산했습니다.¹⁷¹¹⁸

이 높이들 가운데 320으로 나누어떨어지는 것은 하나도 없습니다. 그러니 현행 기기에서 “정확히 스무 타일”은 언제나 레터박스를 뜻합니다. 18 Pro Max의 2868 ÷ 320 = 8.96이 깔끔한 9에 가장 가깝습니다. HIG는 게임에 “다양한 화면 비율에서 보기 좋고 올바르게 동작할 것”과 “전체 화면 경험을 전제로 설계할 것”을 요구하는데, 이는 레터박스를 두기보다 세계를 더 보여 주라는 주장으로 이어집니다. 광장에서는 그렇게 하고, 전체를 보여 주는 방들은 대신 가운데로 정렬합니다.¹¹⁵ 3배 디스플레이에서 k = 8일 때 다섯 텍셀짜리 폰트는 13.3포인트이고 k = 6이면 10포인트로 HIG의 최소 11포인트 아래입니다. 그래서 대화 텍스트는 월드 안이 아니라 SwiftUI의 UI 배율에 둡니다.¹¹⁵ 그 SwiftUI 크롬 안에 들어가는 픽셀 아트 아이콘과 나인 슬라이스 테두리에는 Image.interpolation(.none)이 선명함을 지켜 줍니다.¹¹⁶

iPhone Duo의 안쪽 디스플레이는 이 산수가 아직 끝나지 않은 유일한 자리입니다. Apple의 사양표는 패널을 1878×2670픽셀로 적지만, 시뮬레이터 프로파일은 논리 프레임버퍼를 2007×2853, 배율 3.0으로 제시합니다. 즉 UIKit은 669×951 포인트를 3배로 렌더링하고 컴포지터가 유리면에 맞춰 약 0.936배로 다운샘플링해야 하는데, 이는 Apple의 Technical Q&A QA1909가 Plus 계열 기종에 대해 설명하는 바로 그 동작입니다. 그러면 UIScreen.nativeScale은 2.807 근처가 되고, 텍셀당 여섯 논리 픽셀은 실제 패널에서 약 5.6픽셀이 됩니다.^17112120 논리 프레임버퍼를 보여 주는 시뮬레이터에서는 광장이 제대로 보이지만 실제 기기에서는 아주 약간 무를 것입니다. 이를 피할 수 있는 길은 nativeBounds에서 Metal이 소유하는 드로어블뿐이며, 첫걸음은 실기에서 nativeScale을 로그로 찍어 보는 것입니다. 바깥쪽 디스플레이는 깔끔하게 나누어떨어집니다(1398 ÷ 466 = 3.0).

저희가 찾은 버그 둘, 그리고 캡처상의 이상 하나

카드 뷰어는 장면이 첫 번째와 프레임 단위로 똑같은데도 두 번째와 세 번째로 열 때 까맣게 나왔습니다. 원인은 RealityView의 Metal 레이어를 담고 있는 SwiftUI 뷰에 건 불투명도 애니메이션이었습니다. 그 경계를 가로질러 .opacity를 애니메이션하면 레이어가 칠해지지 않은 채로 남습니다. 해결책은 뷰를 애니메이션하는 것을 그만두고 대신 검은 베일 오버레이를 페이드아웃시키는 것이었습니다. 부하가 걸린 시뮬레이터에서는 첫 그리기가 최대 12초까지 늦게 도착하므로, 저희 UI 워크스루는 일련의 타이머 기반 밝기 표본 중 첫 번째가 아니라 마지막 것을 읽습니다.

두 번째는 렌더러가 아니라 저희 도구 쪽에 있었습니다. 호스트에서 Duo 시뮬레이터의 안쪽 디스플레이를 캡처하면(xcrun simctl io <udid> screenshot --display=primary-1), 이미지는 Core Animation이 다시 합성할 때만 갱신됩니다. RealityKit 프레임만으로는 재합성이 일어나지 않으므로 화면에서는 움직이는 보행 플레이어가 캡처에서는 멈춰 보입니다. 테스트 번들 안에서 XCUIScreen.screens[1]로 캡처하면 사실 그대로 찍힙니다. 둘 다 하루씩을 잡아먹었고 제가 찾을 수 있는 어떤 문서에도 없었습니다. 여기에 적어 두는 이유가 그것입니다.

6. 사례 연구: 저희 광장을 심판하고, 규칙으로 다시 짓다

TestFlight 빌드 18로 나갔을 때의 Kiradex World를 1절부터 4절까지에 비추어 정직하게 감사한 결과가 이것입니다. 바닥은 텍스트 격자에 적어 넣은 임시변통 색으로 된 28타일 세트였고, 램프도 없고 합의된 빛도 없는 단색 평면이었습니다. 수집가는 48×96 시트였고 보행은 두 프레임, 대기 동작 없음, 그림자 없음, 아웃라인 방침은 스프라이트마다 제각각이었습니다. 머리 위 레이어가 없어서 나뭇잎 차양 뒤나 지붕 아래를 지날 수가 없었습니다. 오토타일이 없어서 잔디에서 길로 넘어가는 가장자리는 모두 자로 그은 직선이었고, 높이 개념도 없었습니다. 그 아래의 엔진은 건전했습니다(맵은 메시 하나, nearest 샘플링, 정수 배율, 카드는 같은 깊이 버퍼). 그러나 그 위에 얹힌 그림은 Game Boy 앞에서도 부끄러울 물건이었습니다.

설계 지침

이어지는 사양은 저희 것이며, 위에 인용한 출처 있는 실천에서 도출했습니다. 사실이 아니라 권장일 뿐인 수치는 권장이라고 밝혀 두었습니다.

• 투영과 격자. 평행 투영 3쿼터 시점, 빛은 왼쪽 위에서 한 방향, 수직선은 수직인 채로. 타일은 16×16. 집과 큰 나무는 32픽셀 리듬으로. 방은 10×8에서 12×9 타일. 마을 규모는 무궁시티의 30×30과 잿빛시티의 40×60 사이로.
• 레이어, 그리는 순서대로. 바닥(오토타일 잔디, 길, 광장 돌바닥, 물), 디테일(변형, 꽃, 구워 넣은 그림자), 오브젝트(밑변 기준 y 정렬. 사람, 벤치, 가로등, 나무줄기, 건물 정면, 충돌 판정 포함), 머리 위(지붕, 차양, 난간. 언제나 사람보다 위), 조명(가산 합성 가로등 스프라이트, 해 질 녘에 교체), 날씨, 그리고 자기 배율을 가진 UI. Stardew의 다섯 레이어에 Pokémon의 Normal 사례, 즉 위 레이어가 플레이어를 덮는 것을 머리 위 레이어로 더한 구성입니다.
• 오토타일. 잔디에서 길, 잔디에서 물, 잔디에서 절벽, 광장에서 길까지 네 가지에 47타일 blob 세트. 울타리와 생울타리에 16타일 변 세트. 잔디 변형은 세 가지이되 반복이 눈에 띄지 않도록 가중치를 둡니다. 물은 250밀리초에 네 프레임(Emerald의 열여섯 틱 여덟 단계가 리듬의 참조점입니다). 꽃은 두 프레임. 가로등은 두 상태에 밤의 깜박임을 더합니다.
• 팔레트. 마스터 팔레트 하나, 색상을 이동시킨 램프 여섯에서 여덟 개로 48에서 64색, 채도는 램프 중간에서 최고, 순색은 쓰지 않고, 실내는 차가운 쪽 절반에서 가져옵니다. 스프라이트 하나당 최대 여덟 색, 타일 하나당 여섯 색. 해 질 녘과 밤은 세계 전체에 곱셈 틴트 한 겹을 올리고, 가로등과 창문과 매점 간판에는 손으로 그린 발광 변형을 더해 표현합니다.
• 캐릭터. 16×32 셀 안에 폭 16, 높이 24인 인물. 머리는 9에서 10픽셀, 눈은 1픽셀, 입은 없음, 발은 맨 아래 타일에 닿게 해서 y 정렬이 밑변을 쓰도록 하고, 모자와 들어 올린 카드를 위해 머리 위로 여덟 픽셀을 비워 둡니다. 그리는 방향은 셋에 반전한 넷째 하나. 다만 카드를 들어 올리는 동작만은 들고 있는 카드가 좌우 비대칭이므로 오른쪽을 향한 세트를 따로 그립니다. 보행은 125밀리초에 네 프레임, 대기 동작은 1픽셀 들썩이는 두 프레임, 카드 들어 올리기는 세 프레임(예비 동작, 들어 올리기, 유지). 종이 인형 레이어는 Stardew의 순서를 따르며 각각 몸의 격자에 놓이는 완전한 시트이고, 모자는 방향마다 기준점을 둡니다. 모든 사람과 나무 아래에 12×4 타원 그림자를 둡니다.
• 아웃라인. 캐릭터는 거의 검정, 세계 쪽은 주변보다 어두운 고유색, 타일 안쪽에는 절대 긋지 않습니다.
• 텍스트. m5x7을 정수 배율로, 24×24 나인 슬라이스 상자 안에 두 줄, 타자기식 표시, 넘김 화살표는 두 프레임. 픽셀 밀도에 대한 유일한 의도적 예외가 수집가의 진짜 카드입니다. 엔진이 이미 플레이어 머리 위로 들어 올리는, 음영이 들어간 3D 카드이고 높이는 세 타일이며 같은 장면 안에 있습니다. 들어 올린 손 안의 작은 카드는 소지 레이어 위의 스프라이트이고, 둘이 같은 물체인 척하는 일은 없습니다.

포지

이 그림을 이미지 편집기에서 그릴 생각도 없고, 프롬프트로 생성할 생각도 없습니다. 미국 저작권청의 2025년 1월 보고서는 저작자성에 대해 “프롬프트만으로는 충분한 통제를 제공하지 못한다”고 결론짓습니다. 그리고 저작자가 없는 타일셋이란 누구든 앱에서 가져가도 되는 타일셋입니다. 같은 보고서는 “산출물에 대한 창작적 수정”과, AI가 사람을 대신하는 것이 아니라 거드는 작업을 보호합니다.¹⁸ Circular 33은 아이디어, 절차, 시스템, 운용 방법을 저작권 바깥에 둡니다. 투영 방식, 타일 크기, 레이어 구성이 바로 거기에 삽니다. 반면 특정 타일과 스프라이트는 보호되는 표현이고, 이름은 보호된다면 상표로서입니다. 그러니 깔끔한 길은 모든 픽셀의 출처를 자기 것으로 삼는 일입니다.¹⁹ 저희 포지는 scripts/forge/ 아래의 작은 Python 프로그램으로, 마스터 팔레트 하나를 두고 손으로 정한 규칙에서 모든 타일과 스프라이트를 그립니다. 팔레트 모듈은 색상을 이동시킨 열네 개 램프로 58색을 만들고 검토용으로 GIMP 팔레트 파일을 내보냅니다. 래스터는 인덱스 방식입니다. 스프라이트는 색 이름의 격자이고, 한 픽셀이 가질 수 있는 값은 팔레트 항목이거나 앱이 수집가마다 바꿔 칠하는 아홉 개 마커 색 중 하나뿐입니다. 지형 모듈은 잔디, 다져진 흙, 판석, 물을 그린 다음, 안쪽 지형 위에 바깥쪽 지형을 흔들리는 경계선을 따라 바깥 모서리를 둥글리고 테두리 색을 더하며 칠해서 47가지 blob 전이를 모두 생성합니다. 모든 무작위 선택은 위치에서 정해지는 고정 해시이므로 다시 만들면 바이트 단위로 같은 결과가 나옵니다. 그리고 모든 규칙은 사람이 쓰고 변호할 수 있는 코드 한 줄입니다.

첫 번째 필드는 이 방법이 애초에 성립한다는 증명이었습니다. 이튿날 아침에는 같은 프로그램으로 캐릭터와 엔진이 이름을 가진 28개 타일이 뒤따랐습니다. 16×32 셀에 들어가는 16×24 인물은 몸, 머리카락, 모자, 들고 있는 카드 레이어로 그려지며 앱이 수집가마다 바꿔 칠하는 마커 색을 유지합니다. 대기 동작은 두 프레임, 보행은 네 프레임, 카드 들어 올리기는 세 프레임입니다. 나무는 줄기 위의 잎 다발이고 그림자는 그 아래에 있습니다. 회벽에는 걸레받이를 넣지 않습니다. 같은 타일이 방 바깥의 벽체도 채우는데 걸레받이가 있으면 화면 전체에 줄무늬가 가 버리기 때문입니다. 물은 네 프레임이고 바닥이 1초에 네 번 그것을 넘깁니다. 아래 캡처는 이것들과 함께 통과한 시뮬레이터 보행 확인입니다. 광장은 아직 엔진이 이름을 가진 28개 타일을 깔고 있어서, JSON 맵이 blob 세트를 실어 올 때까지 옆면 가장자리는 곧은 채로 있습니다.

방과 홀, 소품, 그리고 더 큰 마을도 같은 프로그램으로 이어집니다. 출구에서는 Aseprite 호환 시트와 JSON이 나오므로, 그림이 바뀌어도 Swift 로더는 전혀 바뀌지 않습니다.

이 세계가 할 일

그림 프로그램은 메커니즘을 위해 있고, 수집형 게임에 대한 조사는 작업 순서를 바꿔 놓았습니다. 주인공은 카드입니다. 세계는 무광으로 두고 진짜 카드만 음영이 들어간 유일한 오브젝트가 됩니다. 1억 회 넘게 내려받은 게임인 Pokémon TCG Pocket에서 한 장짜리 전시판과 서른 장짜리 앨범만으로도 충분한 자랑거리가 되었기 때문입니다.¹²⁹ 방의 가구는 열여섯 개가 상한인데, 비밀기지와 같은 숫자입니다. 상한이야말로 선반을 구도로 바꾸어 놓기 때문입니다. 방문은 읽기 전용이고, 좋아요는 하루 한 번이며, 방의 누계는 결코 줄지 않습니다. 이글루에 대한 Club Penguin의 규칙입니다.¹²²¹²⁴ 방문자는 방마다 깃발을 얻고 30, 100, 500에서 등급이 오릅니다. 낯선 사람의 비밀기지에 걸어 들어가는 일을 주된 동사로 만들었던 ORAS의 등급 설계입니다.¹²⁵ 일요일마다 방을 채점하는 보고서가 도착하고 점수의 출처가 함께 적힙니다. 해피 홈 아카데미의 리듬입니다.¹²³ 주간 홀이 빌려 오는 것은 Pokémon의 콘테스트가 아니라 Stardew의 농산물 품평회입니다. 아홉 개 받침대, 기본 점수, 시대와 세트를 가로지르는 다양성 보너스, 스캔 기록에서 나오는 아이템 점수, 세 단계 기준선, 그리고 낯선 사람도 한눈에 이해할 수 있는 심사입니다.¹²¹ 대화는 미리 준비된 문장의 트리(인사, 대답, 수집 이야기, 반응)로 두고 어휘는 플레이로 풀립니다. Emerald의 유행을 좇는 사람이 기록 교환으로 올 때마다 유행어를 하나씩 풀어 주던 방식 그대로입니다. 직접 입력은 결코 쓰지 않습니다. Club Penguin의 단어 필터는 “mom”을 막았으면서도, 자사 도움말 페이지가 인정하듯 일부 모욕적인 메시지는 통과시켰기 때문입니다.¹³³¹²⁴ 또한 FTC의 2022년 명령은 Epic에게 어린이와 청소년에 대해 음성 및 텍스트 대화를 기본으로 끄도록 요구했습니다.^126124131 친구 한 명당 하루에 작은 선물 하나, 친밀도 등급은 1일, 7일, 30일, 90일. 이것은 Pokémon GO의 사다리입니다.¹²⁷ 후원자 표식은 이름표와 방 스킨에 머물고 받침대 자리나 심사 보너스에는 결코 닿지 않습니다. 코지 게임 논문이 경고하는 “화려함은 종종 사회적 비교의 압박을 만들어 낼 수 있다”가 한계선입니다.¹²⁸ 무작위가 걸린 것은 절대 팔지 않습니다.

그림 다음에 오는 엔진 작업은 이렇습니다. 하드코딩된 줄 대신 JSON에서 불러오는 레이어 타일 맵, 공통 리듬으로 도는 애니메이션 타일, y 정렬 가림이 있는 머리 위 레이어, 프레임마다 합성되는 종이 인형 스프라이트, 그리고 서버의 맵과 NPC와 패리티 테이블 갱신입니다.

핵심 요약

그림을 그리는 분께

• 첫 타일을 그리기 전에 셀과 팔레트와 빛을 고정하십시오. 16×16 타일, 16×32 셀 안의 16×24 인물, 색상을 이동시킨 램프로 48에서 64색, 빛은 왼쪽 위에서. 이 가이드에 나온 거장들은 하나같이 제약에서 출발해 바깥으로 작업했습니다.
• 아웃라인 규칙을 하나 골라 배역진 전체에 적용하십시오. FF VI의 93퍼센트 검정 가장자리도, Secret of Mana의 0퍼센트도 둘 다 일관됩니다. 둘을 섞은 배역진은 일관되지 않습니다.⁹
• 프레임은 표현에, 색은 움직임에 쓰십시오. FF VI의 46가지 포즈, Emerald의 걷기-서기-걷기-서기, 그리고 스프라이트가 아니라 색을 움직이는 서브픽셀 애니메이션입니다.¹⁴⁸⁶⁶
• 전이는 47타일, 울타리는 16타일, 나무는 잎 다발에 그림자는 바로 아래. 규칙은 한 번만 그리고 배치는 에디터에 맡기십시오.⁸⁰⁸⁴

Apple 플랫폼에서 만드는 분께

• 평평한 세계 안에서 하나가 반드시 진짜 3D여야 한다면 RealityKit에 머무르십시오. 깊이 버퍼를 공유하고, 픽셀 아트의 모든 요구 사항에 문서화된 API가 있습니다. 순수한 2D 게임이라면 SpriteKit을 고르고, 120Hz와 패널 정확 픽셀을 위한 Metal 비상구로 RealityRenderer를 남겨 두십시오.¹⁴¹¹⁰
• AR 기본값은 첫날에 끄십시오. 모션 블러와 HDR 톤 매핑은 비활성화하지 않는 한 켜져 있고, 이 레시피는 피사계 심도와 카메라 그레인과 안티에일리어싱도 끕니다. 하나같이 텍셀을 번지게 하기 때문입니다.¹⁶
• 산수는 픽셀로 하십시오. k = floor(pixelsTall ÷ 320), 모든 스프라이트의 x와 y 그리고 카메라를 정수 월드 단위로 반올림하고, 시뮬레이터를 믿기 전에 실기에서 UIScreen.nativeScale을 읽으십시오. iPhone Duo에서는 특히 그렇습니다.¹¹²¹¹⁸
• 저희 RealityView에서는 그것을 담은 뷰의 불투명도를 애니메이션했더니 화면이 까맣게 되었습니다. 대신 베일을 덮어 페이드시키십시오. Duo의 안쪽 디스플레이 캡처는 호스트가 아니라 테스트 번들 안에서 하십시오. 그리고 LSSupportsGameMode를 추가하십시오. Game Mode는 “더 매끄러운 게임플레이와 더 일관된 프레임 레이트를 위해 백그라운드 활동을 최소화”합니다.¹¹⁷

스튜디오를 운영하는 분께

• 그림의 규모를 팀에 맞추십시오. Eric Barone는 한 사람이 Stardew만 한 세계를 그릴 수 있도록 16×16 타일을 지켜 왔고, Sabotage는 Sea of Stars를 만드는 동안 일곱 명에서 약 스물다섯 명으로 커졌습니다.⁷¹⁷²
• 엔진에 반년을 쓸 수 있는 것이 아니라면 Moonlighter에서 Celeste 사이의 조명 등급을 고르십시오. HD-2D 등급은 “생각보다 비용이 많이 들고” 다름 아닌 그 플레이어들이 효과를 꺼 버립니다.¹⁰¹¹¹³
• 모든 픽셀의 출처를 자기 것으로 삼으십시오. 순수하게 프롬프트로 생성된 그림은 저작권청 자신의 결론에 따르면 보호되지 않고, 혼합된 경우는 하나하나 따로 판단됩니다. 손으로 그린 그림, 그리고 사람이 쓴 규칙으로 그려진 그림은 인간 저작자라는 출처를 지킵니다.¹⁸
• 수집가를 위한 세계에서는 수집한 것만을 유일하게 반짝이는 오브젝트로 두고, 방에 상한을 걸고, 일요일에 채점하고, 좋아요는 늘기만 하게 하고, 결코 타이핑하게 하지 마십시오. Daniel Cook의 “대화를 없애면 긍정적인 사회적 행동의 95퍼센트도 없어진다”는 말은 사실입니다. 그래서 아이가 입력하고 싶어 할 대답을 미리 준비된 문장이 대신 감당해야 하는 것입니다.¹³⁰

자주 묻는 질문

내려다보는 픽셀 아트 게임에는 어떤 타일 크기를 써야 합니까

16×16입니다. Game Boy의 16픽셀 보행 칸 이래 Pokémon이 써 온 셀이고, Stardew Valley가 바탕으로 삼은 셀이며, Raymond Schlitter가 “작업하기에 가장 균형 잡힌 크기”라고 부르는 셀입니다.^4079132 캐릭터는 16×32 셀에 앉히고 몸은 대략 24픽셀 높이로 합니다. 집과 큰 나무는 두 타일 단위로 설계합니다.

iOS 픽셀 아트에는 SpriteKit입니까, RealityKit입니까

3D 오브젝트가 없는 게임이라면 SpriteKit입니다. 인접 규칙이 있는 타일 맵, 노멀 맵을 쓰는 조명, 그리고 filteringMode = .nearest면 처방은 끝입니다.¹⁰¹¹⁰² 장면 안의 하나가 반드시 타일과 같은 깊이 버퍼에서 음영이 들어간 3D여야 한다면 RealityKit입니다. 평행 투영 카메라, 명시적 혼합 모드나 불투명도 임계값을 갖춘 UnlitMaterial, nearest 샘플러, 밉맵 없음이 모두 문서화되어 있고, iOS 26은 인스턴싱과 후처리 훅까지 더합니다.^104106108109 SpriteKit의 유일한 3D 다리인 SK3DNode는 SceneKit에 기대어 있는데, Apple은 WWDC25에서 SceneKit을 유지보수 모드로 옮겼습니다.¹⁰³

iPhone 화면에서 정수 배율을 어떻게 얻습니까

픽셀로 생각하십시오. 뷰의 포인트에 displayScale을 곱하고, 높이를 320(16픽셀 타일 스무 개)으로 나눈 뒤 버림하면 그것이 텍셀당 기기 픽셀 수입니다. iPhone 18 Pro Max에서는 8이고, 펼친 iPhone Duo와 13인치 iPad Pro, 4K Apple TV에서는 6입니다.¹⁷¹¹⁹ 카메라와 모든 스프라이트의 x와 y는 매 프레임 정수 월드 단위로 반올림하십시오. 나머지를 더 넓은 세계로 돌릴지 레터박스로 돌릴지 정하십시오. 현행 iPhone 중 높이가 320으로 나누어떨어지는 것은 없습니다. iPhone Duo의 안쪽 디스플레이에서는 실기에서 UIScreen.nativeScale을 확인하십시오. 패널의 1878×2670 픽셀이 시뮬레이터가 보여 주는 2007×2853 프레임버퍼와 맞지 않기 때문입니다.¹¹²

게임의 픽셀 아트를 AI가 생성해도 됩니까

이미지를 생성할 수는 있지만, 프롬프트만으로는 생성물에 대한 저작권을 얻지 못합니다. 미국 저작권청의 2025년 보고서는 순수하게 AI가 생성한 소재는 보호되지 않으며 “프롬프트만으로는 충분한 통제를 제공하지 못한다”고 결론짓는 한편, 산출물에 대한 인간의 창작적 수정과 AI가 “인간의 창의성을 대신하는 것이 아니라 거드는” 쓰임은 보호된다고 봅니다.¹⁸ 출시하는 게임에 미치는 실제 결과는 이렇습니다. 프롬프트로 통째로 생성되고 인간의 표현이 더해지지 않은 타일셋에는 행사할 저작권이 없으며, 그 학습 출처도 알 길이 없습니다. 사람이 표현을 더한 경우라면 저작권청이 그 기여를 건별로 판단합니다. 직접 그리거나, 그리는 규칙을 직접 쓰십시오. 그리고 어느 쪽인지 기록해 두십시오.

“Pokémon에서 영감을 받은” 세계의 법적 경계는 어디입니까

화풍과 방법과 시스템은 보호되지 않고, 구체적인 표현이 보호됩니다. Circular 33은 “모든 아이디어, 절차, 과정, 시스템, 운용 방법, 개념, 원리, 발견”을 저작권에서 제외합니다.¹⁹ 16픽셀 타일로 된 3쿼터 시점 마을, 두 레이어 메타타일, 걷기-서기 보행, 47타일 해안선은 방법입니다. 태초마을의 타일들과 그 생물들, 몬스터볼, 타입 기호는 표현이고, 이름은 상표입니다. Kiradex는 모든 타일과 스프라이트를 자기 팔레트 안에서 자기 규칙으로 그리며, 앱 어디를 뒤져도 Pokémon 이미지는 사용자가 스캔한 진짜 카드뿐입니다.

지형 전이에는 왜 정확히 47타일이 필요합니까

타일의 생김새가 여덟 이웃(네 변과 네 모서리)에 달려 있어 256가지 조합이 나오지만, 모서리는 그 양옆의 변이 함께 있을 때만 의미가 있기 때문입니다. 그 규칙으로 256개의 마스크를 접으면 47개의 서로 다른 실루엣이 남습니다. Tiled 문서가 혼합 세트의 통상적인 축약형으로 “47타일 Blob 타일셋”을 꼽는 이유가 이것입니다.⁸⁰⁸¹⁸²

이 가이드를 만든 방법. 뒷받침한 여섯 편의 조사 자료는 2026년 10월 2일에 Claude 에이전트로 정리했고, 본문의 모든 숫자는 각주에 적힌 1차 출처에서 다시 읽었습니다. pret 디컴파일, Apple 문서(JSON 엔드포인트를 통해), 개발자 본인의 강연과 글, 그리고 Shmuplations와 Nova Crystallis, Lava Cut Content에 실린 번역 인터뷰입니다. 스프라이트 측정, 배율 산수, RealityKit 카메라 실측, 그리고 Kiradex 포지는 제가 직접 한 작업이며 그렇게 표시해 두었습니다. 어떤 주장이 단일 출처에 기대고 있다면 각주에 그렇게 적혀 있습니다.

이 사이트의 관련 글. 개발자를 위한 iPhone Duo는 위 배율 표가 딛고 선 안쪽 디스플레이의 포인트 치수와 1.42라는 비율을 도출합니다. iPhone Duo를 위해 앱을 준비하기는 접힘과 예약 영역, 그리고 광장이 지금 따르는 HUD 규칙을 실제 사례로 보여 줍니다. Xcode 27.1 베타: iPhone Duo 시뮬레이터 속의 내 앱은 시뮬레이터와, 이 글의 캡처가 나온 Device Hub 포즈를 다룹니다. RealityKit과 공간의 심상 모형은 5절의 RealityKit 토대입니다. Metal 4의 핵심은 그 비상구를 만든다면 쓰게 될 API를 다룹니다. 그리고 브라우저에서 MacPaint 되살리기는 제가 1차 자료에서 픽셀 렌더러를 다시 만든 지난번 기록입니다.

출처