마켓플레이스에 공개하기
이 튜토리얼이 끝나면 당신의 게임은 마켓플레이스에 나열되고 어떤 사용자든 그 게임 id로 임베드할 수 있습니다. 공개는 일부러 격식이 낮습니다: 제출 대기열도, 심사도, 업로드도 없습니다. 당신이 공개 GitHub 저장소를 태그하면 플랫폼이 그것을 색인합니다.
이것은 당신이 게임을 빌드했고(마켓플레이스 게임 빌드하기) 그 매니페스트를 썼다고 가정합니다.
1. GitHub 저장소 태그하기
당신의 공개 저장소에 GitHub 토픽 caputchin-game을 더하세요(저장소 페이지의 About 섹션). 색인기는 이 토픽으로 GitHub에 질의합니다; 그 태그가 당신의 옵트인 전부입니다.
당신의 게임 id는 저장소 좌표 owner/repo(또는 컬렉션 자식의 경우 owner/repo/<leaf-dir>)에서 도출됩니다. 당신이 그것을 고르거나 선언하지 않습니다.
2. 매니페스트 필수 사항 확인하기
세 가지가 색인을 게이트합니다; 당신의 루트 caputchin.json에 그것들이 있는지 확인하세요:
- 마켓플레이스 제출 약관을 확인하는
"terms_accepted": true(리터럴 불리언). - 승인된 목록의
license. - 번들이 해소되도록 배포 포인터(
entry,npm, 또는 둘 다).
공개 실패 이메일을 원하면 marketplace.author.email을 더하세요(그것은 공개적으로 결코 보이지 않으며, 그것들을 받는 유일한 방법입니다).
3. 공개 또는 갱신
색인에 들어가는 두 방법:
- 일일 cron이 태그된 저장소를 자동으로 집어 갑니다.
- 마켓플레이스의 "Publish or update" 버튼이 저장소별 색인기를 동기로 돌리고 당신을 당신의 상세 페이지로 리디렉션하거나, 정확한 검증 오류를 보입니다. 첫 나열이나 매니페스트 편집 직후에 이것을 쓰세요.
그것이 돌 때, 색인기는 당신의 매니페스트를 가져오고, 번들을 불변 ref에 고정하고(공개된 npm 버전이나 해소된 커밋 SHA), SHA-384 무결성 해시를 계산하고, 당신의 게임 id로 키된 { url, integrity }를 저장합니다. 새 릴리스는 다음 색인 실행에서, 또는 버튼으로 즉시 라이브가 됩니다.
4. 리플레이 자체 확인
색인 시점에 플랫폼은 당신의 run 산출물을 봉인된 아이솔레이트에서 결정론적 시드로 한 번 돌립니다:
- 통과 → 당신의 게임이 재생 가능합니다: 진짜 플레이어의 라운드가 결정에 닿으려고 서버 측에서 다시 실행되니, 사이트 키를 게이트할 수 있습니다.
- 실패(
run-not-conforming) → 게임이 재생 불가로 보입니다. 그것은 여전히 나열되고 임베드 가능하지만, 당신이 적합한 버전을 공개할 때까지 오직 UX로만입니다. 이미 이전의 재생 가능한 버전에 있는 사이트는 그 정확한 스냅샷을 계속 돌립니다.
실패하는 자체 확인은 거의 늘 당신의 run의 비결정성입니다; 당신의 시뮬레이션을 결정론적으로 만들고 다시 공개하세요. 먼저 로컬에서 엔진 키트의 selfCheck를 돌리면 푸시하기 전에 이것을 잡습니다.
5. 발견 확인하기
성공적 공개 후, 상세 페이지가 선언된 각 로케일, 스킨, 구성 프리셋을 위한 손잡이와 함께 라이브 미리보기에 당신의 게임을 임베드합니다. 거기서 그것을 플레이해 프리셋이 당신의 의도대로 해소되는지 확인하세요.
공개가 실패할 때 알림 받기
일일 색인기는 모든 공개된 게임을 다시 확인합니다. 다시 색인이 문제에 부딪히면, 그것에 대해 이메일받을 수 있지만, 매니페스트에 marketplace.author.email을 설정해 옵트인할 때만입니다. 이메일이 설정되지 않으면, 어떤 알림도 받지 못합니다. 다른 채널은 없습니다; 이것은 당신이 달리 놓칠 하나의 신호인데, 일일 재확인이 당신이 지켜보지 않는 사이에 돌기 때문입니다.
두 결과에 맞는 두 종류의 이메일이 보내집니다:
| 이메일 | 언제 | 무엇을 뜻하나 |
|---|---|---|
"Verification check failed for <game>" | 다시 색인된 버전이 리플레이 자체 확인에 실패(run-not-conforming) | 게임은 나열되고 임베드 가능한 채로 있지만, 그 버전이 재생 불가로 보이고 당신이 적합한 것을 공개할 때까지 게이트할 수 없습니다. |
"We couldn't publish <game>" | 다시 색인이 다른 어떤 실패에 부딪힘(매니페스트, 라이선스, 또는 번들 오류) | 그 버전은 당신이 고칠 때까지 나열되지 않습니다. |
중요한 세부:
- 일일 재색인만 이메일을 보냅니다. 수동 "Publish or update" 버튼의 실패는 그때 바로 모달에서 당신에게 보이니, 그것에 대해서는 이메일이 보내지지 않습니다.
- 중복 제거됨. 같은 게임의 같은 실패는 한 번 이메일되고, 그다음 30일 동안 억제됩니다. 다른 실패(새 오류 코드나 사유)는 즉시 이메일됩니다.
- 언제든 옵트아웃
marketplace.author.email을 제거하거나 바꿔서. 이메일은 또한 제출 약관으로의 원클릭 구독 취소 포인터를 지닙니다. 당신은 여기서 Caputchin 계정이 아니니, 매니페스트 필드가 유일한 제어입니다.
6. CI로 자동화하기
공개가 "태그 더하기 불변 ref로 푸시"이므로, 모든 릴리스가 자동으로 다시 색인되도록 그것을 당신의 릴리스 파이프라인에 배선할 수 있습니다. 믿을 만한 패턴:
- CI에서 번들을 불변 ref에 공개, 당신 매니페스트의
npm/entry가 상대로 해소하는 npmpublish(또는 태그된 GitHub 릴리스). 색인기는 늘 다음 실행에서 당신의 최신 공개 버전으로 다시 해소하니, 평범한 릴리스 파이프라인이 이미 고정을 전진시킵니다. - 릴리스를 로컬 결정성 확인에 게이트. 비결정론적
run이 재생 불가로 출시되는 대신 빌드를 실패시키도록, 엔진 키트의selfCheck(또는 당신 자신의 리플레이 테스트)를 CI 단계로 돌리세요. - 선택적으로 즉시 재색인을 트리거, 일일 cron을 기다리는 대신 "Publish or update"를 호출해서, CI가 끝나는 순간 새 버전을 라이브로 원한다면.
# sketch: release job
- run: npm ci
- run: npm test # includes your replay selfCheck
- run: npm publish # advances the immutable ref the indexer pins
# the daily indexer picks up the new version; or hit Publish or update for instant나쁜 run이 조용히 재생 불가인 나열로 결코 마켓플레이스에 닿지 않도록, 결정성 확인을 publish 전에 두세요.
결코 할 필요 없는 것
- 코드 서명 없음, 심사 제출 없음, 플랫폼 CDN 업로드 없음.
- 수익 분배 합의 없음.
- id 고르기 없음; 당신의 GitHub 좌표가 id입니다.
- 버전 필드 없음; 색인기가 ref를 고정합니다.
공개가 실패하면
모든 공개 경로 오류는 당신이 저장소에서 고치고 재시도하는 것입니다. 당신의 코드를 공개 실패 고치기에서 찾으세요; 전체 코드 목록은 공개 오류 레퍼런스입니다.
함께 보기
- 공개 실패 고치기: 오류 코드별 단계별 고침.
- caputchin.json 매니페스트: 색인기가 검증하는 필드.
- 리플레이 계약: 자체 확인이 돌리는 것.