플레이 가능한 계약에서 환상을 분리하세요
플레이어 동사, 목표, 제약, 피드백을 적어보세요. 예: "어두운 미로를 통해 랜턴을 이동하고 세 개의 파란색 키를 수집합니다. 빛이 근처 벽을 드러냅니다. 벽 충돌로 인해 플레이어가 입구로 재설정되고 수집된 키가 유지됩니다." 이 문장은 테스터에게 이동, 수집, 가시성 반경 및 재설정 동작이라는 네 가지 검사 항목을 제공합니다. 재설정 시 키를 보존하는 것이 필수적이지 않은 경우 실수로 해석될 수 있도록 남겨 두지 말고 해당 조항을 제거하세요.
관찰 가능하고 범위가 지정된 기준을 유지하세요.
어떤 관찰 결과가 그것을 뒷받침하는지 설명할 때까지는 "미로가 다듬어진 느낌"과 같은 기준을 피하십시오. "플레이어는 세 번째 열쇠를 수집한 후 출구를 식별할 수 있습니다"가 더 유용합니다. 또한 첫 번째 빌드를 바인딩했습니다(미로 1개, 키 3개, 위험 1개 및 다시 시작). 제한이 작으면 레벨, 장식, 업그레이드, 스토리를 한 번에 요청하는 프롬프트보다 불완전한 결과를 진단하기가 더 쉽습니다.
게임 프롬프트 승인 기준 관련 질문
승인 기준은 게임 메시지와 동일합니까?
중복되지만 기준은 프롬프트 또는 리뷰 체크리스트 내에서 확인 가능한 결과입니다. 프롬프트에는 어조, 테마, 시각적 방향도 포함될 수 있습니다.
게임 메시지는 얼마나 구체적이어야 하나요?
입력, 골, 득점, 실패 및 재시작 동작을 정확하게 확인하세요. 다른 선택이 규칙 작동 여부를 변경하지 않는 시각적 해석의 여지를 남겨두십시오.
추가 읽을거리
오래된 정보를 발견하셨나요? 수정 사항 제보