정보와 행동의 의존 관계로 협동 루프 설계하기

비대칭 협동 게임은 플레이어들이 서로 다른 정보를 갖고, 상대는 할 수 없는 행동을 각자 하나씩 맡을 때 작동합니다. 공동 목표 하나를 정하고 역할별로 무엇을 보고 바꿀 수 있는지 정의한 뒤 결과를 모두에게 보여 주세요. 그다음 작은 만남 하나와 확장 전에 규칙을 살펴볼 방법을 요청합니다.

아래 프롬프트는 두 명의 로컬 참가자가 음성으로 소통하는 동굴 구조 교육용 콘셉트 Lantern Relay를 사용합니다. 아직 제작되거나 테스트되지 않았습니다. Keeper는 경로 지도를 읽고 원격 셔터 하나를 바꾸며, Delver는 물리 거울 하나를 돌리고 자신이 보는 빔 구간을 보고합니다. 이는 예시의 설계 가정이며 SEELE 기능에 대한 주장이 아닙니다.

캐릭터 직업보다 의존 관계부터 시작하기

역할 이름을 붙이기 전에 다음 문장을 완성하세요. “우리는 한 플레이어가 [비공개 정보]를 사용해 [행동]을 하고, 다른 플레이어가 [다른 정보]를 사용해 [다른 행동]을 한 뒤에만 [공동 목표]에 도달한다.” 둘 중 한 행동을 없애도 해결 방법이 달라지지 않는다면 역할 이름만 다를 뿐 아직 서로 의존하지 않습니다.

비대칭 협동 게임 프롬프트에서는 공동 목표를 먼저 쓰고, 각 역할의 정보 경계와 전용 행동을 정의하세요. 한 플레이어가 언제 다른 플레이어의 보고를 필요로 하는지, 무엇이 바뀌었는지 확인하는 피드백도 포함합니다. 이렇게 하면 “능력이 서로 다르다”는 설정을 서로 무관한 캐릭터 설명이 아니라 실제 퍼즐 루프에 연결할 수 있습니다.

정보 분리의 문서화된 사례는 Keep Talking and Nobody Explodes 공식 원격 플레이 안내에 있습니다. Defuser는 폭탄을 보지만 설명서는 보지 못하고, Experts는 폭탄을 보지 않고 설명서를 사용합니다. Lantern Relay는 배경과 규칙이 다릅니다. 유용한 설계 질문은 성공적인 행동 전에 어떤 정보가 역할 사이를 오가야 하는가입니다.

두 역할 모두 꼭 필요한 일을 맡기기

Lantern Relay에서 Keeper는 고정 동굴 경로와 원격 셔터 선택지를 알지만 현재 어느 빔 구간이 켜졌는지는 볼 수 없습니다. Delver는 실제 빔과 물리 거울 하나를 보지만 경로 지도는 볼 수 없고 셔터도 조작할 수 없습니다. Delver가 거울을 조정하고 보이는 구간을 외치면 Keeper가 그 보고를 바탕으로 맞는 셔터를 선택합니다. 그래야 빔이 구조 게이트에 도달합니다.

이것은 역할 계약입니다. 각 측에 비공개 정보, 그 정보와 연결된 행동, 소통해야 할 이유가 있습니다. 전체 프롬프트를 쓰기 전에 플레이어가 가리킬 수 있는 명사와 동사로 표를 채우세요. “정찰병은 빠르다”만으로는 부족합니다. “정찰병은 압력판을 보고 그 위에 올라가 누를 수 있다”라고 하면 다른 역할이 의존할 구체적 조건이 생깁니다.

이 표는 흔한 실패도 드러냅니다. Keeper 지도에 이미 현재 빔 구간이 표시되면 Delver의 보고는 새로운 정보를 주지 않습니다. Delver가 혼자 거울을 조정해 목표에 도달할 수 있다면 Keeper는 관찰자에 불과합니다. 대화, 방 추가, 캐릭터 성장 요소를 넣기 전에 규칙의 빈틈을 메우세요.

규칙에서 한 방까지 프롬프트 세 단계로 구성하기

각 요청을 분리해 응답마다 역할 하나만 맡기세요. 먼저 역할 계약을 정의합니다. 다음으로 간단한 플레이 상호작용을 요청하거나, 선택한 도구가 필요한 조작을 지원하지 못한다면 구조화된 설계 전달 문서를 요청합니다. 마지막으로 실제 관찰이 있을 때만 평가 계획을 요청합니다. 다음 비대칭 협동 게임용 AI 프롬프트는 템플릿입니다. 괄호 안을 바꾸고 예시가 아직 테스트되지 않았다는 점을 유지하세요.

프롬프트 1: 역할 계약 정의하기

