우주 식민지 게임 규칙을 첫 빌드 브리프로 전환

우주 식민지 게임 AI 프롬프트는 짧은 생존과 생산 순환 하나로 시작하면 확인하기 쉽습니다. 자원, 행동 비용, 타이밍, 승리 조건부터 정의한 뒤 작은 플레이 장면과 예상 추적을 비교하는 방법을 요청하세요. 이 글은 재사용 가능한 미실행 프롬프트 템플릿 세 개와 Kestrel Relay Shift라는 손 계산 허구 예시를 제공합니다. 수치는 게임 단위이지 공학 데이터가 아닙니다. 프롬프트를 실행하지 않았고 빌드나 플레이테스트를 주장하지 않습니다. 이 추적은 향후 빌드를 위한 종이 수용 목표이지 이미 존재하는 증거가 아닙니다.

세계를 요청하기 전에 식민지 범위를 정하세요

전초기지 하나, 자원 세 개, 목표 하나로 시작하세요. Kestrel Relay Shift에서 플레이어는 세 교대 동안 공기, 전지, 얼음을 관리한 뒤 통신 비콘을 조립합니다. 이는 분명한 설계 질문을 만듭니다. 마지막 교대가 끝나기 전에 공기가 0을 넘도록 유지하고 알맞은 재료를 모아 조립 비용을 낼 수 있을까요?

첫 요청은 의도적으로 작게 유지하세요. 연구 트리, 돌아다니는 승무원, 무작위 폭풍, 여러 서식지, 주변 지도를 넣으면 상태가 늘어 불일치의 원인을 설명하기 어렵습니다. 첫 버전에는 얼음 채굴기, 공기 필터, 비콘 조립 지점, 작은 서식지만 필요합니다. 플레이어는 한 화면에서 목표를 이해하고 자원 막대로 행동 결과를 판단할 수 있습니다.

이 장면은 설계 목표입니다. 조작자가 Mine을 선택하고 최대 두 개 작업 슬롯 중 하나가 차며 공기는 3으로, 전지는 3으로 유지되는 동안 얼음은 0에서 1로 바뀝니다. 유용한 장면 프롬프트는 “현실적인 달 기지”라고만 하지 않고 이 상태 전이를 지정합니다. 그러면 플레이어의 다음 선택도 분명해집니다. 얼음을 더 모을지, 나중에 공기를 걸러낼지, 작업 지시 하나를 남길지.

장면보다 먼저 규칙을 작성하세요

모델에 방을 만들거나 아트를 추가하라고 하기 전에 간결한 계약을 작성하세요. 각 자원의 시작값과 상한을 주고 행동 비용, 변화, 수동 효과 시점, 실패 검사 시점을 적습니다. 필요한 비용이 없는 주문은 부분 효과 없이 거부되는지도 명시하세요. 그래야 프롬프트가 구현에 필요한 결정을 암묵적으로 남기지 않습니다.

Kestrel은 추상값을 씁니다. NASA의 ECLSS 개요는 실제 대기압, 산소 농도, 환기, 폐기물 관리, 물 공급 같은 기능을 설명합니다. 이는 생명 유지 테마의 유용한 어휘지만 여기 허구의 공기 계량기, 조합식, 자원 상한, 태양광 일정의 근거는 아닙니다.

참조 표는 “주문이 무엇을 하는가?”에 답하며 예시 타이밍과 섞지 않습니다. Filter를 거부하면 아무것도 바뀌지 않습니다. 낼 수 있는 자원 하나만 먼저 쓰고 나머지가 부족해 실패하지 않습니다. 짧은 문장 하나로 흔한 상충 해석을 없앱니다.

전체 순서는 해당 교대 태양광을 적용하고 작업 지시를 최대 두 개 받으며 선택한 각 지시를 다음 선택 전에 처리한 뒤 플레이어가 선택하면 End Shift를 처리합니다. End Shift는 교대 초 또는 완료한 지시 뒤 선택할 수 있으며 작업 지시가 아닙니다. 교대 3 끝에는 비콘이 조립됐고 공기가 1 이상일 때만 승리합니다. 이 교육 계약에는 숨은 사건이나 무작위 주사위가 없습니다.

