먼저 작은 나들이 하나를 완성하세요
아늑한 탐험 프롬프트에는 부드러운 색과 조용한 장소만으로 부족합니다. 반복할 행동, 진행 방향을 보여 주는 경로, 실수를 되돌릴 수 있는 복구 방법, 알아보기 쉬운 종료 조건을 정하세요. 이 규칙을 먼저 쓰면 첫 요청을 검토하기 쉬워집니다.
Mossglass Crossing은 이 안내서의 독창적인 종이 설계 예시입니다. 노 젓는 사람 한 명, 잔잔한 만 하나, 순서가 정해진 부표 관문 세 곳, 마지막 작은 만 선착장이 있습니다. 아래 경로와 조작, 프롬프트, 예상 상태는 가상 설계 자료입니다. 프롬프트 실행이나 플레이 가능한 빌드, 테스트는 없었습니다.
첫 나들이는 몇 문장으로 설명할 수 있을 만큼 작게 유지하세요. 요청한 기능이 다음 선택, 경로 상태, 복구, 결말을 바꾸지 않는다면 첫 버전에서 빼세요.
잔잔한 분위기를 플레이 가능한 제약으로 바꾸세요
“아늑하다”는 제작자마다 의미가 다릅니다. 타이머, 피해, 연료, 진행 손실 없음, 알아보기 쉬운 넓은 관문, 완료된 관문을 취소하지 않고 카약을 안전한 물로 돌려놓는 복구 행동처럼 확인 가능한 동작으로 바꾸세요.
Mossglass Crossing의 작은 만 선착장은 출발점에서 보이고 물길은 갈라지지 않습니다. 관문 쌍을 통과하면 잔잔한 물결과 부표 흔들림으로 유효한 통과를 알려 줍니다. 피드백은 행동에 바로 연결되므로 점수, 카운트다운, 추가 수집물이 필요하지 않습니다.
이는 제안 설계의 선택이지 아늑한 게임의 보편 규칙은 아닙니다. 다른 아이디어가 선택적 발견, 사회적 만남, 자유로운 배회를 중심으로 한다면 경로와 만족스러운 마무리에 어떤 영향을 주는지 정한 다음 추가하세요.
풍경 프롬프트 전에 규칙 계약을 작성하세요
바위나 갈대를 자세히 요청하기 전에 이동, 진행 조건, 복구 효과, 나들이 종료 시점을 정합니다. 통과 방향과 다음 관문을 명시하면 뒤 관문을 먼저 통과하거나 역방향 통과가 조용히 진행을 바꾸는 일을 막습니다.
| 규칙 | Mossglass 제안 | 예상 반응 |
|---|---|---|
| 시작 상태 | 출발 부두에서 시작, `routeProgress=0`, 체크포인트는 출발, 완료 false. | 첫 관문이 다음 목표이며 한 물길 너머 작은 만 선착장이 보임. |
| 조작 | 전진을 누르고 노 젓기, 좌/우 방향 조정, 후진은 느리게 노 젓기, Recover는 카약 위치 복구, Interact는 마지막 선착장용. | 각 키에 효과 하나. 조향 자체는 진행도 보상하지 않음. |
| 순서 통과 | 접근 방향에서 다음 부표 쌍 사이 틈을 통과. 유효한 전진 통과는 관문 1, 2, 3 순으로 진행. | 새 관문마다 진행도 한 번 증가. 반대 방향, 건너뜀, 이미 통과한 관문은 진행을 바꾸지 않음. |
| 피드백 | 유효 통과 때 부표가 살짝 흔들리고 물결이 틈을 지납니다. | 행동에 연결된 작은 반응을 표시. 이 설계에는 숫자 HUD가 필요하지 않음. |
| 복구 | 얕은 둑에 닿으면 카약이 멈춥니다. Recover를 누르면 진행 0일 때 출발점, 그 외에는 마지막 통과 관문 옆의 안전한 물로 이동. | 위치만 바뀌고 경로 진행 및 완료는 그대로. |
| 종료와 재시작 | 진행 3일 때 작은 만 선착장에서만 Interact가 나들이를 끝냅니다. 재시작하면 어느 상태에서든 출발점, 진행 0, 완료 false, 출발 체크포인트로 복귀. | 일찍 선착장에 가도 관문을 건너뛸 수 없음. 재시작은 같은 초기 상태를 복원. |
상태 전환은 한 문장으로 정리할 수 있습니다. 다음 관문을 전진 통과할 때만 `routeProgress`가 바뀌고, Recover는 위치만 바꾸며 선착장은 3/3에서만 나들이를 끝냅니다. 장면을 작성하는 동안 이 문장을 프롬프트 옆에 두세요.
이 그림은 작성된 2/3 상태의 콘셉트 묘사이지 게임 스크린샷이 아닙니다. 아직 숫자를 추가하지 않고도 물리적 표식으로 순서를 전달하는 방법을 보여 줍니다.
프롬프트 세 개를 순서대로 사용하세요
규칙 명확화, 첫 빌드 요청, 이후 수정 요청을 분리하세요. 각 프롬프트에는 입력, 제약, 예상 출력, 점검 방법을 적습니다. 앞의 두 요청은 빌드 전에도 적용할 수 있지만 세 번째는 실제 관찰 뒤에만 사용합니다.
프롬프트 A: 불명확한 규칙 드러내기
Mossglass Crossing이라는 소규모 1인 아늑한 탐험 게임을 계획합니다. 가상의 설계 설명이지 기존 게임에 대한 보고가 아닙니다. 플레이어는 카약을 타고 출발 부두에서 시작합니다. 목표는 부표 쌍 세 곳 사이를 순서대로 통과하고 마지막 작은 만 선착장에서 Interact를 누르는 것입니다. 전진은 노를 저으며 좌우는 방향 조정, 후진은 느리게 이동, Recover는 얕은 둑에서 안전한 물로 위치 이동만 합니다. 다음 관문을 접근 쪽에서 전진 통과할 때만 진행이 한 단계 오릅니다. 역방향, 건너뛰기, 중복 통과는 진행을 바꾸지 않습니다. Recover는 진행 0이면 출발점, 이후에는 마지막 통과 관문으로 이동시킵니다. 진행 3이 되어야 선착장에서 종료할 수 있습니다. 타이머, 점수, 피해, 연료, 수집물, 진행 손실은 없습니다. 흐릿한 부분과 직접 정해야 할 선택을 나열하세요. 새 시스템을 발명하지 마세요.
모호한 부분 목록을 먼저 읽으세요. 빌드를 요청하기 전에 열린 선택을 직접 정해야 합니다. 그렇지 않으면 나중 결과가 의도하지 않은 가정을 따를 수 있습니다.
프롬프트 B: 최소 경로 요청
이 사양에 따라 소규모 1인 3인칭 실시간 3D 카약 탐험 프로토타입을 만드세요. 출발 부두, 이어지는 물길 하나, 넓은 부표 관문 쌍 세 곳, 마지막 작은 만 선착장이 있는 잔잔한 석회암 만을 사용합니다. 플레이어는 성인 노 젓는 사람이며 카약을 조종합니다. 화면에 다음 관문과 출발 쪽을 표시합니다. 전진/좌우/느린 후진/Recover/Interact 조작을 표시합니다. 접근 방향에서 다음 관문을 전진 통과할 때만 진행을 한 번 올립니다. 부표 반응으로 유효 통과를 확인합니다. Recover는 위치만 바꾸고 진행은 유지합니다. 3/3 진행 뒤 선착장에서 상호작용해야 종료됩니다. 타이머, 피해, 연료, 수집물, 다른 물길, 진행 손실은 추가하지 마세요. 재시작은 완전 초기화합니다.
이는 정의된 프로토타입을 시도해 달라는 요청이지 작업 공간에서 조작이나 관문 규칙이 그대로 구현된다는 증거는 아닙니다. 실제 출력과 계약을 비교한 뒤 풍경이나 경로를 확장하세요.
프롬프트 C: 관찰한 불일치 하나 수정
실제 빌드가 있고 같은 점검을 반복한 뒤에만 사용하세요. 관찰을 지어내지 마세요. 재현 가능한 행동: [정확한 입력과 시작 상태] 작성된 계약의 예상 상태: [진행, 위치, 완료] 빌드에서 관찰한 상태: [실제 결과] 불일치 원인 규칙이나 조작 하나만 수정합니다. 나머지 진행, Recover, 종료 규칙은 유지하고 같은 입력 순서를 반복합니다. 시각 자료, 경로, 전혀 관련 없는 기능은 바꾸지 않습니다. 실제 증거 없이 성공했다고 주장하지 마세요.
프롬프트 C는 재사용 가능한 수정 양식이지 이 예시에서 실제 불일치가 관찰되었다는 주장이 아닙니다. 관찰 항목에는 실제 행동과 결과만 넣을 수 있습니다.
경로 하나를 손으로 추적한 뒤 점검하세요
짧은 순서를 사용해 규칙이 서로 맞는지 확인하세요. 제안 규칙을 직접 계산한 것으로 게임 실행이나 플레이테스트가 아닙니다.
| 단계 | 플레이어 행동 | 예상 상태 |
|---|---|---|
| 시작 | 출발 부두 옆에서 시작. | 진행 0/3, 출발 체크포인트, 완료 false. |
| 1 | 관문 1을 전진으로 통과. | 진행 1/3, 관문 1이 최신 체크포인트. |
| 2 | 관문 2를 통과. | 진행 2/3, 관문 2가 최신 체크포인트. |
| 3 | 얕은 둑으로 흘러간 뒤 Recover 누름. | 카약이 관문 2 옆으로 복귀, 진행 2/3, 완료 false. |
| 4 | 관문 3을 전진으로 통과. | 진행 3/3, 아직 부두 상호작용 전이므로 미완료. |
| 5 | 작은 만 부두에 가서 Interact 누름. | 잔잔한 착지 반응과 함께 완료 true. |
예상 순서: 0/3 → 1/3 → 2/3 → 2/3에서 복구 → 3/3 → 부두 완료. Recover는 위치를 바꾸지만 진행은 유지하며 부두는 전진 통과 세 번 후에만 완료됩니다. 이미지는 제안된 결말 콘셉트이지 실제 결과 증거가 아닙니다.
| 점검 | 알려진 상태에서 행동 | 예상 결과 |
|---|---|---|
| 반대 방향 | 0/3에서 관문 1을 먼 쪽에서 통과. | 진행 0/3 유지. |
| 앞선 관문 건너뜀 | 0/3에서 관문 2를 전진 통과. | 진행 0/3, 관문 1이 다음 목표. |
| 중복 관문 | 1/3에서 관문 1을 다시 통과하거나 빙 돌아 통과. | 진행 1/3, 관문 2가 다음 목표. |
| 진행 0에서 복구 | 0/3에서 둑에 닿고 Recover. | 출발점 복귀, 진행 0/3 유지. |
| 진행 2에서 복구 | 2/3에서 둑에 닿고 Recover. | 관문 2 옆으로 복귀, 진행 2/3 유지. |
| 이른 부두 | 2/3에서 작은 만 부두로 가 Interact. | 나들이 미완료, 진행 2/3 유지. |
| 재시작 | 완료 뒤 재시작. | 출발점, 0/3, 완료 false, 출발 체크포인트 복구. |
이 사례는 자신의 빌드에서 실행할 수용 점검입니다. 실행 전까지는 적힌 규칙에서 나온 예상 결과이지 관찰된 결과가 아닙니다.
관찰 근거가 있는 수정 하나를 하세요
실제 결과가 예상과 다르면 프롬프트를 바꾸기 전에 시작 상태, 정확한 입력, 예상 결과, 관찰 결과를 기록하세요. 영향받은 규칙이나 조작만 수정하고 같은 행동을 반복합니다. 예를 들어 관문 2를 유효 통과했는데 진행이 오르지 않으면 먼저 전진 방향 및 다음 관문 판정을 고치고 Recover와 종료 조건은 유지합니다.
기록에서 예상과 관찰값을 분리하세요. 종이 경로로 사양의 내부 일관성을 확인할 수는 있지만 생성된 조작이 반응이 좋은지, 관문을 통과하기 쉬운지, 플레이어가 피드백을 이해하는지는 알 수 없습니다. 빌드가 없다면 관찰란을 비워 둡니다.
제작 작업 공간에 설명을 전달하세요
현재 Free AI Game Maker 페이지는 평이한 영어로 게임 아이디어 설명, 플레이 가능한 2D/3D 결과 검토, Workspace에서 반복 개선, 생성 전 표시된 Koin 비용과 계정 옵션 확인을 안내합니다. 이는 일반 제작 흐름이지 카약 조작, 순서 관문, 복구 동작이 구현된다는 보장은 아닙니다.
짧은 계약을 입력하고 작업 공간에서 실제 반환 결과를 확인하세요. 관문 규칙, 복구 상태, 조작, 완료 조건이 달라지면 표와 비교해 프롬프트 또는 설계를 바꿀지 판단합니다.
다음 단계에도 계약을 유지하세요
두 번째 경로나 새 활동을 추가하기 전에 플레이어 행동, 순서 표식, 진행 변화, 복구, 종료 조건 다섯 가지를 확인하세요. 이 요소가 있는 짧은 경로로 첫 요청과 실제 결과 평가 기준을 명확히 만들 수 있습니다.
자신의 게임 아이디어를 구체화할 준비가 되면 Free AI game maker를 열고 점검할 수 있는 짧은 설명을 전달하세요. 결과와 현재 생성 비용을 확인하고 검증되지 않은 메커니즘은 확인 전까지 열린 질문으로 둡니다.
자주 묻는 질문
Mossglass Crossing은 플레이 가능하거나 테스트된 게임인가요?
아니요. Mossglass Crossing은 종이로 설계한 독창적인 교육 예시입니다. 경로 순서는 글의 규칙으로 손 계산했으며 프롬프트 실행, 생성 빌드, 사용자 세션, 플레이테스트는 제공되지 않았습니다. 사양 연습으로 사용하고 조작이나 경로 동작을 관찰했다고 말하기 전에 자신의 빌드를 확인하세요.
카약이 관문을 역방향 통과하면 진행이 줄어야 하나요?
이 설계에서는 아닙니다. 다음 관문을 전진 통과할 때만 진행이 오르고 반대 방향, 건너뛰기, 중복 통과는 값을 바꾸지 않습니다. 되돌아가면 진행을 잃게 하려면 별도 발동 조건과 피드백을 명시하세요. 방향만으로 규칙을 암시하지 마세요.
카약이 둑에 닿은 뒤 복구는 무엇을 바꿔야 하나요?
여기서 Recover는 위치만 바꿉니다. 0/3이면 출발점으로 돌아가고 유효 관문을 통과한 뒤에는 마지막 관문 옆 안전한 물에 놓입니다. 진행과 완료는 유지됩니다. 일부 진행을 초기화하려면 어떤 상태가 바뀌는지 정확히 적고 검사 사례를 추가하세요.
잔잔한 경로가 어떻게 명확한 목표를 줄 수 있나요?
타이머 없이 표식과 결말을 사용하세요. 이 예시의 보이는 관문 세 쌍은 다음 목적지를 보여 주고 멀리 있는 부두는 나들이의 끝을 나타냅니다. 너그러운 복구는 조향 실수 비용을 줄이고 물결 피드백은 점수 압박 없이 유효 통과를 알려 줍니다.
프롬프트가 게임 제작기에서 경로 작동을 보장하나요?
아니요. 공식 제품 페이지는 아이디어에서 플레이 가능한 결과로 이어지는 일반 흐름을 설명하지만 이 카약 규칙을 확인하거나 특정 조작, 관문, 복구 구현을 약속하지 않습니다. 실제 결과를 점검표와 비교하세요. 빌드가 없다면 프롬프트와 검사를 테스트 결과가 아니라 계획으로 설명하세요.
