세상을 설명하기 전에 정착지의 결정을 정하세요
식민지 관리 프롬프트는 건물과 자원 목록보다 결과가 따르는 선택 하나를 먼저 정의해야 합니다. 서로 경쟁하는 행동, 비용과 산출물이 처리되는 시점, 생존 및 완료 조건을 정하세요. Dayglass Outpost에서는 매일 새벽 2단위 배터리를 수경 재배 구역이나 중계 안테나 중 하나에 모두 씁니다. 구역은 식량을 생산하고 안테나는 신호를 진전시킵니다. 하루 종료 전 주민 식량을 확인합니다.
Dayglass Outpost는 이 프롬프트 구조를 가르치기 위한 가상의 지상 식민지입니다. 새벽마다 플레이어는 2단위 배터리를 수경 재배 구역 또는 중계 안테나 한 곳에 씁니다. 구역은 식량을 만들고 안테나는 신호를 진전시킵니다. 세 주민이 매일 식량 3개를 필요로 하므로 진행과 유지 사이에 선택이 생깁니다. 여기 값과 결과는 교육용 가정입니다.
첫 선택은 한 상태에서 다음 상태까지 따라갈 수 있을 만큼 작게 유지하세요. 무엇을 포기했는지 플레이어가 알기 어렵다면 주민, 연구 트리, 날씨를 추가해도 프롬프트를 확인하기 쉬워지지 않습니다.
추가 시스템을 요청하기 전에 상태 계약을 작성하세요
모든 수치에 처리 단계가 있고 행동마다 제한이 있으면 프롬프트를 구현하기 쉬워집니다. Dayglass에서는 배터리가 새벽에 초기화되고 플레이어는 이를 수동으로 모듈 하나에 모두 씁니다. 식량 검사는 모듈 처리 뒤에 옵니다. 세 주민이 하루 끝에 각각 식량 하나를 소모합니다. 식량이 3 미만이면 아무것도 차감하기 전에 실패합니다. 그 전까지 유지에 성공했고 3일째 신호가 2/2면 목표를 달성합니다.
| 규칙 | Dayglass 제안 | 첫 점검에서 보여 줄 것 |
|---|---|---|
| 시작 상태 | 1일차 새벽: 주민 3명, 식량 3, 신호 0/2. 배터리는 매 새벽 2단위로 초기화. | 선택 전에 날짜, 식량, 신호, 현재 배터리 확인. |
| 행동 제한 | 하루에 모듈 행동 하나를 정확히 선택합니다. 배터리 두 단위를 모두 쓰며 남은 전력은 이월되지 않습니다. | 한 번 선택하면 다음 새벽까지 두 모듈 모두 사용 불가. |
| 수경 재배 | 수동 작동 시 식량 6 추가. 신호 변화 없음. | 황혼 확인 전에 식량 재고가 6 증가. |
| 중계기 | 신호가 2/2 미만이면 수동 작동 시 신호 단계 1 추가. 2/2에서 선택 불가. | 중계기를 선택해야만 신호가 진행되며 식량은 생산하지 않음. |
| 황혼 식량 확인 | 모듈 처리 뒤 식량 3개 이상인지 확인합니다. 3개 미만이면 차감 전에 실패합니다. 그렇지 않으면 주민당 하나씩 총 3개를 차감합니다. | 실패 전 소비 여부를 포함한 단계 순서가 보여야 합니다. |
| 종료 및 재시작 | 3일차 식량 처리 뒤 이전에 실패하지 않았고 신호 2/2면 성공, 아니면 실패. 재시작은 1일차 전체 상태 복원. | 성공은 점수나 숨은 이벤트가 아니라 목표와 생존 검사에 연결. |
이 표는 짧은 장르 프롬프트에서 빠질 수 있는 점을 정합니다. 전력이 돌아오는 시점, 행동 분할 가능 여부, 신호 완료 뒤 재사용, 소비 전후 음식 확인을 다룹니다. 이 단계가 분명하지 않으면 같은 시나리오에 재현 가능한 입력 순서를 쓰기 어렵습니다.
기능을 더하기 전에 사흘을 손으로 계산하세요
생성기에 식민지를 만들라고 요청하기 전에 제안 규칙으로 경로를 추적하세요. 산술 계산으로 불가능한 승리 조건이나 의도치 않은 지름길을 찾아 시각 자료, 주민, 추가 자원이 원인 분석을 어렵게 하기 전에 수정할 수 있습니다.
| 일 | 행동 | 황혼 확인 전 식량 | 행동 후 신호 | 황혼 및 최종 상태 |
|---|---|---|---|---|
| 1 | 중계기 | 3 | 1/2 | 식량 3 차감. 식량 0, 신호 1/2로 종료; 식민지는 생존. |
| 2 | 수경 재배 | 6 | 1/2 | 식량 3 차감. 식량 3, 신호 1/2로 종료; 생존. |
| 3 | 중계기 | 3 | 2/2 | 식량 3 차감. 식량 0, 신호 2/2로 종료; 마지막 배급 확인 뒤 성공. |
결과는 계약에 적힌 순서에 달려 있습니다. 황혼 전에 모듈 산출물이 적용됩니다. 식량 확인 뒤 수경 재배가 실행되면 2일차 상태가 달라집니다. 다른 경로로는 수경 재배 뒤 중계기를 두 번 사용할 수 있지만 같은 제한과 성공/실패 조건을 지켜야 합니다.
이는 손으로 계산한 교육 예시이지 밸런스 테스트가 아닙니다. 미래 빌드의 예상 상태 참고로 사용하고 구현이 규칙을 따랐다는 증거로 사용하지 마세요.
과부하 프롬프트 하나 대신 단계별 세 개를 쓰세요
규칙 명확화, 구현, 수정 요청을 나누세요. 그러면 장면을 확장하기 전에 모순을 검토하고 필요한 부분만 고칠 수 있습니다. 아래는 가상 설계를 위한 시도 가능한 프롬프트이며 실행하지 않았습니다.
프롬프트 1: 규칙 표 요청
이 식민지 아이디어를 간결한 규칙 계약으로 바꾸세요. 새 시스템을 추가하지 마세요. 시작 상태: 1일차 새벽, 주민 3, 식량 3, 신호 0/2, 배터리 2. 매 새벽 배터리를 2로 초기화합니다. 플레이어는 수동 행동 하나를 정확히 선택해 배터리 두 단위를 모두 씁니다. 수경 재배는 식량 6을 더하고 신호 변화 없음. 중계기는 신호를 1 올리며 2/2에서는 사용할 수 없습니다. 모듈 효과가 처리된 다음 황혼 식량 확인을 합니다. 식량 3 이상이면 주민당 1을 빼고 계속합니다. 식량이 3 미만이면 빼기 전에 실패합니다. 3일차 식량 검사 뒤 신호가 2/2이면 성공합니다. 나머지는 실패입니다. 재시작은 초기 상태를 복구합니다. 단계별 상태 표와 불가능한 선택을 명시하세요.
다음 요청 전에 반환된 계약과 원 규칙을 비교하세요. 식량 확인을 옮기거나 남은 배터리를 유지하거나 숨은 음식 비용을 추가하면 더 큰 빌드가 아니라 규칙 표를 먼저 바로잡으세요.
프롬프트 2: 최소 프로토타입만 요청
아래 규칙 계약으로 Dayglass Outpost라는 작은 1인 지상 식민지 프로토타입을 만드세요. 간결한 거주 공간, 수경 재배 구역 하나, 중계 안테나 하나, 주민 세 명, 식량 저장고를 보여 주세요. 선택 전 날짜, 식량, 신호, 배터리를 표시합니다. 매 새벽 배터리 두 단위가 초기화되고 플레이어는 모듈 하나에 모두 씁니다. 선택된 모듈은 황혼 식량 확인 전에 처리됩니다. 주민 셋에게 식량 세 개를 공급할 수 있을 때만 계속하며 3일차 식량 확인 후 신호가 2/2면 승리합니다. 모듈 선택은 하루 한 번, 신호 상한은 2, 초기화는 전체 시작 상태로 돌아갑니다. 추가 건물, 직원, 연구, 날씨, 무작위 이벤트는 넣지 마세요.
이 프롬프트는 결정 하나와 확인 가능한 상태를 요청하며 모든 식민지 기능을 한 번에 요구하지 않습니다. 도구가 다른 결과를 반환하면 프롬프트를 바꾸기 전에 실제 결과를 기록하세요. 요청한 동작이 나타났다고 가정하지 마세요.
조용히 달라질 수 있는 규칙을 점검하세요
“작동하나요?” 같은 넓은 질문 대신 구체적인 검사를 사용하세요. 아래 목록은 미래 실제 빌드를 위한 계획이며 통과한 테스트가 아닙니다.
| 시도 | 예상 상태 | 불일치 기록 |
|---|---|---|
| 새 실행 시작. | 1일차, 식량3, 신호0/2, 배터리2. | 시작값 누락 또는 차이. |
| 중계기를 고르고 새벽 전에 수경 재배 선택 재시도. | 중계기가 배터리 모두 소모하고 신호를 1/2로 올리며 두 번째 행동 불가. | 하루에 두 행동 실행 또는 배터리 이월. |
| 1일차 중계 후 2일차 중계 다시 선택. | 2일차 황혼에 식량 0이므로 재고를 빼기 전에 실패. | 식량이 음수로 줄거나 실패 검사 뒤에도 실행 지속. |
| 사흘 동안 중계기 → 수경 재배 → 중계기. | 종료 식량은 0, 3, 0. 신호는 1/2, 1/2, 2/2. 3일차 배급 후 성공. | 손 계산과 전환 중 하나라도 차이. |
| 신호가 2/2가 된 뒤 중계기 선택 시도. | 중계기 사용 불가, 신호 상한 유지. | 신호가 2/2 초과 또는 추가 완료 단계 발생. |
| 결과 후 재시작. | 주민3, 식량3, 신호0/2, 배터리2의 1일차로 복구. | 이전 재고, 날짜, 결과 상태 잔류. |
각 검사에 실제 행동과 화면에 나타난 내용을 기록하세요. 검사할 빌드가 없다면 계획된 체크리스트로 유지합니다. 표의 예상은 게임에서 관찰한 결과와 다릅니다.
관찰에 근거한 수정 하나를 요청하세요
실제 빌드가 계약과 다르면 다음 프롬프트를 좁히세요. 한 행동, 예상값, 실제 표시값을 정확히 제시하고 해당 규칙만 바꾸도록 요청합니다. 나머지 상태는 유지하고 같은 입력 순서로 다시 확인하세요.
현재 빌드에서 관찰된 불일치: 행동: [정확한 날짜와 모듈 선택] 예상: [규칙 표의 상태] 관찰: [빌드 화면에 실제로 표시된 내용] 이 불일치 원인 규칙만 변경하세요. 다른 자원 값, 행동 시점, 종료 조건을 유지하세요. 규칙이 바뀐 이유와 같은 경로에서 확인할 방법을 설명하세요.
빌드를 실행하지 않았다면 손 계산 경로에서 관찰 내용을 채우지 마세요. 템플릿으로 남깁니다. 계산은 나중의 비교 대상을 제공하지만 실제 관찰을 대신하지 않습니다.
일반 게임 제작기에 프롬프트를 가져가세요
SEELE의 현재 Free AI Game Maker 페이지는 평이한 영어로 게임 아이디어 입력, 플레이 가능한 2D/3D 결과 검토, Workspace에서 반복 개선, 생성 전 표시된 Koin 비용과 계정 옵션 확인을 설명합니다. 이는 일반 제작 흐름이지 Dayglass의 식량 처리나 승리 조건이 구현된다는 증거가 아닙니다.
규칙 계약과 검사 표를 자신의 설계 설명으로 가져가세요. 현재 제공되는 결과를 살펴보고 예상 전환 하나와 화면 상태를 비교해 수정하거나 단순화할지 결정합니다. Free AI game maker 페이지 설명은 실제 결과를 대신할 수 없습니다.
자주 묻는 질문
첫 식민지 프롬프트에는 어떤 메커니즘이 들어가야 하나요?
시작 자원, 플레이어 행동 하나, 비용과 산출물, 처리 시점, 이후 확인 조건을 포함하세요. 순환을 닫는 승리, 실패, 재시작 규칙도 더합니다. 결정에 영향을 주지 않는 일자리, 날씨, 연구, 자동화는 뒤로 미루세요.
식민지 프로토타입은 자원 몇 개로 시작해야 하나요?
중앙 결정을 이해하는 데 필요한 자원만 사용하세요. Dayglass에는 주민 식량 공급과 중계기 완성 사이의 선택을 설명하는 식량, 배터리, 신호만 있습니다. 행동 선택, 생존 검사, 목표를 바꾸지 않는 자원은 첫 요청에서 빼세요.
생산과 소비를 명확히 보여 주려면 어떻게 하나요?
선택 전 상태, 선택된 모듈 처리 후, 황혼 확인, 최종 재고를 각각 보여 주세요. 단계를 분리하면 산출물이 늦게 들어왔는지 배급이 두 번 차감되었는지 파악하기 쉽습니다. 화면 디자인은 달라도 플레이어가 확인할 수 있어야 할 수치는 프롬프트에 지정해야 합니다.
식량 확인에 실패하면 어떻게 해야 하나요?
프롬프트 전에 실패 규칙을 고르세요. 이 예시에서는 식량 3 미만이면 어떤 것도 차감하기 전에 실패하므로 화면 상태가 규칙과 일치합니다. 다른 식민지는 부족분이나 부분 배급을 허용할 수 있지만 재고가 어떻게 변하고 실행이 계속되는지 프롬프트에서 정해야 합니다.
상세한 프롬프트가 플레이 가능한 식민지 관리 게임을 보장하나요?
아니요. 상세한 프롬프트는 요구 규칙을 확인하기 쉽게 하지만 특정 도구가 정확히 구현한다는 증거는 아닙니다. 실제 출력을 검토하고 상태 전환을 확인하며 불일치를 기록하세요. Dayglass 수치는 가상 예시이지 테스트 결과가 아닙니다.
확인 가능한 식민지 루프 하나를 만드세요
더 큰 식민지를 요청하기 전에 선택, 시점, 자원 변화, 생존 검사, 완료 조건을 작성하세요. 경로 하나를 손으로 계산하고 실제 결과를 한 번에 하나씩 살펴본 뒤 최초 불일치로 범위를 좁힌 수정을 진행합니다. 아이디어를 직접 시험할 준비가 되면 일반 제작 흐름에 계약과 검사를 적용하세요.
