← 모든 글

픽셀 아트 방: 가구 그리드, 상한, 채점

Pokémon Emerald에서 꾸민 방이란 16픽셀 셀로 된 그리드 위에 놓인 물건 열여섯 개입니다. 디컴파일된 소스는 플레이어의 비밀기지에 놓을 수 있는 장식을 16개, 침실은 12개로 제한하고, 세이브에는 자기 기지와 다른 플레이어의 기지를 합쳐 최대 20개를 보관합니다.12 카탈로그는 8개 카테고리의 장식 120개입니다. 인형 35, 장식품 23, 매트 18, 포스터 10, 쿠션 10, 책상 9, 의자 9, 식물 6입니다. 그중 71개는 셀 하나만 차지하고, 평균은 2.43셀이며, 18개는 작은 장식을 올려 두는 받침면입니다.23 기지의 걸을 수 있는 셀은 44에서 81, 평균 60.2개이므로 상한은 바닥의 약 4분의 1입니다. 배치는 덮이는 각 셀이 답하는 질문이며, 배치 함수 어디에도 통로가 남는지 확인하는 부분은 없습니다.24 이 글에서 다루는 이후의 게임 중 세 가지가 같은 모델을 각기 다른 예산으로 돌립니다. Animal Crossing: New Horizons는 Nookipedia의 설명에 따르면 방마다 150개이고, 일요일 편지가 방을 채점합니다. Final Fantasy XIV는 패치 7.5 이후 주택 유형에 따라 실내 150에서 600개입니다. Club Penguin 이글루는 팬 출처 하나에 따르면 99개입니다.5678 제 앱 Kiradex에는 방이 있고, 아트 포지가 23가지 가구 어휘로 방을 꾸미지만, 플레이어는 그중 어느 것도 옮길 수 없습니다. 이 글은 원전을 측정하고, 규칙을 숫자와 함께 정리하고, 그것을 SwiftData와 SwiftUI에 대응시킨 뒤, Kiradex가 아직 만들지 않은 가구 배치 시스템의 브리프로 마무리합니다. 그 내용은 층마다 16개의 상한, Emerald의 배치 함수에는 없는 통로 규칙, 모든 점수 출처를 나열한 주간 점수, 그리고 플레이로만 해금되는 카탈로그입니다.910

TL;DR

  • 열여섯은 보관 한도가 아니라 구도의 예산입니다. Emerald는 기지에 16개, 침실에 12개의 장식을 놓게 하지만, 소유할 수 있는 장식은 카테고리별 칸 8개에 150개까지이므로 플레이어는 놓을 수 있는 것보다 많이 가질 수 있습니다. 배치된 장식 하나는 2바이트로, ID 하나와 위치 하나(x와 y를 각각 4비트)이며, 기지 레이아웃 전체가 32바이트에 들어갑니다.111122
  • 규칙은 바닥에 들어 있습니다. Emerald에는 배치 권한이 다섯 가지(바닥, 밟고 지나가는 바닥, 뒤쪽, 벽, 받침면 위) 있습니다. 책상 윗면의 셀에는 작은 장식이 올라설 수 있게 하는 동작 값이 있어서, 책상을 놓으면 그 위에 인형을 놓을 수 있습니다. 작은 것을 받치는 장식은 18개, 큰 것을 받치는 장식은 14개입니다. 침실은 인형과 쿠션만 받습니다.1324
  • 상한은 플랫폼과 함께 오르고, 그중 하나는 프레임 예산이기도 합니다. Nookipedia의 설명에 따르면 Animal Crossing의 방당 아이템 수는 Wild World 24, City Folk 64, New Leaf 48, New Horizons 150입니다. Final Fantasy XIV는 패치 7.5에서 실내 한도를 절반 올려 150에서 600으로 만들었고, 패치 노트에는 화면에 가구가 400개를 넘으면 다른 층에 있는 가구는 그려지지 않는다는 설명이 붙어 있습니다.57
  • 점수에는 나열된 출처, 정해진 요일, 집과 함께 오르는 기준이 있습니다. Nookipedia의 해피 홈 아카데미 표는 방 하나의 아이템이 6, 10, 15, 20개가 될 때마다 1,000점씩 주고, 시리즈, 세트, 카테고리, 색, 풍수 보너스를 더하며, 집이 커질수록 S 등급 기준을 15,000에서 90,000으로 올립니다. 이 페이지는 New Horizons의 해당 숫자에 출처를 달지 않았습니다.6
  • 카탈로그는 구매로, 플레이로, 또는 둘 다로 늘어납니다. Emerald에서는 120개 중 90개가 돈으로 팔리고, 24개는 한 번도 팔리지 않으며(경품, 배틀 포인트, 선물), 두 개는 한 걸음씩 모으는 6,000 ash와 8,000 ash(ash는 화산재)로 삽니다. Stardew는 매일 무작위로 바뀌는 재고를 팝니다. 첫 집 증축 뒤에는 로빈이 가구 카탈로그(Furniture Catalogue)도 200,000g에 파는데, 이 카탈로그는 목록에 있는 가구를 0g에 무제한으로 팝니다. 다만 박물관, 축제, 그 밖의 출처에서만 얻을 수 있는 가구도 여전히 있습니다. Habbo는 가구를 팔고, 그중 일부는 일부러 희귀하거나 무작위입니다.14151617
  • 방문자는 보기만 하고 손대지 않습니다. Animal Crossing의 방문자는 다른 플레이어 집의 가구를 쓸 수는 있지만 “modify the interior in any way”(어떤 식으로든 실내를 바꾸는 것)는 할 수 없습니다. Habbo의 방문자는 소유자의 권한 없이 가구를 내려놓거나 옮길 수 없습니다. Club Penguin은 디자인 하나에 하루 한 번 좋아요를 허용하고, 그 Grand Total(총합)은 “will never decrease”(결코 줄지 않는다)고 합니다. 이는 도움말 페이지를 옮긴 팬 사본 하나에 따른 것입니다.51819
  • Kiradex가 얻는 것. 출시된 기능이 아니라 브리프입니다. 포지의 가구 23가지 중 20가지를 셀 단위로 배치하는 것, 문에서 계단, 호스트, 모든 진열 그룹의 앞 셀 하나까지 이어지는 통로 규칙을 실제로 걸어서 확인하는 것, 층마다 16개, 시작 방은 8개로 출시하는 것, 포지가 그린 벽지 여섯 가지와 바닥 여섯 가지, 모든 점수 출처를 인쇄한 일요일 편지(최대 23,600점), 지금 쓸 수 있는 레벨과 핀에서 출발해 동기화되는 컬렉션, 앱이 기기에 기록하는 퀘스트 도장, 그리고 걸음 수와 방 방문과 편지의 집 등급이라는 새로 동기화되는 카운터 세 개에서 도출하는 플레이 해금 카탈로그, 서버가 레이아웃을 저장할 수 있게 되면 읽기 전용 방문, CloudKit 동기화가 고유 제약을 강제할 수 없으므로 고유 제약이 없는 SwiftData 모델, 그리고 VoiceOver로 터치 없이 할 수 있는 드래그 배치입니다.9202122

1. Emerald: 그리드 위의 열여섯 개, 소스에서 측정하다

이 장르의 가장 작은 완성형은 Pokémon Ruby, Sapphire, Emerald의 장식 시스템이며, 그 대부분은 데이터입니다. 저는 이것을 pret의 Emerald 디컴파일 커밋 731ad5b(2026년 10월 1일 커밋)에서, 소스를 파싱할 뿐 게임은 한 번도 실행하지 않는 스크립트 두 개로 읽었습니다. 하나는 카탈로그, 상한, 받침면, 방 크기를, 다른 하나는 각 장식의 입수처를 다룹니다. 출력은 스크립트 옆에 저장해 두었습니다.214 이 절의 모든 숫자는 이 두 출력이나 각주가 밝힌 소스 파일에서 나온 것입니다.

상한

세 상수가 한도를 정합니다. DECOR_MAX_SECRET_BASE는 16, DECOR_MAX_PLAYERS_HOUSE는 12, SECRET_BASES_COUNT는 20이며, 마지막은 세이브가 보관하는 기지의 수, 즉 자기 기지와 다른 플레이어에게서 받은 기지의 합입니다.12 놓을 수 있는 수의 상한은 가질 수 있는 수의 상한과 따로 있습니다. 세이브는 카테고리별 칸에 소유 장식 150개를 보관합니다. 책상 10, 의자 10, 식물 10, 장식품 30, 매트 30, 포스터 10, 인형 40, 쿠션 10입니다.112 따라서 플레이어는 방에 들어갈 수 있는 것보다 많이 가질 수 있고(새 게임은 모든 칸이 빈 상태로 시작합니다), 무엇을 넣을지 고르는 일이 곧 게임입니다.23

배치된 장식 하나는 2바이트입니다. 기지는 decorations[16]에 ID를 하나씩, decorationPositions[16]에 1바이트씩 저장하며, 상위 4비트가 x, 하위 4비트가 y입니다. 그래서 기지는 최대 16×16 셀의 그리드로 주소가 매겨지고, 기지 레이아웃 전체가 32바이트에 들어갑니다.1112 저는 이 크기를 세이브가 자기 기지와 다른 플레이어의 기지를 합쳐 스무 개를 보관할 수 있는 이유로 해석합니다.

카탈로그

gDecorations[]에는 항목이 121개 있습니다. 항목 0인 DECOR_NONE은 작은 책상의 데이터를 재사용하는 빈 슬롯이므로, 장식은 ID 1부터 120까지 120개가 남습니다.32 카테고리별로는 인형 35, 장식품 23, 매트 18, 포스터 10, 쿠션 10, 책상 9, 의자 9, 식물 6입니다.2 셀 단위의 모양으로는 1×1이 71, 1×2가 22, 3×3이 13, 2×1이 5, 2×2가 4, 3×2가 3, 2×4와 4×2가 하나씩입니다. 헤더는 3×1과 1×3도 선언하지만, 이를 쓰는 장식은 없습니다. 장식 하나가 덮는 셀은 1에서 9개, 평균 2.43개입니다.213 구조물 편 글을 위한 예전 메모처럼 빈 슬롯을 장식으로 세면 한 셀짜리는 72개, 단단한 바닥은 19개가 되고, 빼면 71개와 18개입니다.2

Emerald의 장식 120개를 카테고리별로 나타낸 가로 누적 막대 그래프. 각 막대는 장식이 덮는 16픽셀 셀의 수로 나뉩니다. 인형 35(1셀 25, 2셀 10), 장식품 23(1셀 9, 2셀 9, 4에서 6셀 1, 8 또는 9셀 4), 매트 18(1셀 11, 8 또는 9셀 7), 포스터 10(5와 5), 쿠션 10(모두 1셀), 책상 9(1셀 2, 4에서 6셀 3, 8 또는 9셀 4), 의자 9(모두 1셀), 식물 6(2셀 3, 4에서 6셀 3).

Emerald 카탈로그의 대부분은 한 셀입니다. 큰 장식은 책상, 3×3 매트, 그리고 몇몇 장식품입니다.243

표의 가격은 가장 싼 매트의 500부터 가장 비싼 장식품과 인형의 10,000까지입니다. 가격이 0인 것이 셋 있는데, 방패 둘과 유리 장식품 하나이며 셋 모두 경품입니다.23

다섯 가지 권한과, 데이터인 받침면

각 장식은 다섯 가지 권한 중 하나를 가집니다. 헤더는 이를 “collision and placement permissions, in that order”(충돌과 배치 권한, 이 순서로)라고 부릅니다.13 개수는 다음과 같습니다.

권한 의미 장식
단단한 바닥 걷기를 막고, 바닥에 선다 18: 책상 9개 전부, 장식품 9
통과 바닥 밟고 지나가며, 바닥에 선다 37: 매트 18개 전부, 의자 9개 전부, 장식품 10
뒤쪽 바닥 막으며, 맨 윗줄은 뒷벽에 걸쳐도 된다 10: 식물 6개 전부, 장식품 4
벽 뒷벽에 건다 10: 포스터 10개 전부
스프라이트 받침면 위에 서는 인형 45: 인형 35개 전부, 쿠션 10개 전부

src/data/decoration/header.h에 대해 measure_emerald_decor.py로 센 수.2

가장 영리한 부분은 받침면이 코드가 아니라 셀의 속성이라는 점입니다. 각 장식은 메타타일로 그려지고, 각 메타타일은 동작을 나타내는 바이트를 하나 가집니다. 장식 18개가 MB_HOLDS_SMALL_DECORATION 동작을 가진 셀을 지닙니다. 책상 9개 중 7개, 벽돌 3개, 타이어 1개, 매트 7개입니다. 14개는 MB_HOLDS_LARGE_DECORATION을 지니며, 이는 같은 책상 7개와 매트 7개입니다.2 1×2 인형은 아래에 “큰” 셀이 있어야 하고, 다른 인형이나 쿠션은 “작은” 셀이든 “큰” 셀이든 놓일 수 있습니다.4 그래서 책상을 놓으면 바닥에 인형에게 “예”라고 답하는 새 셀이 생기고, 같은 배치 함수가 둘 다 처리합니다. 열여섯 개로 방이 꽉 차 보이는 이유가 여기에 있습니다. 120개 중 45개, 즉 스프라이트들이 18개의 받침면 위에 섭니다.2

움직이는 장식도 있습니다. 음표 매트 8개는 밟으면 소리를 내고, 점프 매트, 회전 매트, 반짝이 매트는 이름 그대로 동작합니다. 풍선 3개와 진흙 공은 터집니다. 부술 수 있는 문, 미끄럼틀, 모래 장식품도 있습니다. 각각은 장식의 메타타일에 붙은 동작(MB_SECRET_BASE_SOUND_MAT, _JUMP_MAT, _SPIN_MAT, _GLITTER_MAT, _BALLOON, _BREAKABLE_DOOR, MB_SLIDE_SOUTH, _SAND_ORNAMENT)이며, 비밀기지 타일셋의 속성 파일에서 읽었습니다.225

배치는 각 셀이 답하는 질문

src/decoration.c의 CanPlaceDecoration은 들고 있는 장식이 덮게 될 셀을 하나씩 돌며 각 셀에 질문을 던집니다. 바닥 장식과 통과 바닥 장식은 덮는 모든 셀 아래에 평범한 바닥(MB_NORMAL)이 있어야 하며, 구멍을 덮을 수 있는 것은 단단한 판자뿐입니다. 셀 위에 오브젝트가 서 있어서는 안 됩니다. 메뉴를 열 때 플레이어가 서 있던 셀은, 장식이 그 셀에 일반 레이어 유형의 타일을 둘 때만 덮을 수 있습니다. 그 셀에 놓이는 장식 자신의 타일이 다른 레이어 유형이면 함수는 거기에 놓는 것을 거부합니다. 뒤쪽 바닥 장식은 맨 윗줄을 뺀 모든 셀 아래에 바닥이 있어야 하고, 맨 윗줄은 북쪽 벽에 걸쳐도 됩니다. 벽 장식은 모든 셀이 북쪽 벽이어야 합니다. 스프라이트는 아래에 받침 셀이 있어야 합니다.4 침실에서는 메뉴가 인형과 쿠션을 뺀 모든 카테고리를 거부합니다. isPlayerRoom이 설정되어 있으면 DecorationItemsMenuAction_AttemptPlace가 gText_CantPlaceInRoom을 보여 줍니다.4

CanPlaceDecoration에는 통로가 남는지 확인하는 부분이 전혀 없습니다. 이 함수가 걷기에 주는 보호는 서 있던 셀에 관한 그 조건부 규칙 하나뿐입니다. 이 함수에 대한 제 해석으로는, 플레이어가 책상으로 기지의 컴퓨터를 둘러막아도 게임은 그것을 허용합니다.4 이 문제는 브리프에서 다시 다룹니다. 다른 사람이 찾아오는 방에는 이 함수가 하지 않는 검사가 필요하기 때문입니다.

상한의 기준이 되는 방

기지 레이아웃 24가지는 여섯 스타일에 크기 네 가지씩입니다. 각 map.bin에서 벽까지 포함해 재면 너비 7에서 17셀, 깊이 7에서 17셀이고, 99셀(11×9)에서 196셀(14×14)까지이며, 길쭉한 것은 7×16, 10×17, 17×8입니다.226 각 레이아웃의 충돌 비트에서 읽은 걸을 수 있는 셀은 44에서 81, 평균 60.2입니다.2 상한 16은 평균적인 기지의 걸을 수 있는 바닥의 0.27입니다.2 침실은 두 플레이어 집의 2층으로 9×8이고, 걸을 수 있는 셀은 54, 상한은 12입니다.21

바닥만 보면 붐비는 정도를 과대평가하게 됩니다. 열여섯 개 중 상당수는 밟고 지나가는 매트이거나 책상 위에 선 인형이기 때문입니다. 상한이 예산으로 나누는 것은 바닥이 아니라 구도입니다.

캐릭터에 견준 셀

플레이어의 걷기 시트는 144×32픽셀로, 16×32 프레임 아홉 장입니다. 즉 캐릭터의 프레임은 16픽셀 메타타일 그리드에서 너비 한 셀, 높이 두 셀입니다. 꾸미기 포즈는 16×32 프레임 한 장입니다.27 그리드 셀은 프레임의 너비이며, 모든 장식은 이 단위로 크기가 정해집니다.

카탈로그가 늘어나는 방식

입수처 스크립트는 상점, 경품, 선물 스크립트에서 모든 장식 상수를 검색했습니다. 120개 중 90개는 상점 다섯 곳에서 돈으로 팝니다. 3개는 경품 교환소의 교환품, 15개는 배틀 포인트 교환품이고, 10개는 스크립트가 줍니다. 경품 교환소의 3개가 다시 들어가고, 퍼즐 저택을 풀면 받는 텐트 2개, 박물관 위층의 장식품 1개, 배틀 시설 주인이 주는 방패 2개, 주민이 주는 인형 2개입니다. 24개는 얻어야만 하며 돈으로는 결코 팔지 않습니다.14

두 개는 걸어서 삽니다. 유리 공방은 의자를 6,000 ash, 책상을 8,000 ash에 바꿔 주며, ash는 플레이어가 자루를 지닌 채 재로 덮인 풀숲을 지나갈 때 한 걸음에 한 단위씩 9,999까지 모입니다(VAR_ASH_GATHER_COUNT).15 저는 이 두 개를 원전에서 가장 순수한 플레이 해금으로 해석합니다. 돈은 오가지 않고 걸음만 오갑니다. 자루는 숫자를 보여 주지 않습니다. 필드에서의 사용 처리는 쓸 수 없는 도구를 위한 함수이고, 설명은 화산재를 모아 담는 일에 관한 고정 문구입니다.28 걸음 카운터 자체를 빼면 이 수를 읽는 것은 공방 스크립트뿐입니다. 플레이어의 재가 모자라면 스크립트는 모은 재를 가격에서 빼고, 그 차이를 아직 걸어야 할 걸음 수로 알려 줍니다.15

장식 4개(전설 인형 3개와 다른 인형 1개)는 검색 범위에 든 어떤 상점, 경품, 선물 스크립트도 참조하지 않습니다. 교환이나 통신 기능으로 들어올 수도 있지만 저는 추적하지 않았습니다. 판매 90개와 획득 전용 24개라는 숫자는 상점, 경품, 선물 스크립트 검색에 근거하며, 이 4개는 추적하지 않은 채로 남아 있습니다.14

Emerald가 가르쳐 주는 것

장식 시스템은 표 세 개와 함수 하나입니다. 장식마다 카탈로그 행 하나(권한, 모양, 카테고리, 가격, 메타타일), 각 셀이 무엇인지(바닥, 북쪽 벽, 구멍) 말해 주는 레이아웃, 배치 상한보다 큰 소유 목록, 그리고 덮이는 각 셀에 질문 하나를 던지는 배치 검사입니다. 받침면이란 더 작은 장식에 “예”라고 답하는 셀입니다. 상한은 배치된 장식만 셉니다. 빠진 것은 걷기입니다. 배치 함수는 셀을 확인할 뿐 통로는 한 번도 확인하지 않습니다.

2. Animal Crossing: 아이템 150개와 일요일의 편지

이 절은 팬 위키인 Nookipedia에 기대며, 2026년 10월 5일에 읽고 저장했습니다. Nintendo의 공식 수치는 찾아보지 않았습니다. 위키가 아무 출처도 달지 않은 곳은 그렇다고 밝히겠습니다.56

상한과 방

시리즈의 모든 게임이 방 하나의 아이템 수에 상한을 두며, 그 상한은 커져 왔습니다. Nookipedia는 방당 “furniture and clothing items”(가구와 옷 아이템)를 Wild World 24, City Folk 64, New Leaf 48로 적습니다. New Horizons에 대해서는 이렇습니다. “A maximum of 150 items can be placed in each room of the house, including wall and ceiling-mounted furniture.”(벽걸이와 천장 가구를 포함해 집의 각 방에 최대 150개의 아이템을 놓을 수 있다)5