정확히 [플레이어 수]명이 함께하는 협동 게임 콘셉트를 설계한다.
공동 목표: [그룹이 달성해야 할 일을 한 문장으로 설명].
소통 가정: [플레이어가 정보를 주고받는 방식].

각 역할마다 다음을 적는다.
- 해당 역할만 관찰할 수 있는 정보
- 해당 역할만 수행할 수 있는 행동
- 행동 뒤에 바뀌는 상태
- 역할이 다른 플레이어에게 보고할 신호

정보, 보고, 파트너의 판단, 행동, 공유 피드백 순서로 의존 관계를 보여 준다. 시작 상태, 가능한 행동, 성공 조건, 실패 조건, 리셋 상태를 포함한 짧은 만남 하나를 만든다. 그런 다음 역할을 하나씩 제거했을 때 만남이 여전히 해결 가능한지 설명한다. 역할을 제거해도 해법이 바뀌지 않는다면 의존 관계를 수정한다. 아직 방, 진행 체계, 추가 시스템을 넣지 않는다.

역할 표, 상태 전이 표, 아직 설계 결정이 필요한 규칙을 반환한다. 게임이 제작 또는 테스트되었다고 주장하지 않는다.

첫 요청은 다듬어진 세계관이 아니라 설계 계약을 요구합니다. 모든 역할에 관찰할 것, 할 일, 파트너의 다음 판단에 영향을 미치는 보고가 있는지 확인하세요. 응답이 아직 선택하지 않은 구현 세부 사항을 만들어 내면 확정된 동작으로 취급하지 말고 미결정 항목으로 남깁니다.

프롬프트 2: 첫 방의 범위 정하기

Lantern Relay라는 동굴 구조 퍼즐 방 하나를 설계한다.
음성으로 소통하는 두 명의 로컬 참가자를 위한 가상의 교육 콘셉트다.
이 프롬프트는 실행하거나 테스트하지 않았다.

공동 목표: 신호기를 구조 게이트까지 안내한다.
Keeper의 시야와 행동: Keeper는 고정 경로 지도와 원격 셔터 선택지를 보지만, 동굴의 실시간 화면이나 현재 빔 구간은 보지 못한다. 원격 셔터 설정 하나를 바꾸는 역할은 Keeper만 맡는다.
Delver의 시야와 행동: Delver는 실시간 빔과 물리 거울 하나를 보지만 경로 지도와 원격 셔터 상태는 보지 못한다. 그 거울을 돌리고 어느 빔 구간이 켜졌는지 보고하는 역할은 Delver만 맡는다.
경로 지도는 가능한 길을 제공하고 Delver의 보고는 현재 빔 구간을 알려 준다. Keeper는 그 보고를 바탕으로 맞는 셔터를 선택해야 한다. 빔이 구조 게이트에 도달하기 전에 거울과 셔터가 모두 정확해야 한다.

시작 상태, 각 합법 행동, 잘못된 행동의 피드백, 성공 상태, 실패 또는 시간 초과 상태, 시작 상태로의 리셋을 보여 준다. 물리 거울 하나와 원격 셔터 하나만 둔다. 전투, 인벤토리, 캠페인 진행, 온라인 네트워킹, 음성 채팅 소프트웨어, 두 번째 방은 넣지 않는다. 제안하는 화면에서 각 역할의 정보를 분리한다.

사용 가능한 제작 도구가 로컬 입력 두 개나 분리된 화면을 표현하지 못한다면, 콘셉트를 플레이 가능한 것처럼 제시하지 말고 구조화된 메커니즘 및 인터페이스 전달 문서를 반환한다. 결정이 필요한 규칙은 표시한다. 상태 표와 짧은 수용 확인 목록을 반환한다.

응답을 받은 뒤 아트 방향보다 상태 표를 먼저 읽습니다. 잘못된 셔터 선택이 눈에 보이고 복구 가능한 결과를 내는지, Delver가 Keeper의 지도를 보지 않고도 빔 상태를 보고할 수 있는지, Keeper가 그 보고를 사용해 의미 있는 다음 행동을 선택할 수 있는지 확인합니다. 도구나 런타임이 이런 제약을 표현하지 못하면 설계 전달 문서는 유용하지만, 작동하는 협동 빌드의 증거는 아닙니다.

프롬프트 3: 실제로 수집한 관찰 평가하기

이 1실 협동 설계에 대해 내가 제공하는 관찰을 검토한다.
플레이어 행동, 플레이테스트 메모, 성공 결과를 지어내지 않는다.

설계 계약: [합의된 역할 표와 시작 상태를 붙여넣기].
관찰한 순서: [기록한 행동과 반응만 붙여넣기].
예상 결과: [규칙에 따른 결과를 적기].
실제 결과: [플레이어 또는 빌드가 보여 준 내용을 적기].
첫 혼란 지점: [가장 먼저 생긴 모호함을 인용하거나 설명].

