한 가지 분명한 물체 경로로 포털 퍼즐 설계하기

플레이어가 물체를 밀기 전에 어디로 나올지 예측할 수 있으면 포털 퍼즐은 이해하기 쉬워집니다. 큐브 하나, 연결된 입구와 출구 하나씩, 스위치 하나, 문 하나로 시작하세요. 이 가상 방에서는 출구 화살표가 큐브를 북쪽 장벽 쪽으로 보내거나 장애물이 없는 동쪽 길로 스위치까지 보냅니다. 경로 변경은 종이 위 설계 예시일 뿐이며 프롬프트, 빌드, 플레이어 테스트를 실행하지 않았습니다.

도착 지점 하나로 시작하세요

첫 방에 눈에 보이는 목표를 하나 둡니다. 큐브를 황동 바닥 스위치 위에 놓아 돌로 된 출구 문을 여는 것입니다. 플레이어는 큐브를 청록색 입구 틀로 밀고, 큐브는 구리색 출구 틀에서 다시 나타납니다. 출구 틀은 네 방향으로 고정해 돌릴 수 있습니다. 화살표가 큐브의 출구 방향을 정하고, 이 설계에서는 경로 속도가 그대로 유지됩니다.

첫 단계의 목표는 연결된 표면 사이의 경로를 가르치는 것이지 일반적인 물리 시스템을 설명하는 것이 아닙니다. 방에는 짧은 트랙 하나, 큐브 하나, 고정 입구, 회전 가능한 출구, 안전한 북쪽 장벽, 비어 있는 동쪽 길, 스위치 하나, 문 하나만 둡니다. 플레이어가 큐브가 어디로 나올지 결정하는 데 집중할 수 있도록 다른 이동 요소는 단순하게 유지하세요.

정해 둔 예시에서 북쪽을 향한 경로는 고정 장벽에 닿고 스위치는 작동하지 않습니다. 출구를 동쪽으로 한 단계 돌리면 같은 큐브가 열린 길을 따라 스위치로 갑니다. 접촉하면 스위치가 눌리고 큐브가 그 위에 있는 동안 문이 올라가 열린 상태를 유지합니다. 이는 작은 설계 연습을 위해 만든 규칙이지 실제 포털의 동작이나 테스트된 게임에 대한 주장이 아닙니다.

각 포털 틀이 바꾸는 것을 정의하세요

시각 효과를 더하기 전에 포털 규칙을 먼저 작성하세요. 큐브가 입구 틀의 평면을 가로지를 때만 입구가 큐브를 받으며 큐브가 사라지는 것은 아닙니다. 출구 틀은 현재 화살표가 가리키는 방향으로 큐브를 내보냅니다. 화살표는 카메라 각도에서 플레이어가 추측해야 하는 힌트가 아니라 월드 기준의 기본 방향을 나타내게 하세요. 이 제안 방에서는 출구 속도가 입구에서 들어온 경로 속도와 같습니다.

밀기 전에 짧은 예고를 보여 주세요. 출구 화살표를 밝히고 선이나 바닥 빛으로 경로를 표시합니다. 북쪽 방향 끝에는 출구 바로 북쪽에 단단한 장벽이 있습니다. 동쪽 길은 출구에서 스위치까지 막히지 않습니다. 장벽은 동쪽 길 밖에 있으므로 동쪽을 선택한 큐브는 장벽에 부딪히지 않습니다.

이 두 경로만으로 첫 학습 목표를 설명할 수 있습니다. 포털 틀에는 네 방향이 표시되더라도 종이 예시는 북쪽과 동쪽만 비교합니다. 숨겨진 지름길, 피해 페널티, 두 경로 사이에서 큐브 속도를 바꾸는 규칙을 추가하지 마세요.

플레이어가 행동할 수 있는 프롬프트를 쓰세요

두 포털 틀, 큐브, 북쪽 장벽, 동쪽 길, 스위치, 문이 모두 보이는 직접적인 게임 카메라를 사용하세요. 간단한 조작 규칙에서는 이동 입력으로 플레이어 위치를 바꾸고, 상호작용 버튼 하나로 출구 화살표를 기본 방향 한 칸씩 돌리며, 큐브가 입구 옆에 있을 때 밀기 입력 하나를 씁니다. 정확한 키는 프로젝트에서 정할 수 있지만 화살표를 바꾸는 조작과 큐브를 보내는 조작은 분명해야 합니다.

경로 규칙은 유지하면서 다음의 범위가 정해진 설계안을 복사해 미술 방향이나 조작을 바꿔 보세요.