같은 페이지의 증축 표에 따르면 New Horizons의 방은 텐트가 4×4, 집이 6×6, 메인 방을 넓히면 8×8, 뒷방과 왼쪽 방, 오른쪽 방은 각각 6×6, 2층과 지하는 10×6입니다. “Unlike previous games, only the main room can be expanded in size, as all other rooms have a fixed size.”(이전 게임들과 달리 넓힐 수 있는 것은 메인 방뿐이며, 다른 방은 모두 크기가 고정되어 있다)5 6×6 방에 150개라면 바닥 타일 하나에 4.2개인데, 이것이 가능한 것은 벽, 천장, 다른 가구의 윗면이 바닥을 쓰지 않고 아이템을 받아 주기 때문입니다(두 숫자로 낸 제 계산입니다).529

가구는 “a size in tiles that it takes up when placed, ranging from 1.0×0.5”(놓았을 때 차지하는 타일 단위 크기가 있으며, 1.0×0.5부터) 3×3까지이고, New Horizons에서는 “can also now be pushed in half-tile increments”(이제 반 타일 단위로 밀 수도 있다)고 합니다.29 New Horizons는 가구를 생활용품, 바닥이나 받침면 위에 놓는 잡화, 벽걸이, 그리고 버전 2.0에서 추가된 천장 장식으로 나눕니다.29 이 글에서 배치 그리드를 읽은 게임(Emerald의 셀, Stardew의 타일, New Horizons의 타일) 가운데 가구를 한 타일보다 작은 단위로 옮기는 것은 New Horizons뿐입니다. FFXIV의 배치 그리드는 읽지 않았고, Habbo에 대해 인용되는 더 잘게 쪼갠 단계는 서드파티 클라이언트의 쌓기 높이입니다(3절).

카탈로그

Nookipedia는 버전 3.0.2 기준 New Horizons의 가구를 2,076개로 세며, 그중 1,074개는 업데이트로 추가되었습니다. 시리즈는 “around 10 furniture items, as well as a matching wallpaper and flooring”(가구 10개 안팎과 그에 어울리는 벽지와 바닥재)입니다.29 위키는 버전 1.9.0 기준 벽지를 262개, 바닥재를 215개로 셉니다.3031 벽지와 바닥은 방마다 바꿀 수 있고, 버전 2.0은 포인트 벽을 추가했습니다. “a second wall covering can be applied to single wall in the room”(방의 벽 한 면에 두 번째 벽지를 바를 수 있다)는 기능입니다.5

해피 홈 아카데미

Kiradex가 빌려 오는 것은 채점 쪽입니다. Nookipedia에 따르면 아카데미는 “sends an evaluation by mail most Sunday mornings, which cannot be disabled”(대부분의 일요일 아침에 우편으로 평가를 보내며, 이를 끌 수 없다)고 합니다. 등급은 B, A, S이며, S 기준은 증축할 때마다 오릅니다. 첫 집은 15,000, 메인 방 증축 뒤에는 23,000, 이어서 35,000, 47,000, 60,000, 75,000, 그리고 지하가 생기면 90,000입니다.6

위키가 정리한 New Horizons의 보너스는 다음과 같습니다.

기준 점수
방 하나에 가구 6, 10, 15, 20개 각 기준마다 1,000
행운 아이템 아이템당 777
벽걸이 가구 아이템당 400, 최대 3개
한 시리즈의 아이템 4개 이상 아이템당 1,000
완성된 가구 세트 아이템당 800
한 카테고리의 아이템 3개 이상 아이템당 500
방 아이템의 70% 이상이 한 색 아이템당 200
90% 이상이 한 색 아이템당 600
빨강, 초록, 노랑 풍수 500
바퀴벌레 마리당 마이너스 2,500
바닥에 놓인 가구가 아닌 아이템 개당 마이너스 1
바닥의 쓰레기 개당 마이너스 500
벽을 향한 방향성 아이템 개당 마이너스 300

Nookipedia, “Happy Home Academy”, New Horizons 표, 2026년 10월 5일 저장. 페이지에 출처 없음.6

이 숫자들은 이 절에서 가장 불확실합니다. 보너스 표와 감점 표에는 출처가 없습니다. 그 아래의 보상 표에는 “Includes data sourced from the Data Spreadsheet for Animal Crossing New Horizons”(Animal Crossing New Horizons 데이터 스프레드시트에서 가져온 데이터를 포함한다)라고 적혀 있고, 이름이 밝혀진 기여자들이 정리한 것입니다. New Horizons의 아이템별 점수 절은 “This section is a stub”(이 절은 작성 중입니다)라고 되어 있습니다.6 그러니 이 계산은 팬의 재구성입니다. 마지막 브리프는 그 형태(나열된 출처, 개수 기준, 세트와 색 보너스, 정해진 요일)를 빌려 오되 숫자는 하나도 빌리지 않습니다.

주간 방 점수를 원하는 앱이라면 여기서 중요한 선택이 두 가지 있습니다. 기준이 집과 함께 오르므로, 방이 커진다고 최고 등급이 쉬워지지 않습니다. 그리고 편지는 정해진 요일, 대부분의 일요일 아침에 오며, 플레이어는 이를 끌 수 없습니다.6 그곳에서는 자리를 비우는 일에도 대가가 따릅니다. 집 페이지에 따르면 집을 “for at least one week”(적어도 일주일) 방치한 플레이어의 집에는 바퀴벌레가 들끓고, 위 표는 마리당 2,500점을 깎습니다.56 브리프는 정해진 요일은 남기고 벌은 버립니다.

방문

위키의 설명에 따르면 시리즈의 모든 게임에서 “a player may enter any other player’s house freely”(플레이어는 다른 플레이어의 집에 자유롭게 들어갈 수 있다)고 합니다. 가구는 쓸 수 있지만, 아이템을 내려놓거나 줍는 것도, “or modify the interior in any way”(어떤 식으로든 실내를 바꾸는 것)도 할 수 없습니다.5 다른 섬으로의 꿈 방문(dream visit)은 같은 결과에 다른 길로 도달합니다. 꿈을 운영하는 캐릭터의 위키 페이지에서 New Leaf 절은 꿈속에서 “any changes will not be saved and items cannot be brought back to the real world”(어떤 변경도 저장되지 않으며 아이템을 현실 세계로 가져올 수 없다)고 하고, New Horizons 절은 그녀의 서비스가 “work the same as they do in New Leaf”(New Leaf와 똑같이 작동한다)고 합니다. 꿈을 업로드하면 호스트는 5,000벨 상당의 “Dream Bell Exchange Ticket”(꿈 벨 교환권)을 받고, 업데이트할 때마다 한 장을 더 받습니다.32 제 해석으로는, 이것이 이 글에 나오는 방문 가운데 어린이용 앱에 가장 안전한 형태입니다. 방문자는 사본 속을 걷고 보존되는 것은 아무것도 바꿀 수 없으며, 호스트는 공유한 대가로 보상을 받습니다.

3. Habbo, Stardew, Final Fantasy XIV, Club Penguin, 그리고 이 모델의 기원

Habbo: 방이 곧 상품이고, 상품은 팔린다

Habbo의 공식 고객센터는 소유와 방문자 규칙을 분명하게 밝힙니다. “You can own 200 rooms.”(방은 200개까지 소유할 수 있다)33 바닥과 벽은 한 번 깔면 영구적입니다. “Wallpaper and flooring are stuck down - so once you put them down, they can’t be picked back up. You can put new wallpaper or floor down if you wish to change the look of your room.”(벽지와 바닥재는 붙박이라 한 번 깔면 다시 주울 수 없다. 방의 모습을 바꾸고 싶으면 새 벽지나 바닥을 깔면 된다)33 방문자는 손댈 수 없습니다. “You can’t drop or manipulate furni in other Habbo’s rooms unless you’re a member of a group, and the owner of that group has enabled you to participate in the building of that room.”(그룹의 회원이고 그 그룹의 소유자가 방 꾸미기에 참여하도록 허락하지 않는 한, 다른 Habbo의 방에서 가구를 내려놓거나 조작할 수 없다)18

가구 경제는 구매가 이끕니다. “To buy furni you need credits, diamonds or duckets.”(가구를 사려면 크레딧, 다이아몬드, 더킷이 필요하다)18 Builders Club은 가구를 한도까지 빌려 주며, 그 한도는 회원 기간 한 달마다 250씩 오릅니다. 플로어 플랜 편집기에서 사용자 정의 방 레이아웃을 저장하는 기능도 포함되고, “Furni limits never go down.”(가구 한도는 결코 내려가지 않는다)고 약속합니다.34 가구 정의 페이지는 캠페인 가구를 “for 4-12 months in order to leave an ample window for traders to build their businesses around them”(거래자들이 그것을 중심으로 장사를 꾸릴 넉넉한 기간을 두기 위해 4에서 12개월 동안) 묶어 두는 일, “will never be re-released”(다시는 출시되지 않는) 레어, 사서 깨면 “to reveal another, random rare furni”(무작위의 다른 레어 가구가 나오는) 크래커블 레어, 그리고 “a special type of rare, which comes in limited quantities”(수량이 한정된 특별한 종류의 레어)인 LTD를 설명합니다.17 거래에는 거래 패스가 필요하며, “There is no guide to what items of furni are worth”(어떤 가구가 얼마의 가치인지에 대한 안내는 없다)고 합니다.35 Habbo는 방 안의 우연까지 제한합니다. “Placing more than three chance elements will disable all randomiser functions in the room.”(우연 요소를 세 개보다 많이 놓으면 방의 모든 무작위 기능이 꺼진다)36

Habbo의 공식 페이지는 그리드도, 쌓기 높이도, 방당 가구 한도도 알려 주지 않습니다. 고객센터에서 “furni”, “stack”, “floor plan”을 검색해도 그것을 밝히는 글은 나오지 않았습니다.37 사람들이 인용하는 숫자는 오픈소스 서드파티 클라이언트인 Nitro에서 나온 것입니다. 그 플로어 플랜 편집기의 상수는 축당 최대 64타일과 27단계의 높이 체계를 허용하며, 이는 이 시리즈의 구조물 편 글이 같은 파일에서 인용한 것입니다. 제 예전 메모는 같은 클라이언트에서 0에서 40까지 0.01 단위로 조절하는 쌓기 높이 도구를 덧붙이는데, 이 글을 위해 다시 읽지는 않았습니다.3839 세 가지 모두 Sulake가 아니라 클라이언트의 것으로 다루십시오.

제 해석으로는, Habbo는 카탈로그가 사업이 될 때 가구 배치 루프가 어떻게 변하는지 보여 줍니다. 방문자 규칙은 따라 할 만하고, 경제(의도된 희소성, 무작위 내용물, 거래 가치)는 거부해야 할 것입니다.

Stardew Valley: 한 번 사는 카탈로그, 그다음은 무료 가구

Stardew Valley Wiki의 가구(Furniture) 페이지 리비전 193159는 26개 섹션에 걸쳐 718개의 아이템 행을 나열하며, 서로 다른 이름은 615개입니다. 이는 제가 페이지의 행을 센 숫자입니다. 영화 포스터 섹션은 다른 마크업을 써서 건너뛰었고, “서로 다른”은 두 섹션에 실린 아이템을 하나로 합친 것입니다.4016 벽지 페이지(리비전 193801)는 벽지 137개(카탈로그 안 123, 밖 12, 얻을 수 없는 것 2)를, 바닥재 페이지(리비전 190285)는 바닥재 97개를 보여 주며, 둘 다 게임의 데이터 파일이 아니라 페이지의 아이콘으로 센 것입니다.404142

카탈로그는 두 길로 동시에 늘어납니다. 로빈과 여행 상인 수레(Traveling Cart)는 각각 “offer a random selection of furniture each day they are open”(영업하는 날마다 무작위로 고른 가구를 판다)고 합니다. “After the first Farmhouse upgrade, Robin also offers the Furniture Catalogue for sale”(첫 농가 증축 뒤에는 로빈이 가구 카탈로그도 판다)고 하며, 페이지의 카탈로그 표에서는 200,000g입니다. 놓아 둔 카탈로그는 목록에 있는 가구를 0g에 “in unlimited quantity”(무제한으로) 팝니다. 가구 페이지에서 278개 행이 가구 카탈로그를 입수처로 듭니다.1640 페이지가 드는 예외는 예외로 남습니다. “Some furniture can be obtained only by donating items to the Museum”(박물관에 아이템을 기증해야만 얻을 수 있는 가구도 있다)고 하며, 축제, 카지노, 그 밖의 출처도 있습니다.16 그러니 플레이의 이정표 하나와 게임 내 화폐로 하는 큰 구매 한 번이, 카탈로그에 실린 것에 대해서만 희소성을 끝냅니다.

배치 피드백은 타일 단위입니다. “Furniture will display a green square on tiles where it can be placed. The tile will turn red if the furniture cannot be placed.”(가구는 놓을 수 있는 타일에 초록 사각형을 표시하고, 놓을 수 없으면 타일이 빨갛게 변한다)16 벽지는 면 하나에 동작 하나입니다. 벽지는 “cover the whole room they’re placed in”(놓은 방 전체를 덮으며), 붙이려면 “the character must be facing up by its wall”(캐릭터가 벽 옆에서 위를 보고 있어야 하며), “single-use and do not stack”(한 번 쓰면 끝이고 겹쳐지지 않는다)고 합니다.41 증축 전 농가는 내부가 10×7이고 16픽셀 타일을 쓰며, 이는 구조물 편 글이 위키에서 인용한 것입니다.39

Final Fantasy XIV: 프레임 예산이기도 한 상한

Square Enix의 Lodestone에 실린 패치 7.5 노트는 모든 하우징 한도를 올렸습니다. 실내 가구는 아파트와 개인실이 100에서 150, 코티지가 200에서 300, 하우스가 300에서 450, 맨션이 400에서 600으로, 실외 가구는 20에서 40, 30에서 60, 40에서 80으로 늘었습니다.7 같은 노트는 그 이유를 직접 밝힙니다. “Please note that up to 400 furnishings can be displayed on-screen at once. If more than 400 furnishings are on-screen simultaneously, those on a different floor to your character will stop being displayed, with small, more distant furnishings being hidden first.”(화면에는 가구를 한 번에 400개까지 표시할 수 있습니다. 400개가 넘는 가구가 동시에 화면에 있으면 캐릭터와 다른 층에 있는 가구는 표시되지 않으며, 작고 멀리 있는 가구부터 먼저 숨겨집니다)7 상한은 디자인 예산이자 동시에 렌더링 예산입니다.

노트는 “Furnishings from the FFXIV Furnishing Design Contest”(FFXIV 가구 디자인 콘테스트의 가구)도 추가했습니다. 수상한 디자인이 이 패치에서 가구가 된 커뮤니티 콘테스트입니다.7 이것이 콘테스트의 안전한 형태입니다. 플레이어가 만들고, 스튜디오가 심사해 출시합니다.

부지 크기는 이 글에 없습니다. Square Enix의 하우징 가이드는 2026년 10월 5일에 HTTP 404를 반환했고, 다른 공식 페이지는 시도하지 않았으므로 FFXIV가 이 글에 보태는 것은 Lodestone 노트의 아이템 한도뿐입니다.7

Club Penguin: 하루 한 번의 좋아요와 결코 줄지 않는 총합

여기 나오는 Club Penguin의 사실은 모두 단일 출처입니다. Club Penguin Wiki가 인용하는 보관된 공식 블로그 글은 2026년 10월 5일 Wayback Machine에서 HTTP 429를 두 번 반환해 확인할 수 없었습니다.43

That Penguin Game은 게임의 도움말 페이지라고 소개하는 내용을 재현해 두었는데, 저는 그 출처를 검증하지 않았습니다. 그 “Your Igloo” 페이지에는 이렇게 적혀 있습니다. “You can Like any igloo design once every day!”(어떤 이글루 디자인이든 하루에 한 번 좋아요할 수 있다!) 각 디자인은 “earns its own individual Likes”(저마다 개별 좋아요를 얻고), 이것이 Grand Total(총합)에 더해지며, “Likes are permanent, so your Grand Total Likes will never decrease, even if you delete an igloo design!”(좋아요는 영구적이라 이글루 디자인을 지워도 Grand Total Likes는 결코 줄지 않는다!)고 합니다. Popular 탭은 이글루를 좋아요 총합으로 순위를 매기고, 이글루는 “Everyone”(모두)이나 “Friends”(친구)에게만 열립니다.19

Club Penguin Wiki는 “igloos have a limit preventing more than 99 units of furniture being placed at once”(이글루에는 한 번에 가구를 99개보다 많이 놓지 못하게 하는 한도가 있다)고 하며, 대부분의 가구는 종류별로 99개의 소유 한도가 있고, 소유자는 자기 이글루는 꾸밀 수 있지만 “but not other player’s igloos”(다른 플레이어의 이글루는 꾸밀 수 없다)고 합니다.8 꾸미기는 멤버십 혜택이었습니다. 2005년 11월 1일부터 멤버십이 없는 플레이어도 이글루를 가질 수 있었지만 가구는 놓을 수 없었고, 2012년 7월 26일부터는 바닥 아이템 하나, 일반 아이템 넷, 벽 아이템 하나로 된 무료 가구 6개를 받았습니다.438

위키가 전하는 이글루 콘테스트의 역사는 이렇습니다. 첫 콘테스트는 2005년 12월 15일에 발행된 게임 내 신문 9호에서 공지되었고, 우승자 한 명에게 5,000코인을 주었습니다. 이후 콘테스트들은 공모 후 1에서 4주 뒤에 우승자와 차점자를 발표했고, 상품은 언제나 코인이었으며 가구가 붙기도 했습니다. 2008년 핼러윈 콘테스트부터는 캐릭터들이 우승자를 심사하고 그 평이 이글루와 함께 실렸고, 2009년부터는 이글루의 버튼으로 응모했으며, 마지막 콘테스트는 2012년 12월에 열렸습니다. 한 예로 2008년의 Ye Olde Igloo Contest는 우승자 열 명에게 각각 25,000코인, 차점자 스무 명에게 15,000코인을 주었습니다.44

The Sims: 사람들은 집을 채점하려고 거기 있었다

그리드와 카탈로그 모델에는 기원 이야기가 있고, 그것은 채점의 이야기입니다. 제 출처는 인터뷰 하나입니다. Game Developer가 2011년 5월 23일에 게재한 Tristan Donovan의 Will Wright 인터뷰입니다. 빌드 모드에 관해 Wright가 1999년이나 2000년에 한 기록된 발언은 찾지 못했습니다.45

영감에 대해. “one of the original things that was a really inspiration for The Sims was this book, A Pattern Language, by Christopher Alexander.”(The Sims의 원래 큰 영감 중 하나는 Christopher Alexander의 『A Pattern Language』라는 책이었다) 채점에 대해. “In some sense I wanted The Sims originally to be an architecture game where it was analyzing these patterns. So the people in The Sims originally were just there to score the architecture.”(어떤 의미에서 저는 The Sims를 원래 이런 패턴을 분석하는 건축 게임으로 만들고 싶었다. 그래서 처음에 The Sims의 사람들은 건축을 채점하려고 거기 있었을 뿐이다) 이름에 대해. “my original name for it was Doll House. We did some test marketing and found out that the name didn’t go very well with males.”(원래 이름은 Doll House였다. 시장 테스트를 해 보니 그 이름은 남성들에게 반응이 좋지 않았다) 오브젝트에 대해. “Everything we put in the world is advertising”(세계에 놓는 모든 것이 광고를 낸다)이라고 했고, 그는 이 모델을 SimAnt의 페로몬 흔적으로 거슬러 올라가 설명합니다.45

팬 위키이자 단일 출처인 The Sims Wiki는 출시된 화면을 설명합니다. 구매 모드에서 플레이어는 “purchase items from an object catalog and place them on the current lot”(오브젝트 카탈로그에서 아이템을 사서 현재 부지에 놓을 수 있다)고 하며, The Sims와 The Sims 2는 그 카탈로그를 물건의 기능별로 분류했습니다. 그리고 들고 있는 오브젝트의 발자국 타일은 놓을 수 있는 곳에서는 초록, 놓을 수 없는 곳에서는 빨강으로 표시됩니다. 위키는 이 초록과 빨강 문장을 The Sims 2와 The Sims 3에 연결해 두었으므로, 저는 이를 2000년 원작에 대해서는 주장하지 않습니다.46 점수는 Sim의 욕구로서 Sim 안에 남았습니다. 첫 게임에서는 Room, 두 번째 게임에서는 Environment이며, 이는 “analyzes the design and content of the room that the Sim is currently standing in”(Sim이 지금 서 있는 방의 디자인과 내용을 분석한다)는 욕구입니다. 작은 방, 부족한 조명, 더럽거나 고장 난 물건이 이를 떨어뜨립니다.47

