Quick Reference

관심 영역(interest management)은 client마다 지금 알아야 하는 entity만 고르는 과정입니다. 거리가 가깝다고 항상 보내고, 멀다고 항상 숨기는 단순 규칙이 아니라, 팀·시야·전투·관전·UI marker 같은 게임 규칙을 함께 반영한 replication set을 만듭니다.

client connection
  -> 항상 필요한 entity를 추가
  -> 공간 index로 가까운 후보를 찾음
  -> 팀·시야·instance·game rule로 후보를 필터링
  -> bandwidth 예산 안에서 update priority를 정함
  -> spawn / delta / despawn을 전송

후보를 빠르게 줄이기

모든 entity가 모든 connection에 나를 보낼까?를 묻는 구조는 player와 entity가 늘수록 CPU가 빠르게 커집니다. 공간 grid, zone, persistent replication list 같은 index로 먼저 후보를 좁히고, 그 뒤에 game rule을 적용합니다. Unreal Replication Graph도 connection별 목록을 빠르게 만들기 위해 actor 목록을 persistent graph node에 모아 재사용하는 접근을 제공합니다.

공간 후보는 관심 영역의 최종 답이 아닙니다. 같은 cell에 있어도 다른 instance이면 보이면 안 되고, 멀어도 party member·spectator target·revealed enemy처럼 반드시 보여야 하는 entity가 있습니다. 공간 index는 broad phase, game rule은 narrow phase처럼 분리하면 거리 안인데 보이지 않는다와 거리 밖인데 보내도 된다를 각각 설명할 수 있습니다.

false negative는 player가 실제로 알아야 하는 enemy·projectile·door를 받지 못하게 하므로 gameplay bug입니다. false positive는 bandwidth와 CPU를 낭비하지만 다음 filter나 우선순위에서 줄일 수 있습니다. 먼저 필요한 entity가 빠지지 않는 test를 만들고, 그 다음 후보 수와 byte budget을 줄입니다.

update 빈도를 같이 정하기

replication set에 들어왔다는 사실이 매 tick 전체 state를 보낸다는 뜻은 아닙니다. 가까운 enemy의 transform은 자주, 멀리 있는 AI의 animation은 드물게, 휴면 entity는 변경 event가 있을 때만 보낼 수 있습니다. distance만으로 frequency를 정하면 시야에 막힌 대상을 계속 보내거나, 중요한 objective가 멀다는 이유로 늦게 갱신될 수 있습니다.

client별 byte budget을 두고, budget을 넘으면 낮은 우선순위 update를 다음 snapshot으로 미룹니다. 이때 spawn은 보냈지만 초기 baseline을 못 보낸 entity, despawn을 보내지 못해 계속 화면에 남은 entity처럼 lifecycle event를 일반 delta와 같은 취급으로 밀어내면 안 됩니다. entity 생성과 제거의 순서 계약을 별도로 둡니다.

관측해야 할 값

관심 영역의 품질은 평균 entity 수 하나로 판단할 수 없습니다. connection별 후보 수, 최종 replication set 수, byte 수, drop·defer된 update 수, spawn/despawn 지연, 각 filter 단계 시간을 함께 봅니다. 특정 map cell이나 관전 mode에서만 set이 폭증하는지 확인하려면 match·instance·connection을 식별할 수 있어야 합니다.

처음부터 복잡한 tree를 만들 필요는 없습니다. 작은 room 기반 게임은 instance 전체를 replication set으로 보내도 충분할 수 있습니다. player 수·entity 수·관전 기능·월드 크기 때문에 실제 병목이 확인될 때 grid, zone, frequency bucket, custom rule을 추가합니다.