세 교대 시나리오를 손으로 추적하세요

합법 경로 하나와 부정 사례 하나를 포함하면 프롬프트를 평가하기 쉽습니다. 다음 표는 선택한 행동 뒤 각 교대의 공기 감소 뒤 상태를 기록합니다. 전지와 얼음에는 상한이 있으므로 위 규칙으로 예상 상태를 재현할 수 있습니다.

첫 교대는 작업 지시 두 개를 쓰고 마지막 교대는 하나만 씁니다. 두 개는 최대치이지 의무가 아니므로 마지막 행동 뒤 End Shift를 고를 수 있습니다. 부정 검사도 유용합니다. 초기 상태에서 Filter를 고르면 얼음이 0이라 거부해야 하며 공기 3, 전지 2, 얼음 0이 변하지 않아야 합니다.

이 메커니즘 장면은 교대 2의 Filter 처리 직후 상태입니다. 계량기 변화는 행동이 단순히 “좋거나 나쁜” 것이 아님을 보여 줍니다. 공기는 2 올리지만 전지와 얼음은 각각 1을 씁니다. 이후 Mine이 마지막 조립에 필요한 얼음을 복구합니다. 향후 프로토타입은 필터 애니메이션이 그럴듯한지만 보지 말고 이러한 전이를 기준으로 확인해야 합니다.

역할이 다른 프롬프트 세 개를 사용하세요

긴 프롬프트 하나로 규칙 창작, 장면 구성, 전체 구현, 자체 평가를 모두 요청하지 마세요. 각 결과에 분명한 수용 검사가 생기도록 작업을 나눕니다. 아래 템플릿은 허구 계약의 복사 가능한 시작점입니다. 실행하지 않았으며 샘플 출력은 손으로 쓴 기대값이지 모델 응답 결과가 아닙니다.

템플릿 A: 규칙 고정

Kestrel Relay Shift라는 간결한 우주 식민지 게임 규칙 계약을 설계하세요.
다음 허구 상태만 사용: 공기 3/6, 전지 2/4, 얼음 0/3, 비콘 미조립; 교대 3회; 교대마다 작업 지시 최대 2개.
작업 지시 전에 교대 1과 3에서만 전지 1을 더하고 최대 4로 제한하세요.
Mine은 작업 지시 1개를 쓰고 얼음 1을 더하며 최대 3입니다.
Filter는 얼음 1과 전지 1을 쓰고 공기 2를 더해 최대 6으로 제한합니다. 비용 중 하나라도 부족하면 상태 변화 없이 거부하세요.
Assemble Beacon은 얼음 2와 전지 1을 쓰고 비콘 상태를 한 번만 조립 완료로 바꿉니다. 반복할 수 없습니다.
End Shift는 작업 지시가 아닙니다. 플레이어가 선택한 뒤 공기가 1 감소하며 공기 0이면 즉시 패배합니다. 교대 3 뒤 비콘이 조립됐고 공기가 1 이상일 때 승리합니다.
상태 표, 행동 표, 턴 순서 목록, 모순 또는 모호성을 반환하세요. 폭풍, 자원, 건물, 행동을 임의로 만들지 마세요.

기대 출력은 시작 상태, 상한, 행동 비용, 태양광 시점, End Shift 시점, 종료 조건을 그대로 유지하는 간결한 규칙 계약입니다. 숫자를 바꾸거나 작업 지시 두 개를 의무화하거나 행동 전에 공기를 낮추거나 거부된 Filter에 일부 비용을 부과하지 않아야 수용합니다. 추가 메커니즘을 제안하면 기준선에 조용히 넣지 말고 요청에서 제거하세요.

템플릿 B: 플레이 장면 하나 요청

