AI 게임 마스터 설계
AI 게임 마스터에게 구조화 출력과 서술은 언제 필요할까?
구조화된 AI 출력이 RPG에서 어디에 도움이 되는지, 서술이 여전히 중요한 이유, 그리고 게임 엔진이 주사위·권한·저장 상태를 검증해야 하는 이유를 알아보세요.
구조화된 데이터와 이야기에 각각 역할을 맡기세요
AI 게임 마스터는 플레이어가 무엇을 시도했는지 이해하고, 무슨 일이 일어났는지를 설득력 있는 이야기로 전달해야 한다. 이 둘은 관련이 있지만, 같은 단락이 규칙과 저장 상태의 유일한 출처가 되어서는 안 된다. 구조화 출력을 사용하면 모델이 제안한 판단을 프로그램이 더 쉽게 검사할 수 있다. 서술은 플레이어에게 분위기, 대화, 그리고 명확한 다음 선택지를 제공한다. 어느 형식이든 모델이 생성한 주장만으로 사실이 확정되지는 않습니다.
예시 장면을 상상해 보자: 도적은 봉인된 금고에 도착하고, '자물쇠를 만지기 전에 작은 거울로 문양를 살펴본다'고 말한다. 게임은 조사 시도를 식별하고, 주사위가 필요한지 판단하며, 주사위를 처리한 다음 도적이 무엇을 알게 되는지를 서술할 수 있다. 만약 모델이 해결 전에 '당신은 해제 표식을 발견하고 금고를 연다'고 쓴다면, 서사가 규칙상의 결과를 앞질렀습니다. 이는 설계 예시이며, Playworlds의 실제 운영 동작의 기록은 아니다.
결정안을 담을 간단한 스키마를 사용하세요
구조화된 제안에는 시도한 행동, 대상 객체, 가능한 판정, 관련 규칙 참조, 그리고 판단이 필요한 불확실성이 포함될 수 있다. 금고의 경우, 거울로 살펴보는 것을 시도한 행동으로 식별하고 지각 또는 조사 판정를 제안할 수 있다. 주사위 값을 단정하거나, 아이템을 부여하거나, 캐릭터를 이동시키거나, 금고가 열렸다고 표시해서는 안 됩니다.
OpenAI는 모델과 애플리케이션 도구를 연결하는 function calling과, 모델 응답의 형태를 정하는 구조화된 응답 형식을 구분한다. 그 Structured Outputs 가이드는 지원되는 엄격한 스키마가 스키마 준수를 강제하지만, 구조화된 결과에도 여전히 오류가 있을 수 있다고 경고한다. 게임 설계 관점에서 이는 'check_required: false'와 같은 유효한 필드도 규칙과 상태에 대조해 검토해야 할 주장이라는 뜻이다. 파서 검사를 통과하는 것은 첫 번째 관문일 뿐입니다.
주사위와 상태는 게임이 관리하세요
엔진은 결과를 결정하는 사실들을 소유해야 한다: 캐릭터 능력, 인벤토리, 사용 가능한 행동, 주사위, 목표치, 그리고 승인된 세계 상태 변경. 제안된 워크플로에서 모델은 판정을 요청하거나 그것이 왜 중요할 수 있는지 설명할 수 있다. 애플리케이션은 그 요청을 검증하고, 주사위를 수행하거나 기록한 다음, 확정된 결과를 반환한다. 그때 비로소 내레이션이 그에 따른 일을 서술한다. 동반 캐릭터는 완료된 판정에 반응할 수 있지만, 새로운 새로운 주사위 결과를 만들거나 기존 결과를 바꾸어서는 안 됩니다.
승인된 결과가 주사위 눈금 11에 보너스 2를 더한 13이 목표치 16에 못 미친다고 가정해 봅시다. 내레이터는 거울에서 표식이 흐려지고, 자물쇠가 여전히 봉인되어 있으며, 도적이 스케치를 참고하거나 동반자에게 묻거나 다른 도구를 시도할 수 있다고 말할 수 있다. 13을 조용히 성공으로 바꿔서는 안 된다. 규칙이 부분적 결과를 허용한다면, 엔진은 서술이 그것을 사실로 제시하기 전에 이를 승인해야 한다.
결과가 확정된 뒤에 서술을 작성하세요
내러티브 출력은 구조화된 제안과 다른 수용 기준을 가진다. 시도한 방법을 인정하고, 확정된 결과를 존중하며, NPC들의 지식을 보존하고, 유용한 결정 지점에서 끝나야 한다. 상태 업데이트가 허용하지 않는 한 새로운 상처, 상태, 또는 아이템이 추가되었다고 주장하지 않으면서도 도적의 손에 닿을 듯한 황동의 냉기를 서술할 수 있다. 엔진이 규칙을 결정하는 주체로 남아 있으면, 장면은 생생하게 유지될 수 있다.
이 분리는 수정을 더 쉽게 만든다. 제안된 판정이 잘못되었다면, 해석이나 규칙 매핑을 변경한다. 판정과 상태가 맞는데 장면이 지루하다면, 서술 지침를 개선한다. 서술이 주사위와 모순된다면, 서술 입력과 후처리를 점검하세요. 같은 저장된 장면을 바탕으로 출력을 비교하세요.
잘못되거나 불확실한 응답에 대비하세요
스키마에는 불확실성을 위한 명시적인 경로가 필요하다. 모델은 플레이어가 규칙 질문을 하고 있는지, 월드 내 행동을 취하고 있는지, 아니면 여러 행동을 동시에 서술하고 있는지를 판단하지 못할 수 있다. 자신감 있는 규칙 선택을 강요하기보다, 제한된 '확인 필요' 또는 '판정 제안 없음' 결과를 반환하도록 하라. 참조된 캐릭터 ID와 장면 객체를 현재 상태와 대조해 검증하고, 허용된 행동을 초과하는 변경은 거부하라. 스키마는 객체가 모험에 실제로 존재한다는 것을 증명할 수 없다.
거절, 불완전한 응답, 지원되지 않는 스키마, 누락된 도구 결과, 또는 오래된 장면 버전은 조용히 승인된 스토리 이벤트가 되어서는 안 된다. 안전한 이유를 기록하고 정의된 한도 내에서 재시도하라; 그렇지 않으면 더 명확한 행동을 요청하거나 복구 가능한 오류를 표시하라.
실전 점검표
생성된 턴을 승인하기 전에 확인하라: (1) 제안된 행동이 플레이어의 말과 일치하는가? (2) 각 참조된 캐릭터와 객체가 현재 장면에 존재하는가? (3) 엔진이 주사위가 필요한지 결정하고 결과를 기록했는가? (4) 상태 변경이 검증되고 한 번만 저장되었는가? (5) 서술이 그 승인된 사실과 일치하고 다음 선택을 플레이어에게 남기는가? (6) 다시 불러오면 같은 위치, 주사위, 결과가 재현되는가? 이 점검 항목은 설계 지침이며, 측정된 Playworlds 성능에 대한 주장은 아니다.
플레이어는 자신의 캐릭터가 무엇을 시도했는지, 규칙이 어떻게 해결했는지, 그리고 어떤 선택지가 남아 있는지를 봐야 한다. Playworlds는 월드, 캐릭터 시트, 주사위, 그리고 계속되는 모험을 한 곳에서 제공한다. 작은 행동을 시도한 다음, 응답을 화면에 보이는 게임 상태와 비교해 보라. 우리의 행동 가이드는 그 행동을 구체적으로 만드는 데 도움이 된다.