사회적 추리 게임의 정보 규칙과 플레이 흐름 설계

사회적 추리 게임 프롬프트에는 화면보다 먼저 정보 계약이 필요합니다. 각 플레이어가 무엇을 알고 있는지, 공개 단서가 후보를 어떻게 좁히는지, 투표는 어떻게 판정되는지, 모든 종료 상태가 어떤 결과를 만드는지 정하세요. 그런 다음 작은 상태 단위로 빌드를 요청하고 명시적 사례와 대조하세요. 이 안내서의 5인 Harbor Relay는 직접 계산한 독창적 허구 설계입니다. 프롬프트 템플릿은 실행하지 않았으며 생성 빌드, 플레이 가능한 샘플, 플레이테스트를 주장하지 않습니다. 제작 도구가 모든 비공개 정보 세부 사항을 지원한다고 가정하지 말고 가시성 규칙과 수용 검사를 재사용할 수 있습니다. 나중에 만든다면 사례별로 각 상태 전이를 확인하세요.

정보 순환부터 시작하세요

AI 게임 제작 도구에 사회적 추리 게임을 요청하기 전에 의심을 공정하게 만드는 순환을 설명하세요. 숨은 역할을 배정하고 공개 사건을 만들고 단서가 밝힐 정보 범위를 제한하고 토론하게 한 뒤 비공개 투표를 모아 승리 조건을 판정합니다. 게임이 보여 줄 정보와 비밀로 유지할 정보를 모두 프롬프트에 적어야 합니다.

짧은 계약은 흔한 설계 공백을 막습니다. 이야기는 범인을 찾는다고 하지만 규칙은 단서가 후보를 어떻게 좁히는지, 동률이면 어떻게 끝나는지 설명하지 않을 수 있습니다. 이런 결정을 먼저 내리세요. 그런 다음 규칙 일관성, 첫 빌드, 초점 있는 수정에 각각 별도 프롬프트를 사용합니다. 아래 Harbor Relay 설명은 종이 설계 예시이며 어떤 프롬프트가 게임을 만들거나 테스트했다는 증거가 아닙니다.

인터페이스 전에 규칙을 고정하세요

Harbor Relay는 사건 하나와 투표 하나를 사용합니다. 공개 배지 그룹을 먼저 고정한 뒤 방해자 한 명과 수호자 네 명을 무작위 배정합니다. 단서는 좌석이 아니라 배지 그룹을 이름으로 부르므로 역할을 직접 공개하지 않고도 유용한 정보를 제공합니다.

역할 전달은 일부러 단순화했습니다. 한 플레이어가 역할 하나를 보고 숨긴 뒤 기기를 건넵니다. 이는 로컬 패스 앤 플레이 동작을 설명할 뿐 온라인 멀티플레이나 보안 보장을 뜻하지 않습니다. 잘못된 대상, 중복 투표, 판정 전 역할 공개 시도가 게임 상태를 조용히 바꾸면 안 됩니다.

단서와 토론 순환을 요청하세요

배지 추적은 가능한 후보 집합 두 개를 만듭니다. 초승달이면 A와 B, 바퀴살이면 C, D, E입니다. 방해자는 항상 로그에 표시된 그룹에 속하고 각 그룹에는 다른 좌석도 하나 이상 있습니다. 이는 의도적인 정보 한계입니다. 단서는 의심 범위를 좁히지만 특정 플레이어를 지목하지 않습니다.

종이 검산에서는 B를 방해자로 둡니다. 초승달 사건이면 A와 B가 모두 후보입니다. 로그는 “초승달”과 영향을 받은 단말을 말하지만 B의 좌석이나 역할은 보여 주지 않습니다. 같은 규칙은 어떤 무작위 배정에도 적용됩니다. 후보 그룹은 두 번째 비밀 단서가 아니라 방해자의 공개 배지에서 정해집니다.

화면을 요청하기 전에 규칙 계약 프롬프트를 사용하세요. 누락을 구현 전에 발견할 수 있도록 모델이 비공개 정보 경계와 승리 로직을 되풀이하게 합니다:

