Quick Comparison

room, match, channel, instance는 업계 전체에서 같은 뜻으로 고정된 이름이 아닙니다. 이름보다 누가 상태를 소유하는지, 누가 들어올 수 있는지, 언제 사라지는지, 다른 공간으로 어떻게 이동하는지를 계약으로 정합니다.

party 생성
  -> matchmaking queue 진입
  -> match 확정
  -> instance 할당 또는 생성
  -> player session을 instance에 attach
  -> 결과 저장 후 instance 종료 또는 재사용

이름보다 상태 소유자

instance는 보통 entity, timer, RNG, spawn, combat log처럼 독립적으로 진행되는 simulation state를 소유합니다. 두 dungeon이 같은 template map을 쓰더라도 몬스터 체력과 문 열림 상태가 다르면 서로 다른 instance입니다. instance를 담당하는 server process가 바뀔 수 있다면, process ID와 instance ID를 같은 값으로 취급하지 않습니다.

match는 게임 규칙상 같은 결과를 공유하는 참여 관계입니다. 한 match가 하나의 instance를 쓰는 게임도 많지만, 관전용 instance·재접속 대기 공간·여러 round가 섞이면 일대일이라는 가정을 깨기 쉽습니다. matchId와 instanceId를 분리하면 결과 저장과 서버 이동을 추적하기 쉽습니다.

room은 더 넓은 이름이라서 계약이 없으면 가장 빨리 모호해집니다. 채팅 room인지, 5인 전투 room인지, 같은 channel의 모든 플레이어를 가리키는지 코드와 protocol에서 명시합니다. 새 기능이 room.players를 읽을 때 어떤 종류의 room인지 몰라도 되게, Lobby, Match, WorldInstance처럼 책임이 드러나는 type을 나누는 편이 안전합니다.

입장과 퇴장의 계약

플레이어가 instance에 들어갈 때는 단순히 목록에 ID를 넣는 것 이상이 필요합니다. 인증된 session인지, 정원이 남았는지, 이미 다른 instance에 attach되어 있지 않은지, 필요한 초기 snapshot을 받았는지, input queue가 어느 tick부터 유효한지를 정합니다. 재접속은 기존 player state를 복구하는 일과 network session을 새로 여는 일을 분리해야 합니다.

종료도 같은 수준으로 설계합니다. match 결과와 보상 저장이 성공하기 전에 instance를 지우면 결과를 잃고, 종료된 instance에 늦은 packet이 들어오면 새 instance와 섞일 수 있습니다. 종료 상태를 closing으로 바꾸고 새 command를 막은 뒤, 결과를 확정·저장하고 session을 분리하는 순서를 정합니다.

자주 섞이는 구조

channel 선택 UI가 있다고 해서 channel마다 별도 simulation process가 필요한 것은 아닙니다. 반대로 같은 process가 여러 instance를 운영한다고 해서 모든 instance가 같은 tick과 성능 예산을 공유해도 된다는 뜻도 아닙니다. UI상의 선택 단위, matchmaking 단위, simulation 단위, 배포 단위를 따로 기록하면 확장 시점의 잘못된 분산을 줄일 수 있습니다.

작은 협동 게임이라면 lobby -> match -> instance 세 단위만으로도 충분할 수 있습니다. 처음부터 channel·shard·world server를 모두 도입하면 입장, 재접속, 모니터링, cleanup 책임만 늘어납니다. 실제 동시 접속, 월드 지속성, 지역 분리, 매칭 정책이 필요해질 때 단위를 늘립니다.