제 해석으로는, 이 글의 모든 게임은 예산만 다른 그 화면 하나입니다. 카탈로그, 사람 한 걸음 크기의 그리드, 초록이나 빨강으로 바뀌는 발자국, 그리고 심사자입니다.

상한을 나란히 놓고 보면

"배치 아이템 한도"라는 제목의 가로 막대 그래프. 각 막대에는 그 한도가 무엇을 세는지 표시되어 있고 출처별로 색이 다릅니다. Final Fantasy XIV의 주택 유형별 실내 배치 한도(Lodestone 패치 7.5 노트 기준. 맨션 600, 이전 400. 하우스 450, 이전 300. 코티지 300, 이전 200. 아파트 또는 개인실 150, 이전 100). Animal Crossing의 방당 한도(Nookipedia 기준. New Horizons 150, City Folk 64, New Leaf 48, Wild World 24). Club Penguin의 이글루당 99(팬 위키 하나 기준). 디컴파일된 소스 기준 Emerald(기지 하나 16, 침실 12). 그리고 Kiradex가 제안하는 층당 16.

한도는 Emerald의 침실부터 FFXIV의 맨션까지 50대 1의 폭을 보이지만, 세는 대상이 같지 않습니다. FFXIV는 주택 유형별로 적힌 실내 배치 한도, Animal Crossing은 방당, Club Penguin은 이글루당, Emerald는 기지 또는 침실당, Kiradex는 층당입니다. 발행사 자신의 글이나 코드에서 나온 숫자는 FFXIV와 Emerald의 것뿐입니다.247581

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

측정 결과가 뒷받침하는 규칙을 각각의 근거가 되는 범위와 함께 정리하면 다음과 같습니다. 숫자가 제 계산이거나 제 선택이면 그 행에 그렇게 적었습니다. “셀”은 16픽셀 걷기 셀을 뜻하며, 이는 Kiradex의 타일이기도 합니다.227

요소 규칙 출처
배치 상한 방이 보여 주는 것을 방마다 제한하고, 벽 아이템도 센다. Emerald는 기지 16, 침실 12. New Horizons는 방당 150, “including wall and ceiling-mounted furniture”(벽걸이와 천장 가구 포함). FFXIV는 집 크기에 따라 실내 150에서 600. Club Penguin 99(팬 출처 하나)
소유 상한 들어갈 수 있는 것보다 많이 소유하게 해서, 놓는 일이 고르는 일이 되게 한다. Emerald는 칸 8개에 150개 소유, 배치 16. Club Penguin은 종류별 99개 소유(팬 출처)
바닥 대비 상한 벽이나 천장 레이어가 없는 2D 방에서는 바닥 셀 세 개당 아이템 하나 미만으로 유지한다(제 기준이며, Emerald가 바로 그 아래에 오도록 골랐다). 받침면과 밟고 지나가는 장식이 이를 늘린다. Emerald는 걸을 수 있는 셀 평균 60.2에 16, 0.27. New Horizons는 6×6 방에 150으로 타일당 4.2, 벽, 천장, 받침면 배치가 있어야만 가능(제 계산)
받침면 작은 물건을 받치는 일을 셀의 속성으로 만들어, 책상이 인형을 위한 바닥을 더하게 한다. Emerald: 작은 것을 받치는 장식 18, 큰 것을 받치는 장식 14, 이를 필요로 하는 스프라이트 장식 45
그리드 셀 그리드를 캐릭터의 프레임이나 셀 너비에 맞춘다. 장식을 조금씩 밀 수 있고 아트가 허락할 때만 더 잘게 나눈다. Emerald의 플레이어 프레임은 16픽셀 셀로 1×2. Stardew는 16픽셀 타일. New Horizons는 반 타일
배치 검사 덮이는 각 셀에 질문 하나(바닥, 벽, 받침면인가. 비어 있는가. 도착 셀이나 호스트 셀이 아닌가)를 던지고, 답을 셀마다 보여 준다. 셀별 질문은 Emerald의 CanPlaceDecoration. 다만 플레이어의 시작 셀은 레이어 유형이 일반이 아닌 타일일 때만 거부. 도착 셀과 호스트 셀은 Kiradex의 규칙(7.1). Stardew는 타일마다 초록 또는 빨강 사각형. The Sims 2와 3은 초록 또는 빨강 발자국(팬 위키)
통로 배치할 때마다 걷기가 남는지 확인한다(브리프가 더한 것). Emerald의 CanPlaceDecoration은 통로를 확인하지 않고, 플레이어가 서 있던 셀도 레이어 유형이 일반이 아닌 타일에 대해서만 비워 둔다. 여기서 읽은 Stardew와 Sims 페이지는 타일별 피드백을 설명하며 통로에 대해서는 어느 쪽으로도 말하지 않는다. 브리프가 걷기를 더한다
벽지와 바닥 방마다 하나, 동작 하나로 바꾸고, 되돌릴 수 있게. Stardew는 벽에서 “the whole room”(방 전체)을 덮는다. New Horizons는 방마다, 거기에 포인트 벽 하나. Habbo는 영구적이고 교체만 가능
카탈로그 규모 스타일이 선택이 될 만큼 크게. Stardew 벽지 137, 바닥재 97(위키 아이콘을 제가 센 수). New Horizons 262와 215. New Horizons 가구 3.0.2 기준 2,076
점수 출처를 나열하고, 요일을 고정하고, 집과 함께 기준을 올리고, 자리를 비운 것을 결코 벌하지 않는다. 해피 홈 아카데미: 대부분의 일요일. B, A, S. S는 15,000에서 90,000. 6, 10, 15, 20개에서 1,000. 시리즈, 세트, 카테고리, 색(팬 표, 출처 없음). 특정 게임을 밝히지 않은 위키의 집 페이지는 적어도 일주일 방치한 집에 바퀴벌레가 들끓는다고 하고, New Horizons의 HHA 표는 바퀴벌레 마리당 2,500을 깎는다. 이 규칙은 그 벌을 거부한다
카탈로그 성장 9+ 앱이라면 플레이로 늘린다. 얻어서 채우는 선반과, 이정표에서 열리는 카탈로그. 무작위 판매나 희소 판매로는 결코 늘리지 않는다. Emerald는 120개 중 90개 판매, 24개 비매품, 두 개는 6,000 ash와 8,000 ash. Stardew는 매일 무작위 재고, 첫 증축 뒤에는 목록 가구가 0g인 200,000g 카탈로그, 박물관과 축제 등의 전용품은 그 밖. 반례로 Habbo의 레어, 크래커블, LTD
방문 방문자는 보기만 하고 손대지 않는다. 방문자당 하루 한 번의 표시. 호스트의 총합은 결코 내려가지 않는다. Animal Crossing 방문자는 “modify the interior in any way”(어떤 식으로든 실내를 바꾸는 것)를 할 수 없다. Habbo 방문자는 권한 없이 가구를 내려놓거나 옮길 수 없다. Club Penguin은 디자인당 하루 한 번 좋아요, Grand Total은 결코 줄지 않는다(팬 출처 하나)
저장 배치된 아이템은 몇 바이트: 종류, 셀, 방향. Emerald: ID 1바이트와 위치 1바이트, 기지 하나에 32바이트

출처: 1절에서 3절까지와 그 각주.256781916414033181746141511

이 가운데 세 가지는 한 문장씩 덧붙일 만합니다.

상한은 눈을 위한 예산이고, 때로는 GPU를 위한 예산이기도 합니다. Emerald의 16은 기지 바닥의 약 4분의 1입니다. FFXIV는 화면에 가구가 400개를 넘으면 일부를 그리지 않는다고 대놓고 말합니다.27 휴대폰 앱에는 두 번째 이유도 실재하지만, 제 해석으로는 숫자를 정하는 것은 첫 번째 이유입니다. 상한이야말로 선반을 구도로 바꾸며, 이는 10월 3일 세계 편 글이 열여섯을 고른 이유로 든 것입니다.10

통로 규칙은 브리프가 더한 것입니다. Emerald의 CanPlaceDecoration이 지키는 것은 기껏해야 셀 하나, 메뉴를 열려고 서 있던 셀뿐이며, 문에서 아직 컴퓨터까지 갈 수 있는지는 결코 묻지 않습니다.4 제가 읽은 Stardew와 Sims 페이지는 타일마다 색이 바뀌는 발자국을 설명하지만, 두 게임이 통로도 확인하는지는 말하지 않으며, 저도 더 찾아보지 않았으므로 이 글은 어느 쪽으로도 아무것도 주장하지 않습니다.1646 다른 사람이 찾아오는 방에서는 이 질문에 답이 있어야 합니다. 진열에 닿지 못하는 방문자에게는 볼 것이 없기 때문입니다.

플레이 해금은 어린이용 앱의 카탈로그 문제에 대해 방어할 수 있는 결론입니다. 이는 제 해석이지 법률 자문이 아닙니다. 사거나, 무작위이거나, 희소한 장식 루프는 수집 앱에 필요 없는 루트박스와 결제 압박의 문제를 떠안습니다. Emerald의 얻어서 채우는 선반은 그런 것이 전혀 필요 없는 방 루프를 보여 주고, Stardew의 카탈로그는 플레이의 이정표 뒤에 게임 내 화폐로 한 번 사는 것으로, 목록에 있는 모든 것의 희소성을 끝내는 방법을 보여 줍니다.141617

5. Apple의 방식: 동기화되는 모델, 칸에 맞춰지는 드래그, VoiceOver로 쓸 수 있는 그리드

iOS의 가구 배치 화면에는 세 가지가 필요합니다. iCloud로 동기화되는, 배치된 가구 하나마다의 레코드. 가구를 셀 위로 끌어다 놓는 방법. 그리고 같은 일을 시각이나 터치 없이 하는 방법입니다. 아래 내용은 모두 2026년 10월 5일 JSON으로 저장한 Apple 문서 페이지에서 스크립트로 제목, 선언, 요약, 플랫폼을 뽑아낸 것입니다.48 이 글을 위해 빌드하거나 실행한 것은 없으며, 아래의 비용은 어느 것도 측정하지 않았습니다.

레코드: CloudKit에 맞춘 SwiftData

@Model은 “Converts a Swift class into a stored model that’s managed by SwiftData”(Swift 클래스를 SwiftData가 관리하는 저장 모델로 바꾼다)이며, iOS 17.0부터 쓸 수 있습니다.49 SwiftData는 #Unique로 고유성을 강제할 수 있는데, 이는 “Specifies the key-paths that SwiftData uses to enforce the uniqueness of model instances”(SwiftData가 모델 인스턴스의 고유성을 강제하는 데 쓰는 키 경로를 지정한다)이며 iOS 18.0부터입니다.50 배치된 가구에는 셀 하나에 하나라는, 딱 맞는 쓰임새로 보입니다.

CloudKit 동기화가 이를 막습니다. SwiftData 동기화에 관한 Apple의 가이드는 이 프레임워크가 “does include a small number of features that CloudKit doesn’t support natively, such as unique constraints and nonoptional relationships”(고유 제약이나 옵셔널이 아닌 관계처럼 CloudKit이 기본으로 지원하지 않는 기능을 몇 가지 포함한다)고 하며, “CloudKit requires all relationships to be optional.”(CloudKit은 모든 관계가 옵셔널이어야 한다)고 말합니다.22 Kiradex의 모델은 이미 그렇게 만들어져 있습니다. CardCopy의 주석은 “every property has a default and nothing is unique, for CloudKit”(CloudKit을 위해 모든 프로퍼티에 기본값이 있고 고유한 것은 없다)이라고 하고, PriceHistory는 “Shaped for CloudKit like CollectionEntry: defaults everywhere, nothing unique”(CollectionEntry처럼 CloudKit에 맞춘 형태: 어디에나 기본값, 고유한 것은 없음)라고 하며, 두 기기가 같은 기록을 만들면 모든 기기에서 같은 승자를 고르는 접기(fold)가 있습니다.5152

그래서 중요한 고유성, 즉 셀 하나에 가구 하나라는 조건은 코드로 강제해야 합니다. 읽을 때마다 실행되어, 한 셀에 놓인 두 기기의 가구를 어디서나 같은 승자로 정리하고 진 쪽을 트레이로 돌려보내는 순수 함수입니다. 두 기기가 함께 망가뜨릴 수 있는 것은 셀 하나만이 아닙니다. 각자의 휴대폰에서는 모든 규칙을 통과하는 두 편집이 합쳐지면 실패할 수 있으므로, 이 함수는 겹침 검사만이 아니라 배치 검사 전체를 거쳐 방을 다시 지어야 합니다. 7절의 브리프가 이를 정합니다.

드래그: draggable, 드롭 대상, 손가락 아래의 셀

draggable(_:)은 Transferable 페이로드에 대해 “Activates this view as the source of a drag and drop operation”(이 뷰를 드래그 앤 드롭 동작의 출발점으로 활성화한다)이며, iOS 16.0부터입니다.53 dropDestination(for:action:isTargeted:)는 드롭된 아이템과 CGPoint를 받는데, 그 페이지는 이 점을 “the drop location in this view’s coordinate space”(이 뷰의 좌표 공간에서의 드롭 위치)라고 설명하며, 역시 iOS 16.0부터입니다.54 그 점을 셀로 바꾸는 일은 산수입니다. 맵의 원점을 빼고 타일의 포인트 단위 크기로 나눕니다.

예전 메모에 없던 발견이 하나 있습니다. 저장한 dropDestination(for:action:isTargeted:) 페이지는 이를 폐기 예정으로 만드는 릴리스로 iOS 27.2를 적고, “Use dropDestination(for:isEnabled:action:) with an action that takes a DropSession parameter instead.”(대신 DropSession 매개변수를 받는 action과 함께 dropDestination(for:isEnabled:action:)를 사용하라)라는 메시지를 붙여 둡니다.54 대체 API의 action은 점 대신 DropSession을 받으며, 이는 “A description of a drop that is in progress”(진행 중인 드롭에 대한 기술)입니다.54 DropSession 페이지는 저장하지 않았으므로 그것이 뷰의 좌표 공간에서의 위치를 담는지는 읽지 못했고, 브리프는 두 형태를 모두 적습니다.

방에 이미 있는 가구를 옮기는 데는 DragGesture가 “A dragging motion that invokes an action as the drag-event sequence changes”(드래그 이벤트 시퀀스가 바뀔 때마다 동작을 호출하는 드래그 움직임)이고(iOS 13.0), SpatialTapGesture가 “A gesture that recognizes one or more taps and reports their location”(한 번 이상의 탭을 인식하고 그 위치를 알려 주는 제스처)입니다(iOS 16.0). 탭으로 가구를 고르고, 드래그로 셀 단위로 옮깁니다.5556

Kiradex의 카메라 아래에서 드롭 지점이 타일 셀에 깔끔하게 대응하는지는 테스트되지 않았습니다. 방은 RealityKit이 텍셀당 정수 개의 기기 픽셀로 그리고, 드롭을 받는 SwiftUI 오버레이가 그 위에 얹혀 있습니다. 계산은 카메라의 맞춤(fit)이 이미 하는 것과 같지만, 아직 아무도 그 위에 무언가를 떨어뜨려 본 적이 없습니다.10

터치 없는 그리드: VoiceOver

가구 그리드는 요소를 하나씩 쓸어 넘기기에 맞지 않으므로, 설계는 VoiceOver에 전용 동사를 줍니다.

  • accessibilityElement(children:)는 “Creates a new accessibility element, or modifies the AccessibilityChildBehavior of the existing accessibility element”(새 접근성 요소를 만들거나 기존 접근성 요소의 AccessibilityChildBehavior를 바꾼다)이며(iOS 13.0), 여러 셀에 걸친 가구를 요소 여섯 개가 아니라 하나로 만듭니다.57
  • accessibilityAction(named:_:)은 이름 있는 동작을 더합니다. “Actions allow assistive technologies, such as the VoiceOver, to interact with the view by invoking the action”(동작을 통해 VoiceOver 같은 보조 기술이 동작을 호출해 뷰와 상호작용할 수 있다)이라고 합니다(iOS 16.0). 왼쪽으로 이동, 오른쪽으로 이동, 위로 이동, 아래로 이동, 돌리기, 치우기가 각각 동작 하나입니다.58
  • accessibilityAdjustableAction(_:)은 위아래 쓸기를 AccessibilityAdjustmentDirection으로 처리하며(iOS 13.0), 벽지나 바닥을 차례로 바꾸는 데 알맞습니다.59
  • accessibilityRotor(_:entries:)는 “an Accessibility Rotor with the specified user-visible label”(지정한, 사용자에게 보이는 레이블을 가진 접근성 로터)을 만들며(iOS 16.0), “가구” 로터로 방의 가구 사이를 건너뛸 수 있습니다.60
  • AccessibilityNotification.Announcement는 “A notification that an app posts when it needs to convey an announcement to an assistive app”(앱이 보조 앱에 안내를 전해야 할 때 보내는 알림)입니다(iOS 17.0). 거부된 이동은 모두 그 이유와 함께 읽어 줍니다.61

그러면 UI 테스트는 XCUIApplication.performAccessibilityAudit(for:_:)로 화면을 감사할 수 있습니다. iOS 17.0으로 적혀 있고, 저장한 페이지에는 요약이 없으며 이 모듈 경로에는 Xcode 16.3이 적혀 있습니다.62 이것이 하는 일은 감사뿐입니다. Xcode 27.0과 함께 설치되는 XCUIAutomation 헤더에서 이 감사는 “Runs an accessibility audit on the current view”(현재 뷰에서 접근성 감사를 실행한다)입니다. 같은 헤더는 iOS 27.0부터 XCUIVoiceOverService를 추가하는데, 이는 “Provides programmatic control of VoiceOver for UI testing”(UI 테스트를 위해 VoiceOver를 프로그램으로 제어한다)이며, VoiceOver를 켜고 끄고, 포커스를 앞, 뒤, 컨테이너 안과 밖으로 옮기고, 포커스된 요소에 대해 VoiceOver가 읽는 내용을 돌려줍니다. 프레임워크의 모든 헤더를 검색해도 이름 있는 사용자 정의 동작을 수행하거나, 로터를 돌리거나, 안내를 읽는 호출은 찾을 수 없으므로, UI 테스트는 VoiceOver 사용자처럼 왼쪽으로 이동이나 치우기를 누를 수 없습니다.63 브리프는 그 동작들의 핸들러를 직접 테스트하고, 읽어 주는 레이블은 VoiceOver 서비스로 확인하며, 동작, 로터, 안내는 VoiceOver를 켠 사람에게 맡깁니다.

비용

측정하지 않았습니다. 가구를 들인 집은 두 층 각각에 최대 16개의 작은 레코드입니다. 배치된 가구가 엔진이 포지의 가구를 위해 이미 만드는 오브젝트 메시 하나에 합쳐진다면, 변경할 때마다 그 메시를 다시 만들어야 합니다. 어느 것도 휴대폰에서 프로파일링하지 않았습니다.39

6. 사례 연구: 오늘의 Kiradex 실내

Kiradex는 iPhone용 카드 수집 앱으로, Kiradex World라는 작은 픽셀 마을이 있습니다. 마을에서 수집가마다 2층짜리 집을 가지며, 마을에는 쇼 홀이 있습니다. 이 절의 모든 내용은 2026년 10월 5일 앱 저장소에서 읽은 것이며, 실행하거나 바꾸지 않았습니다. 실내는 스크립트로 파싱했고, 문서와 모델은 텍스트로 읽었습니다.964

구조물 편 글 이후 바뀐 것

10월 3일 구조물 편 글은 interiors.py가 방, 위층, 홀을 “each 14 by 11, with a two-row wall band”(각각 14×11, 두 줄의 벽 띠)로 그린다고 했습니다.39 쓸 당시에는 사실이었습니다. 같은 날 TestFlight 빌드 26이 실내 키트를 가져왔습니다. “Rooms sixteen wide with a three-row wall band (cornice, face, wainscot)”(너비 16의 방에 세 줄의 벽 띠(코니스, 벽면, 징두리판)), 32픽셀 리듬의 가구, 바닥으로 그리는 벽에 붙은 가구와, 수집가가 그 뒤로 걸어가는 오브젝트로 그리는 독립 가구입니다.65 지금 포지는 room과 room-up을 16×12 셀로, 홀을 16×13으로 그리며, 각각 코니스, 벽면, 징두리판의 세 줄 띠가 있습니다.964 빌드 26은 구조물 편 글이 설명하는 빌드 23과 그 저녁 추가 글이 설명하는 빌드 35 사이에 있으므로, 두 글 모두 각자의 빌드에 대해서는 맞습니다.3965

포지의 가구

