분기형 내러티브 게임에는 대사보다 먼저 상태 모델이 필요합니다. 장면, 지속 변수에 영향을 주는 선택, 후속 행동을 여는 조건, 조건이 만드는 결말을 정하세요. 그런 다음 작은 이야기 한 토막을 요청하고 도달 가능한 모든 상태 조합을 확인합니다. 아래 프롬프트는 준비 행동 선택지 두 개, 불리언 플래그 두 개, 이들을 처리하는 마지막 상호작용 하나만 사용합니다.
The Last Light at Orison Observatory는 교육을 위해 만든 가상의 독창적 설계입니다. 산악 관측소, 행동 슬롯, 이야기 플래그, 중계소 작업, 결말은 글로 작성한 예시이며 제작하거나 테스트하지 않았습니다. 그래프는 기존 또는 검증된 게임의 보고가 아니라 자신의 아이디어를 위한 템플릿으로 사용하세요.
장면을 쓰기 전에 선택지를 지도에 그리세요
작은 그래프를 그리는 것부터 시작하세요. 노드는 장면이나 결정 지점, 간선은 플레이어를 다른 노드로 옮기는 행동, 상태 변수는 이후 선택이나 결과를 바꾸는 정보를 기억합니다. 각 선택의 시작 값, 허용 조건, 행동 효과, 다음 장면, 플레이어가 보는 피드백을 기록하세요.
대사가 두 경로를 다르게 들리게 해도 둘 다 같은 상태로 이어질 수 있습니다. 그래프를 쓰면 이 문제를 일찍 발견합니다. 간선이 상태를 바꾸거나 새 선택을 열거나 결말을 바꾸지 않는다면, 장식인지 결과를 만드는 분기인지 결정하세요. 캐릭터를 살리는 장식은 유지하되 문구만으로 선택의 중요성을 입증하려 하지 마세요.

이 예시는 의도적으로 작게 설계했습니다. 관측소에 들어가 준비 행동 슬롯 두 개를 사용하고, 공용 중계실로 돌아온 뒤 마지막 확정 단계에서 플래그를 처리합니다. 중계실에서 합류하면 이야기는 간결해지고 의미 있는 차이는 플래그로 이어집니다.
선택 두 개와 도달 가능한 결과 네 가지를 정의하세요
폭풍이 접근 다리를 끊기 전 플레이어에게 정확히 두 개의 선택 행동 슬롯이 있습니다. 각 슬롯에서 Archive(기록 보관소), Help(돕기), Wait(대기)를 선택합니다. Archive와 Help는 각각 슬롯 하나를 쓰며 한 번씩만 선택할 수 있습니다. Wait는 이야기 상태를 바꾸지 않고 슬롯을 소비합니다. 순서는 자유이므로 플레이어는 두 준비를 모두 마친 뒤 중계실로 돌아올 수 있습니다.
| 선택 | 조건과 비용 | 상태 변화 | 플레이어 피드백 |
|---|---|---|---|
| Archive | `logFound`가 false일 때 가능하며 슬롯 하나를 씁니다. | 보관소를 수색하고 `logFound`를 true로 설정합니다. | 오래된 신호 기록을 회수하고 보관소 경로를 닫습니다. |
| Help | `keeperTrust`가 false일 때 가능하며 슬롯 하나를 씁니다. | 회전 돔을 안정시키고 `keeperTrust`를 true로 설정합니다. | 관리인이 수동 재조정을 도울 준비가 됩니다. Help는 반복할 수 없습니다. |
| Wait | 두 슬롯에서 모두 가능하며 슬롯 하나를 씁니다. | 플래그 변화 없음. | 폭풍이 다가오지만 다리가 끊기기 전에 다른 슬롯을 사용할 수 있습니다. |
이 규칙으로 플래그 조합 네 가지에 모두 도달할 수 있습니다. 준비를 하나도 안 함, Archive만, Help만, 두 가지 모두입니다. Wait를 두면 분기를 강제로 선택하지 않고 슬롯을 남길 수 있습니다. 두 조건은 준비 행동 중복을 막지만 Archive 다음 Help, Help 다음 Archive 순서는 모두 허용합니다. 각 슬롯 뒤 같은 중계실 장면으로 돌아오게 해, 이후 결과가 도달 불가능한 경로가 아니라 상태에 따라 달라지게 하세요.
중계실에서 “체크섬 재검사”는 `logFound`가 true일 때만, “수동 재조정 요청”은 `keeperTrust`가 true일 때만 활성화됩니다. 불가능한 선택지도 짧은 이유와 함께 보이되 비활성화 상태로 둡니다. 시도해도 아무것도 바뀌지 않습니다. 중계소의 하위 작업용 플래그나 별도 행동 예산은 없습니다. 마지막 확정(Commit) 한 번으로 기존 플래그가 나타내는 작업을 처리한 뒤 송신합니다.

