넓은 게임 월드에서 각 플레이어에게 주변 상태만 보내려 합니다. 누구의 정보를 보낼지와 경계에서 나타났다 사라지는 문제를 어떻게 처리하나요?

핵심은 각 클라이언트에 현재 공개해도 되는 객체와 이벤트만 골라 보내는 것입니다. 단순히 반경 안의 객체를 모두 보내는 방식은 구현은 쉽지만 대규모 전투에서 전송량과 갱신 비용이 급증하고, 반대로 거리만 줄이면 팀 상태나 전투 결과처럼 거리와 무관하게 전달해야 하는 정보가 빠질 수 있습니다. 따라서 객체의 위치, 같은 인스턴스인지, 시야와 지형, 팀·파티 관계, 전투 참여 여부를 함께 사용해 수신자를 결정하겠습니다. 이 수신 대상과 공개 범위를 정하는 문제를 관심 영역(AOI)이라고 부릅니다.

거리 경계와 공개 계약

예를 들어 50m 안으로 들어온 객체는 기준 스냅샷을 보내고 이후 증분 변경을 보내며, 55m 밖으로 나가야 삭제 이벤트를 보냅니다. 진입과 이탈 반경을 일부러 다르게 두면 경계에서 몇 센티미터 움직일 때마다 생성과 삭제를 반복하는 현상을 줄일 수 있습니다. 이 차이를 히스테리시스(hysteresis)라고 부릅니다. 다만 넓은 이탈 반경을 사용한다고 해서 비밀 상태까지 미리 보내서는 안 됩니다. 클라이언트가 화면에서 숨기는 것은 이미 전송된 정보의 노출을 되돌리지 못하므로, 서버에서 필드별 공개 권한과 이벤트 채널을 나눠야 합니다. 진입 스냅샷과 증분 갱신의 순서도 계약으로 둡니다. 객체 생성 버전이 20인데 버전 19의 갱신이 먼저 도착하면 클라이언트는 폐기해야 하고, 기준 스냅샷을 적용하기 전에 증분을 처리하지 않도록 합니다. 서버는 객체별 세대나 단조 증가 버전을 넣고, 클라이언트는 오래된 갱신을 무시합니다. 전투·보상처럼 반드시 받아야 하는 이벤트는 화면에 보이는 상태 스트림과 분리해 대상 자격을 별도로 판정하고, 누락 복구가 필요하면 이벤트 ID를 사용합니다.

갱신 비용과 경계 실패

매 틱 모든 플레이어와 모든 객체의 거리를 비교하지 않겠습니다. 공간 해시나 계층 격자로 후보를 찾고, 공간 인덱스는 위치가 셀을 넘을 때 후보 목록을 갱신하는 데 사용하되, 후보 안의 거리·시야·팀 관계는 셀을 넘지 않아도 상태나 경계 변화가 있을 때 다시 계산합니다. 밀집된 핫스팟에서는 후보 수 자체가 커지므로 객체별 송신 예산, 갱신 빈도, 중요도별 샘플링을 둘 수 있습니다. 새로 들어온 객체의 스냅샷이 준비되기 전에 이동 갱신이 오면 스냅샷 기준 버전으로 병합하거나 해당 갱신을 재요청해야 합니다. 검증은 경계 왕복, 순간이동, 청크 경계, 밀집 전투, 팀 변경, 시야를 가리는 벽을 포함합니다. 평균 전송량만 보지 말고 사용자별 p99 송신량, 후보 조회 시간, 생성·삭제 반복 횟수, 스냅샷 뒤 누락된 상태가 있는지를 확인하겠습니다.

AOI는 단순한 네트워크 압축이 아니라 누가 어떤 시점에 어떤 상태를 볼 수 있는지를 정하는 공개 정책(disclosure policy)입니다. 실제 공개 상태는 객체 단위보다 필드와 이벤트 단위로 나누는 편이 안전합니다. 같은 캐릭터라도 위치·외형은 넓은 반경에, 체력은 전투 참여자에게, 인벤토리나 숨은 목표는 권한 있는 서버 채널에만 보낼 수 있습니다. 진입 때 보낸 스냅샷이 지나치게 크면 필수 상태와 선택 상태를 나누되, 선택 상태가 오기 전의 기본 화면을 정의합니다. 클라이언트가 누락 필드를 확정값으로 해석하지 않도록 프로토콜 상태도 명시하겠습니다. 경계 판단은 거리 계산의 기준점도 고정해야 합니다. 캐릭터 중심만 비교할지 실제 bounding volume을 비교할지, 텔레포트 때 중간 영역의 이탈·진입 이벤트를 어떤 순서로 만들지 정합니다.

서버가 한 틱에 계산한 AOI 집합을 이전 집합과 차분해 이벤트를 만들고, 삭제 뒤 늦은 갱신이 도착할 때는 객체 세대로 거절합니다. 이 규칙이 있어 재접속이나 패킷 재정렬에서도 화면 상태가 수렴합니다. 실패 처리는 단순히 객체를 삭제하는 것으로 끝내지 않겠습니다. 네트워크가 잠시 막혔다가 회복하면 서버가 현재 AOI 스냅샷 버전을 다시 제시하고 클라이언트가 이전 객체 세대를 정리한 뒤 재동기화하게 합니다. 이때 중요 이벤트의 전달 보장과 위치 스트림의 최신성은 서로 다른 요구이므로 같은 재전송 정책을 적용하지 않습니다. 공개 대상이 바뀐 순간의 권한도 로그에 남겨, 나중에 왜 특정 사용자에게 보이지 않았거나 보였는지 설명할 수 있게 하겠습니다.