scripts/forge/interiors.py는 PIECES 표에 가구 23가지를 적어 두었고, 각각 셀 단위의 너비와 높이, 그리고 독립 가구인지를 나타내는 플래그를 가집니다.9

종류 가구와 차지하는 영역(셀, 너비×높이)
벽에 붙어 바닥에 그려 넣는 것(9) 책장 5×2, 옷장 2×2, 조리대, 싱크대, 화덕 각 1×1, 벽난로 2×2, 계단과 내려가는 계단 각 2×3, 기둥 1×3
독립해 서며, 수집가와 앞뒤를 정렬하는 오브젝트로 내보내는 것(14) 침대와 장미 침대 각 2×3, 협탁 1×1, 테이블 2×2, 네 방향 의자 각 1×1, 소파 3×2, 벤치 2×1, 식물 1×2, 상자, 나무 궤짝, 통 각 1×1

measure_kiradex_interiors.py로 PIECES에서 파싱. 파일은 임포트하거나 실행하지 않았다.9

가구 하나가 덮는 셀은 1에서 10개, 평균 3.04개이며, Emerald의 1에서 9개, 평균 2.43개와 비교됩니다.92 서로 다른 그림은 이름보다 적습니다. 의자 넷은 그림 하나의 네 방향이고, 침대 둘은 변형 두 가지, 계단 둘은 방향 두 가지이며, 조리대, 싱크대, 화덕은 조리대 하나의 세 종류입니다.9

파일의 docstring과 표가 어긋납니다. docstring은 관례를 “furniture on the 16-pixel grid in a 32-pixel rhythm, every piece at least two tiles on one axis”(가구는 16픽셀 그리드 위에 32픽셀 리듬으로, 모든 가구는 한 축으로 적어도 두 타일)로 정합니다.64 표에서는 23가지 중 11가지가 1×1입니다. 의자 넷, 조리대, 싱크대, 화덕, 협탁, 상자, 나무 궤짝, 통입니다.9 이 리듬은 큰 가구에는 맞고 작은 가구에는 맞지 않습니다. 이는 한 파일 scripts/forge/interiors.py 안에서 주석과 코드가 다른 것이며, 브리프는 작은 가구를 남깁니다. 두 타일짜리 가구만 있는 방에는 의자가 없을 것이기 때문입니다.

벽면에는 글자로 된 자체 어휘가 있습니다. 그림 p, 시계 k, 창문 N, 커튼 친 창문 K, 깃발 n, 벽 촛대 l, 그리고 벽 보드가 걸리는 자리 W입니다. 바닥은 마루 o, 타일 t, 대리석 s, 그리고 이웃 셀을 보고 스스로를 9분할(nine-slice)로 그리는 러그 r입니다. 벽 스타일은 둘로, 집의 회반죽과 목조, 홀의 다듬은 석재이며, FACES를 통해 실내마다 고릅니다.64

만들어진 그대로의 방

맵 크기 바닥 셀 가구(옮길 수 있는 것) 가구 아래의 바닥 빈 바닥 앱이 꾸미는 자리
room 16×12 125 14(13) 25 100 선반 5셀, 진열장 2, 책상 2. 도착, 계단, 호스트
room-up 16×12 125 12(11) 27 98 벽 보드 3셀, 책상 2. 계단에서 도착
hall 16×13 144 6(4) 8 받침대 8개를 놓은 뒤 128 받침대 8개

옮길 수 있는 것에서는 계단과 기둥을 뺀다. measure_kiradex_interiors.py 기준.9

host 자리에는 파일 안에 “where the owner stands when you visit”(방문했을 때 주인이 서 있는 곳)이라는 주석이 달려 있습니다.64 포지의 check()는 이미 잘못된 글자 위에 있는 선반, 진열장, 책상, 받침대 자리, 문이나 계단 위에 있지 않은 워프, 걸을 수 없는 도착, 계단, 호스트 셀, 그리고 한 셀에 내보낸 오브젝트 두 개를 거부합니다. 브리프에 중요한 것은 그 좁은 경계입니다. 벽 보드의 자리에는 글자 검사가 없고, 겹침 루프는 내보낸 오브젝트, 즉 독립 가구만 읽으므로 바닥에 그려 넣은 벽 가구는 거기에 들어가지 않습니다. 문에서 모든 자리에 닿는지는 확인하지 않습니다.64

통로 규칙을 오늘의 방에 돌려 보다

저는 내보내는 글자를 export()와 같은 방식으로 다시 짓고, 각 층의 도착 셀에서 포지의 걸을 수 있는 글자 otsrUD 위로 네 방향으로 걷는 스크립트를 썼습니다.20 오늘의 레이아웃에서 걷기는 아래층에서는 계단과 호스트에, 위층에서는 계단에 닿습니다. 진열 자리 바로 앞의 셀은 사정이 다릅니다.

  • 아래층 선반 앞 다섯 셀: 둘은 통과 나무 궤짝 아래에 있고, 셋에 닿습니다.
  • 진열장 앞 두 셀에는 둘 다 닿습니다.
  • 책상 앞 두 셀: 하나는 책상에 붙여 놓은 의자 아래에 있고, 하나에 닿습니다.
  • 위층 책상도 같아서, 둘 중 하나입니다.
  • 위층 벽 보드 앞 세 셀은 침대와 협탁 아래에 있습니다. 하나도 닿지 않습니다.20

그러니 각 자리 자신의 앞 셀에 닿아야 한다는 규칙이라면 두 층에 걸친 포지의 꾸밈 그룹 가운데 넷(아래층의 선반과 책상, 위층의 책상과 벽 보드)이 실패하고, 막힌 앞 셀은 모두 일곱 개입니다. 각 꾸밈 그룹에 닿을 수 있는 앞 셀이 하나 있으면 된다는 규칙이라면 실패하는 그룹은 하나, 위층의 벽 보드뿐입니다. 브리프는 그룹 형태를 쓰고, 시작 방을 다시 배치할 때 보드를 고칩니다.

스크립트는 room에 가구를 더 놓아 보기도 했습니다. 독립 가구 하나를 더하면 셀 규칙을 통과하는 배치가 733가지이고, 그중 44가지가 목표를 끊어 놓는데, 모두 목표 셀 자체를 덮어서 그렇게 합니다. 모든 목표에서 떨어져 있고 서로 겹치지 않는 가구 두 개를 더하면 쌍이 229,891가지이고, 그중 713가지는 목표를 덮지 않고도 끊어 놓습니다. 예를 들어 (9,3)의 침대와 (6,4)의 협탁은 유리 진열장 앞의 오목한 공간을 막아 버립니다.20 이 713가지가 바로 셀별 검사가 놓치고 걷기가 잡아내는 것입니다. 또한 두 휴대폰이 함께 만들어 낼 수 있는 것이기도 합니다. 가구 하나씩만 놓으면 모든 목표에 닿으므로 각자의 기기에서는 걷기를 통과하고, 둘이 함께 동기화되어야 비로소 실패합니다(7.7).66 추가 가구가 두 개를 넘는 경우의 탐색은 돌리지 않았습니다. 열여섯 개일 때 셀별 검사는 통과시키고 걷기는 거부하는 레이아웃이 얼마나 되는지는 측정하지 않았습니다.

그리드에 견준 수집가

수집가의 스프라이트 셀은 32×40픽셀이고 인물 위로 7픽셀, 아래로 2픽셀의 여백이 있으므로, 인물의 키는 약 31픽셀이며 셀은 너비 2타일, 높이 2.5타일입니다. Emerald 프레임의 1×2와 비교됩니다. WORLD.md는 이를 “a 30-pixel figure in a 32 × 40 cell”(32 × 40 셀 안의 30픽셀 인물)이라고 설명합니다.2767 인물 자체의 너비는 측정하지 않았습니다. 저는 이 셀을 포지가 16픽셀 그리드 위에 32픽셀 리듬으로 가구를 그리는 이유로 해석합니다. 수집가의 셀은 너비가 두 타일이기 때문입니다.

방이 하지 못하는 것

구조물 편 글의 솔직한 목록은 집에 관해서는 여전히 유효합니다. “Rooms have no wallpaper or floor choice and no placeable furniture; the house is dressed from the collection and nothing else.”(방에는 벽지나 바닥 선택도, 놓을 수 있는 가구도 없다. 집은 컬렉션으로만 꾸며진다)39 앱은 이름 붙은 자리를 컬렉션으로 꾸미고(선반에는 바인더, 진열장에는 카드, 보드에는 리본과 핀, 홀의 받침대에는 카드), 가구는 모두 포지가 놓습니다.6439

서버는 아직 방을 담아 둘 수 없습니다. 서버의 rooms 모듈에는 이렇게 적혀 있습니다. “Everything here is in memory; a room empties when its last collector leaves and nothing of them is kept.”(여기 있는 것은 모두 메모리에 있다. 마지막 수집가가 떠나면 방은 비고, 그들에 관한 것은 아무것도 남지 않는다)68 그러니 오늘 다른 수집가의 집을 방문하는 것은 맵을 방문하는 것이며, 실제 수집가의 배치를 읽기 전용으로 방문하려면 서버가 레이아웃을 저장해야 합니다.

방 규칙이 적혀 있는 곳

10월 3일 세계 편 글은 방 규칙을 발표했습니다. “a furnishing cap of sixteen”(가구 상한 열여섯), “visits are read-only, a like is once a day, and the room’s total never decreases”(방문은 읽기 전용, 좋아요는 하루 한 번, 방의 총합은 결코 줄지 않는다), 그리고 “A report arrives every Sunday grading the room, with its point sources listed”(일요일마다 점수 출처를 나열해 방을 채점하는 보고서가 도착한다)입니다.10 이 규칙들은 앱의 설계 문서에 없습니다. docs/WORLD.md 4절은 코인 상점(“clothes, hats, backpacks, card-display frames and emotes”(옷, 모자, 배낭, 카드 진열 액자, 이모트))과 레벨로 잠긴 “that cannot be bought”(살 수 없는) 꾸미기 아이템을 적지만, 가구, 상한, 좋아요, 일요일 보고서에 대해서는 아무 말도 하지 않습니다.67 규칙은 연구 노트 docs/research/pixel-art/06-collecting-and-hubs.md의 5.3절에 있으며, 거기서는 편지를 “a pixel object that appears on the doormat”(현관 매트 위에 나타나는 픽셀 오브젝트)로 할 것, “a stamp on their passport per room visited, with ranks at 30 / 100 / 500”(방문한 방마다 여권에 도장, 30 / 100 / 500에서 등급), 그리고 5.7절에서는 후원자 아이템을 “never a bigger furnishing cap”(결코 더 큰 가구 상한이 아닌 것)으로 할 것도 요구합니다.69 이 글은 세계 편 글이 발표했다는 이유로 이 규칙들을 결정된 것으로 다루며, 브리프의 첫 정리 항목은 이를 WORLD.md에 옮겨 적는 것입니다. 세계 편 글의 같은 문단에는 “Patron flair stays on the name-plate and the room skin”(후원자 표식은 이름표와 방 스킨에 머문다)이라는 말도 있습니다.10 브리프는 방 스킨을 결정된 것으로 다루지 않고, Blake의 결정 사항으로 다시 엽니다(7.5).

주간은 이미 있다

주간 퀘스트는 Quest.current에서 달력의 주 단위로 바뀌고, 홀의 테마는 그 주 퀘스트의 제목이며, 프로토타입 노트는 테스터들에게 “Weekly reset on your calendar’s week”(달력의 주 기준 주간 초기화)에 대해 묻습니다.7071 일요일 편지에는 새 시계가 필요 없습니다. 다만 7.4에서 밝힐 이유로, 편지는 자기만의 키인 그 일요일의 날짜를 씁니다.

7. 브리프: Kiradex가 만들 것과 통과해야 할 검사

이것은 브리프이지 출시된 작업의 보고가 아닙니다. 아래의 어느 것도 아직 앱에 없습니다. 6절에서 측정한 것, 즉 포지의 가구 23가지, 16×12인 집의 두 층과 16×13인 홀, 꾸밈 자리, 아무것도 남기지 않는 서버, CloudKit으로 동기화되는 SwiftData 저장소, 주간 퀘스트의 시계, 그리고 세계 편 글이 이미 발표한 방 규칙에 대한 차이(diff)로 썼습니다.96810 모든 요소는 위에서 측정한 메커니즘 하나를 이어받고, 모든 것을 Kiradex 자신의 포지, 팔레트, 말로 그립니다. 어떤 요소도 생물, 어느 게임의 장소, 프랜차이즈의 기능 이름을 쓰지 않으며, 방 안의 어떤 것도 던지거나, 잡거나, 불러내거나, 타지 않으므로, 세계 편 글이 설명하는 게임 방법 특허의 청구 단계와 닮은 것은 없습니다. 이는 제 해석이지 법률 자문이 아닙니다.10 좌표는 포지의 것으로, 왼쪽 위 셀에서 x는 오른쪽으로, y는 아래로 갑니다. 이 절의 숫자(시작 여덟 개, 점수 표, 집 등급 기준, 해금 일정)는 제 제안이지 사실이 아닙니다.

7.1 셀 단위 배치를, 포지 자신의 어휘로

집 안의 배치(Arrange) 모드. 배치할 수 있는 가구는 포지의 23가지 중 20가지입니다. stairs, stairs_down, pillar를 뺀 전부이며, 이 셋은 레이아웃의 일부로 남습니다. 의자 넷은 방향을 가진 한 종류가 되므로 20가지 가구는 바닥 종류 17가지가 됩니다. 벽면의 그림, 시계, 깃발, 촛대는 배치할 수 있는 벽 아이템 네 가지가 되어, 오늘의 포지에서 21가지가 나옵니다. 창문과 계단 개구부는 건축으로 남습니다. 7.5절이 새 가구 세 가지(진열 테이블, 병풍, 압화 벽 아이템)를 더해 모두 24가지가 됩니다.72 배치된 가구는 층의 글자 맵에서 왼쪽 위 셀 기준의 (kind, x, y, facing)이며, ROOM_FURNITURE가 이미 쓰는 것과 같은 형태입니다.964

규칙은 셀 하나하나에 대해 다음과 같습니다. 처음 다섯은 Emerald의 셀별 질문을 Kiradex의 글자에 맞게 고쳐 쓴 것이고, 여섯째는 브리프가 더한 것, Emerald의 배치 함수가 하지 않는 검사입니다.4

  1. 독립 가구는 덮는 모든 셀이 바닥(o, t, s, r)이고 다른 가구가 없어야 합니다.
  2. 벽 가구(책장, 옷장, 조리대, 싱크대, 화덕, 벽난로)는 맨 윗줄이 벽 띠 위에 있어야 하며, 이는 포지가 이미 두는 자리입니다. 벽난로는 y = 1에서 벽면과 징두리판에 걸치고, 나머지는 y = 2에서 징두리판 위에 있습니다.64
  3. 벽 아이템은 1행에 있는 벽면 셀(A)로서 창문이나 계단 개구부가 아닌 곳이 필요합니다.
  4. 도착 셀, 문 셀 두 개(포지는 문을 아래쪽 벽에 두 셀 너비로 그립니다), 계단의 걸을 수 있는 셀, 호스트 셀에는 가구를 놓을 수 없습니다.
  5. 책장은 선반 자리 다섯 개를 함께 가지고 다닙니다. 자리가 가구에 상대적이므로, 선반을 옮기면 바인더도 옮겨집니다. 유리 진열장 c와 책상 d는 이 브리프에서 고정된 글자로 남습니다.
  6. 통로 규칙. 배치한 뒤에도 도착 셀에서 걸을 수 있는 셀 위로 네 방향으로 걸어 계단 셀, 호스트 셀, 그리고 각 꾸밈 그룹(선반, 진열장, 책상, 벽 보드) 바로 앞의 셀 중 적어도 하나에 닿아야 합니다. 걷기를 끊는 가구는 거부되고, 그 거부는 무엇을 끊게 되는지 알려 줍니다.

포지가 오늘 만드는 그대로의 Kiradex 아래층을 아트 없이 셀로 나타낸 16×12 그리드. 위를 가로지르는 세 줄의 벽 띠, 거기에 붙은 책장과 유리 진열장, 오른쪽 위의 계단 셀, 아래의 문. 도착 셀에서 닿는 바닥은 흰색, 포지의 독립 가구는 회색. 도착, 계단, 호스트는 A, S, H로 표시. 선반, 진열장, 책상의 앞 셀은 닿는 것으로, 또는 통, 나무 궤짝, 의자가 놓인 곳은 가위표로 표시. 그 위에 주황색으로 (9,3)의 침대와 (6,4)의 협탁을 그리고, 이 둘이 끊어 놓는 진열장 앞 셀 여섯 개의 윤곽을 표시했습니다.

주황색 가구 두 개는 각각 셀 규칙을 통과합니다. 둘이 함께 진열장을 둘러막고, 이를 잡아내는 것은 규칙 6의 걷기뿐입니다.2420

그룹 형태를 쓰는 이유. 오늘의 레이아웃에서는 자리 앞의 셀이 가구인 경우가 많습니다. 선반 앞 다섯 셀 중 둘 아래에는 통과 나무 궤짝, 책상마다 의자, 보드 앞 세 셀 모두 아래에는 침대와 협탁이 있습니다.20 포지는 이미 이 언어의 일부를 씁니다. check()는 독립 오브젝트끼리의 겹침과, 잘못된 글자 위의 선반, 진열장, 책상, 받침대 자리를 거부합니다.64 플레이어에게는 그 규칙이 벽 가구를 포함한 모든 영역과 벽 보드의 셀까지 넓혀지고, 거기에 걷기가 더해진 것이 주어집니다.

인수 검사. - 단위 테스트가 room.json에 대해 여섯 규칙을 돌립니다. 24가지 종류(오늘의 포지에서 나온 21가지와 7.5가 더하는 세 가지) 각각이 한 셀에서 받아들여지고, 적용되는 규칙마다 한 셀에서 거부되어야 합니다. - 출시하는 시작 층 두 개(7.2) 모두에서 통로 규칙이 통과하고, 위층 보드에 닿는 앞 셀이 있음을 테스트로 고정합니다. - 속성 기반 테스트가 room과 room-up에 최대 16개의 합법적인 배치 순서를 무작위로 놓고, 단계마다 도착 셀에서의 걷기가 계단, 호스트, 모든 꾸밈 그룹의 앞 셀에 닿는지 확인합니다. - 회귀 테스트가 room의 (9,3)에 침대를, (6,4)에 협탁을 놓고, 두 번째가 진열장을 언급하는 메시지와 함께 거부되는지 확인합니다.20 - iPhone 18 Pro Max 시뮬레이터에서 배치 모드를 캡처해, 들고 있는 가구의 영역이 셀마다 색으로 표시되는 모습을 합법 하나, 불법 하나로 보여 줍니다. - 포지의 check()가 앱이 만들 수 있는 모든 레이아웃에서 통과해야 합니다. 테스트는 배치된 레이아웃을 ROOM_FURNITURE로 내보내고 포지의 검사를 읽기 전용으로 돌립니다. 그 검사는 내보낸 오브젝트만 읽고 벽 보드의 글자 검사도 없으므로, 같은 테스트가 브리프 자체의 검증기로 벽 가구를 포함해 배치된 두 영역이 셀을 공유하지 않는지, 그리고 벽 보드의 자리 세 개가 만들어진 맵에서 보드의 W 셀 위에 있는지도 확인합니다.64

7.2 상한: 층마다 열여섯, 시작 방은 여덟

내용. 층 맵마다, room과 room-up 각각에 배치된 가구 16개. 벽 아이템도 포함하며, New Horizons가 150 안에 벽과 천장 아이템을 세는 것과 같습니다.5 컬렉션이 꾸미는 것(선반의 바인더, 진열장의 카드, 보드의 리본과 핀)은 결코 세지 않습니다. 상한이 예산으로 나누는 것은 가구이고, 컬렉션이 핵심이기 때문입니다. 소유는 이 상한으로 제한되지 않습니다. Emerald가 16개 배치에 150개 소유를 허락하듯, 수집가는 들어갈 수 있는 것보다 많이 가질 수 있습니다.2

숫자. 바닥 셀 125개에 16개는 셀당 0.13으로 Emerald의 0.27의 절반입니다. 이는 Emerald의 2.43셀에 비해 평균 3.04셀인 가구, 그리고 너비가 두 타일인 셀에 사는 수집가에게 맞습니다(제 계산입니다).9227 포지의 시작 room에는 이미 옮길 수 있는 가구가 13개, room-up에는 11개 있으므로, 새 수집가가 16개 중 13개 상태로 도착하면 남은 선택은 세 개뿐입니다.9 제안은 시작 층마다 포지에서 고른 옮길 수 있는 가구 8개로 출시하는 것입니다. 아래층에서는 선반 자리를 지닌 책장을 남기고, 위층에서는 침대 하나를 남기며, 다시 배치하면서 오늘은 하나도 없는 벽 보드 앞 셀을 적어도 하나 비웁니다. 치운 가구는 사라지지 않고 수집가의 트레이로 들어가므로, 층마다 8칸이 첫날부터 수집가의 몫이 됩니다.20 시작 가구는 고정 ID로 만들어서, 두 기기가 처음 실행될 때 두 벌이 아니라 같은 레코드가 생기게 합니다(7.7).