결말은 준비 플래그 두 개에서 바로 결정됩니다:
| `logFound` | `keeperTrust` | 확정 결과 | 결말 |
|---|---|---|---|
| false | false | 사용할 수 없음. 플레이어는 대피처로 갈 수 있습니다. | 송신하지 않습니다. 팀은 그 자리에 대피합니다. |
| true | false | 검증된 체크섬을 다시 확인한 뒤 송신합니다. | 돔이 정렬되지 않아 수신 확인이 없고 팀은 대피합니다. |
| false | true | 수동 재조정 후 송신합니다. | 호출 부호가 확실하지 않아 수신 확인이 없고 팀은 대피합니다. |
| true | true | 체크섬을 확인하고 돔을 재조정한 다음 송신합니다. | 계곡 수신기가 응답하고 팀이 구조됩니다. |
두 값이 모두 true인 경우에는 한 번의 확정으로 활성화된 두 작업을 순서대로 처리한 후 송신해야 합니다. `checksumDone`이나 `retuneDone` 같은 플래그를 추가하면 플레이어와 검토자가 추적할 숨은 상태가 늘어납니다. 여기서는 준비 플래그로 확정 단계에서 수행할 작업을 결정하기에 충분합니다. 표는 종이 위의 모델이지 실제 플레이 빌드가 이를 따른다는 증거가 아닙니다.
그래프, 이야기 한 토막, 경로 감사를 차례로 요청하세요
프롬프트 역할을 분리하세요. 먼저 모든 경로와 조건을 명시하는 상태 계약을 요청합니다. 다음으로 작은 플레이 가능 분기 하나를 요청하거나 선택한 도구가 필요한 상태를 표현하지 못한다면 구조화된 설계 전달물을 요청합니다. 마지막으로 관찰 결과를 지어내지 않고 모든 조합을 나열하는 감사를 요청합니다. 이렇게 하면 분기형 이야기 게임 프롬프트를 제작자가 확인할 수 있는 전환에 연결할 수 있습니다.
프롬프트 1: 이야기 그래프 반환
The Last Light at Orison Observatory의 분기형 이야기 게임 장면을 설계하세요. 가상의 콘셉트이며 제작하거나 테스트한 게임이 아닙니다. 폭풍이 다리를 끊기 전에 플레이어에게 준비 행동 슬롯이 정확히 두 개 있습니다. 각 슬롯에서 고를 수 있는 것은 Archive, Help, Wait뿐입니다. Archive는 슬롯 하나를 쓰고 한 번만 선택 가능하며 `logFound=true`로 설정합니다. Help는 슬롯 하나를 쓰고 한 번만 선택 가능하며 `keeperTrust=true`로 설정합니다. Wait는 슬롯 하나를 쓰며 두 플래그를 바꾸지 않습니다. 순서는 자유롭습니다. 두 슬롯을 사용한 뒤 공용 중계실로 돌아옵니다. `logFound`가 true면 체크섬을 재확인할 수 있고, `keeperTrust`가 true면 돔을 수동 재조정할 수 있습니다. 마지막 Commit은 활성화된 작업을 체크섬, 재조정 순으로 처리하고 송신을 시도합니다. 두 값이 모두 false이면 송신할 수 없고 팀은 대피합니다. 체크섬만 참이면 돔 정렬이 없어 수신 확인이 없습니다. 관리인 신뢰만 참이면 호출 부호가 없어 수신 확인이 없습니다. 두 플래그가 참이면 계곡 수신기가 신호에 답하고 팀이 구조됩니다. 네 가지 플래그 조합 모두를 표로 보여 주세요. 각 간선의 조건, 상태 변화, 다음 장면, 플레이어 피드백을 반환하세요. 장면 이동 뒤에도 플래그가 유지되는지, 허용되지 않은 행동이 상태를 바꾸지 않는지 명시하세요. 추가 플래그를 만들지 마세요.
긴 산문이 아니라 완전한 그래프 계약을 요청합니다. Wait가 어느 슬롯에서든 사용 가능한지, 두 준비 행동을 어느 순서로든 할 수 있는지, 중계실이 하나의 공용 상태로 돌아오는지 확인하세요. “둘 다 안 함” 사례가 도달 불가능하거나 별도 중계소 작업 플래그가 추가되면 대사나 그림을 요청하기 전에 계약을 바로잡으세요.
프롬프트 2: 이야기 장면 하나 제작 요청
아래 승인된 상태 계약으로 간결한 내러티브 게임 장면 하나를 만드세요. 관측소 입구, Archive 장면, Help 장면, 공용 중계실, 플래그가 모두 false인 경우의 대피 선택지를 보여 주세요. 준비 슬롯은 정확히 두 개입니다. 각 슬롯에서 Archive, Help, Wait를 표시하세요. `logFound`가 true가 된 뒤 Archive를 비활성화하고 `keeperTrust`가 true가 된 뒤 Help를 비활성화하세요. 경로 순서는 자유롭게 유지합니다. 중계실에서는 두 플래그를 보여 주고 체크섬 재확인 또는 수동 재조정이 비활성화된 이유를 설명하세요. 마지막 Commit의 작업 순서는 체크섬, 수동 재조정, 송신입니다. 화면 전환 뒤에도 상태를 유지하고 재시작 시 두 플래그를 모두 false로 초기화하세요. 추가 플래그나 행동 슬롯을 만들지 마세요. 대화와 함께 상태 표시, 선택 가능/불가 피드백, 확정 후 결과를 반환하세요.
대화와 함께 상태 표시도 요청하세요. 이 장면에서 독자는 어떤 준비가 끝났는지, 작업이 왜 비활성화되었는지, 확정이 실제로 무엇을 하는지 알아야 합니다. 프롬프트에 요구사항이 있다는 사실만으로 특정 제작 도구가 이를 구현한다고 입증되지는 않습니다. 분기 대화가 지속 상태와 같다고 가정하지 말고 반환된 상호작용을 계약과 비교하세요.
프롬프트 3: 경로 열거와 실제 관찰 비교
이야기 그래프를 상태 계약과 대조해 감사하세요. 플레이테스트 결과를 지어내지 마세요. 다음 중계실 초기 상태 네 가지를 열거하세요: 1. `logFound=false`, `keeperTrust=false` 2. `logFound=true`, `keeperTrust=false` 3. `logFound=false`, `keeperTrust=true` 4. `logFound=true`, `keeperTrust=true` 각 상태에 대해 Commit 사용 가능 여부, 처리할 작업과 순서, 송신 여부, 결말을 보고하세요. Archive, Help, Wait를 이용해 준비 슬롯 두 개로 모든 조합에 도달할 수 있는지 확인하세요. 플래그 초기화와 비활성 작업을 시도했을 때 상태 불변인지 확인하세요. 실제 관찰 기록이 제공되지 않았다면 관찰 결과 칸은 비워 두고 예상만 적으세요.
감사 프롬프트는 부족한 증거가 무엇인지 모델에 알려 줍니다. 테스트 전에는 예상 전환과 점검표를 반환할 수 있습니다. 실제 관찰 후에는 그 순서를 종이 모델과 비교하고 범위를 제한한 수정 하나를 요청할 수 있습니다. 하지만 프롬프트만으로 동작을 사실대로 인증할 수는 없습니다.
| 프롬프트 단계 | 입력 | 출력 | 수용 기준 |
|---|---|---|---|
| 그래프 | 장면, 슬롯, 선택, 플래그, 조건, 결말 | 노드/간선/상태 계약 | 네 조합 모두 도달 가능하고 정의되어 있음. |
| 장면 제작 | 승인된 그래프와 표시 상태 요구사항 | 간결한 상호작용 순서 또는 설계 전달물 | 조건부 행동, 비활성 이유, 확정 순서, 초기화가 분명함. |
| 경로 감사 | 예상 조합표와 가능한 관찰 결과 | 경로 열거와 최초 불일치 | 관찰하지 않은 동작은 미관찰로 표시. |
막다른 경로와 의미 없는 선택을 찾으세요
초기 상태에서 그래프를 따라가며 각 조합에 합법적인 경로가 있는지 확인하세요. 이어서 결과 장면이 상태 표에서 예측한 결과를 보여 주는지 확인합니다. 관측소에서 의도한 두 플래그 모두 참인 결말은 작성된 규칙에서 가능한 결과이지 측정된 결과가 아닙니다.