‘고요한 물문’이라는 독창적인 포털 퍼즐 방 하나를 설계하세요. 큐브 하나, 청록색 입구 틀, 구리색 출구 틀, 황동 스위치, 돌문 하나를 보여 주는 명확한 3/4 시점 게임 카메라를 사용하세요. 플레이어가 네 가지 기본 출구 방향 중 하나를 고르고 짧은 경로 미리보기를 확인한 다음 큐브를 동쪽으로 밀어 입구에 넣게 하세요. 큐브는 입구 평면을 지날 때만 들어가고, 짝을 이루는 출구에서 화살표가 가리키는 방향으로 나오며 경로 속도는 유지합니다.

출구 틀 바로 북쪽에 고정된 돌 장벽 하나를 놓으세요. 출구부터 스위치까지의 동쪽 길은 막지 마세요. 출구 화살표가 북쪽이면 큐브는 안전하게 장벽에 부딪히고 스위치는 작동하지 않으며 문은 닫힌 상태로 남습니다. 화살표가 동쪽이면 큐브가 스위치에 도달하고, 접촉하면 스위치가 눌린 채 큐브가 그 위에 있는 동안 문이 열려 있습니다. 큐브, 화살표, 스위치, 문을 시작 상태로 복원하는 초기화를 제공하세요.

방의 규칙, 플레이어 행동, 눈에 보이는 경로 미리보기, 충돌 피드백, 스위치와 문의 상태, 초기화 동작, 북쪽과 동쪽 경로의 확인 항목을 제시하세요. 방은 이 큐브 경로 하나로 유지하세요. 숨은 경로, 두 번째 큐브, 타이머, 피해, 속도 변화는 추가하지 마세요. 실제 빌드를 살펴보기 전까지 설계 제안으로 다루세요.

프롬프트에는 입력, 변환, 도착 지점, 예상 결과 두 가지, 초기화가 명시돼 있습니다. 이 덕분에 인상적인 포털 효과에 기대지 않고 방의 각 부분이 같은 규칙을 따르는지 제작자가 확인할 수 있습니다.

피드백과 초기화를 모호하지 않게 하세요

각 상태 변화를 별도의 규칙으로 확인하세요. 밀기 전에는 선택한 화살표와 경로 미리보기가 일치해야 합니다. 큐브가 입구 평면을 넘으면 한 번만 포착합니다. 출구에서는 큐브가 표시된 쪽으로 나타나 그 방향을 따라 움직여야 합니다. 북쪽 경로에서는 장벽이 큐브를 멈추고 스위치는 작동하지 않아야 합니다. 동쪽 경로에서는 큐브가 닿을 때만 스위치가 반응하고, 큐브가 스위치 위에 있는 동안만 문이 열린 상태여야 합니다.

초기화하면 전체 구성이 복구되어야 합니다. 큐브는 짧은 트랙의 시작점으로 돌아가고 출구 화살표는 북쪽, 스위치는 올라간 상태, 문은 닫힌 상태가 됩니다. 화살표가 동쪽으로 남거나 문이 열린 채라면 다음 시도는 이전과 같은 조건에서 시작하지 않습니다. 첫 경로와 두 번째 경로가 다른 이유를 플레이어가 이해하려면 올바른 초기 상태가 중요합니다.

결과가 혼란스럽다면 효과를 더하는 대신 관계를 진단하세요.

• If the cube passes through the entry without being captured, check that the frame-plane crossing is the trigger.
• If the preview points east but the cube hits the north barrier, check world direction and camera orientation together.
• If the switch activates before contact, check whether the rule uses overlap with the cube rather than proximity to the portal.
• If the gate closes while the cube still rests on the switch, check the occupancy condition; if the cube rolls off, the gate should return to its stated closed state.
• If a retry starts with changed pieces, test the reset as a full state restoration rather than a visual flash.

이 항목은 향후 시제품을 위한 수용 기준이지 관찰한 결과가 아닙니다. 실패가 작성된 규칙의 어느 부분과 연결되는지 알려 주므로 나중에 플레이 테스트를 해석하기 쉽습니다.

화살표를 한 번 바꾸는 상황을 종이로 확인하세요

이 글에는 프롬프트 실행 결과, 플레이 가능한 빌드, 플레이어 관찰이 없습니다. 다음은 직접 규칙을 적용해 종이로 풀어 본 설계 시뮬레이션이며 실제 테스트나 측정된 반복 개선이 아닙니다.

방, 큐브, 입구 틀, 시작 시 밀기, 경로 속도, 스위치, 문 규칙은 모두 그대로입니다. 의도한 선택 하나만 분리했습니다. 동쪽 길이 비어 있고 장벽이 출구 북쪽, 그 길 바깥에 있으므로 결과는 설정한 배치와 일치합니다. 이것이 모델이 방을 생성했다거나 코드에서 움직임이 작동한다거나 플레이어가 선택을 이해한다는 점을 입증하지는 않습니다.

