복셀의 물리적 고체 여부와 특정 에이전트의 이동 가능 여부를 하나의 점유 비트로 표현하면 어떤 규칙을 잃게 되나요?

복셀이 물리적으로 고체인지와 특정 에이전트가 그 위치를 통과할 수 있는지는 서로 다른 질문입니다. 고체 여부는 지형이 차지하는 부피에 관한 원본 정보이고, 이동 가능 여부는 에이전트의 반경·높이·능력·현재 상태와 주변 여유를 함께 계산한 결과입니다. 물, 낮은 장애물, 경사, 문, 사다리, 위험 지형을 occupied=true/false 하나로 뭉치면 에이전트별 통과 규칙과 상호작용을 잃습니다. 따라서 물리 점유와 이동성 분리(separation of occupancy and traversability)를 기본으로 두겠습니다.

원본과 질의 결과

정적 지형의 재질·고체 부피, 동적 객체의 점유, 에이전트별 clearance·이동 능력을 별도 계층으로 저장합니다. 작은 캐릭터가 통과할 수 있는 두 칸 높이의 통로를 큰 캐릭터가 통과할 수 없고, 공중 에이전트는 발밑뿐 아니라 진행 방향의 3차원 부피와 위쪽 공간을 확인해야 합니다. 문은 고체일 때 막히지만 열리면 통과 가능하고, 물은 지상 캐릭터와 수영 가능한 캐릭터의 결과가 다를 수 있습니다. 따라서 조회는 staticMaterial, dynamicOccupancy, agentProfile, 경사·높이 조건을 합쳐 최종 충돌·이동 가능성을 계산합니다. 정적 원본에서 walkable, clearance, 경사 같은 파생 데이터를 만들 수 있지만, 이것은 특정 에이전트 유형과 원본 버전에 종속됩니다. 원본이 바뀌면 해당 파생 결과를 무효화하고, 비동기 생성 중에는 이전 결과와 현재 원본을 섞지 않도록 sourceVersion을 확인합니다. 동적 점유가 자주 바뀌면 정적 압축 블록을 매번 재인코딩하지 않도록 동적 계층을 따로 두고 조회 시 합집합·우선순위 규칙을 적용합니다. 동적 객체가 제거됐다고 정적 벽도 사라지는 식의 의미 혼합은 피해야 합니다.

저장과 검증

저장 효율 때문에 고체 비트를 팔레트·압축 블록으로 인코딩할 수 있지만, 압축 표현이 곧 게임 규칙이 되게 하지 않겠습니다. 한 셀 수정이 블록 분할·재인코딩을 유발할 수 있고, 읽기와 쓰기가 겹치면 새 블록을 만든 뒤 포인터를 교체하고 이전 블록의 참조 수명을 보장해야 합니다. 에이전트 프로필이 늘어날 때마다 전체 맵의 walkable 비트를 복제하는 대신 원본 질의와 필요한 유형별 캐시의 비용을 비교합니다. 테스트는 재질, 문 상태, 경사, 반경·높이, 지상·공중 이동, 동적 장애물, 압축 블록 단일 셀 수정, 서버·클라이언트 버전 차이를 포함합니다. 같은 원본과 같은 프로필을 입력했을 때 충돌과 경로가 같은 의미를 반환하는지 확인하겠습니다. 하나의 점유 비트는 저장 공간은 작지만 질의 조건을 잃는 압축일 수 있습니다. 최종 질의가 여러 계층을 합칠 때 우선순위도 명확해야 합니다.

문이 열리면 문 자체의 충돌 형상만 제거되며, 문틀이나 뒤의 독립된 벽은 그대로 고체로 남습니다. 물과 위험 영역이 겹치면 지상·수영·비행 프로필별 규칙이 달라집니다. 단순한 불리언 OR로 합치지 말고 재질과 상태를 보존한 뒤 에이전트 정책을 적용하겠습니다. 이동성 캐시는 에이전트 프로필과 원본 버전에 종속됩니다. 반경이나 경사 한계가 바뀌면 캐시를 무효화하고, 정적 결과와 동적 오버레이를 각각 읽은 시점의 버전으로 묶어 충돌과 경로가 서로 다른 틱의 점유를 섞지 않게 하겠습니다.