boardgame-studio: Skill for Cursor

프린트 앤 플레이 출력

두 개를 만든다. 컴포넌트 시트와 룰북이다. 공모전은 대개 둘을 따로 요구한다.

projects/<slug>/pnp/<slug>-<날짜>.pdf              컴포넌트
projects/<slug>/pnp/<slug>-rulebook-<날짜>.pdf     룰북

컴포넌트는 아트 없이도 나온다. 룰이 흔들리는 동안 카드 아트를 뽑으면 카드가 바뀔 때마다 다시 뽑아야 한다. 도형과 텍스트만으로 먼저 인쇄해서 플레이테스트를 돌리고, 룰이 굳은 뒤에 아트를 얹는다.

룰북은 spec.json 이 없어도 나온다. 룰셋만 쓴 단계에서 뽑아 남에게 읽히는 게 첫 쓰임이다. 컴포넌트 규격을 정하기 전에도 된다.

진행

node tools/spec.mjs validate <slug>       # 1. 규격과 수량부터
node tools/pnp.mjs <slug> --check         # 2. 텍스트가 카드에 들어가는가
node tools/pnp.mjs <slug>                 # 3. 컴포넌트 렌더
node tools/rulebook.mjs <slug> --check    # 4. 룰북에 넘치는 것이 있는가
node tools/rulebook.mjs <slug>            # 5. 룰북 렌더

1. 규격 검증

validate 가 통과해야 한다. spec.json 의 count 와 CSV 실제 수량이 어긋난 채로 인쇄하면 장수가 안 맞는다.

2. 텍스트 오버플로 검사

렌더보다 먼저 돌린다. --check 는 PDF를 만들지 않고 카드에 텍스트가 들어가는지만 본다. 넘치는 카드가 있으면 id와 함께 나온다.

넘치면 두 가지 중 하나다. 문구를 줄이거나 카드를 키운다. 문구를 줄이는 쪽을 먼저 검토한다. 카드 텍스트가 길다는 건 대개 규칙이 복잡하다는 신호고, 카드를 키우면 인쇄 시트 수가 늘고 슬리브 호환이 깨진다.

인쇄한 뒤에 발견하면 룰을 다시 써야 하므로 여기서 잡는 게 훨씬 싸다.

3. 렌더

출력 결과를 사용자에게 알린다. 컴포넌트별 페이지 수와 총 시트 수를 말해준다.

4. 룰북 검사

--check 는 PDF를 만들지 않고 페이지 수와 절 목록, 그리고 넘치는 것을 낸다. 넷을 잡는다.

경고	뜻
table-narrow	표의 열이 좁아 글자가 한두 자씩 쌓인다. 열을 줄이거나 항목 이름을 짧게 한다
code-overflow	코드 블록 한 줄이 폭을 넘는다. 접지 않으므로 잘린다
heading-too-deep	5단계 이상 제목은 본문과 크기가 같아 구분되지 않는다
image-unsupported	마크다운 이미지는 그리지 않는다. 도판은 컴포넌트로 넣는다

경고가 있으면 종료 코드가 1이다. 인쇄한 뒤에 알면 다시 뽑아야 하므로 여기서 잡는다.

5. 룰북 렌더

--toc 를 주면 목차를 앞에 붙인다. 세 쪽 넘는 룰북이면 붙이는 편이 낫다.

꼬리말에 룰셋 상단의 버전이 그대로 박힌다. 어느 버전을 인쇄한 룰북인지가 종이에 남아야 플레이테스트 기록과 연결된다. 여러 버전을 뽑아놓고 어느 게 최신인지 헷갈리는 일이 실제로 생긴다.

여백은 컴포넌트 시트와 다르다. 9mm는 카드 3열이 무너지지 않는 최댓값이고 룰북에는 자를 것이 없으므로, studio.config.json 의 print.rulebook 이 따로 정한다(기본 20mm).

이탤릭은 본문과 같은 굵기로 나온다. 굵게는 시스템에서 굵은 짝 폰트를 찾아 쓰고, 못 찾으면 획을 덧그린다.

인쇄할 때 전달할 것

PDF를 만든 뒤 이걸 안내한다. 이 설정이 어긋나면 재단선이 안 맞는다.

• 배율을 100%로 둔다. "페이지에 맞춤"이나 "축소하여 인쇄"를 끄지 않으면 카드가 작아져서 슬리브에 안 맞는다. 이게 가장 흔한 실수다
• 용지는 A4, 방향은 자동. PDF 안에 세로와 가로 페이지가 섞여 있다
• 양면 인쇄는 긴 쪽 넘김(long edge) 으로 한다. 뒷면은 용지 중심 기준으로 좌우를 뒤집어 배치했으므로 긴 쪽 넘김이어야 앞뒤가 맞는다