궁 미로 PalaceMaze TIL 1
정답이 하나뿐이면 다시 할 이유가 없다
완벽한 미로를 만들었더니 재미가 없었다
궁을 5×5 마당으로 나누고 모든 마당이 이어지도록 담을 뚫었다. DFS(깊이 우선 탐색 — 한 갈래를 끝까지 파고들었다가 돌아오는 방식)로 신장 트리(모든 칸을 고리 없이 한 번씩 잇는 연결)를 만들면 고립된 구역 없이 전부 연결된다. 두 지점 사이 경로가 정확히 하나뿐인, 교과서에 나오는 퍼펙트 메이즈다.
만들고 보니 문제가 보였다. 이 게임은 클리어 타임으로 점수를 매기는데, 경로가 하나면 최적 동선도 하나다. 한 번 외우면 그다음부터는 그냥 그대로 뛰는 것뿐이다.
그래서 담 몇 개를 일부러 더 뚫어 루프를 만들었다(브레이드 메이즈). 이제 “왼쪽으로 돌까 오른쪽으로 돌까”가 생긴다. 익숙해질수록 더 나은 동선을 찾을 여지가 남는다.
판단에 쓰는 방식
반복해서 하길 바라는 콘텐츠에는 선택의 여지를 남긴다. 정답이 하나면 처음 푸는 순간 끝난다.
반대로 한 번만 풀 것이라면 정답이 하나인 편이 깔끔하다. 길찾기 퍼즐이라면 퍼펙트 메이즈가 맞았다. 무엇을 만드는지에 따라 같은 구조가 장점도 되고 단점도 된다.
막는 것보다 어렵게 두는 편이 낫다
담을 넘을 수 있다는 걸 알았다
미로니까 담을 못 넘어야 한다고 생각했다. 그런데 마당에 오브제를 놓으면 그걸 밟고 넘어갈 수 있다는 걸 알게 됐다. 캐릭터 점프 높이와 담 높이 차가 오브제 하나만큼이었다.
막을 방법은 있었다. 담을 높이거나, 밟을 수 있는 높이의 오브제를 안 놓거나, 점프력을 낮추면 된다. 그런데 실제로 넘어 보니 생각이 바뀌었다. 담 위에 올라설 수는 있는데 걸어 다니기는 어려웠다. 담 두께가 좁아서 자꾸 떨어진다.
이게 오히려 좋은 상태였다. 담을 넘는 건 숙련자의 지름길이 되고, 담 위를 타고 미로를 통째로 무시하는 건 안 된다. 완전히 막으면 모두가 같은 길로만 다니고 기록이 금방 천장에 닿는다.
우연이냐 설계냐가 갈림길이다
넘을 수 있다는 것 자체는 문제가 아니었다. 문제는 내가 그걸 정하지 않았다는 것이었다.
그래서 오브제 높이에 규칙을 뒀다. 넘을 수 있는 높이대가 좁게 존재해서, 그 구간만 피하면 우연히 뚫리지 않는다. 지름길을 만들고 싶은 자리에만 그 높이를 의도적으로 놓는다.
질문은 “가능하냐”가 아니라 “어디서 가능한지 내가 정했냐”였다. 이 전환이 이후 판단을 여러 번 도왔다.
조합이 규칙을 깬다
높이 규칙을 정하고 나서 구멍을 하나 더 발견했다. 오브제 하나씩 보면 전부 안전한 높이인데, 두 개를 붙여 놓으면 낮은 걸 밟고 높은 데 올라가 담을 넘을 수 있다.
각각은 규칙을 지키는데 조합이 규칙을 깬다. 그래서 높이 규칙만으로는 부족하고 오브제 사이 최소 간격도 정해야 했다.
개별 항목만 검사하는 규칙은 이런 걸 놓친다. 규칙을 만들 때 “이걸 두 개 겹치면?”을 한 번 물어보게 됐다.
접근이 막히면 접근하지 않는 구조로 바꾼다
블루프린트끼리 변수를 못 읽는 상황이었다
상자를 열면 마패조각 수가 오르게 만들어야 했다. 보통은 상자가 레벨 매니저를 찾아 변수를 올린다. 그런데 MCP로는 다른 블루프린트의 변수에 접근하는 노드가 만들어지지 않았다. 네 가지 경로를 시도해서 다 막혔다.
방향을 뒤집었다. 상자가 매니저를 찾는 대신, 매니저가 모든 상태를 들고 상자는 아무것도 모르게 했다. 상자는 열리기만 하고 이벤트 디스패처(한 블루프린트가 “일어났다”고 알리면 구독한 쪽이 받는 방송 장치)로 알린다. 매니저는 셔플된 보상 배열을 들고 있다가 순서대로 하나씩 내보낸다. 어느 상자가 열렸는지 알 필요조차 없어졌다.
제약 때문에 나온 설계가 더 나았다
결과적으로 더 단순해졌다. 상태가 매니저 한 곳에 모여 있으니 지금 조각이 몇 개인지, 시간이 얼마 남았는지 추적하기 쉽다. 상자를 스물다섯 개 놓아도 각자 변수를 들고 있지 않으니 신경 쓸 게 없다.
제약이 없었으면 상자마다 보상 번호를 들고 있는 구조로 갔을 것이다. 그게 더 자연스러워 보였을 테고, 나중에 “지금 조각 수가 왜 이렇지”를 찾을 때 상자 스물다섯 개를 뒤졌을 것이다.
막혔을 때 우회로를 찾기 전에 방향을 뒤집어 보는 게 나을 때가 있다. 다만 이건 한계도 드러났다 — 뒤집는 걸 반복하다 보니 결국 이벤트 디스패처라는 정석으로 돌아왔다. 그 이야기는 다음 글에 이어진다.
Begin Overlap은 시작 상태를 말해주지 않는다
겹쳐 놨는데 반응이 없었다
픽업에 닿으면 사라지게 만들고, 시험하려고 PlayerStart에 픽업을 겹쳐 놨다. 그런데 아무 일도 안 일어났다.
Begin Overlap은 겹치기 시작하는 순간에만 발생한다. 스폰 시점에 이미 겹쳐 있으면 그 순간이 없어서 이벤트가 안 온다. PlayerStart를 위로 올려 캐릭터가 떨어져 들어가게 하니 바로 반응했다.
판단에 쓰는 방식
변화를 알리는 이벤트는 현재 상태를 묻는 쿼리가 아니다. 둘을 헷갈리면 “분명히 조건은 맞는데 왜 반응이 없지”에서 오래 막힌다.
지금 겹쳐 있는지가 궁금하면 상태를 직접 물어야 한다. 이후로 판정이 필요한 곳에서는 오버랩 결과를 변수에 저장해 두는 대신 필요한 순간에 직접 확인하는 쪽을 택했다. 저장해 둔 플래그는 언제 갱신됐는지 알 수 없어서 믿기 어렵다.