플레이어가 편집할 수 있는 칸, 자원 변화, 배치 블록의 지지 조건, 승리 판정을 명시하면 복셀 건축 프롬프트를 확인하기 쉽습니다. 수정 가능한 세계 하나로 시작하고 채굴과 배치를 정확히 정의한 다음 범위가 제한된 구현을 요청하세요. 나중에 빌드가 생기면 정해 둔 검사와 비교합니다.
이 가이드는 Mosslight Span이라는 독창적 1인용 다리 건설 연습을 사용합니다. 지도와 규칙, V0/V1 비교는 직접 만들고 손으로 계산한 교육 자료입니다. 세 프롬프트는 템플릿이며 실행하지 않았고 게임 생성이나 플레이테스트도 없습니다.
실용적인 산출물은 짧은 순서입니다. 편집할 세계 하나를 정의하고 채굴과 배치를 명확히 한 뒤 구현 하나를 요청하고, 나중의 빌드가 명시된 검사와 맞는지 비교합니다.
작고 편집 가능한 세계를 정하세요
첫 복셀 범위에는 목적지, 장애물, 자원 선택, 종료 신호가 필요합니다. Mosslight Span은 좁은 협곡 하나에서 이를 다룹니다. 탐험가는 안정된 시작 플랫폼에서 건너편 등대까지 가야 합니다. 다리 칸은 세 개지만 시작 블록은 둘뿐입니다. 옆에 노출된 예비 블록 하나를 회수할 수 있는지가 차이를 만듭니다.
시작 장면은 성공 결과가 아니라 설계 선택을 보여 줍니다. 빈칸은 세 개인데 블록은 둘뿐이므로 자원 예산을 바꾸거나 예비 블록 회수 행동을 추가해야 합니다.
나머지 범위는 고정하세요. 협곡의 세 칸만 블록 배치를 허용합니다. 블록은 가까운 플랫폼이나 이미 지지되는 다리 줄과 면으로 이어져야 합니다. 영구 지형은 채굴하거나 덮을 수 없습니다. 시작 인벤토리는 블록 둘, 예비 자원 활성 상태는 한 번의 Mine 행동으로 기록합니다.
이 제한은 요청한 행동을 눈에 보이는 상태에 연결해 프롬프트를 개선합니다. “복셀 세계”만으로는 지도, 상호작용 거리, 건설 경계, 목표, 블록의 물리적 지지 여부를 알 수 없습니다.
채굴, 배치, 지지 규칙을 작성하세요
채굴, 배치, 이동 같은 말은 정확한 상태 변화를 정의해야 합니다. 이 종이 예시에서 채굴은 노출된 예비 블록을 대상으로 하는 단일 행동입니다. 플레이어 위치나 지형 높이는 바뀌지 않고 블록 하나가 인벤토리에 추가됩니다. 배치는 빈 협곡 칸 하나에 블록 한 개를 놓으며, 지지를 확인한 뒤 인벤토리에서 차감합니다. 이동은 지지된 표면의 직교 칸 하나로만 가능합니다.
| 행동 | 유효 대상 및 비용 | 확인할 상태 변화 |
|---|---|---|
| 예비 블록 채굴 | (0,1)에서 상호작용 높이에 면으로 인접한 노출 블록 (0,0,y=1)만 대상. 행동 1회. | 예비 블록이 사라지고 인벤토리 +1. 탐험가는 (0,1)에 그대로 있음. |
| 다리 블록 배치 | z=1의 빈 협곡 x=1,2,3 중 하나. 시작 플랫폼 또는 지지된 줄과 면으로 연결되어야 함. | 인벤토리 -1, 지지된 연속 줄이 한 칸 늘어남. |
| 이동 | 지지된 표면에서 직교 방향 한 칸만 이동. | 플레이어 위치 변경. 다리 완성 후 (4,1)에 들어가면 등대가 켜지고 승리. |
순서가 중요합니다. 지지되지 않은 공중에 배치할 수 있으면 자원 퍼즐이 사라집니다. 어디서든 채굴할 수 있으면 예비 블록 위치가 중요하지 않습니다. 상호작용 거리, 지지, 비용, 위치 변경 여부를 빌드 요청 전에 계약으로 정하세요.
기작 이미지는 시작 지점에서 이동 없이 예비 블록을 회수한 뒤 x=1과 x=2에 배치한 상태입니다. 탐험가는 시작 플랫폼에 있고 돌 하나를 더 놓아야 합니다.
세 프롬프트를 순서대로 작성하세요
하나의 요청에 규칙 발명, 세계 제작, 성공 평가를 모두 맡기지 마세요. 각 요청에 명확한 입력과 산출물을 주세요. 첫 요청은 계약을 확정하고, 두 번째는 최소 루프를 구현하며, 세 번째는 실제 관찰 뒤에만 수정합니다. 요청 사이에 좌표와 비용을 바꾸지 마세요.
프롬프트 1: 구현 전 규칙 확정
게임 이름 {game_name}, 격자와 시작점 {grid_and_start}, 목표 {goal}, 시작 인벤토리 {inventory}를 사용하는 작은 1인용 복셀 건축 루프를 설계하세요. 편집 가능한 블록과 영구 지형을 구분하세요. 채굴 대상, 상호작용 거리와 비용, 배치 가능한 칸, 면 지지 조건, 이동 범위, 승리 조건, 재시작 상태를 정의하세요. 먼저 상태 스키마, 행동 전제조건과 전이 순서를 간결한 표로 반환하세요. 아직 구현하지 말고 지형이나 아이템을 추가하지 마세요.
Mosslight Span에서는 다섯 칸 교차로, x=4의 꺼진 등대, 시작 블록 두 개를 입력하세요. 예비 블록은 시작 (0,1)에서 상호작용 높이로 면에 맞닿은 (0,0,y=1)에 있다고 지정합니다. 플레이어는 이동하지 않고 Mine 행동 한 번으로 이를 회수할 수 있습니다. 채굴 전후 위치와 인벤토리를 확인하고 V0와 V1에서 같은 규칙표를 사용하세요.
프롬프트 2: 최소 루프만 요청
승인된 복셀 규칙 계약 {approved_contract}만 구현해 간결하고 플레이 가능한 루프 하나를 만드세요. 모든 좌표, 인벤토리 수량, 행동 비용을 그대로 유지하세요. (0,1)에서 노출된 예비 블록을 한 행동으로 채굴하고, 지원 조건을 충족하는 x=1,2,3에 블록을 놓고, 지지된 블록에서 직교 이동하며, x=4 목적지 진입 시 승리 표시를 보여 줍니다. 불가능한 채굴과 지지되지 않은 배치를 거부하고 위치, 지형, 인벤토리가 바뀌지 않게 하세요. 시작 상태를 재설정하는 버튼을 제공하세요. 실행 방법을 반환하고 각 검사를 실제 실행하기 전까지 미검증으로 표시하세요.
루프 하나로 제한하는 것은 설계 선택이지 생성기가 정확히 구현한다는 보장이 아닙니다. 자원과 지지 규칙이 보이면 나중에 창작자가 경치를 추가할 수 있습니다. 경계 밖 채굴, 공중 배치, 지원되지 않는 목표 셀, 재시작의 정확한 상태를 각각 확인하세요.
프롬프트 3: 관찰 후에만 수정
승인된 예상 상태: {expected_state}. 사람이 제공한 실제 관찰: {observed_state_or_blank}. 제공된 관찰만 예상 규칙과 비교하세요. 관찰이 비어 있으면 모든 검사를 미검증으로 표시하고 결과를 만들지 마세요. 한 검사에 차이가 있으면 처음 달라진 상태를 식별하고 관련 규칙 하나만 좁게 수정하도록 제안하세요. 나머지 좌표, 비용, 조작은 유지하고 변경 영향을 받는 검사만 다시 실행 목록에 넣으세요. 실행하지 않은 통과를 주장하지 마세요.
이 세 번째 프롬프트는 결과를 꾸며 내지 않도록 합니다. 나중에 빌드가 블록 두 개에서 멈춘다면 시작 인벤토리, 예비 블록 대상, 배치 순서, 남은 인벤토리, x=3 반응을 기록해야 유용한 관찰이 됩니다. 빈 로그만 있다면 올바른 상태는 미검증입니다.
다리 자원 루프를 손으로 확인하세요
허구의 비교에서 바꾸는 변수는 하나입니다. V1은 노출 예비 블록을 추가하고 V0에는 없습니다. 시작 인벤토리와 경로를 포함한 나머지는 같습니다. 표는 V0가 두 블록으로 세 칸을 채우지 못하고 V1이 추가 Mine 한 번으로 연결을 완성하는 이유를 보여 줍니다.
| 버전 및 행동 | 채운 다리 칸 | 인벤토리 | 수동 계산 결과 |
|---|---|---|---|
| V0 시작 | 0 | 2 | 예비 블록이 없음. |
| V0: x=1, x=2 배치 | 2 | 0 | 두 블록은 지지됐지만 x=3은 비어 있음. |
| V0: x=3 배치 시도 | 2 | 0 | 인벤토리가 비어 거부됨. 건너편 플랫폼에 닿지 못함. |
| V1: 시작점에서 이동 없이 채굴 | 0 | 3 | 면에 붙은 예비 블록이 사라지고 인벤토리 2에서 3으로 변경. |
| V1: x=1, x=2, x=3 배치 | 3 | 0 | 각 블록은 시작 플랫폼 또는 지지된 줄과 연결됨. |
| V1: x=0→1→2→3→4 이동 | 3 | 0 | 지지된 네 번의 이동으로 건너편에 도착하고 x=4 진입 시 등대가 켜짐. |
V1 전체 경로는 Mine 1회 + Place 3회 + Move 4회 = 총 8행동입니다. 마지막에는 세 칸이 연속 연결되고 인벤토리는 비며 탐험가는 건너편 플랫폼에 있고 등대가 켜집니다. 이는 규칙에 대한 손계산이지 게임 결과가 아닙니다.
나중에 버전을 만들면 종료 장면뿐 아니라 이벤트 순서도 확인하세요. 배치 전에 예비 블록을 회수하고, 다리를 건너기 전에 세 번 배치하며, 네 번째 이동에서만 등대가 켜져야 합니다. 등대가 일찍 켜지거나 인벤토리가 불가능한 수치가 되면 첫 상태 차이를 기록하세요.
향후 빌드를 실제 관찰과 비교하세요
유용한 수락 목록은 시작 상태, 행동 하나, 예상 변화를 명시합니다. 먼저 (0,1)에서 한 번 Mine을 수행해 (0,0,y=1)의 노출 블록만 회수되고 플레이어가 움직이지 않는지 확인하세요. (0,0,y=2)의 블록은 상호작용 높이 밖이므로 바뀌면 안 됩니다. 그런 다음 빈칸 x=1에 놓고, 인벤토리 차감과 플랫폼 연결을 확인합니다.
다음으로 지지와 이동을 따로 테스트하세요. 다리 블록은 가까운 플랫폼이나 이전에 지지된 블록에 연결되어야 합니다. 지지되지 않는 대상을 거부할 때 인벤토리는 그대로여야 합니다. 마지막으로 V0와 V1 경로를 확인합니다. V0는 세 번째 배치를 거부하고 V1은 추가 Mine 뒤에 도착합니다.
실제로 본 내용을 기록하세요. 버전, 행동, 이전 상태, 입력, 결과 위치, 인벤토리, 대상 칸 상태, 승리 피드백을 적습니다. 실행하지 않은 검사는 미검증으로 표시하세요. 글의 표는 예상 상태이며 테스트 보고서가 아닙니다.
복셀 브리프를 Workspace로 가져가세요
규칙 범위를 정하면 제작자는 간결한 계약을 게임 제작 흐름으로 전달할 수 있습니다. 현재 공식 Free AI Game Maker 페이지에는 복셀 샌드박스 빌더 시작 카드가 있어 큰 지형에서 자유롭게 블록을 배치하고 생존하며 건설하는 아이디어를 소개합니다. 이는 관련 시작점이지 이 글의 좌표별 채굴이나 지지 규칙이 지원된다는 증거는 아닙니다.
공식 Free AI Game Maker 페이지는 쉬운 영어 프롬프트로 게임을 설명하고, 브라우저에서 플레이 가능한 첫 2D/3D 결과를 검토한 뒤 후속 요청으로 다듬는 일반 흐름을 설명합니다. 전용 Workspace 작업 공간도 안내합니다. 이 내용은 제작 경로를 설명할 뿐, 특정 복셀 메커니즘이 동작한다는 보장은 아닙니다.
아이디어를 정리하려면 Free AI 게임 메이커를 이용하세요. 첫 요청은 작게 유지하고 반복 전에 생성 결과를 확인하며 계속하기 전 표시 비용을 확인하세요. 이 페이지는 폭넓은 복셀 샌드박스 지침을 제공하지만 Mosslight Span의 수량과 규칙을 검증하지 않습니다.
자주 묻는 질문
복셀 건축 게임 AI 프롬프트에는 무엇을 포함해야 하나요?
편집 가능한 영역, 플레이어 시작점, 블록 수량, 정확한 채굴 거리, 배치 규칙, 지지 조건, 이동, 목표, 재시작 동작을 명시하세요. 그 뒤 예상 상태와 좌표를 포함한 작은 검증 표를 요청합니다. 이렇게 하면 프롬프트가 목표 세계를 임의로 확장하지 않고 규칙을 확인하기 쉬워집니다.
구현 프롬프트 전에 채굴 거리를 정해야 하는 이유는 무엇인가요?
거리가 필요한 행동 수를 바꾸기 때문입니다. Mosslight Span의 노출 블록은 시작 칸과 면으로 맞닿아 있어 이동 없이 Mine 한 번으로 회수됩니다. 거리가 정의되지 않으면 먼 블록도 회수할 수 있어 V0/V1 자원 비교가 달라집니다. 먼저 상호작용 가능 위치를 명시하세요.
예시는 다리를 건널 블록을 어떻게 확보하나요?
V0에는 블록 두 개만 있고 세 개가 필요하므로 인벤토리가 0일 때 세 번째 배치는 거부됩니다. V1에는 시작 칸에서 한 번의 행동으로 회수할 수 있는 노출 예비 블록 하나가 추가됩니다. 그 블록을 포함하면 세 칸을 모두 채울 수 있습니다.
Mosslight Span 프롬프트를 실행하거나 게임을 테스트했나요?
아니요. Mosslight Span과 규칙은 독창적인 허구 연습이고 프롬프트 템플릿도 이 글을 위해 작성했지만 게임 생성기에 입력하지 않았습니다. 표는 수동 계산입니다. 플레이 가능한 빌드, 생성 결과, 플레이테스트를 주장하지 않습니다.
향후 빌드가 추적 결과와 다르면 어떻게 하나요?
버전, 플레이어 위치, 인벤토리, 대상 칸, 행동, 결과 피드백을 포함해 처음 달라진 상태를 기록하세요. 해당 수락 검사와 비교하고 원인이 되는 규칙 하나만 좁게 수정합니다. 관련 검사만 반복하고 관찰하지 않은 동작은 미검증으로 남기세요.