다음의 정확한 계약으로 Harbor Relay라는 허구의 5인 사회적 추리 게임을 설계하세요. A와 B는 공개 초승달 배지, C, D, E는 공개 바퀴살 배지를 가집니다. 방해자 1명, 수호자 4명을 무작위로 배정하세요. 각 역할을 순서대로 비공개 표시하고 기기 전달 전에 숨기기를 요구하세요. 방해자는 중계 단말 하나를 골라 정전 하나를 일으킵니다. 공개 기록에는 단말과 방해자의 배지 그룹만 표시하며 좌석이나 역할은 절대 공개하지 않습니다. 초승달은 후보 A/B, 바퀴살은 C/D/E를 만듭니다. 단서는 방해자와 최소 한 명의 다른 후보를 포함하며 정체를 직접 공개하면 안 됩니다. 플레이어가 90초간 말로 토론하게 하되 주장을 생성하거나 판정하지 마세요. 각 활성 플레이어는 좌석 하나에 비공개 투표를 제출합니다. 절반 초과의 득표면 그 좌석을 추방하고 역할을 공개하며, 동률 또는 절대 다수 없음은 판정 없음입니다. 수호자는 방해자를 추방해야 승리하고 잘못된 추방이나 판정 없음에서는 방해자가 승리합니다. 사건 하나, 투표 하나만 있습니다. 재시작은 역할, 사건, 타이머, 투표를 지웁니다. 잘못된 대상, 중복 투표, 조기 공개는 상태를 바꾸지 않습니다. 비공개와 공개 정보를 나누는 단계 표를 반환하고 모순이나 누락된 결정을 열거하세요. 다른 메커니즘은 추가하지 마세요.

반환된 계약은 작동하는 게임의 증거가 아니라 점검표로 읽으세요. 단서가 좌석을 직접 공개하거나 라운드가 추가되거나 동률 해소 규칙이 만들어지면 그 줄을 지적하고 빌드 프롬프트를 쓰기 전에 고쳐 달라고 하세요.

상태별로 첫 빌드를 요청하세요

정보 계약이 안정되면 정보를 드러낼 최소 인터페이스를 설명하세요. 로컬 패스 앤 플레이 프로토타입에는 역할 공개와 숨김 전달, 사건 행동 하나, 공개 로그, 토론 타이머, 비공개 투표, 판정, 재시작이 필요합니다. 명확한 상태 변화와 터치 및 키보드 조작을 요청하되 도구가 비밀 규칙을 정확히 구현한다고 가정하지 마세요.

빌드 프롬프트는 문자 그대로 유지하세요. 장르에 흔하다는 이유만으로 캐릭터 능력, 추가 단서, 온라인 방을 넣지 않습니다. 이 정보 순환이 이해 가능한지 살펴보는 것이 목표입니다:

허구 Harbor Relay 규칙 계약을 위한 간단한 2D 탁상형 단일 기기 패스 앤 플레이 프로토타입을 만드세요. 좌석 5개, 무작위 방해자 1명, 수호자 4명, 정전 1회, 공개 배지 그룹 단서, 90초 플레이어 토론, 비밀 투표 1회, 판정, 재시작만 구현하세요. 현재 플레이어에게만 역할을 보여 주고 전달 전 숨기며 역할을 공개 로그에 넣지 마세요. 토론 중에는 방해자를 식별하지 않고 영향받은 단말과 배지 그룹을 표시하세요. 모든 활성 플레이어가 유효 투표 하나를 제출할 때까지 투표 선택은 비공개로 유지하세요. 절반 초과를 엄격한 다수로 판정하고 그렇지 않으면 판정 없음을 표시하세요. 판정 뒤에만 추방된 역할을 공개하세요. 모든 상태 변화의 피드백, 잘못된 입력 처리, 읽기 쉬운 대비, 터치와 키보드 지원을 넣으세요. 네트워크 멀티플레이, 자동 생성 플레이어 주장, 추가 단서, 라운드, 점수, 동률 규칙은 추가하지 마세요. 상태 흐름과 추가 검증이 필요한 동작 목록을 반환하세요.

이는 빌드 시도를 요청할 뿐 이미 만들었다고 말하지 않습니다. 화면 전이를 각각 별도 질문으로 검토하세요. 지금 누가 역할을 볼 수 있는지, 무엇이 공개되는지, 어떤 투표 상태를 숨기는지, 정확히 어떤 조건이 라운드를 끝내는지 확인합니다.

수용 사례로 결과를 확인하세요

“괜찮아 보임” 같은 포괄적 검사가 아니라 관찰 가능한 사례를 사용하세요. 활성 투표 5개에서 절대 다수는 절반인 2.5보다 큰 최소 3표입니다. 종이 예시에서 B에게 3표면 방해자를 추방해 수호자가 이깁니다. A에게 3표면 무고한 좌석을 추방해 방해자가 이깁니다. 2–2–1 분할은 절대 다수가 없으므로 판정 없음으로 방해자가 승리합니다.

이는 향후 빌드를 위한 수용 사례이지 테스트 결과 보고가 아닙니다. 아래 결과 그림도 콘셉트입니다. 결정적인 3표 선택과 투표 종료 후 뒤집힌 역할 카드를 묘사할 뿐 소프트웨어 결과가 아닙니다.

초점 있는 수정 하나를 요청하세요

수용 사례가 실패하면 사례 이름과 정확한 관찰 상태를 말하세요. 이미 작동하는 규칙을 바꿀 수 있는 포괄적 다듬기를 요청하지 마세요. 예를 들어 사건 로그에 역할이 노출되면 역할 전달, 후보 그룹, 투표, 초기화를 유지하면서 공개 상태 직렬화만 수정해 달라고 요청하세요.