| 증상 | 먼저 점검할 규칙 | 다음 확인 |
|---|---|---|
| 플레이어가 두 플래그 참 상태에 도달할 수 없습니다. | 슬롯 수 또는 경로 복귀. | Archive와 Help가 각각 두 슬롯 중 하나를 쓰고 어느 순서든 공용 중계실로 돌아오는지 확인합니다. |
| Archive 또는 Help를 반복할 수 있습니다. | 한 번만 허용하는 조건. | 플래그가 참이 된 뒤 해당 선택을 비활성화하고 시도해도 상태가 바뀌지 않는지 확인합니다. |
| 비활성 중계 옵션이 여전히 작동합니다. | 행동 조건과 무효 동작 처리. | 옵션은 보이되 비활성화하고 시도해도 두 플래그가 유지되는지 확인합니다. |
| 두 플래그가 참인데 Commit이 재조정을 건너뜁니다. | Commit 작업 순서. | 한 번의 상호작용에서 체크섬, 수동 재조정, 송신을 그 순서로 처리합니다. |
| Commit 뒤 잘못된 결말이 표시됩니다. | 결말 조건. | 조합표 네 행에 따라 `logFound`와 `keeperTrust`만 평가합니다. |
| 재시작 뒤 이전 준비 상태가 남아 있습니다. | 상태 초기화. | 두 플래그를 false로 돌리고 준비 슬롯 두 개를 복구합니다. |
가장 먼저 어긋난 지점에 따라 무엇을 바꿀지 결정하세요. 결과에 도달할 수 없다면 결말 대사를 수정하기 전에 그래프나 슬롯 규칙을 바로잡습니다. 상태는 맞지만 비활성 선택지가 혼란스럽다면 그 옆의 이유를 개선하세요. 네 전환 모두 계약과 일치할 때 상태 모델을 바꾸지 않고 이야기의 세부 묘사를 더합니다.
작성한 그래프를 첫 제작 시도로 옮기세요
그래프가 일관된 뒤에는 자연어로 범위를 좁힌 설명을 작성해 게임 아이디어를 탐색할 수 있습니다. SEELE의 현재 Free AI Game Maker 페이지는 평이한 영어 설명, 플레이 가능한 2D 또는 3D 결과 검토, Workspace에서의 반복 개선, 표시된 생성 비용과 계정 옵션 확인을 안내합니다. 이 일반 흐름은 지속 이야기 플래그, 조건부 서사 행동, 관측소 설계를 확인해 주지 않습니다.
노드/간선 표와 결말 네 행 조합표를 제작 요청에 포함하세요. 그런 다음 반환된 실제 상태, 선택, 피드백, 재시작 동작을 점검합니다. 특정 조건이 빠졌다면 표현해 달라고 요청하고 다시 확인하세요. 선택한 흐름에서 지속 플래그를 표시할 수 없다면 그래프를 설계 전달물로 유지하고 플레이 가능하다고 설명하기 전에 적합한 도구에서 평가하세요.
그래프가 견고해진 뒤 이야기 깊이를 더하세요
대사를 더 쓰려고 세 번째 플래그를 추가하지 마세요. 현재 플래그 두 개가 네 조합 모두로 구성될 수 있고, 중계 선택이 이에 반응하며, Commit이 정해진 순서를 따르고, 초기화가 시작 상태를 복원하는지 먼저 확인하세요. 기존 그래프로 표현할 수 없는 의미 있는 선택을 만들 때만 장면이나 변수를 하나 추가합니다. 그러면 겉으로만 다르게 읽히고 플레이는 똑같은 경로를 늘리는 대신 새로운 분기를 결과와 연결할 수 있습니다.
자신의 이야기 계약이 준비되면 간결한 그래프를 Free AI game maker에 넣고 실제 결과가 무엇을 표현하는지 살펴보세요. 상태 전환은 한 번에 하나씩 수정합니다.
자주 묻는 질문
분기 이야기에는 선택지를 몇 개 두고 시작해야 하나요?
가르치려는 결정을 표현하는 데 필요한 최소 개수로 시작하세요. 이 예시에서는 선택 행동 두 개로 네 조합을 만들며, 서로 독립된 플래그와 조건부 결과를 보여 주기에 충분합니다. 현재 상태로 표현할 수 없는 의미 있는 선택이나 결과를 바꾸는 경우에만 변수를 추가하세요.
분기 경로가 다시 합쳐져도 되나요?
네. 중요한 상태를 다시 사용할 수 있다면 경로는 공용 장면으로 돌아올 수 있습니다. 관측소의 Archive와 Help 경로는 모두 중계실로 돌아오며 두 플래그가 가능한 작업을 결정합니다. 합류하면 장면 그래프를 간결하게 유지하면서 후속 선택과 결말의 차이는 보존할 수 있습니다.
비활성화된 이야기 선택지는 어떻게 동작해야 하나요?
선택지를 계속 표시하고, 빠진 조건을 짧고 정확하게 설명하며, 사용할 수 없는 행동을 시도해도 아무 변화가 없어야 합니다. 예를 들어 기록을 찾지 못했을 때 “체크섬 재검사”를 비활성화할 수 있습니다. 설명은 플래그를 바꾸지 않고 플레이어에게 필요한 정보나 행동을 알려 줘야 합니다.
결말을 전부 확인해야 하나요?
일부 경로가 앞선 장면을 공유하더라도 선택한 상태 변수 조합을 전부 점검하세요. 불리언 플래그 두 개라면 조합은 네 가지입니다. 각 경로에 도달할 수 있는지, 조건부 행동과 순서가 규칙에 맞는지, 다음 실행 전에 초기화가 변수를 지우는지 확인하세요.
Orison Observatory 이야기는 테스트되었나요?
아니요. 관측소, 준비 행동 슬롯 두 개, 중계소 작업, 결말 네 가지는 종이 위에서 만든 독창적인 설계입니다. 이 페이지의 프롬프트와 이미지는 제작된 게임이나 플레이테스트를 보여 주지 않습니다. 결과를 테스트했다고 표현하기 전에 자신의 빌드에서 얻은 관찰 결과로 경로 감사를 진행하세요.