플레이 가능한 버전이 생기면 매 시도를 초기화 상태에서 시작하고 선택한 방향, 경로 미리보기, 실제 충돌 또는 스위치 접촉, 최종 문의 상태를 기록하세요. 새 플레이어에게 밀기 전에 경로를 설명해 달라고 하세요. 설명이 미리보기와 다르면 방을 더 추가하기 전에 안내 표시를 고칩니다.

AI 게임 메이커로 설계안을 만든 뒤 결과를 확인하세요

SEELE의 공식 무료 AI 게임 메이커 페이지는 일반적인 흐름을 설명합니다. 평범한 문장으로 게임 아이디어를 작성하고 플레이 가능한 2D 또는 3D 결과를 검토한 뒤 Workspace에서 반복 작업을 할 수 있으며, 이때 선택된 모델, 남은 Koin, 표시된 생성 비용을 확인합니다. 이는 첫 방의 설계 방향을 정하는 데 유용하지만 이 포털 변환이 구현됐는지 검증하거나 큐브, 장벽, 스위치, 초기화가 지정대로 동작한다고 보장하지는 않습니다. 설계를 확장하기 전에 실제 결과를 작성한 수용 기준과 비교하세요.

작은 범위로 시작하세요. 방 하나, 행동 순서 하나, 경로 두 개, 눈에 보이는 성공 조건 하나입니다. 첫 결과가 조건에 맞지 않으면 지시 하나를 바꾸고 다음 버전을 확인합니다. 콘셉트 이미지나 이 종이 계산을 SEELE가 생성한 게임 또는 플레이 테스트로 다루지 마세요.

검증할 수 있는 포털 방으로 이어가세요

좋은 첫 포털 퍼즐에는 연결된 방의 미로가 필요하지 않습니다. 플레이어가 볼 수 있는 규칙 하나, 서로 다른 결과를 만드는 경로 선택, 무슨 일이 일어났는지 확인해 주는 피드백이 필요합니다. ‘고요한 물문’의 북쪽 장벽과 빈 동쪽 길로 시작한 뒤 실제 빌드에서 입구, 출구 방향, 스위치 접촉, 문 상태, 초기화를 확인하고 나서 메커니즘이 성공했다고 판단하세요.

‘고요한 물문’은 허구의 설계 예시이며 북쪽과 동쪽 경로 비교는 종이 위 시뮬레이션입니다. 나만의 게임 아이디어를 구체화하려면 무료 AI 게임 메이커에서 시작한 뒤 플레이 가능한 결과를 작성한 규칙 및 상태 확인 항목과 대조하세요. 무료 AI 게임 메이커

자주 묻는 질문

포털 퍼즐은 일반적인 스위치 퍼즐과 무엇이 다른가요?

핵심 선택이 단순히 스위치에 도달할 수 있는지를 바꾸는 게 아니라 연결된 표면 사이에서 물체가 이동하는 방식을 바꿉니다. 출구 화살표는 같은 밀기로 큐브를 북쪽 장벽 또는 동쪽 스위치로 보내므로 플레이어가 행동 전 관계를 읽고 출구 후 결과를 확인할 수 있어야 합니다.

북쪽 장벽을 동쪽 길 밖에 두는 이유는 무엇인가요?

북쪽 경로의 실패를 안전하고 분명하게 보이게 하면서 목표로 향하는 동쪽 길은 열어 두기 위해서입니다. 두 경로를 모두 막으면 출구 방향 선택을 배울 수 없습니다. 장벽을 출구 북쪽에 두고 동쪽 길을 비워 두며 두 위치가 방에서 함께 보이는지 확인하세요.

북쪽에서 동쪽으로 바꿔 본 종이 비교도 플레이 테스트인가요?

아닙니다. 작성된 규칙상 북쪽은 장벽에 닿고 동쪽은 스위치에 도달한다는 점만 확인합니다. 실제 게임이나 플레이어 이해도는 입증하지 않으므로 종이 위 시뮬레이션으로 표시하고 실제 테스트를 진행해야 합니다.

첫 포털 퍼즐에서 초기화는 무엇을 복원해야 하나요?

큐브를 시작 위치로 옮기고 화살표를 시작 방향으로 되돌리며 스위치는 올라가고 문은 닫혀야 합니다. 각 상태를 따로 확인해 다음 시도가 동일한 배치에서 시작하도록 하세요.

두 번째 포털 방을 추가하기 전에 무엇을 확인해야 하나요?

입구 작동, 화살표와 미리보기 일치, 북쪽 장벽의 안전한 정지, 동쪽 경로와 스위치 접촉, 문 제어, 전체 초기화를 확인하세요. 새 플레이어에게 경로를 예측하게 하고 실제 빌드에서 첫 루프가 이해된 뒤 방을 추가하세요.