수용 사례: [실패한 사례 이름]. 예상: [상태와 보이는 결과]. 관찰: [프로토타입이 표시한 것]. 이 사례를 고치는 데 필요한 규칙 또는 전이만 변경하세요. 역할 비공개, 사건 1회 제한, 후보 그룹, 엄격한 다수 판정, 판정 없음 동작, 초기화를 포함해 통과한 동작은 보존하세요. 수정된 상태 매핑과 다시 확인할 수용 사례를 반환하세요. 검사를 실행하기 전까지 수정이 검증됐다고 주장하지 마세요.

각 수정 옆에 원래 사례 목록을 유지하세요. 무엇이 바뀌었는지, 어떤 동작을 보존했는지, 새 상태를 확인할 증거가 무엇인지 말할 수 있을 때 다음 검토를 준비할 수 있습니다.

다음 단계에 게임 제작 워크플로를 사용하세요

SEELE의 현재 Free AI Game Maker 페이지는 쉬운 영어 입력, 플레이 가능한 2D 또는 3D 첫 버전, 브라우저 테스트, 후속 프롬프트 개선을 설명합니다. 무료 Koins를 안내하고 생성 전 표시 비용을 검토하라고 합니다. 비용 FAQ는 Workspace에서 선택 모델, Koin 잔액, 표시 비용을 확인하라고 합니다. 이는 일반 워크플로 정보입니다. 페이지는 Harbor Relay, 비공개 핫시트 역할, 사회적 추리 순환을 설명하지 않습니다.

게임 제작 도구에서 아이디어를 살펴본다면 규칙 계약과 수용 목록부터 시작하세요. 반환 결과에서 역할 가시성, 단서 범위, 투표 비공개, 모든 종료 조건을 확인합니다. 결과는 검증 대상으로 다루고 프롬프트가 모든 세부를 보존한다고 보장된 것으로 보지 마세요.

자신의 게임 브리프를 다듬을 준비가 되면 Free AI Game Maker. The Harbor Relay example and images on this page are fictional design material; they are not SEELE output or a claim of tested gameplay.

사회적 추리 게임 프롬프트 FAQ

사회적 추리 프롬프트에서 먼저 무엇을 지정해야 하나요?

정보 계약부터 시작하세요. 각 숨은 역할을 누가 받는지, 무엇이 공개되는지, 단서가 무엇을 드러내거나 감출 수 있는지, 투표가 어떻게 판정되는지 정합니다. 다음으로 승리, 동률, 초기화 상태를 정의하세요. 시각 테마는 나중에 정해도 됩니다. 각 단계에서 플레이어가 아는 정보를 정의하지 않으면 매력적인 화면도 추리 순환의 일관성을 만들 수 없습니다.

단서를 결정적이지 않으면서 유용하게 하려면 어떻게 하나요?

단서로 생기는 후보 집합을 나열하고 그 안에 숨은 역할과 가능한 다른 플레이어가 최소 한 명 포함되는지 확인하세요. Harbor Relay의 배지 단서는 그룹에 따라 후보 둘 또는 셋을 만듭니다. 이는 예시의 설계 선택이지 모든 게임의 공정성 공식은 아닙니다. 각 단계에서 단서가 무엇을 공개하는지 확인하세요.

패스 앤 플레이는 온라인 멀티플레이를 뜻하나요?

아니요. 패스 앤 플레이는 여러 사람이 한 기기를 번갈아 사용하며 비공개 차례 사이에 화면을 숨기는 방식입니다. 네트워크, 계정, 매치메이킹, 원격 플레이를 뜻하지 않습니다. Harbor Relay는 이를 허구의 설계 제약으로 쓰며 제품 페이지는 비공개 역할 전달 구현을 보장하지 않습니다.

투표가 동률이면 어떻게 되나요?

빌드를 요청하기 전에 동률 규칙을 정하세요. Harbor Relay에는 숨은 타이브레이커가 없습니다. 절대 다수가 없으면 판정이 없고 방해자가 이깁니다. 다른 게임에서는 토론을 다시 시작하거나 재투표할 수 있지만 다른 규칙이므로 계약과 수용 사례에 명시해야 합니다.

첫 빌드를 어떻게 확인하나요?

각 정보 경계와 종료 조건마다 역할 공개, 공개 단서, 비공개 투표, 올바른 추방, 잘못된 추방, 판정 없음, 잘못된 입력, 재시작을 검사하는 작은 사례를 실행하세요. 빌드를 살펴보기 전에 설정과 예상되는 표시 결과를 기록하세요. 검사를 실행하지 않았다면 테스트 결과가 아니라 계획된 사례라고 설명하세요.