한 근무조의 시작, 몇 곳의 재고 위치, 짧은 행동 시계에 맞는 마감 시간을 보이면 창고 관리 게임 설계가 쉬워집니다. 보관 칸을 지정하고 상자를 입고 처리해 적치하고 주문별로 피킹한 뒤 출고하는 플레이어로 시작하세요. 늦은 주문이 왜 생겼는지 알 수 있도록 매 행동 뒤 상태를 기록합니다.
이 튜토리얼은 Bluegate Fulfillment라는 독창적 허구 창고의 6틱 근무조를 손으로 계산합니다. 근무 전 보관 칸 지정 하나가 정시 주문을 1건에서 2건으로 바꾸는 예입니다. 수동 설계 연습이며 프롬프트 실행, 플레이 가능한 게임 제작, 실제 창고나 플레이테스트 데이터는 없습니다.
한 근무조의 창고 범위를 정하세요
한 번의 플레이로 답할 수 있는 질문부터 시작하세요. 마감 틱 전에 입고, 보관, 피킹, 출고를 거쳐 주문 두 건을 처리할 수 있을까요? 작은 근무조는 도시 경제, 직원 성장, 방대한 재고 목록 없이 핵심 루프를 드러냅니다.
Bluegate Fulfillment에는 입고 도크, 바닥 임시 보관칸 하나, 각각 1개를 담는 랙 칸 두 개, 주문 토트 위치, 별도 출고 게이트가 있습니다. A 칸에는 주황색 A 1개가 있습니다. 두 번째 가변 칸은 비어 있고 할당되지 않았습니다. 파란 B 상자 하나가 입고 대기 중입니다. Rush 주문은 2틱 종료 전 A가 필요하고 Standard 주문은 6틱까지 B가 필요합니다. 마감 틱 출고도 정시로 셉니다.
이 첫 모델에서는 작업자의 개별 이동 경로를 다루지 않습니다. 각 작업은 1틱이므로 일정을 확인하기 쉽습니다. 이는 의도적인 추상화이며 실제 물류센터 운영을 설명하는 주장이 아닙니다. 재고와 주문 루프가 명확해진 뒤 통로 거리나 직원 수용량을 추가할 수 있습니다.
| 요소 | 시작 상태 | 설계 목적 |
|---|---|---|
| A 칸 | 용량 1, 주황색 A 1개 | 짧은 마감인 Rush 주문에 공급. |
| 가변 칸 | 용량 1, 비어 있고 미할당. | 근무 전 보관 위치 선택을 만듦. |
| 입고 도크 | 파란 B 상자 1개 대기. | 입고 흐름 시작. |
| 임시 보관 | 처음엔 비어 있는 바닥 칸 하나. | 입고된 상자를 잠시 보관. |
| 주문 | Rush A 마감 t2, Standard B 마감 t6. | 긴급도와 작업 연쇄를 표시. |
| 근무 시계 | 행동 6틱. | 제한된 일정과 종료 조건 제공. |
첫 버전은 한 근무조, 결정론적 규칙으로 유지하세요. 무작위 입고, 부패, 교통 정체, 직원 숙련도, 경쟁 업체, 시장 사건, 보충 규칙은 없습니다. 각각 별도의 설계 과제가 될 수 있습니다. 지금 화면에서 각 재고 단위 위치, 이동 가능한 행동, 출고 마감까지 남은 틱 수를 알 수 있어야 합니다.
보관과 주문 상태를 정의하세요
지도를 그리거나 AI 도구에 프로토타입을 요청하기 전에 테스트 가능한 최소 상태 튜플을 정하세요. 현재 틱, A 칸 재고, 가변 칸 할당과 재고, 임시 보관, 입고 재고, 주문별 토트, 마감, 배송 상태를 추적합니다. 6번째 행동 처리 후 정시 출고된 주문 수가 점수입니다.
재고와 주문 상태는 분리해야 합니다. B를 입고해도 바로 피킹할 수 없습니다. B로 지정된 칸에 적치해야 합니다. 피킹은 랙 칸의 재고 한 개를 해당 주문 토트로 옮기고, 출고는 토트가 완성돼야 가능한 별도 행동입니다. 막연한 “주문 처리” 행동 하나에 여러 상태 변화와 마감 비용을 숨기지 마세요.
| 행동 | 전제조건 | 상태 변화 및 비용 |
|---|---|---|
| 가변 칸 지정 | 근무 시작 전. | 허용 SKU를 A, B, 미할당 중 지정. 틱 비용 없음. |
| 입고 | 입고 상자가 있고 임시 보관칸이 비어 있음. | 도크에서 임시 보관으로 상자 1개 이동. 틱 1 소모. |
| 적치 | 임시 보관 상자와 해당 SKU로 지정된 빈 칸이 있음. | 상자를 칸으로 이동. 틱 1 소모. |
| 피킹 | 해당 랙 칸에 재고가 있고 주문 토트가 그 SKU를 필요로 함. | 랙에서 주문 토트로 1개 이동. 틱 1 소모. |
| 출고 | 주문 토트가 완성됨. | 토트 하나를 출고 게이트로 보냄. 틱 1 소모. |
| 대기 | 완료되지 않은 근무 중 언제나. | 상태 변화 없이 틱 1 소모. |
이 허구 설계에서 무효 작업도 틱을 소비하지만 재고나 위치는 바꾸지 않습니다. 따라서 실패한 적치는 일정 시간을 쓰고 상자는 임시 보관에 남습니다. 임시 보관은 상자 하나만 담으므로 먼저 적치하기 전에는 추가 입고가 불가능합니다. 임시 보관에서 바로 피킹할 수도 없습니다. 구현 전에 이런 경계 사례를 명시하세요. 그렇지 않으면 프로토타입이 결과를 비교할 수 없는 지름길을 임의로 만들 수 있습니다.
행동 처리를 일관되게 유지하세요. 전제조건 확인, 상태 전이 하나 적용, 틱 증가, 출고 시각과 마감 비교 순입니다. 마감 전 또는 마감 틱에 출고하면 1점을 주고, 6틱 종료 시 미완료나 지연 주문은 0점입니다. 재시작은 선택한 버전의 초기 할당, 재고, 상자, 임시 보관, 주문, 틱, 점수를 복원해야 합니다.
가변 칸을 지정하고 입고를 진행하세요
이제 예시에서 바꿀 변수 하나를 정합니다. V0은 가변 칸 미할당, V1은 근무 전에 B로 할당합니다. 마감, 행동 비용, 재고 수량, 시계는 바꾸지 마세요. 나머지를 고정해야 차이를 해석할 수 있습니다.
V0에서 먼저 A를 Rush 토트로 피킹한 뒤 2틱에 출고합니다. 정시입니다. B는 3틱에 입고되어 임시 보관을 차지합니다. 4틱에는 B를 받을 칸이 없어 적치가 막힙니다. 상자는 임시 보관에 남지만 행동 틱은 소모됩니다. 거기서 바로 피킹할 수 없으므로 남은 일정에 Standard를 완료할 방법이 없습니다.
V1은 가변 칸을 B로 지정해 입고 상자의 목적지를 마련합니다. 도크, 임시 보관, 마감, 행동 비용은 같습니다. 3틱에 입고해 B를 임시 보관에 놓고 4틱에 지정 칸에 적치하여 임시 보관을 비웁니다. 남은 두 행동으로 6틱까지 Standard를 피킹하고 출고합니다. 앞선 Rush는 2틱에 정시 출고되었습니다.
기작 이미지는 해당 보드 상태를 그린 콘셉트 렌더링입니다. 파란 B 상자 하나를 바닥 랙 칸에 적치 중이고 Rush 표시는 완료, Standard 주문은 열려 있습니다. 실제 창고 사진이나 생성 게임 스크린샷이 아닙니다. 활성 상자를 하나만 그려 할당 결정을 쉽게 읽게 합니다.
마감 틱 전에 피킹과 출고 일정을 잡으세요
마감 때문에 행동 순서가 중요합니다. Rush 주문은 2틱 마감이므로 첫 두 틱에 A 피킹과 Rush 출고를 해야 합니다. 하나라도 늦추면 그 점수를 잃습니다. Standard는 B 입고, 적치, 피킹, 출고의 더 긴 연쇄가 필요합니다. Rush 출고 뒤 6틱 근무조에는 정확히 네 행동이 남습니다.
주문 토트는 보관 규칙을 건너뛰는 지름길이 아닙니다. 피킹 전에 해당 재고가 맞는 랙 칸에 있어야 합니다. 그래서 적치 규칙이 보이고 가변 칸 설정이 의미를 갖습니다. B 칸이 없을 때 적치를 시도하면 오류 메시지로 차단 이유를 알리고 B를 임시 보관에 남겨야 합니다. 상자를 조용히 없애거나 작업을 완료 처리하지 마세요.
이 모델은 이동을 의도적으로 1틱 비용에 포함했습니다. 나중에 경로 거리를 더한다면 이름 있는 구역 사이 이동 행동에 1틱을 부과하는 식으로 새 규칙을 명시하고 두 주문 일정을 다시 계산하세요. 손계산 뒤에 숨겨진 이동 비용을 추가하면 마감 실패 원인이 칸 배치인지 공개되지 않은 이동 규칙인지 알기 어렵습니다.
시간 표시 방식도 정하세요. 6칸 시계는 작은 글자 없이 사용한 행동 수를 보여 줄 수 있습니다. 작업 뒤 직접 피드백을 주세요. 입고 후 도크 수량 변경, 적치 후 임시 보관 비움, 피킹 후 랙 재고 변경, 유효 출고 후 주문 표시 변경. 막힌 작업은 성공한 이동과 다른 시각 신호를 써야 합니다.
V0에서 V1로의 근무를 손으로 확인하세요
제작 전에 추적표를 작성하세요. 각 행은 행동 하나 뒤 재고와 주문 상태를 기록합니다. V0은 실패한 적치가 4틱을 소비하고, V1은 바뀐 칸 지정 하나 덕분에 성공합니다. 두 일정 모두 숨겨진 이동 행동은 없습니다.
| 버전/틱 | 행동 | A 칸 | B 가변 칸 | 임시 보관 | 주문 결과 |
|---|---|---|---|---|---|
| V0 시작 | 가변 칸 미할당 | A=1 | 사용 불가 | 비어 있음 | Rush 마감 2, Standard 마감 6. |
| V0 t1 | A를 Rush 토트로 피킹 | A=0 | 사용 불가 | 비어 있음 | Rush 토트=1. |
| V0 t2 | Rush 출고 | A=0 | 사용 불가 | 비어 있음 | Rush 정시, 점수 1. |
| V0 t3 | B 입고 | A=0 | 사용 불가 | B=1 | Standard 대기. |
| V0 t4 | 적치 시도 | A=0 | 사용 불가 | B=1 | 차단되지만 틱 소모. |
| V0 t5–t6 | 대기, 근무 종료 | A=0 | 사용 불가 | B=1 | Standard 지연, 점수 1/2. |
| V1 설정 | 가변 칸을 B에 지정 | A=1 | B 용량=1 | 비어 있음 | 바뀐 변수는 하나. |
| V1 t1 | A를 Rush 토트로 피킹 | A=0 | B=0 | 비어 있음 | Rush 토트=1. |
| V1 t2 | Rush 출고 | A=0 | B=0 | 비어 있음 | Rush 정시. |
| V1 t3 | B 입고 | A=0 | B=0 | B=1 | Standard 대기. |
| V1 t4 | B 적치 | A=0 | B=1 | 비어 있음 | 임시 보관 해제. |
| V1 t5 | B를 Standard 토트로 피킹 | A=0 | B=0 | 비어 있음 | Standard 토트=1. |
| V1 t6 | Standard 출고 | A=0 | B=0 | 비어 있음 | 두 주문 모두 정시, 점수 2/2. |
V0은 가변 칸에 B 할당이 없어 입고된 상자를 피킹 가능 재고로 만들 수 없습니다. V1은 그 할당만 바꿉니다. 순서는 A 피킹, Rush 출고, B 입고, 적치, B 피킹, Standard 출고입니다. 마지막 출고가 마감 포함 규칙의 6틱에 도착해 허구 점수는 정시 주문 1건에서 2건으로 바뀝니다.
그림의 종료 상태에서 모든 랙 칸, 임시 보관, 주문 토트 위치는 비어 있고 진행 표시 여섯 칸이 완료되었습니다. 종이 추적을 맞춘 직접 제작 콘셉트이며 생성 게임이 주문을 출고했다는 증거는 아닙니다.
첫 버전을 만들고 확인하세요
규칙이 명확해지면 “현실적인 창고를 만들어” 같은 모호한 요청 대신 범위가 제한된 제작 요청을 하세요. 도크, 임시 보관 칸 하나, 1개 용량 랙 칸 두 개, 주문 토트 두 개, 6행동 시계, 아이콘 피드백을 가진 작은 1인 근무조를 요청할 수 있습니다. 상태 전이와 적치 차단 동작을 명시하고 확인할 수락 추적 하나를 적으세요.
설계 계약, 향후 빌드 요청, 검증 체크리스트를 분리하세요. 계약은 행동이 바꾸는 상태를 말하고, 빌드 요청은 최소 장면과 상호작용을 설명하며, 체크리스트는 나중에 실제로 관찰할 항목을 적습니다. 이 페이지는 프롬프트를 모델에 보내거나 플레이 가능한 결과를 생성했다고 주장하지 않습니다. 향후 시도에 사용할 제안 단계입니다.
현재 Free AI Game Maker 페이지는 쉬운 문장으로 게임 아이디어를 설명하고 플레이 가능한 2D/3D 결과를 검토한 뒤 Workspace에서 반복하고 표시 비용과 계정 옵션을 확인하는 일반 흐름을 설명합니다. 창고 전용 생성기나 위 칸 배치 규칙을 보장하지 않습니다. 제작 흐름을 사용한다면 게임이 규칙을 따랐다고 가정하지 말고 실제 결과를 계약과 비교하세요.
향후 빌드는 시작 상태부터 확인하세요. 가변 칸 지정이 허용 SKU만 바꾸는지, Receive가 상자 하나를 임시 보관으로 옮기는지, 막힌 Put-away가 허구 틱을 쓰면서 상자를 보존하는지, 유효 적치가 임시 보관을 비우는지, Pick이 지정 랙에서만 재고를 가져오는지, 완성 토트만 Dispatch 가능한지, 6틱 출고가 포함 마감 전에 계산되는지 확인합니다. 재시작이 초기 지정, 재고, 주문, 틱, 점수를 복원하는지도 봅니다.
관찰 결과에서 규칙 하나를 수정하세요
실제 빌드가 생기면 예상 상태와 처음 달라진 지점을 기록하세요. 시작 틱, 칸 할당, 상자 위치, 선택 행동, 예상 다음 상태, 화면에서 본 내용, 근거를 적습니다. “창고가 헷갈린다”는 보고로는 칸 규칙, 상태 표시, 행동 일정 중 무엇이 문제인지 알 수 없습니다.
- Find the first mismatch. Compare the observation with the relevant transition row before changing the whole concept.
- Name one rule. Examples are the matching-bay precondition, the staging capacity, or the inclusive dispatch cutoff.
- Make one narrow repair. Keep stock, order needs, and deadlines fixed while you revise that rule or its feedback.
- Repeat affected checks. A staging change needs the blocked receive/put-away cases; a deadline change needs both schedule traces.
- Label evidence accurately. A paper trace predicts expected behavior. A prompt is only an instruction. A pass claim requires an actual observation from a real run.
빌드나 실행 기록이 없다면 모든 수락 검사는 미검증으로 둡니다. 작성된 시뮬레이션을 프롬프트가 게임을 개선했다는 주장으로 바꾸지 마세요. 수동 예시는 향후 관찰 결과와 비교할 기준을 제공하고 가장 이른 잘못된 전이를 찾는 데 도움이 됩니다.
창고 게임 브리프 시작하기
첫 창고 프로토타입은 독자가 추론할 수 있는 작은 작업이면 충분합니다. 입고 상자 하나, 보관 선택 하나, 주문 두 건, 근무 시계입니다. 일정 예시는 구현이 마감을 놓칠 때 어디를 먼저 살펴볼지 제안합니다. 실제 창고 운영을 입증하지 않으며 게임 도구가 정확한 시스템을 생성한다는 뜻도 아닙니다.
일반적인 게임 제작 흐름을 알아보려면 Free AI game maker를 사용하세요. 공개된 흐름은 쉬운 영어 프롬프트, 브라우저에서 테스트 가능한 2D/3D 첫 결과, 후속 반복 요청을 설명합니다. 제출 전에 모델, Koin 잔액, 표시 생성 비용을 확인하세요. 이는 일반 제품 정보입니다. 후보 블로그 경로와 진입 출처 값은 경로가 확인될 때까지 로컬 계획 값입니다.
자주 묻는 질문
첫 창고 관리 게임에는 무엇이 필요한가요?
근무조 하나, 작은 지도, 몇 곳의 재고 위치, 명확한 주문 항목, 행동 시계에 맞는 마감으로 시작하세요. 입고, 적치, 피킹, 출고가 각각 눈에 보이는 상태를 바꾸게 합니다. 운영 루프를 쉽게 설명하고 확인할 수 있게 된 뒤 도시 경제나 직원 성장, 큰 목록을 더하세요.
B 상자는 왜 피킹 전에 적치해야 하나요?
이 허구 규칙에서는 SKU가 지정된 랙 칸의 재고만 피킹할 수 있습니다. 입고는 B를 도크에서 임시 보관으로 옮길 뿐 피킹 가능 상태로 만들지 않습니다. 성공적인 적치는 상자를 B 칸으로 옮기고 임시 보관 한 칸을 비웁니다.
V0은 왜 Standard 마감을 놓치나요?
V0은 가변 칸을 지정하지 않습니다. 3틱에 B 입고 후 4틱 적치가 막히지만 행동은 소비됩니다. 임시 보관에서 바로 피킹할 수 없어 6틱 근무가 끝나기 전 B가 피킹 가능 위치에 도달하지 못하고 Standard가 지연됩니다.
V1에서는 무엇이 바뀌나요?
근무 전 가변 칸을 SKU B로 지정하는 것만 바뀝니다. Rush는 여전히 2틱에 출고되고 B 상자는 3틱 입고, 4틱 적치, 5틱 피킹, 6틱 출고됩니다. 포함 마감 규칙에 따라 두 허구 주문 모두 정시입니다.
이 창고 예시는 생성되거나 플레이테스트 되었나요?
아니요. Bluegate Fulfillment와 용량, 비용, 마감, 결과, 이미지는 교육용 허구입니다. V0/V1 추적은 명시한 규칙으로 손계산했습니다. 프롬프트 실행, 플레이 가능한 빌드, 실제 창고 데이터, 소프트웨어 테스트, 플레이테스트, 측정 결과는 주장하지 않습니다.