후원과 무관. 연구 노트의 문장이 그대로 유지됩니다. 후원자 아이템은 “never a bigger furnishing cap”(결코 더 큰 가구 상한이 아닌 것)입니다.69

인수 검사. 단위 테스트로 16개를 놓고 17번째가 상한을 언급하는 메시지와 함께 거부되는지 확인합니다. 꾸밈 자리 위의 바인더, 카드, 리본, 핀이 개수를 바꾸지 않는지에 대한 테스트. 모든 후원자 등급에서 상한이 16으로 보이는지에 대한 테스트. 두 시작 층이 옮길 수 있는 가구 8개로 불러와지고 통로 규칙을 통과하는지에 대한 테스트.

7.3 벽지와 바닥

내용. 층 맵마다 벽 스타일 하나와 바닥 스타일 하나. 각각 배치 모드에서 탭 한 번으로 바꾸며, 무료이고 되돌릴 수 있습니다. Stardew의 면 하나에 동작 하나와 New Horizons의 방별 선택이지, Habbo의 영구성이 아닙니다.41533 스타일은 16개에 세지 않습니다.

이미 있는 어휘. 벽면 두 가지(plaster와 blocks), 바닥 세 가지(마루 o, 타일 t, 대리석 s), 그리고 러그입니다.64 포지는 이름 붙은 팔레트 램프에서 규칙으로 그리므로, 스타일은 그리기 함수와 램프의 짝입니다. 첫 세트는 벽면 둘을 각각 램프 셋으로, 바닥 셋을 각각 램프 둘로 그린 것으로, 벽 스타일 여섯과 바닥 스타일 여섯이며, 모두 포지가 그리고 손으로 칠한 것은 없습니다. 더 많은 것은 플레이로 옵니다(7.5).

출시 방법. 포지는 각 스타일을 방 자체의 셀 옆에 아틀라스 셀로 내보내고, 앱은 벽 셀과 바닥 셀의 바닥 인덱스를 바꿔 끼웁니다. 러그는 9분할을 유지합니다.

인수 검사. 각 벽 스타일과 각 바닥 스타일로 그린 room의 캡처, 모두 12장. 모든 스타일의 모든 픽셀이 포지 팔레트 인덱스인지 확인하는 팔레트 검사. 스타일을 바꿔도 배치된 가구와 꾸밈 자리가 그대로인지에 대한 테스트.

7.4 일요일 편지: 모든 출처를 인쇄한 주간 점수

내용. 일주일에 한 번, 현지 시각으로 일요일 자정 이후 처음 앱을 열 때 현관 매트(도착 셀에 있는 오브젝트) 위에 편지가 나타나 그 시점의 집을 채점합니다. 편지는 일요일마다 한 통이며, 현지 시각 기준 그 일요일의 날짜를 키로 씁니다. 퀘스트 보드의 주는 키가 될 수 없습니다. Quest.current는 달력의 weekOfYear 구간을 쓰고, 그 구간은 달력의 주가 시작하는 요일에서 시작하므로, 주 키와 일요일 규칙이 어긋날 수 있기 때문입니다.70 한 주를 놓쳐도 잃는 것은 없습니다. 편지는 모든 출처 줄을 점수와 함께 인쇄하고, 이어서 합계와 집 등급을 적습니다. 이름은 Kiradex 고유의 것으로 지금은 큐레이터의 메모라고 하며, 리듬을 빌려 온 게임의 이름은 결코 쓰지 않습니다.

출처. 형태는 Nookipedia가 정리한 해피 홈 아카데미의 것(개수 기준, 세트 보너스, 색 보너스)이고, 숫자는 제 것이며, 컬렉션이 들어가 있습니다.6 상한은 16과 마찬가지로 층 맵마다입니다.

출처 점수 상한 빌려 온 것
배치된 가구 하나마다 100 층당 16개 개수 기준
가구를 들인 층: 6, 10, 16개 각 500 층당 1,500 6, 10, 15, 20개에서 1,000
스위트: 한 층에 같은 포지 세트의 가구 4개 이상 가구당 200 층당 16개 한 시리즈에서 4개 이상
한 램프: 층의 가구와 두 면(벽과 바닥)의 70%가 한 램프 계열 층에 배치된 가구당 100 층당 16 70%가 한 색
한 램프 90%(70% 줄을 대신함) 층에 배치된 가구당 300 층당 16 90%가 한 색
선반: 바인더 자리 5개를 모두 컬렉션으로 채움 500 한 번 인형을 받치는 Emerald의 책상
진열장: 자리 2개에 각각 카드 각 300 600
보드: 셀 3개에 각각 핀, 도장, 리본 각 100 300
감점 없음 통로 규칙이 이미 막힌 방을 거부한다

제안. 모든 줄은 기기 안의 방과 컬렉션으로 계산할 수 있다.

이 표가 줄 수 있는 최고 점수는 23,600점으로, 두 층에 16개씩 놓고 모든 보너스를 채운 경우를 줄마다 계산한 것입니다. 스위트와 램프 줄은 열여섯 개 모두를 감당할 만큼 큰 세트와 램프 계열을 가정하므로, 이는 상한이지 누가 실제로 그린 레이아웃이 아닙니다. 세트, 램프, 자리 전의 8개짜리 시작 층은 1,300점입니다.21

두 층 모두 최대일 때 일요일 편지의 점수 출처를 보여 주는 가로 막대 그래프. 배치된 가구 하나마다 3,200. 6, 10, 16개로 가구를 들인 층 3,000. 스위트 6,400. 한 램프 90% 9,600. 가득 찬 선반 500. 진열장 600. 보드 300. 합계 23,600.

척도의 꼭대기에서는 개수보다 구도(세트와 램프)가 더 값집니다. 그것이 상한의 핵심입니다.2421

편지는 집을 세 단계의 집 등급으로 평가하며, 각 기준은 표 자체가 기준 집에 주는 점수입니다. 4,500은 두 층에 10개씩 놓고 선반을 채운 집, 7,600은 두 층에 16개씩 놓고 선반, 진열장, 보드를 채운 집, 14,000은 그 집에 층마다 8개짜리 스위트와 70% 한 램프를 더한 집입니다. 두 층에 8개씩인 시작 집은 2,600점으로 첫 등급에 못 미칩니다.21 세 숫자는 제 제안이며, 편지를 출시하기 전에 Blake가 최종 숫자를 정합니다. 아카데미와 달리 이 숫자는 오르지 않습니다. 집의 모양이 바뀌지 않기 때문입니다(아래 “이 브리프에 들어가지 않는 것” 참조).6 집 등급은 리본이 아닙니다. 앱이 이미 간직하는 리본은 마을의 수집가들에게서 오며 plaza.ribbons로 저장되고, 보드가 보여 주는 것은 그 리본입니다(6절).73 집 등급은 편지에 인쇄되고 숫자로 보관되며(7.5), 보드에는 결코 올라가지 않습니다.

점수가 결코 읽지 않는 것. 후원 등급, 코인, 구매, 좋아요, 다른 플레이어에 관한 모든 것, 그리고 후원자 방 스킨. 모든 줄을 기기 안의 방과 컬렉션으로 계산할 수 있으므로, 수집가는 자신이 왜 그 점수를 받았는지 정확히 알 수 있습니다. 후원자 방 스킨이 출시된다면, 그것은 층의 일반 벽 스타일 위에 그려질 뿐 그 자체는 벽 스타일이 아닙니다. 층은 채점을 위해 그 일반 스타일을 유지하므로, 램프 줄은 스킨을 켜든 끄든 같은 가구와 면을 셉니다(7.5).

포지 변경. PIECES에 set 태그를 더하고 같은 재질로 그립니다. 첫 세트들은 기존 가구를 그려진 재질별로 묶은 것입니다.

인수 검사. 순수 함수 Score.week(room:collection:)와 모든 줄에 대한 단위 테스트. 5, 6, 10, 16개인 층. 3개와 4개짜리 스위트. 69%, 70%, 89%, 90% 한 램프. 바인더가 4개와 5개인 선반. 최댓값이 23,600인지에 대한 테스트. 세 기준 집이 4,500, 7,600, 14,000점을 받아 각각 첫째, 둘째, 셋째 집 등급을 얻고, 2,600점인 시작 집은 아무 등급도 얻지 못하는지에 대한 테스트. 집 등급에 도달해도 plaza.ribbons와 보드에 아무것도 더해지지 않는지에 대한 테스트. 일요일 편지가 한 번만 생성되는지(같은 일요일 날짜가 두 번이면 편지 한 통, 다음 일요일에는 또 한 통), 그리고 주가 월요일에 시작하는 달력에서도 같은 키가 나오는지에 대한 테스트. 후원 등급만 다른 두 프로필이 같은 점수를 받는지에 대한 테스트. 날짜를 정하는 실행 인수를 써서 일요일에 현관 매트 위에 놓인 편지를 찍은 UI 캡처.

7.5 구매가 아닌 플레이로 해금

내용. 수집가가 소유하는 카탈로그는 플레이에서 도출됩니다. 입력 여섯 가지 중 셋은 오늘 이미 있습니다. 동기화되는 컬렉션에서 도출되는 레벨과 핀, 그리고 기기에만 기록되는 퀘스트 도장입니다. 나머지 셋에는 새 카운터가 필요하며, 각각 이름을 붙여 동기화합니다.

  • 레벨. WORLD.md의 곡선은 level = floor(sqrt(XP / 40)) + 1입니다.67 레벨 2부터 20까지는 레벨마다, 그다음은 두 레벨마다 종류나 스타일 하나씩. WORLD.md가 이미 꾸미기 아이템을 “that cannot be bought”(살 수 없는) 것으로 잠그는 방식과 같습니다.67 오늘 쓸 수 있으며, 동기화되는 컬렉션에서 도출됩니다. 앱은 경험치와 레벨을 거기서 계산하므로 “so every device agrees without anything being stored”(아무것도 저장하지 않아도 모든 기기가 일치합니다).74
  • 핀. 핀마다 이름 붙은 가구 하나를 해금합니다. Full Set은 진열 테이블, Vintage는 시계, Across the Sea는 병풍입니다. 첫째와 마지막은 새 포지 가구입니다.67 오늘 쓸 수 있으며, 같은 계산으로 동기화되는 컬렉션에서 도출됩니다.74
  • 주간 퀘스트. 주간 퀘스트를 하나 완료할 때마다 기본 가구(의자, 식물, 나무 궤짝) 하나가 더해집니다.70 오늘 기록되지만 기기에만 남습니다. 도장은 @AppStorage("quests.stamps")에 있는데, 이는 동기화되는 저장소가 아니라 UserDefaults이므로, 어떤 가구든 이에 의존하기 전에 도장을 PlayRecord(아래)로 옮깁니다.7375
  • 걸음. 긴 걷기 하나. 많은 걸음 수가 드는 가구로, Emerald의 유리 의자가 한 걸음씩 모은 6,000 ash가 드는 것과 같습니다. Emerald의 자루는 숫자를 보여 주지 않고, 공방은 플레이어가 돌아왔을 때만 모자란 양을 알려 줍니다. 여기서의 제안은 가구의 트레이 카드에 늘 보이는 카운터로, 걸은 걸음과 필요한 걸음을 함께 보여 주는 것입니다.2815 창가 식물로 만든 압화는 별도 제안으로, 벽 아이템입니다. 그 해금 조건은 이 항목의 카운터가 아니라 옛 포켓몬 게임을 빌리지 않고 기리는 법 글의 브리프가 정합니다. 식물은 256걸음마다 한 단계 자라고, 1,024걸음 동안 꽃을 피운 뒤 꽃 한 송이를 떨어뜨립니다. 새로 필요: 앱은 오늘 걸음 수를 세지 않으므로 stepsWalked가 필요합니다.73
  • 방문. 여권 등급인 방문한 방 30, 100, 500개가 각각 스타일 하나를 해금합니다.69 새로 필요: 오늘은 기기에도 서버에도 방문을 기록하는 것이 없으므로, 호스트 ID를 담는 roomsVisited가 필요합니다.7368
  • 편지. 수집가가 각 집 등급에 처음 도달하면 가구 하나를 해금합니다. 새로 필요: 집 등급은 이 브리프(7.4)에만 존재하므로, 도달한 가장 높은 집 등급을 담는 letterTier가 필요합니다.

모델 차이. 퀘스트 도장과 새 카운터 셋은 동기화되는 모델 하나인 PlayRecord에 두며, 기기마다 레코드 하나이고, 앱의 다른 모델처럼 CloudKit에 맞춘 형태입니다(7.7). 카탈로그는 모든 기기의 레코드를 읽습니다. 걸음은 더하고, 도장과 방문한 호스트는 합집합을 취하며, 가장 높은 집 등급을 택합니다. 기기는 자기 레코드의 uid를 @AppStorage 키에 보관하며, 이는 광장에서 기기의 ID인 plaza.id와 같은 UserDefaults 네임스페이스에 있습니다.7375 각 기기는 자기 레코드에만 쓰므로 두 기기가 같은 레코드를 편집하는 일이 없고, 병합 규칙도 필요 없습니다. 이는 포인터가 한 기기에 머무는 동안에만 성립하며, 두 번째 휴대폰으로 복원한 백업은 포인터도 함께 가져갑니다(제 해석이며, 복원은 테스트하지 않았습니다). 그래서 레코드는 기기 표식인 writer를 가지며, 규칙은 이렇습니다. 복원된 기기는 포인터가 가리키는 레코드를 다른 기기가 썼다면 새 레코드를 만듭니다. 옛 레코드는 남고, 카탈로그는 계속 그것도 읽습니다. 백업이 새 휴대폰으로 옮기지 않는 표식을 어떤 값으로 만들지는 이 브리프에서 정하지 않으며, 테스트가 규칙을 고정합니다. 변경 후 처음 실행할 때 기기는 자기 quests.stamps 목록을 자기 레코드에 한 번 복사합니다.

거부하는 것. 가구나 스타일의 인앱 결제, 가구의 코인 가격, 어떤 종류든 무작위 가구, 수량 한정 가구, 가구 거래. Habbo의 크래커블, 레어, 거래 가치가 반례입니다.1735 제 해석으로는, 장식 루프가 구매나 무작위에 기대는 9+ 앱은 수집 앱에 필요 없는 루트박스와 결제 압박의 문제를 떠안고, 플레이 해금은 이를 피합니다. 연구 노트가 허락하는 유일한 유료 예외는 후원자를 위한 “one room skin”(방 스킨 하나)이며, 세계 편 글은 이를 명시했습니다. “Patron flair stays on the name-plate and the room skin”(후원자 표식은 이름표와 방 스킨에 머문다).6910 같은 문장이 한계도 정합니다. 후원자 표식은 “never touches a pedestal slot or a judging bonus”(받침대 자리나 심사 보너스에는 결코 닿지 않는다).10 이 브리프는 스킨을 확정된 것으로 다루지 않고 Blake의 결정 사항으로 다시 엽니다. 그가 스킨을 유지한다면, 스킨은 벽 스타일이 아니라 시각적 오버레이입니다. 층은 수집가가 고른 일반 벽 스타일을 유지하고, 스킨은 그 위에 그려지며, 점수는 일반 스타일만 읽으므로, 7.4의 램프 줄은 스킨을 켜든 끄든 같은 분모에 대해 같은 가구와 면을 셉니다. 대신 벽을 램프 계산에서 빼는 것은 중립적이지 않습니다. 비율이 가구뿐 아니라 면도 세기 때문입니다. 가구 16개 중 15개와 바닥 스타일이 한 램프에 있고 벽은 그 밖에 있는 층은 18개 중 16개, 88.9%로 70% 줄에서 1,600점, 즉 램프 밖의 하나를 포함해 배치된 가구 16개 각각에 100점입니다. 벽을 빼면 17개 중 16개, 94.1%로 90% 줄에서 4,800점, 16개 각각에 300점이 되어, 유료 스킨에 3,200점의 심사 보너스가 붙습니다.76 아래 테스트는 스킨을 이름으로 따로 떼어 냅니다.

인수 검사. 소유 카탈로그가 XP, 핀, 퀘스트 도장, 걸은 걸음, 방문한 방, 집 등급의 순수 함수이며 그 밖의 어떤 것으로도 바뀌지 않는지에 대한 단위 테스트. 두 기기의 PlayRecord를 어느 순서로 읽어도 같은 카탈로그가 나오는지(걸음은 합, 도장과 호스트는 합집합, 가장 높은 집 등급)에 대한 테스트. 기기의 기존 quests.stamps 목록이 자기 레코드에 한 번만 복사되고 두 번 복사되지 않는지에 대한 테스트. 포인터가 다른 기기의 writer를 가진 레코드를 가리키는 기기가 새 레코드를 만들고, 옛 레코드를 바꾸지 않고 두며, 둘 다 계속 세는지에 대한 테스트. 어떤 StoreKit 제품 식별자나 코인 상점 아이템도 가구 종류나 스타일에 대응하지 않는지에 대한 테스트이며, 이름을 밝힌 예외는 하나뿐입니다. Blake가 후원자 방 스킨을 유지한다면, 그 제품은 정확히 오버레이 하나에 대응하고 어떤 벽 스타일에도 대응하지 않으며, 적용해도 층의 채점용 벽 스타일은 바뀌지 않아야 합니다. 층이 스킨을 켜고 끈 상태에서 줄마다 같은 점수를 받고 같은 집 등급을 얻는지에 대한 테스트를 모든 경계값에서 돌립니다. 5, 6, 10, 16개, 69%, 70%, 89%, 90% 한 램프를 각각 일반 벽이 램프 계열 안에 있을 때와 밖에 있을 때로, 그리고 각 집 등급 기준보다 1점 아래인 집과 딱 맞는 집으로. 레벨 1(시작 세트만)과 레벨 20에서 카탈로그 트레이의 스냅숏 테스트.

7.6 방문: 읽기 전용, 하루 한 번의 좋아요, 결코 내려가지 않는 총합

내용. 방문자는 마을이 이미 자기 수집가들의 집에 쓰는 방 워프를 이용해 문으로 호스트의 집에 들어가39 호스트가 배치한 가구, 스타일, 꾸밈 자리를 봅니다. 방문자는 걸을 수 있고 미리 정해진 문장을 말할 수 있지만, 아무것도 옮기거나, 가져가거나, 더할 수 없습니다. 이는 Habbo의 규칙이며, New Horizons의 꿈이 방문자가 바꾼 것을 아무것도 남기지 않음으로써 도달하는 결과이기도 합니다.1832 문의 좋아요는 현지 날짜 기준으로 방문자 한 명이 호스트 한 명에게 하루 한 번만 세고, 호스트의 총합은 방을 다시 꾸며도 결코 줄지 않습니다. 이는 Club Penguin의 규칙이며, 팬 출처 하나에 따른 것입니다.19 방문하면 방문자는 여권 도장을 받고, 방문자의 기기가 이를 자기 PlayRecord의 roomsVisited에 더합니다(7.5).69

서버 차이. 오늘의 서버는 아무것도 남기지 않습니다.68 방문에는 플레이어마다 작은 레코드 두 개가 필요합니다. 첫째는 집 레이아웃입니다. 두 층에 걸쳐 최대 32개의 배치된 가구로, 각각 종류, x, y, 방향을 가지며, 층마다 스타일 ID 두 개가 더해집니다. 이름 붙은 키를 쓰는 압축 JSON으로, 모든 칸에 제안된 가장 긴 종류 이름을 넣고 스타일 ID를 16자로 하면 1,974바이트로 2 KB 미만이고, 숫자 네 개짜리 묶음만 쓰면 385바이트입니다(제 계산이며, Emerald의 기지 전체는 32바이트입니다).7211 둘째는 그날의 방문자 집합을 함께 지닌 좋아요 총합입니다. 둘 다 플레이어의 핸들 말고는 개인 데이터를 담지 않습니다. 서버는 레이아웃을 저장하기 전에 같은 여섯 규칙으로 검증하므로, 변조한 클라이언트가 불법적인 방을 저장할 수는 없습니다. 7.5의 플레이 카운터(퀘스트 도장, 걸은 걸음, 방문한 방, 집 등급)는 서버 레코드가 아닙니다. 그것들은 수집가 자신의 iCloud를 통해 PlayRecord로 동기화되며, 서버는 결코 읽지 않습니다.