관찰 순서를 계약과 단계별로 비교한다.
첫 불일치를 짚고 어떤 규칙 또는 신호에 관한 것인지 설명하며 범위가 제한된 수정 하나를 제안한다. 방, 역할, 무관한 규칙은 유지한다. 관찰이 없거나 모호하면 다음에 무엇을 기록해야 하는지 묻는다. 제공된 관찰이 뒷받침하지 않으면 설계가 통과했다고 말하지 않는다.
변경할 문장, 이제 관찰 가능해야 하는 내용, 다음 세션의 후속 확인 하나를 반환한다.

“평가”라는 단어보다 입력 내용이 중요합니다. 관찰한 순서가 없으면 모델은 설계 확인을 제안할 수 있을 뿐, 플레이어 행동을 보고할 수 없습니다. 실제 관찰을 수집할 때는 의도한 결과와 처음 혼란이 생긴 순간을 포함하세요. 그러면 두 역할을 모두 다시 쓰지 않고 가장 작은 불일치를 수정할 수 있습니다.

두 플레이어 모두 중요한지 확인하기

역할 표는 의도를 설명하지만 방에는 여전히 관찰 가능한 확인이 필요합니다. 시작 상태부터 만남을 따라가며 각 단계에서 플레이어가 무엇을 아는지 물어보세요. 다음 확인은 Lantern Relay 플레이테스트 결과가 아니라 본인 설계를 검토하기 위한 제안 방법입니다.

한 번에 하나만 바꾸세요. 보고가 모호하면 힌트 시스템을 추가하기 전에 신호를 명확히 합니다. 한 역할이 놀고 있다면 관찰과 행동 사이의 단계를 줄입니다. 목표가 잘 안 보인다면 퍼즐을 더 추가하기 전에 빔이나 게이트 피드백을 개선합니다. 범위가 좁은 수정은 계속 평가하고 싶은 부분을 보존합니다.

실제 관찰을 바탕으로 수정하기

플레이어와 함께 설계를 관찰할 수 있게 되면 네 가지를 적습니다. 행동, 예상 결과, 실제 결과, 누군가가 처음 망설이거나 오해한 지점입니다. 확인할 장면 없이 “Keeper가 지루했다”고 결론 내리지 마세요. “Delver가 빔을 보고하기 전에 Keeper가 셔터를 아무거나 선택할 수 있었다”는 메모는 바꾸고 다시 확인할 구체적인 의존 관계를 가리킵니다.

그 규칙을 수정하는 동안 방의 나머지는 고정합니다. 같은 시작 상태를 반복하고 보고가 파트너의 판단을 바꾸는지 봅니다. 이것이 설계의 균형이나 광범위한 사용성을 증명하지는 않지만 다음 질문을 추적 가능하게 합니다. 실제 관찰이 없다면 플레이테스트 결과라고 하지 말고 확인할 위험으로 표현하세요.

초점을 좁힌 설계를 제작 워크플로에 전달하기

종이 위 계약이 일관되면 게임 제작 워크플로에 아이디어를 입력하고 결과를 확인할 수 있습니다. SEELE의 현재 Free AI 게임 메이커 페이지는 쉬운 영어 설명, 플레이 가능한 2D·3D 결과 검토, Workspace에서의 반복 작업을 안내합니다. 표시된 생성 비용과 계정 옵션도 확인하라고 합니다. 이런 일반적인 워크플로 정보는 로컬 협동, 로컬 입력 두 개, 음성 통신, 이 가상의 방을 검증하지 않습니다.

공동 목표, 첫 플레이어 행동, 장면 상태, 피드백을 요청에 넣습니다. 협동 프로토타입이라고 부르기 전에 결과가 각 조작과 역할을 실제로 표현하는지 살펴보세요. 현재 워크플로가 두 플레이어의 화면이나 입력을 표현하지 못하면 결과는 설계 출발점으로 쓰고 적절한 구현을 별도로 계획합니다. 퍼즐 자체에는 한 가지 규칙, 보이는 단서, 해결 행동, 결과를 구성하는 AI 퍼즐 게임 메이커 페이지가 관련되지만 멀티플레이어 지원을 증명하지는 않습니다.

좋은 첫 결과는 계약과 비교해 확인할 수 있는 가장 작은 결과물입니다. 각 역할이 정보나 행동을 보태고, 잘못된 선택에 설명이 있으며, 양쪽의 기여에서 성공 상태가 눈에 보이게 이어지는 경우에만 방을 유지하세요. 확인이 되지 않으면 두 번째 방으로 넓히기 전에 규칙 하나를 수정하거나 설계 전달 문서를 요청합니다.