승인된 Kestrel Relay Shift 규칙 아래에서 새 규칙 체계가 아니라 작은 플레이 장면 하나를 지정하세요.
[승인된 규칙 계약을 붙여 넣으세요.]
우주복을 입은 조작자, 서식지, 얼음 채굴기, 공기 필터 콘솔, 비콘 조립 지점을 간결한 전초기지 한 곳에 보여 주세요. 읽기 쉬운 3인칭 카메라와 상태 표시 한 화면을 사용하세요.
태양광 충전 뒤 교대 1 시작: 공기 3/6, 전지 3/4, 얼음 0/3. 플레이어가 Mine을 선택합니다. 얼음이 1/3이 되고 최대 두 작업 슬롯 중 하나가 채워지며 다른 자원은 그대로 있게 하세요.
장면 설명, 보이는 상호작용, 이전/이후 상태, 플레이어의 다음 선택을 반환하세요. 인터페이스 문구는 간결하게 유지하고 시스템을 추가하지 마세요.

기대 출력은 선택한 채굴기, Mine 행동, 얼음 0→1 변화를 식별할 수 있는 화면 규모의 장면입니다. 지정 자원이 유지되고 즉각적인 행동 결과가 있으며 다른 작업 지시나 End Shift를 할 여지가 있어야 수용합니다. 상호작용 물체가 가려지는 멋진 풍경만으로는 부족하고 플레이 공간 없는 상태 패널도 부족합니다.

템플릿 C: 고정 추적 검증

다음 Kestrel Relay Shift 규칙 계약을 아래 예상 추적과 대조해 확인하세요.
[승인된 규칙 계약을 붙여 넣으세요.]
교대 1 뒤 예상: 공기 2, 전지 3, 얼음 2, 비콘 미조립.
교대 2 뒤 예상: 공기 3, 전지 2, 얼음 2, 비콘 미조립.
교대 3 뒤 예상: 공기 2, 전지 2, 얼음 0, 비콘 조립. 승리.
초기 상태 공기 3, 전지 2, 얼음 0에서 Filter도 시도하세요. 상태 변화 없이 거부되어야 합니다.
각 전이를 입력 상태, 주문, 비용, 출력 상태, 통과/실패로 반환하세요. 규칙과 예상값이 다르면 최초 불일치를 표시하고 어느 출처를 따라야 하는지 물으세요. 계약을 조용히 다시 쓰지 마세요.

기대 출력은 행별 비교와 초기 Filter 거부입니다. 비용이 각각 한 번 적용되고 교대마다 지정 시점에 공기가 감소하며 첫 불일치를 덮어쓰지 않고 이름 붙여야 수용합니다. 실제 빌드에 이 템플릿을 사용하면 빌드에서 관찰한 상태를 추가하세요. 그전에는 “예상”은 손 계산이지 관찰값입니다.

템플릿은 계약 고정, 계약 안 장면 요청, 추적 비교 순으로 작동합니다. 다음 프롬프트로 옮길 때 규칙 문구를 동일하게 유지하세요. 비용을 바꾸면 비교가 움직이는 목표가 아니라 규칙 하나의 변경을 측정하도록 예상 상태를 먼저 갱신하세요.

결과 장면은 종이 통과 조건을 보여 줍니다. 돛대 신호, 조작자의 사용한 행동 슬롯 하나, 손 추적 끝 상태와 일치하는 자원이 보입니다. 향후 장면 프롬프트를 위한 시각 목표이지 생성 빌드가 이 상태에 도달했다는 증거는 아닙니다.

전체 게임 대신 첫 불일치를 진단하세요

향후 빌드가 종이 추적과 다르면 처음으로 어긋난 상태에서 멈추세요. 행동, 이전/이후 자원 상태, 교대 번호, 태양광이나 End Shift가 처리됐는지 기록합니다. 그런 다음 해당 전이를 책임지는 규칙만 고치세요. 전체 프롬프트를 “더 잘 작동하게” 반복하면 서로 무관한 동작이 바뀌어 다음 결과를 비교하기 어려워질 수 있습니다.

이 진단 표는 증상을 먼저 확인할 규칙과 연결합니다. 실제 빌드라면 스크린샷이나 구조화된 이전/이후 기록을 보존하고 빌드 리비전과 함께 표시하세요. 이 글의 손 계산 예시는 비교할 관찰 빌드가 없습니다. 방법을 완성된 것처럼 보이게 하려고 관찰값을 만들지 마세요.