인수 검사. 서버 테스트로 다음을 확인합니다. 겹침, 막힌 통로, 층의 17번째 가구가 있는 레이아웃은 거부됩니다. 호스트의 방에서 방문자의 이동이나 배치 메시지는 거부됩니다. 같은 방문자가 같은 날 누른 좋아요 두 번은 한 번으로 세고, 다음 날의 좋아요는 셉니다. 방을 비운 호스트도 총합을 유지합니다. 시뮬레이터 두 대로 걸어 보는 확인도 합니다. 기기 A가 배치하고, 기기 B가 방문해 같은 셀에서 같은 가구를 보며, 각각의 캡처를 남깁니다.

7.7 iOS 26에서의 모델과 화면

SwiftData. 앱의 다른 모델처럼 CloudKit에 맞춘 모델 두 개. 어디에나 기본값이 있고, 고유한 것은 없으며, Profile, PriceHistory, CardCopy가 지닌 것처럼 init에서 UUID로 설정되는 uid를 가집니다.51775222

@Model final class PlacedPiece {
    var uid: String = ""             // set once, at creation; orders the repair
    var roomMap: String = "room"     // "room" or "room-up"
    var kind: String = ""            // a forge PIECES name
    var x: Int = 0
    var y: Int = 0
    var facing: String = "down"
    init() { uid = UUID().uuidString }
}

@Model final class PlayRecord {      // one per device (7.5)
    var uid: String = ""             // the device's pointer to it is an @AppStorage key
    var writer: String = ""          // device marker: the one device that writes it
    var questStamps: [String] = []   // moved from @AppStorage("quests.stamps")
    var stepsWalked: Int = 0
    var roomsVisited: [String] = []  // hosts' ids
    var letterTier: Int = 0          // highest house tier reached, 0 to 3
    init() { uid = UUID().uuidString }
}

벽과 바닥 스타일은 Profile 위에 문자열로, lookData 옆에 둡니다.77 #Unique도 필수 관계도 없습니다. CloudKit이 둘 다 지원하지 않기 때문입니다.22 셀 독점, 상한, 걷기는 코드에서 함수 하나로 강제합니다. RoomLayout.repair(_:)는 읽을 때마다 실행됩니다. 층의 동기화된 가구를 uid 오름차순으로 정렬하고, 층을 고정된 건축(글자 맵, 계단, 기둥)에서부터 다시 짓되, 그 순서대로 각 가구를 더하는데, 이미 받아들인 가구들에 대해 7.1의 배치 검사 전체, 즉 셀 규칙(따라서 겹침 없음), 상한 16, 통로 규칙이 그것을 받아들일 때만 더합니다. 검사가 거부한 가구는 트레이로 돌아갑니다. 모든 기기가 같은 레코드를 같은 방식으로 정렬하므로 모든 기기가 같은 방을 다시 짓고, 두 가구가 충돌하면 uid가 작은 쪽이 이깁니다. 이는 PriceBook이 두 기기의 가격 기록 중 하나를 고를 때 이미 쓰는 규칙입니다.52 순서를 배치 시각이 아니라 uid로 정하는 것은, 시각이 각 휴대폰 자신의 시계에서 오기 때문입니다. 두 휴대폰이 만들 수 있는 충돌은 겹침만이 아닙니다. 한 휴대폰에서 (9,3)에 놓은 침대와 다른 휴대폰에서 (6,4)에 놓은 협탁은 각자의 기기에서 배치 검사 전체를 통과하지만, 함께 있으면 진열장 앞의 두 셀을 모두 끊어 놓습니다. 다시 짓기는 uid가 작은 쪽을 남기고 다른 쪽을 돌려보냅니다.2066 가구를 빼는 일은 통로를 끊지 않으므로, 이미 합법적인 층은 어떤 순서로든 다시 짓기를 그대로 통과합니다(제 추론이며, 인수 검사가 이를 고정합니다). 7.2의 시작 가구는 플레이어가 아무것도 하지 않았는데 두 기기가 레코드를 만드는 유일한 곳이므로, 각 가구에 무작위 값 대신 층과 칸에서 정해지는 고정 uid, 즉 starter.room.1부터 starter.room-up.8까지를 줍니다. 처음 실행되는 두 기기는 같은 uid 열여섯 개를 만들며, 다시 짓기가 층과 트레이로 갈라놓을 열여섯 쌍을 만들지 않습니다. repair는 다시 짓기 전에 같은 uid를 가진 레코드를 하나로 접습니다. ModelContext.profile()이 동기화가 남긴 중복 프로필을 가장 작은 uid의 것으로 접는 것과 같은 방식입니다.77 두 사본이 다를 때, 즉 한 기기가 다른 기기가 처음 실행되기 전에 시작 가구를 옮겼을 때, 접기는 시작 셀에서 벗어난 사본을 남기고, 둘 다 옮겨졌다면 행이 작은 쪽, 그다음 열이 작은 쪽을 남깁니다(제 제안입니다). 가구를 치울 때 그 레코드를 지운다면, 한 휴대폰에서 치운 시작 가구는 두 번째 휴대폰이 처음 실행될 때 되돌아옵니다. 이 브리프는 그 경우를 정하지 않습니다.

배치. 배치 모드는 방의 RealityView 위에 SwiftUI 트레이를 겹칩니다. 트레이 아이템은 종류를 Transferable 페이로드로 하는 draggable이고, 방 뷰는 드롭 대상입니다.53 iOS 26에서 dropDestination(for:action:isTargeted:)는 action에 뷰 좌표의 드롭 지점을 넘기고, 그 지점은 카메라의 알려진 정수 픽셀 배율로 셀에 대응됩니다. cell = floor((point - mapOrigin) / tileSizeInPoints)입니다.54 Apple의 페이지가 이 형태를 iOS 27.2에서 폐기 예정으로 적고 있으므로, 브리프는 DropSession 형태도 만들고, 세션이 위치를 담고 있다면 거기서 위치를 읽습니다. 그 페이지는 아직 읽지 않았습니다.54 배치된 가구는 SpatialTapGesture로 선택하고 DragGesture로 옮기며, 셀 단위로 맞춰지고, Stardew가 타일을 칠하듯 그 영역을 셀마다 색으로 표시합니다.565516

VoiceOver. 배치 모드에서 배치된 가구는 각각 접근성 요소 하나입니다. 예를 들어 소파, 3×2, 9열, 8행이며, 이름 있는 동작 왼쪽으로 이동, 오른쪽으로 이동, 위로 이동, 아래로 이동, 돌리기(의자만), 치우기를 가집니다.5758 “가구”라는 이름의 로터가 방의 가구를 나열합니다.60 트레이 아이템의 놓기 동작은 도착 셀에서 가장 가까운 합법적인 셀에 가구를 놓고 그쪽으로 포커스를 옮깁니다. 벽과 바닥 스타일은 조절 가능한 요소로, 위아래로 쓸어 차례로 바꿉니다.59 모든 거부는 안내로 읽어 줍니다. 예를 들면 옮길 수 없습니다: 소파가 선반으로 가는 길을 막습니다입니다.61 7.1의 규칙은 함수 하나이므로, 음성과 터치가 서로 어긋날 일은 결코 없습니다.

인수 검사. repair가 두 기기의 겹침을 어느 순서로든 같은 방식으로 해결하는지에 대한 단위 테스트. 두 기기 병합 회귀 테스트를 두 레코드의 입력 순서 양쪽으로 돌립니다. 포지가 오늘 만든 그대로의 room에서 기기 A가 (9,3)에 침대를, 기기 B가 (6,4)에 협탁을 놓습니다. 각 배치는 혼자서는 배치 검사 전체를 통과합니다. 둘 다 동기화된 뒤 repair는 두 순서 모두에서 같은 방을 돌려주고, uid가 작은 가구를 남기며, 다른 하나를 진열장을 언급하는 메시지와 함께 트레이에 넣고, 도착 셀에서의 걷기는 여전히 진열장 앞의 두 셀에 닿아야 합니다. 두 uid를 바꾸면 다른 가구가 남아야 합니다.66 repair가 16개짜리 합법적인 층을, 레코드를 여러 순서로 섞어도 바꾸지 않는지에 대한 테스트. 한 층의 동기화된 가구 17개가 상한만 빼면 함께 합법적일 때, 16개로 돌아오고 uid가 가장 큰 것이 트레이에 들어가는지에 대한 테스트. 처음 실행되며 각각 시작 가구를 만드는 두 기기가 어느 동기화 순서로든 시작 셀마다 레코드 하나, 층마다 8개로 동기화되고 트레이에는 아무것도 없는지, 그리고 다른 기기가 실행되기 전에 한 기기에서 옮긴 시작 가구가 옮긴 자리에 머무는지에 대한 테스트. 트레이 아이템을 셀로 끌어다 놓고 그 셀에서 PlacedPiece를 찾는 UI 테스트. VoiceOver를 거치지 않고 배치 모델에서 직접 호출하는 VoiceOver 동작 핸들러의 단위 테스트. 놓기는 도착 셀에서 가장 가까운 합법적인 셀에 의자를 놓고, 왼쪽으로 이동, 오른쪽으로 이동, 위로 이동, 아래로 이동은 각각 한 셀 옮기거나 이유와 함께 거부하며, 돌리기는 방향을 차례로 바꾸고, 치우기는 트레이로 돌려보내며, 모든 거부가 화면이 보낼 안내 문구를 만들어야 합니다. iOS 27 시뮬레이터에서 XCUIVoiceOverService로 VoiceOver를 켜고, 배치된 가구로 포커스를 옮겨 소파, 3×2, 9열, 8행 같은 읽기 레이블을 확인하는 UI 테스트.63 배치 모드를 performAccessibilityAudit로 감사해 문제가 보고되지 않는 것.62 VoiceOver를 켠 기기에서의 수동 검사를 날짜와 빌드와 함께 기록하는 것. 어떤 XCUIAutomation 호출도 사용자 정의 동작을 수행하거나, 로터를 돌리거나, 안내를 읽지 않기 때문입니다. 트레이에서 의자를 놓고, 동작으로 네 방향으로 옮기고, 돌리고, 치우고, 가구 로터로 가구 사이를 건너뛰고, 거부된 이동마다 안내를 듣습니다. 이 모든 것에 앞서 스파이크 하나를 합니다. 시뮬레이터에서 카메라의 실제 배율 아래로 방에 페이로드를 떨어뜨리고, 계산된 셀과 손가락 아래의 셀을 로그로 남깁니다. 그 대응은 테스트된 적이 없기 때문입니다.

7.8 정리 항목

  • WORLD.md에 이 브리프의 숫자와 함께 방 규칙을 넣어, 설계 문서가 세계 편 글이 발표한 내용을 말하게 합니다.6710
  • interiors.py의 docstring과 표를 어느 한쪽으로 일치시킵니다. docstring이 작은 가구를 예외라고 밝히거나, 작은 가구를 두 타일로 다시 그립니다. 브리프는 작은 가구를 남깁니다.9

이 브리프에 들어가지 않는 것

  • 선반 자체의 자리를 넘어서는 쌓기. 테이블 위의 가구도, 책상 위 인형 같은 받침면도 없습니다. 받침면 아이디어는 상한과 걷기가 입증된 뒤의 다음 단계입니다.
  • 밟으면 동작하는 가구. 소리 매트도, 스프링도, 미끄럼틀도 없습니다.
  • 반 셀 배치. 그리드는 16픽셀 정수 셀로 유지됩니다.
  • 쇼 홀의 가구 배치. 홀의 받침대는 주간 쇼의 것으로 남습니다.
  • 가구 배치 콘테스트. 주간 홀이 곧 콘테스트이며, 자체 규칙으로 심사합니다.
  • 평면도. 집의 모양은 바뀌지 않습니다.
  • 공유된 광장 밖의 낯선 사람 방문, 그리고 호스트 자신의 총합을 넘어서는 방 순위.

가구 배치에서 결코 하지 않을 것

  1. 그 어디에도 프랜차이즈 어휘를 쓰지 않습니다. 기지, 꾸미기 컴퓨터, 아카데미, 레코드 믹싱, 어떤 장식의 이름도 쓰지 않습니다. Kiradex의 말만 씁니다. 이 글에서 게임의 이름을 드는 것은 기능으로서가 아니라 출간된 작품에 관한 사실로서입니다.
  2. 게임의 장식을 본뜬 가구를 그리지 않습니다. 생물 인형이나 쿠션, 공 모양의 어떤 것도, 생물 포스터도, 기술 이름을 붙인 매트도 없습니다. 포지의 가구는 가정용 가구이며, 계속 그렇게 남습니다.
  3. 어떤 방에도 생물을 두지 않습니다. 식물은 식물입니다.
  4. 사는 가구, 무작위 가구, 한정 가구는 없습니다(7.5).
  5. 방 안의 어떤 것도 겨누거나, 던지거나, 잡거나, 불러내거나, 싸우라고 내보내거나, 타지 않습니다.
  6. 디컴파일의 코드나 데이터를 앱이나 포지에 넣지 않습니다. 디컴파일된 소스는 연구와 측정을 위한 것이고, 위의 규칙은 Kiradex 자신의 말로 다시 쓴 것입니다.

인수 검사. 문자열 카탈로그, 포지의 PIECES 이름, 서버의 테이블을, 항목 1의 프랜차이즈 어휘로 만든 단어 목록에 “decoration”, “doll”, “Happy Home”, “Academy”를 더한 것으로 검색해 아무것도 나오지 않을 것.

핵심 요약

아트를 그리는 분께

  • 가구는 캐릭터의 프레임이나 셀 너비로 그리십시오. Emerald의 플레이어 프레임은 16픽셀 셀 하나 너비이고 장식의 평균은 2.43셀입니다. Kiradex의 수집가는 너비 두 타일의 셀에 서고, 가구의 평균은 3.04셀입니다.2729
  • 카탈로그는 대부분 작은 가구로 하고, 큰 중심 가구를 몇 개 두십시오. Emerald의 장식 120개 중 71개가 한 셀이며, 책상과 3×3 매트가 작은 것들이 올라서는 중심입니다.224
  • 벽지와 바닥은 규칙과 램프로 그리십시오. 그러면 스타일은 새 그림이 아니라 그리기 함수와 팔레트가 됩니다. 벽면 둘을 램프 셋으로, 바닥 셋을 램프 둘로 그리면 Kiradex에는 각각 여섯 가지가 생깁니다.64

엔진을 만드는 분께

  • 배치된 가구는 종류, 셀, 방향으로 저장하십시오. Emerald는 장식 하나를 2바이트로, 기지 하나를 32바이트로 저장합니다.1112
  • 배치는 셀마다 확인한 다음 걸어 보십시오. Emerald의 셀별 검사는 문에서 아직 무언가에 닿는지 결코 묻지 않습니다. Kiradex의 아래층에서는 합법적인 추가 가구 쌍 229,891가지 중 713가지가 덮지 않고도 계단, 호스트, 진열 가운데 하나를 끊어 놓습니다.420
  • CloudKit 동기화에서는 SwiftData가 고유 제약을 강제할 수 없으므로, 셀 하나에 가구 하나라는 조건은 모든 기기에서 같은 승자를 고르는 순수한 복구 함수로 만드십시오. 그 함수가 걷기를 포함한 배치 검사 전체를 거쳐 고정된 순서로 방을 다시 짓게 하십시오. 각자의 휴대폰에서 통과한 두 편집이 함께 진열을 끊어 놓을 수 있기 때문입니다.225266
  • VoiceOver에는 쓸어 넘길 그리드가 아니라 동사를 주십시오. 이름 있는 이동 동작, 가구 로터, 모든 거부에 대한 안내입니다.586061

게임 루프를 설계하는 분께

  • 소유가 아니라 배치를 제한하십시오. Emerald는 16개를 놓고 150개를 보관합니다. 상한이 곧 구도입니다.2
  • 정해진 요일에 모든 출처를 나열해 채점하고, 기준은 집이 커질 때만 올리며, 놓친 주를 결코 벌하지 마십시오. 특정 게임을 밝히지 않은 위키의 집 페이지는 적어도 일주일 방치한 집에 바퀴벌레가 들끓는다고 하고, New Horizons의 HHA 표는 바퀴벌레 마리당 2,500점을 깎습니다.56
  • 카탈로그는 플레이로 늘리십시오. Emerald는 장식 120개 중 24개를 결코 돈으로 팔지 않고, 두 개는 걸어서 모은 재로만 팝니다. Stardew는 첫 증축 뒤에 200,000g짜리 카탈로그를 팔고, 그 카탈로그는 목록에 있는 가구를 0g에 팝니다. 그리고 Habbo의 희소하고 무작위인 가구는 어린이용 앱에 대한 반례입니다.14151617
  • 방문자는 보기만 하고 손대지 않으며, 결코 줄지 않는 총합에 하루 한 번 좋아요를 남깁니다.51819

자주 묻는 질문

플레이어가 방 하나에 놓을 수 있는 아이템은 몇 개여야 합니까?

구도를 짤 만큼은 많고, 고를 수밖에 없을 만큼은 적어야 합니다. Pokémon Emerald는 기지에 놓는 장식을 16개, 침실을 12개로 제한하는데, 이는 평균적인 기지의 걸을 수 있는 셀 60.2개의 약 4분의 1입니다. Nookipedia의 설명에 따르면 Animal Crossing: New Horizons는 벽과 천장 아이템을 포함해 방마다 150개를 허용하고, Final Fantasy XIV는 패치 7.5 이후 집 크기에 따라 실내 150에서 600개를 허용합니다. 벽이나 천장 레이어가 없는 2D 방이라면, 바닥 셀 세 개당 아이템 하나 미만이라는 상한이 제 기준이며, Emerald의 0.27은 그 기준 바로 아래에 있습니다. Kiradex가 제안하는 16개는 바닥 셀당 0.13입니다.2579

Pokémon Emerald의 장식 시스템은 어떻게 작동합니까?

데이터입니다. 장식 120개는 각각 카테고리, 1에서 9셀의 모양, 가격, 그리고 다섯 권한(단단한 바닥, 밟고 지나가는 바닥, 뒤쪽, 벽, 스프라이트) 중 하나를 가집니다. CanPlaceDecoration은 덮이는 각 셀을 확인합니다. 평범한 바닥인지, 오브젝트가 없는지, 그리고 플레이어가 서 있던 셀에는 레이어 유형이 일반이 아닌 타일이 없는지. 포스터에는 벽 셀. 인형과 쿠션에는 받침 셀이며, 대부분은 작거나 큰 셀, 1×2 인형에는 큰 셀입니다. 작은 받침 셀을 제공하는 장식은 18개로, 책상 일곱, 벽돌 셋, 타이어 하나, 매트 일곱입니다. 배치된 장식은 각각 ID와 위치 바이트 하나씩으로 저장됩니다.2411

해피 홈 아카데미는 방을 어떻게 채점합니까?

New Horizons에 대해 출처를 달지 않은 Nookipedia의 표에 따르면, 대부분의 일요일 아침에 우편으로 평가가 오고, 등급은 B, A, S이며, S 기준은 집이 커질수록 15,000에서 90,000으로 오르고, 방 하나의 아이템이 6, 10, 15, 20개가 될 때마다 1,000점, 시리즈, 세트, 카테고리, 주된 색, 풍수에 대한 아이템별 보너스가 있으며, 바퀴벌레, 쓰레기, 벽을 향한 아이템에는 감점이 있습니다. 아이템별 점수는 위키에서 작성 중인 상태입니다.6

CloudKit 동기화에서 SwiftData가 그리드 셀당 아이템 하나를 강제할 수 있습니까?

#Unique로는 안 됩니다. SwiftData 동기화에 관한 Apple의 가이드는 고유 제약을 “that CloudKit doesn’t support natively”(CloudKit이 기본으로 지원하지 않는) 기능 가운데 하나로 들며, CloudKit은 모든 관계가 옵셔널이어야 합니다. 모든 프로퍼티에 기본값을 주고, 아무것도 고유하게 두지 말고, 한 셀에 놓인 두 기기의 가구는 읽을 때마다 실행되어 모든 기기에서 같은 승자를 고르는 순수 함수로 해결하십시오. 그 함수가 겹침 검사만이 아니라 배치 검사 전체를 거쳐 고정된 순서로 방을 다시 짓게 하십시오. 각각은 합법적인 두 편집이 함께 규칙을 깰 수 있기 때문입니다.225166

드래그 앤 드롭 가구 그리드를 VoiceOver로 쓸 수 있게 하려면 어떻게 합니까?

배치된 가구마다 레이블에 크기와 셀을 담은 접근성 요소 하나로 만들고, 각 방향으로 한 셀 옮기기, 돌리기, 치우기라는 이름 있는 동작을 주고, 방의 가구를 나열하는 로터를 더하고, 거부된 모든 이동을 이유와 함께 안내하십시오. Apple의 accessibilityAction(named:_:), accessibilityRotor(_:entries:), AccessibilityNotification.Announcement가 각 부분을 맡고, performAccessibilityAudit가 UI 테스트에서 화면을 점검합니다. 감사는 이름 있는 동작을 누르지 않고, Xcode 27.0에서는 어떤 XCUIAutomation 호출도 누르지 않으므로, 동작 핸들러는 직접 테스트하고 동작, 로터, 안내는 VoiceOver를 켜고 손으로 확인하십시오.5860616263

어린이용 게임이 가구를 팔아야 합니까?

9+ 등급 앱이라면 제 해석으로는 아닙니다. 사거나, 무작위이거나, 희소한 장식 루프는 게임에 필요 없는 루트박스와 결제 압박의 문제를 떠안습니다. Emerald는 장식 120개 중 24개를 결코 돈으로 팔지 않고(경품, 배틀 포인트 교환품, 선물입니다), 두 개는 걸어서 모은 재로만 팝니다. Stardew는 첫 집 증축을 마치면 가구 카탈로그를 200,000g에 팔고, 그 카탈로그는 목록에 있는 가구를 0g에 팝니다. 다만 박물관, 축제, 그 밖의 출처에서만 얻는 가구도 여전히 있습니다. 레어와 무작위 크래커블이 있는 Habbo의 구매 중심 경제는 그 반대쪽 끝을 보여 줍니다.14151617

이 게임들에서 방문자가 읽기 전용 권한만 받는 이유는 무엇입니까?

제 해석으로는, 방이 호스트의 표현이기 때문입니다. Animal Crossing 방문자는 “modify the interior in any way”(어떤 식으로든 실내를 바꾸는 것)를 할 수 없고, Habbo 방문자는 소유자의 권한 없이 가구를 내려놓거나 옮길 수 없으며, Club Penguin 소유자는 자기 이글루는 꾸밀 수 있지만 “but not other player’s igloos”(다른 플레이어의 이글루는 꾸밀 수 없습니다). 그 대신 방문자가 얻는 것은 기록으로 남는 표시입니다. Club Penguin의, 결코 줄지 않는 Grand Total 위에 디자인당 하루 한 번 누르는 좋아요입니다.518819

이 사이트의 관련 글: 픽셀 아트 건물: iPhone의 집, 홀, 실내는 이 브리프가 가구를 들이는 실내를 만들었고, 그 실내 절은 빌드 26이 대체한 14×11 방을 설명합니다. iPhone에서 만드는 픽셀 아트 세계는 상한 열여섯, 읽기 전용 방문, 하루 한 번의 좋아요, 일요일 보고서가 처음 발표된 곳입니다. 픽셀 아트 인물: iPhone의 캐릭터와 크리에이터는 그 너비가 가구의 리듬을 정하는 수집가를 다룹니다. 픽셀 아트 마을 레이아웃: Pallet에서 Pelican Town까지, 측정하다는 집들이 서 있는 마을을 측정합니다. 픽셀 아트의 움직임: iPhone에서의 걷기, 카메라, 문은 방문자가 들어오는 걷기와 문을 다룹니다. 그리고 픽셀 아트 길: iPhone에서의 맵 연결과 구역은 마을 너머의 땅을 다룹니다.