게임 제작 워크플로에 계약을 전달하세요

규칙과 예상 상태를 적은 뒤 누가 행동하고 플레이어가 무엇을 하며 무엇이 변하고 결과에 무엇이 보여야 하는지를 짧은 게임 아이디어로 바꾸세요. 현재 Free AI Game Maker 페이지는 쉬운 영어 입력, 2D/3D 플레이 가능한 첫 버전, 브라우저 테스트, 후속 프롬프트 개선을 설명합니다. 이는 일반 워크플로 사실이며 Kestrel의 정확한 규칙이 지켜질 것이라는 보장은 아닙니다.

작은 첫 단계에서는 읽기 쉬운 주문 하나와 즉각적인 상태 피드백을 요청하세요. 실제 표시를 검토해 계약과 비교한 뒤 초점 있는 수정 하나를 요청할지 결정합니다. 제출 전에 Workspace에서 선택 모델, 사용 가능한 Koin 잔액, 표시 생성 비용을 확인하세요. 이 글의 추적은 살펴볼 목표를 주는 준비 도구이지 결과 확인을 대신하지 않습니다.

Free AI game maker

확인할 수 있는 규칙 하나로 시작하세요

유용한 우주 식민지 프롬프트는 범위가 명확한 순환, 정확한 자원 비용, 턴 타이밍, 통과 조건으로 시작합니다. 계약을 쓰고 장면 하나를 요청한 뒤 향후 상태를 손 계산 추적과 비교하세요. 어긋나면 최초 불일치 규칙을 고치고 같은 순서를 반복합니다. Kestrel은 허구의 종이 예시일 뿐이지만 식민지 시스템을 더하기 전 다음 실제 프로토타입의 목표를 명확히 합니다.

자주 묻는 질문

첫 우주 식민지 게임 프롬프트에는 무엇이 들어가야 하나요?

목표 하나, 시작 상태, 자원 상한, 합법 행동, 정확한 비용과 효과, 행동 순서, 턴 종료 압박, 승패 조건을 넣으세요. 예상 경로와 거부 행동 검사도 하나씩 추가하세요. 전이가 쉽게 확인될 때까지 다른 시스템을 제외합니다.

AI 도구가 플레이 가능한 Kestrel 게임을 생성했나요?

아니요. Kestrel은 독창적인 허구 규칙 연습이며 세 교대 경로를 손으로 계산했습니다. 이 글의 프롬프트는 실행하지 않은 템플릿입니다. 생성 빌드, 플레이 가능한 결과, 플레이테스트, 관찰된 플레이어 행동을 주장하지 않습니다.

규칙, 장면, 검증 프롬프트를 왜 분리하나요?

각 프롬프트는 역할 하나만 맡습니다. 규칙 프롬프트는 비용과 타이밍을 명확히 하고 장면 프롬프트는 제한 안에서 보이는 플레이어 행동을 요청하며 검증 프롬프트는 예상 상태를 비교합니다. 나누면 문제 원인이 모호한 규칙인지, 읽기 어려운 장면인지, 추적 불일치인지 찾기 쉽습니다.

Filter에 자원이 부족하면 어떻게 되나요?

작성된 Kestrel 규칙에서는 얼음 1과 전지 1이 모두 있어야 Filter가 실행됩니다. 거부는 일부 상태를 바꾸지 않습니다. 공기, 전지, 얼음은 그대로 유지됩니다. 이는 프롬프트에 직접 써서 빌더가 추측하지 않게 해야 하는 허구 설계 선택입니다.

식민지 프롬프트가 너무 큰지 어떻게 알 수 있나요?

검토자가 현재 상태, 플레이어의 가능한 행동, 행동 하나 뒤 예상 결과를 말할 수 없다면 첫 요청에 시스템이 너무 많이 들어갔을 가능성이 있습니다. 한 화면과 짧은 추적이 핵심 순환을 설명할 때까지 메커니즘을 줄이고 순환이 명확해진 뒤 새 시스템을 더하세요.