출처


  1. pret, pokeemerald/include/constants/global.h(SECRET_BASES_COUNT 20, DECOR_MAX_SECRET_BASE 16, DECOR_MAX_PLAYERS_HOUSE 12), 커밋 731ad5b(2026년 10월 1일), 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/include/constants/global.h. ↩↩↩↩↩

  2. 저자의 측정, 2026년 10월 5일: 이 글을 위한 저자의 증거 폴더에 있는 measure_emerald_decor.py, 출력은 measure_emerald_decor.out으로 저장, pret pokeemerald 커밋 731ad5b의 얕은 클론에서 실행. 상한은 include/constants/global.h에서, 장식 120개(DECOR_NONE 제외)의 카테고리, 모양, 권한, 가격은 src/data/decoration/header.h에서, 카테고리별 소유 배열은 include/global.h에서, 각 장식 메타타일의 동작 바이트는 data/tilesets/secondary/secret_base/metatile_attributes.bin에서, 기지 레이아웃 24개와 침실 각각은 data/layouts/layouts.json과 그 map.bin에서 읽고, 걸을 수 있는 셀은 충돌 비트로 센다. 장식당 셀 수는 모양 이름에서. 상한을 걸을 수 있는 셀 평균으로 나누면 16 / 60.2 = 0.27. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩

  3. pret, pokeemerald/src/data/decoration/header.h(gDecorations[]: 장식마다 이름, 권한, 모양, 카테고리, 가격, 타일. 항목 0은 DECOR_NONE), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/src/data/decoration/header.h. ↩↩↩↩

  4. pret, pokeemerald/src/decoration.c(CanPlaceDecoration, DecorationItemsMenuAction_AttemptPlace, isPlayerRoom, gText_CantPlaceInRoom. 스프라이트 장식을 위한 받침 셀 검사), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/src/decoration.c. 스프라이트의 경우 1×2 장식은 MetatileBehavior_HoldsLargeDecoration이 필요하고, 그 밖의 것은 작거나 큰 받침 셀을 받는다. IsntInitialPosition은 장식의 타일이 그 셀에서 METATILE_LAYER_TYPE_NORMAL이 아닌 레이어 유형을 가질 때만 플레이어의 시작 셀을 거부한다. 함수 어디에도 통로를 확인하는 부분이 없다는 것은 저자의 해석이다. ↩↩↩↩↩↩↩↩↩↩

  5. Nookipedia, “Player house”(방당 상한: Wild World 24, City Folk 64, New Leaf 48, New Horizons는 “including wall and ceiling-mounted furniture” 150. 방 크기가 담긴 New Horizons 증축 표. “only the main room can be expanded in size”. 2.0부터의 포인트 벽. 방문자는 “modify the interior in any way” 할 수 없음. 집을 “for at least one week” 방치한 플레이어의 집에는 바퀴벌레가 들끓음), 2026년 10월 5일 가져와 방 편 증거 폴더에 nook-player-house.html과 .txt로 저장, https://nookipedia.com/wiki/Player_house. 타일당 4.2개는 저자의 계산(150 / 36). ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩

  6. Nookipedia, “Happy Home Academy”(일요일 평가. 증축별 B, A, S 등급. New Horizons 점수 보너스와 감점. New Horizons 아이템별 점수에 대한 “This section is a stub”. 보상 표의 주석 “Includes data sourced from the Data Spreadsheet for Animal Crossing New Horizons”), 2026년 10월 5일 가져와 nook-hha.html과 .txt로 저장, https://nookipedia.com/wiki/Happy_Home_Academy. 보너스와 감점 표에는 페이지상 출처가 없다. ↩↩↩↩↩↩↩↩↩↩↩↩↩

  7. Square Enix, The Lodestone, Final Fantasy XIV 패치 7.5 노트(2026년 5월 13일 갱신. 하우징 절의 실내외 가구 한도 변경 전후. 가구 400개 표시에 관한 주석. “Furnishings from the FFXIV Furnishing Design Contest have been added”), 2026년 10월 5일 가져와 ffxiv-patch-7-5.html과 .txt로 저장, https://eu.finalfantasyxiv.com/lodestone/topics/detail/9beb8a7b5c46944cd80ed92b2b8e972395fbea80/. 하우징 플레이 가이드 https://na.finalfantasyxiv.com/lodestone/playguide/contentsguide/housing/ 는 같은 날 HTTP 404를 반환했다. 부지 크기는 이 글에서 출처를 대지 않았다. ↩↩↩↩↩↩↩↩↩↩

  8. Club Penguin Wiki(Fandom), “Furniture”(대부분의 가구에 대한 99개 소유 한도. “igloos have a limit preventing more than 99 units of furniture being placed at once”. 소유자는 자기 이글루를 꾸미지만 “but not other player’s igloos”. 2012년 7월 26일 비회원을 위한 무료 아이템 여섯 개), 위키의 MediaWiki API로 읽어 2026년 10월 5일 cp-fandom-furniture.html과 .txt로 저장, https://clubpenguin.fandom.com/wiki/Furniture. 단일 출처. ↩↩↩↩↩↩

  9. 저자의 측정, 2026년 10월 5일: 방 편 증거 폴더의 measure_kiradex_interiors.py, 출력 measure_kiradex_interiors.out. Kiradex 저장소의 scripts/forge/interiors.py를 Python의 ast로 파싱한다(파일은 임포트하거나 실행하지 않는다). PIECES의 항목 23개와 너비, 높이, 독립 플래그. ROOM, ROOM_UP, HALL 글자 맵과 그 가구 목록, 자리. 바닥 셀은 글자 o t s r로 센다. 옮길 수 있는 가구에서는 stairs, stairs_down, pillar를 뺀다. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩

  10. Blake Crosley, “Pixel-Art Worlds on iPhone: What the 16-Bit Masters Knew”, blakecrosley.com, 2026년 10월 3일(방 규칙: “a furnishing cap of sixteen”, 읽기 전용 방문, 하루 한 번의 좋아요, 결코 줄지 않는 총합, “with its point sources listed”인 일요일 보고서. 같은 문단의 “Patron flair stays on the name-plate and the room skin”. Palworld 소송에서 거론된 특허. 텍셀당 기기 픽셀로 맞추는 카메라), https://blakecrosley.com/blog/pixel-art-world-on-iphone. ↩↩↩↩↩↩↩↩↩↩

  11. pret, pokeemerald/include/global.h(비밀기지 레코드의 u8 decorations[DECOR_MAX_SECRET_BASE]와 u8 decorationPositions[DECOR_MAX_SECRET_BASE]. 세이브의 카테고리별 장식 소유 배열), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/include/global.h. ↩↩↩↩↩↩↩

  12. pret, pokeemerald/src/secret_base.c(장식 위치를 상위 4비트 x, 하위 4비트 y로 읽음), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/src/secret_base.c. ↩↩↩

  13. pret, pokeemerald/include/decoration.h(주석 “The nomenclature here describes collision and placement permissions, in that order.”이 달린 enum DecorationPermission. DECORSHAPE_3x1과 DECORSHAPE_1x3이 미사용으로 표시된 enum DecorationShape), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/include/decoration.h. ↩↩↩

  14. 저자의 측정, 2026년 10월 5일: 방 편 증거 폴더의 measure_emerald_sources.py, 출력 measure_emerald_sources.out. pokeemerald 731ad5b에서 data/maps/*/scripts.inc의 pokemartdecoration 목록, 경품 코너 스크립트, src/data/battle_frontier/battle_frontier_exchange_corner.h의 배틀 시설 교환 표, 그리고 data/ 아래 어디서든 givedecoration과 adddecoration의 첫 인수에서 모든 DECOR_ 상수를 검색한다. 상점 다섯 곳에서 돈으로 파는 것 90, 경품 교환소 3, 배틀 포인트 15, 스크립트로 주는 것 10, 돈으로 결코 팔지 않는 것 24, 어디에도 없는 것 6. 여섯 중 둘은 유리 공방의 짝(주 15)이고, 나머지 넷, 전설 인형 셋과 다른 인형 하나는 추적하지 않았다. ↩↩↩↩↩↩↩↩

  15. pret, pokeemerald/data/maps/Route113_GlassWorkshop/scripts.inc(PRETTY_CHAIR_PRICE, 6000, PRETTY_DESK_PRICE, 8000, VAR_ASH_GATHER_COUNT에서 지불. Route113_GlassWorkshop_EventScript_NotEnoughAsh와 _NotEnoughAshForItem은 가격에서 수를 빼고 그 차이를 아직 걸어야 할 걸음으로 보여 준다. src, data, include를 검색하면 VAR_ASH_GATHER_COUNT는 정의를 빼면 거기와 field_tasks.c에서만 쓰인다)와 pokeemerald/src/field_tasks.c(자루를 지닌 동안 재 풀숲을 한 걸음 지날 때마다 재 하나, 9999까지), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/data/maps/Route113_GlassWorkshop/scripts.inc 및 https://github.com/pret/pokeemerald/blob/master/src/field_tasks.c. ↩↩↩↩↩↩↩

  16. Stardew Valley Wiki, “Furniture”, 리비전 193159(로빈과 여행 상인 수레는 “offer a random selection of furniture each day they are open”. “After the first Farmhouse upgrade, Robin also offers the Furniture Catalogue for sale”. 0g에 “in unlimited quantity”. 카탈로그 표의 가구 카탈로그 행, 목공소(Carpenter’s Shop)에서 200,000g. “Some furniture can be obtained only by donating items to the Museum”, 축제, 카지노, 그 밖의 출처. 초록과 빨강 배치 사각형), 2026년 10월 5일 가져와 sdv-furniture.html과 .txt로 저장, https://stardewvalleywiki.com/Furniture. ↩↩↩↩↩↩↩↩↩↩↩

  17. Sulake, Habbo 고객센터, “Furni Definitions”(거래자를 위해 “4-12 months” 묶어 두는 캠페인 가구, “will never be re-released”인 레어, 크래커블 레어 가구, “in limited quantities”인 LTD), 글 본문을 2026년 10월 5일 방 편 증거 폴더의 habbo-articles.txt에 저장, https://help.habbo.com/hc/en-us/articles/360011621699-Furni-Definitions. ↩↩↩↩↩↩↩

  18. Sulake, Habbo 고객센터, “What is Furni?”(“To buy furni you need credits, diamonds or duckets”. “You can’t drop or manipulate furni in other Habbo’s rooms unless you’re a member of a group”), 글 본문을 2026년 10월 5일 habbo-articles.txt에 저장, https://help.habbo.com/hc/en-us/articles/360011512940-What-is-Furni. ↩↩↩↩↩↩↩

  19. That Penguin Game, “Your Igloo”(Club Penguin 도움말 페이지의 재현. 그 출처는 검증하지 않음: “You can Like any igloo design once every day!”. 개별 좋아요와 Grand Total Likes. “Likes are permanent, so your Grand Total Likes will never decrease, even if you delete an igloo design!”. Everyone과 Friends 설정), 2026년 10월 5일 가져와 tpg-your-igloo.html과 .txt로 저장, https://thatpenguingame.com/club-penguin-help/game-help/your-igloo/. 단일 출처. ↩↩↩↩↩↩

  20. 저자의 측정, 2026년 10월 5일: 글 초안 옆에 둔 measure_path_rule.py, 출력 measure_path_rule.out과 path_rule.json. Kiradex 저장소의 scripts/forge/interiors.py를 ast로 파싱하고, 내보내는 글자를 export()처럼 다시 짓고, 각 층의 도착 셀에서 otsrUD(포지 check()의 걸을 수 있는 집합) 위로 네 방향으로 걸어, 계단, 호스트, 각 꾸밈 자리의 앞 셀(선반과 벽 띠를 지나 곧장 남쪽으로 첫 셀)을 보고한다. 이어 room에서 도착, 계단, 호스트 셀에서 떨어진 빈 바닥 위에 독립 가구 하나(그림 10개. 의자는 한 번, 침대는 한 번)를 더하는 모든 배치(733가지. 44가지가 목표를 끊으며, 모두 목표를 덮어서 그렇다)와, 모든 목표에서 떨어진 겹치지 않는 추가 가구 두 개의 모든 쌍(단일 배치 689가지, 쌍 229,891가지. 713가지가 목표를 끊는다)을 시험한다. ↩↩↩↩↩↩↩↩↩↩

  21. 저자의 계산, 2026년 10월 5일: 초안 폴더 figures/의 score_max.py, 출력 score_max.out과 score_max.json. 브리프의 점수 표를 두 층 16개씩, 각 줄을 상한까지 채워 합한 것(3,200 + 3,000 + 6,400 + 9,600 + 500 + 600 + 300 = 23,600)과, 세트, 램프, 자리 줄 없이 8개짜리 한 층(800 + 500 = 1,300). 같은 스크립트는 제안한 집 등급 기준을 정하는 세 기준 집을 표 자체의 줄로 채점한다. 두 층 10개씩에 선반을 채운 집 4,500. 두 층 16개씩에 선반, 진열장, 보드를 채운 집 7,600. 그 집에 층마다 8개짜리 스위트와 70% 한 램프를 더한 집 14,000. 그리고 두 층 8개씩인 시작 집 2,600. ↩↩↩↩

  22. Apple 개발자 문서, “Syncing model data across a person’s devices”(SwiftData. “does include a small number of features that CloudKit doesn’t support natively, such as unique constraints and nonoptional relationships”. “CloudKit requires all relationships to be optional”), 문서 JSON을 2026년 10월 5일 apple-swiftdata-cloudkit-sync.html과 .txt로 저장, https://developer.apple.com/documentation/swiftdata/syncing-model-data-across-a-persons-devices. ↩↩↩↩↩↩

  23. pret, pokeemerald/src/new_game.c(NewGameInitData가 ClearDecorationInventories()를 호출)와 pokeemerald/src/decoration_inventory.c(ClearDecorationInventory가 각 카테고리의 모든 칸을 DECOR_NONE으로 설정), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/src/new_game.c. ↩

  24. 저자의 그림, 2026년 10월 5일: 초안 폴더 figures/의 make_figures.py. pokeemerald 731ad5b의 src/data/decoration/header.h, 주 1, 5, 8, 7에서 인용한 상한, path_rule.json, score_max.json을 읽고, 모든 합계를 위 측정값과 대조해 확인한 뒤 emerald-decor-sizes.svg, caps.svg, room-path-rule.svg, score-sources.svg를 쓴다. 영역 구분(1셀, 2셀, 4에서 6, 8 또는 9)은 모양을 덮는 셀 수로 묶은 것이다. 팔레트는 dataviz 검증기로 확인. 게임 아트는 쓰지 않았다. ↩↩↩↩↩

  25. pret, pokeemerald/include/constants/metatile_behaviors.h(MB_SECRET_BASE_* 동작, MB_SLIDE_SOUTH, MB_HOLDS_SMALL_DECORATION, MB_HOLDS_LARGE_DECORATION), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/include/constants/metatile_behaviors.h. ↩

  26. pret, pokeemerald/data/layouts/layouts.json(LAYOUT_SECRET_BASE_* 레이아웃 24개와 두 플레이어 집의 2층, 너비와 높이 포함)과 각 레이아웃의 map.bin, 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/data/layouts/layouts.json. 너비, 높이, 면적 범위는 측정 출력에서 저자가 구한 것. ↩

  27. 저자의 측정, 2026년 10월 5일: 방 편 증거 폴더의 measure_character_cell.py, 출력 measure_character_cell.out. pokeemerald의 graphics/object_events/pics/people/brendan/walking.png(144×32)와 decorating.png(16×32)의 PNG 헤더, 그리고 Kiradex 저장소 Kiradex/Resources/World/characters.json의 셀(32×40), figureTop(7), underFeet(2)을 읽는다. 스크립트는 셀과 인물의 키(31픽셀)를 재며, 그려진 인물의 너비는 재지 않는다. ↩↩↩↩↩

  28. pret, pokeemerald/src/data/items.h(ITEM_SOOT_SACK, .fieldUseFunc = ItemUseOutOfBattle_CannotUse)와 pokeemerald/src/data/text/item_descriptions.h(sSootSackDesc, 세 줄짜리 고정 설명), 커밋 731ad5b, 2026년 10월 5일 열람, https://github.com/pret/pokeemerald/blob/master/src/data/items.h. ↩↩

  29. Nookipedia, “Furniture”(“ranging from 1.0×0.5”에서 3×3까지의 크기. 반 타일 밀기. New Horizons 가구 유형과 2.0부터의 천장 장식. 3.0.2 기준 가구 2,076개, 그중 1,074개는 업데이트로 추가. “around 10 furniture items, as well as a matching wallpaper and flooring”인 시리즈), 2026년 10월 5일 가져와 nook-furniture.html과 .txt로 저장, https://nookipedia.com/wiki/Furniture. ↩↩↩↩

  30. Nookipedia, “Wallpaper”(버전 1.9.0 기준 New Horizons 벽지 262개), 2026년 10월 5일 가져와 nook-wallpaper.html과 .txt로 저장, https://nookipedia.com/wiki/Wallpaper. ↩

  31. Nookipedia, “Flooring”(New Horizons에서 215개), 2026년 10월 5일 가져와 nook-flooring.html과 .txt로 저장, https://nookipedia.com/wiki/Flooring. ↩

  32. Nookipedia, “Luna”(New Leaf 절: “any changes will not be saved and items cannot be brought back to the real world”. New Horizons 절: 그녀의 서비스는 “work the same as they do in New Leaf”, 업로드할 때마다 5,000벨 상당의 Dream Bell Exchange Ticket), 2026년 10월 5일 가져와 nook-luna.html과 .txt로 저장, https://nookipedia.com/wiki/Luna. ↩↩

  33. Sulake, Habbo 고객센터, “Rooms”(“You can own 200 rooms.”. “Wallpaper and flooring are stuck down”), 2026년 10월 5일 가져와 habbo-rooms.html과 .txt로 저장, https://help.habbo.com/hc/en-us/articles/360011512640-Rooms. ↩↩↩↩

  34. Sulake, Habbo 고객센터, “What is Builders Club?”(가구 한도는 회원 기간 한 달마다 “increased by 250”. 플로어 플랜 편집기에서 사용자 정의 방 레이아웃 저장)와 “What can I buy in Habbo?”(“Furni limits never go down.”), 글 본문을 2026년 10월 5일 habbo-articles.txt에 저장, https://help.habbo.com/hc/en-us/articles/360011621659-What-is-Builders-Club 및 https://help.habbo.com/hc/en-us/articles/360011620599-What-can-I-buy-in-Habbo. ↩

  35. Sulake, Habbo 고객센터, “Player to player trading in Habbo”(거래 패스가 필요. “There is no guide to what items of furni are worth”), 글 본문을 2026년 10월 5일 habbo-articles.txt에 저장, https://help.habbo.com/hc/en-us/articles/4408726781842-Player-to-player-trading-in-Habbo. ↩↩

  36. Sulake, Habbo 고객센터, “Guidelines on user created games in Habbo”(“Placing more than three chance elements will disable all randomiser functions in the room.”), 글 본문을 2026년 10월 5일 habbo-articles.txt에 저장, https://help.habbo.com/hc/en-us/articles/360011513060-Guidelines-on-user-created-games-in-Habbo. ↩

  37. Sulake, Habbo 고객센터 검색 API, “furni”, “stack”, “floor plan”의 결과, 2026년 10월 5일 방 편 증거 폴더에 habbo-search-furni, habbo-search-stack, habbo-search-floorplan(.html과 .txt)으로 저장. 어느 것도 그리드 크기, 쌓기 높이, 방당 가구 한도를 밝히지 않는다. ↩

  38. billsonnn, nitro-react/src/components/floorplan-editor/common/Constants.ts(MAX_NUM_TILE_PER_AXIS = 64, HEIGHT_SCHEME = 'x0123456789abcdefghijklmnopq', 빈 x 뒤로 27단계 높이), 서드파티 오픈소스 Habbo 클라이언트, 2026년 10월 3일 구조물 편 글에서 인용한 대로, https://github.com/billsonnn/nitro-react/blob/main/src/components/floorplan-editor/common/Constants.ts. 쌓기 높이 도구의 범위(0에서 40까지 0.01 단위)는 제 예전 메모에서 온 것으로, 같은 클라이언트에서 읽었으며 2026년 10월 5일에는 다시 읽지 않았다. ↩

  39. Blake Crosley, “Pixel-Art Structures: Houses, Halls and Interiors on iPhone”, blakecrosley.com, 2026년 10월 3일(실내는 “each 14 by 11, with a two-row wall band”. 빌드 22, 23, 그리고 저녁 추가 글의 35. “Rooms have no wallpaper or floor choice and no placeable furniture; the house is dressed from the collection and nothing else”. room:npc-… 워프. 오브젝트 메시. Stardew 농가의 내부 “10×7”, 주 54. Nitro 상수, 주 62), https://blakecrosley.com/blog/pixel-art-structures-on-iphone. ↩↩↩↩↩↩↩↩

  40. 저자의 측정, 2026년 10월 5일: 방 편 증거 폴더의 measure_sdv_catalogue.py, 출력 measure_sdv_catalogue.out. 저장한 가구 페이지(rev 193159)에서 각 행의 이름 링크로 섹션별 가구 행을 세되, 행이 다른 마크업을 쓰는 영화 포스터 섹션과 References, History, Exploits 섹션은 건너뛴다. 벽지와 바닥재는 저장한 벽지 페이지(rev 193801)와 바닥재 페이지(rev 190285)의 서로 다른 아이콘으로 센다. 가구 카탈로그를 출처로 드는 행은 그 링크로 센다. 위키의 행과 아이콘의 수이지 게임 데이터 파일의 수가 아니다. ↩↩↩↩

  41. Stardew Valley Wiki, “Wallpaper”, 리비전 193801(“Wallpapers are single-use and do not stack. They cover the whole room they’re placed in”. “the character must be facing up by its wall”), 2026년 10월 5일 가져와 sdv-wallpaper.html과 .txt로 저장, https://stardewvalleywiki.com/Wallpaper. ↩↩↩↩

  42. Stardew Valley Wiki, “Flooring”, 리비전 190285, 2026년 10월 5일 가져와 sdv-flooring.html과 .txt로 저장, https://stardewvalleywiki.com/Flooring. ↩

  43. Club Penguin Wiki(Fandom), “Igloo”(역사: 2005년 11월 1일, 멤버십이 없는 플레이어에게도 이글루가 주어졌으나 그들은 “were unable to decorate them with furniture”. 2012년 7월 26일, 새 이글루 경험과 “a set of six items available without membership”), MediaWiki API로 읽어 2026년 10월 5일 cp-fandom-igloo.html과 .txt로 저장, https://clubpenguin.fandom.com/wiki/Igloo. 이 페이지가 인용하는 보관된 공식 블로그 글은 2026년 10월 5일 Wayback Machine에서 HTTP 429를 두 번 반환했다. 단일 출처. ↩↩

  44. Club Penguin Wiki(Fandom), “Igloo Contests”(9호, 2005년 12월 15일의 첫 콘테스트, 우승자 한 명에 5,000코인. 우승자 발표는 “After one to four weeks”. 2008년 핼러윈 콘테스트부터 캐릭터 심사. 2009년부터 응모 버튼. 2012년 12월의 마지막 콘테스트. 2008년 Ye Olde Igloo Contest의 우승자 열 명에 25,000코인, 차점자 스무 명에 15,000코인), MediaWiki API로 읽어 2026년 10월 5일 cp-fandom-contests.html과 .txt로 저장, https://clubpenguin.fandom.com/wiki/Igloo_Contests. 단일 출처. ↩

  45. Tristan Donovan, “The Replay Interviews: Will Wright”, Game Developer, 2011년 5월 23일, 2026년 10월 5일 가져와 gd-replay-wright.html과 .txt로 저장, https://www.gamedeveloper.com/business/the-replay-interviews-will-wright. 빌드 모드에 관해 Wright가 1999년이나 2000년에 한 기록된 발언은 찾지 못했다. ↩↩

  46. The Sims Wiki(Fandom), “Buy mode”(“purchase items from an object catalog and place them on the current lot”. The Sims와 The Sims 2의 기능별 분류. 페이지에서 The Sims 2와 The Sims 3에 연결된 초록과 빨강 발자국 문장), MediaWiki API로 읽어 2026년 10월 5일 sims-fandom-buymode.html과 .txt로 저장, https://sims.fandom.com/wiki/Buy_mode. 단일 출처. ↩↩↩

  47. The Sims Wiki(Fandom), “Environment”(Room과 Environment 욕구. “analyzes the design and content of the room that the Sim is currently standing in”), MediaWiki API로 읽어 2026년 10월 5일 sims-fandom-environment.html과 .txt로 저장, https://sims.fandom.com/wiki/Environment. 단일 출처. ↩

  48. 저자의 추출, 2026년 10월 5일: 방 편 증거 폴더의 measure_apple_docs.py, 출력 measure_apple_docs.out. 저장한 각 Apple 문서 JSON 페이지에서 제목, 선언, 요약, 플랫폼을 뽑는다. dropDestination(for:action:isTargeted:)에 대해 인용한 폐기 예정 필드는 같은 저장 JSON에서 읽었다. ↩

  49. Apple 개발자 문서, Model()(SwiftData 매크로. “Converts a Swift class into a stored model that’s managed by SwiftData”. iOS 17.0), JSON을 2026년 10월 5일 apple-swiftdata-model.html과 .txt로 저장, https://developer.apple.com/documentation/swiftdata/model(). ↩

  50. Apple 개발자 문서, Unique(_:)(SwiftData 매크로. “Specifies the key-paths that SwiftData uses to enforce the uniqueness of model instances”. iOS 18.0), JSON을 2026년 10월 5일 apple-swiftdata-unique.html과 .txt로 저장, https://developer.apple.com/documentation/swiftdata/unique(_:). ↩

  51. Kiradex 저장소, Kiradex/Models/CardCopy.swift(문서 주석: “every property has a default and nothing is unique, for CloudKit”), 2026년 10월 5일 열람. ↩↩↩

  52. Kiradex 저장소, Kiradex/Models/PriceHistory.swift(문서 주석: “Shaped for CloudKit like CollectionEntry: defaults everywhere, nothing unique”. PriceBook은 두 기기의 기록을 “into the one with the smallest uid” 접는다), 2026년 10월 5일 열람. ↩↩↩↩

  53. Apple 개발자 문서, draggable(_:)(SwiftUI. “Activates this view as the source of a drag and drop operation”. Transferable 페이로드. iOS 16.0), JSON을 2026년 10월 5일 apple-swiftui-draggable.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/view/draggable(_:). ↩↩

  54. Apple 개발자 문서, dropDestination(for:action:isTargeted:)(SwiftUI. ([T], CGPoint) -> Bool action, 두 번째 매개변수는 “the drop location in this view’s coordinate space”. iOS 16.0. iOS 플랫폼 항목은 deprecatedAt을 27.2로 적고 메시지 “Use dropDestination(for:isEnabled:action:) with an action that takes a DropSession parameter instead.”를 붙인다. DropSession 참조 “A description of a drop that is in progress”), JSON을 2026년 10월 5일 apple-swiftui-dropdestination.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/view/dropdestination(for:action:istargeted:). ↩↩↩↩↩

  55. Apple 개발자 문서, DragGesture(SwiftUI. “A dragging motion that invokes an action as the drag-event sequence changes”. iOS 13.0), JSON을 2026년 10월 5일 apple-swiftui-draggesture.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/draggesture. ↩↩

  56. Apple 개발자 문서, SpatialTapGesture(SwiftUI. “A gesture that recognizes one or more taps and reports their location”. iOS 16.0), JSON을 2026년 10월 5일 apple-swiftui-spatialtap.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/spatialtapgesture. ↩↩

  57. Apple 개발자 문서, accessibilityElement(children:)(SwiftUI. iOS 13.0), JSON을 2026년 10월 5일 apple-swiftui-accessibilityelement.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/view/accessibilityelement(children:). ↩↩

  58. Apple 개발자 문서, accessibilityAction(named:_:)(SwiftUI. “Actions allow assistive technologies, such as the VoiceOver, to interact with the view by invoking the action”. iOS 16.0), JSON을 2026년 10월 5일 apple-swiftui-accessibilityaction-named.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/view/accessibilityaction(named:_:). ↩↩↩↩

  59. Apple 개발자 문서, accessibilityAdjustableAction(_:)(SwiftUI. AccessibilityAdjustmentDirection을 받는 핸들러. iOS 13.0), JSON을 2026년 10월 5일 apple-swiftui-adjustable.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/view/accessibilityadjustableaction(_:). ↩↩

  60. Apple 개발자 문서, accessibilityRotor(_:entries:)(SwiftUI. “Create an Accessibility Rotor with the specified user-visible label”. iOS 16.0), JSON을 2026년 10월 5일 apple-swiftui-accessibilityrotor.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/view/accessibilityrotor(_:entries:). ↩↩↩↩

  61. Apple 개발자 문서, AccessibilityNotification.Announcement(Accessibility. “A notification that an app posts when it needs to convey an announcement to an assistive app”. iOS 17.0), JSON을 2026년 10월 5일 apple-swiftui-accessibilitynotification.html과 .txt로 저장, https://developer.apple.com/documentation/accessibility/accessibilitynotification/announcement. ↩↩↩↩

  62. Apple 개발자 문서, performAccessibilityAudit(for:_:)(XCUIAutomation, XCUIApplication. iOS 17.0. JSON은 Xcode 16.3을 적고 요약이 없다), JSON을 2026년 10월 5일 apple-xctest-accessibilityaudit.html과 .txt로 저장, https://developer.apple.com/documentation/xcuiautomation/xcuiapplication/performaccessibilityaudit(for:_:). ↩↩↩

  63. Apple, Xcode 27.0(빌드 27A266a)의 XCUIAutomation 프레임워크 헤더, iPhone Simulator 플랫폼, 2026년 10월 5일 열람: XCUIApplication.h(performAccessibilityAuditWithAuditTypes:issueHandler:error:, “Runs an accessibility audit on the current view”). XCUIVoiceOverService.h(“Provides programmatic control of VoiceOver for UI testing”. 켜기, 끄기, 앞으로, 뒤로, 안으로, 밖으로 이동, 현재 읽는 내용. iOS 27.0). XCUIDevice.h(voiceOverService 프로퍼티, iOS 27.0). 프레임워크의 모든 헤더에서 사용자 정의 동작, 로터, 안내를 검색했으나 찾지 못했다. ↩↩↩

  64. Kiradex 저장소, scripts/forge/interiors.py(“every piece at least two tiles on one axis”를 포함한 모듈 docstring. ROOM, ROOM_UP, HALL 글자 맵, 가구 목록, 자리, 워프. host 주석 “where the owner stands when you visit”. PIECES, FACES, EXPORT_LETTERS, export(), 그리고 check(). 그 자리 검사는 도착, 계단, 호스트, 선반, 진열장, 책상, 받침대 자리를 다루고 벽 보드는 다루지 않으며, 겹침 루프는 내보낸 독립 가구인 data["objects"]를 읽는다), 2026년 10월 5일 열람, 실행하지 않음. ↩↩↩↩↩↩↩↩↩↩↩↩↩

  65. Kiradex 저장소, docs/TestFlight.md, 항목 46(“Build 26: the interior kit. Rooms sixteen wide with a three-row wall band (cornice, face, wainscot)”), 2026년 10월 5일 열람. 이 빌드는 파일에 날짜가 없다. 구조물 편 글이 모두 2026년 10월 3일로 적은 빌드 23과 빌드 35 사이에 있다. ↩↩

  66. 저자의 계산, 2026년 10월 5일: 초안 폴더 figures/의 merge_regression.py, 출력 merge_regression.out. 포지가 만든 그대로의 room(옮길 수 있는 가구 13개. path_rule.json과 Kiradex 저장소의 scripts/forge/interiors.py를 ast로 읽음)에서 (9,3)의 침대 하나와 (6,4)의 협탁 하나는 각각 셀 규칙, 상한, 걷기를 통과하지만, 둘이 함께 있으면 진열장 앞의 두 셀인 (7,3)과 (8,3)을 끊는다. 둘을 uid로 정렬하고 각각을 배치 검사 전체를 거쳐 더하는 복구는 uid가 작은 쪽을 남기고 다른 쪽을 돌려보내며, 두 입력 순서와 두 uid 배정 모두에서 결과가 같다. 끊는 713개 쌍이 모두 가구 하나씩으로는 합법적이라는 것은 measure_path_rule.out에서 따라 나온다. 목표에서 떨어진 단일 배치 중 목표를 끊는 것은 없다. ↩↩↩↩↩

  67. Kiradex 저장소, docs/WORLD.md(4절: 코인 상점의 “clothes, hats, backpacks, card-display frames and emotes”, level = floor(sqrt(XP / 40)) + 1, 레벨로 잠긴 “that cannot be bought” 꾸미기 아이템, Full Set, Vintage, Across the Sea를 포함한 핀. “a 30-pixel figure in a 32 × 40 cell”인 수집가), 2026년 10월 5일 열람. sixteen, cap, decoration, furnishing, Sunday, once a day, read-only로 검색했으나 어느 것도 방 규칙을 밝히지 않는다. ↩↩↩↩↩↩

  68. Kiradex 저장소, server/app/rooms.py(모듈 docstring: “Everything here is in memory; a room empties when its last collector leaves and nothing of them is kept.”), 2026년 10월 5일 열람. ↩↩↩↩

  69. Kiradex 저장소, docs/research/pixel-art/06-collecting-and-hubs.md, 5.3절(“Rooms: a budget, a Sunday letter, and a like that never goes down”: 상한 16, “a pixel object that appears on the doormat”인 일요일 편지, 읽기 전용 방문, 방문자당 하루 한 번의 좋아요, “a stamp on their passport per room visited, with ranks at 30 / 100 / 500”)과 5.7절(후원자 아이템은 “one room skin”을 포함하며 “never a bigger furnishing cap”), 2026년 10월 5일 열람. ↩↩↩↩↩

  70. Kiradex 저장소, Kiradex/World/Quests.swift(Quest.current(on:calendar:), 달력 자신의 첫 요일에서 시작하는 weekOfYear 구간을 키로 씀)와 Kiradex/World/HallView.swift(주석 “The week’s theme is the week’s quest”와, 주간 퀘스트의 제목으로 읽히는 테마), 2026년 10월 5일 열람. ↩↩↩

  71. Kiradex 저장소, docs/PROTOTYPES.md(주간 퀘스트 프로토타입의 테스터 질문 “Weekly reset on your calendar’s week: say if it feels wrong.”), 2026년 10월 5일 열람. ↩

  72. 저자의 계산, 2026년 10월 5일: 초안 폴더 figures/의 layout_size.py, 출력 layout_size.out. 종류 수는 오늘의 포지에서 21(바닥 종류 17, 벽 아이템 4), 7.5절에서 새로 3, 모두 24. 저장할 집 레이아웃(두 층, 각각 종류, x, y, 방향을 가진 가구 16개, 층마다 스타일 ID 두 개)을 이름 붙은 키의 압축 JSON으로, 모든 종류를 제안된 가장 긴 이름(pressed_flower, 14자)으로, 모든 스타일 ID를 16자로 하면 1,974바이트. 모든 종류를 16자로 채우면 2,038바이트. 가구 32개의 정수 네 개 묶음만이면 385바이트. ↩↩

  73. Kiradex 저장소, Kiradex/World/PlazaStage.swift(@AppStorage("plaza.id"), “Who this device is to the plaza”. @AppStorage("quests.stamps"), 쉼표로 이은 목록인 퀘스트 도장으로 QuestBoardView와 MeView도 읽음. @AppStorage("plaza.ribbons"), “Ribbons from the town’s collectors”), 2026년 10월 5일 열람. 앱의 Swift 소스에서 저장된 걸음 수나 방문한 방의 기록을 검색했으나 찾지 못했고, 앱과 서버에서 만보계, 걸음 수 타입, 여권을 검색해도 찾지 못했다(steps는 TileMap.swift와 PlazaRig.swift의 걷기 경로뿐). ↩↩↩↩↩

  74. Kiradex 저장소, Kiradex/Models/Progression.swift(Progression의 문서 주석: 경험치, 레벨, 핀은 “worked out from the collection as it is, so every device agrees without anything being stored”), 2026년 10월 5일 열람. ↩↩

  75. Apple 개발자 문서, AppStorage(SwiftUI. “A property wrapper type that reflects a value from UserDefaults”. iOS 14.0), JSON을 2026년 10월 5일 apple-swiftui-appstorage.html과 .txt로 저장, https://developer.apple.com/documentation/swiftui/appstorage. ↩↩

  76. 저자의 계산, 2026년 10월 5일: 초안 폴더 figures/의 skin_denominator.py, 출력 skin_denominator.out. 브리프의 램프 줄로 계산한다. 가구 16개 중 15개와 바닥 스타일이 한 램프 계열에 있고 벽은 그 밖에 있는 한 층은 18개 중 16개(88.9%)로 70% 줄에서 1,600점. 벽을 비율에서 빼면 17개 중 16개(94.1%)로 90% 줄에서 4,800점, 3,200점 더 많다. ↩

  77. Kiradex 저장소, Kiradex/Models/Profile.swift(동기화되는 프로필의 var lookData: Data = Data(). init(handle:)에서 UUID().uuidString으로 설정되는 var uid: String = ""이며, PriceHistory와 CardCopy도 uid를 가진다. ModelContext.profile()의 224행에서 237행은 프로필을 uid 순으로 가져와 첫 번째를 남기고 나머지를 지우며, 주석은 이를 가장 작은 uid로의 접기라고 부른다), 2026년 10월 5일 열람. ↩↩↩

관련 게시물

Pixel-Art Structures: Houses, Halls and Interiors on iPhone

How Pokémon, the SNES RPGs and Stardew build houses, interiors and floors, measured from source, and how Kiradex's town …

80 분 소요

Pixel-Art Routes: Map Connections and Districts on iPhone

How Pokémon, Stardew and Animal Crossing build the land between towns, measured from source: routes, seams, gates, map s…

110 분 소요

iPhone Duo에 맞춰 앱 준비하기: 실제 앱으로 따라가는 예제

iPhone Duo용 앱을 준비하고 제출하는 방법. 레이아웃을 켜는 SDK 스탬프, 모든 포즈로 돌려 본 실제 앱, 스크린샷, App Store 규칙까지 정리했습니다.

53 분 소요