답변:
플레이어 위치를 추적하기 위해 파일을 어떻게 사용할 수 있습니까?
플레이어 위치를 파일에 씁니다. 예를 들어, 고유 번호 (또는 GUID)를 가진 모든 플레이어를 식별하면 해당 파일을 파일 이름으로 사용할 수 있습니다. 파일에서 위치 데이터를 나중에 구문 분석 할 수있는 형식으로 작성하십시오. 예를 들어, 플레이어 # 467239가 해당 위치 ( x, y, z )에 467239.txt있는 20, 3, 19경우를 포함 할 수 있습니다 .
그러나 이는 데이터베이스에서 수행하는 작업과 다르지 않습니다. 데이터베이스가이 작업에서 "느리게"되어서는 안되며 디스크 IO 오버 헤드 나 IO 잠금이 더 많기 때문에 파일보다 훨씬 빠릅니다 (아마도 파일보다 빠름). 파일 시스템 기반 접근 방식에서 경합 (파일 당 여러 위치를 저장 한 경우)
아마도 당신은 런타임에 플레이어 위치를 저장하기 위해 DB 또는 파일 시스템을 사용하려고 했습니까? 이 작업을 전혀 수행해서는 안됩니다 .
런타임에 서버에서 다른 종류의 게임과 마찬가지로 플레이어 위치는 메모리에 유지되고 업데이트됩니다. 주기적으로 디스크 나 다른 영구 저장소에 저장할 수 있습니다 (예 : 플레이어가 휴식, 저장 또는 로그 아웃 할 때).
그러나 모든 플레이어의 위치를 모든 업데이트를 스토리지에 기록하는 것은 불필요하고 비효율적입니다. "대규모"플레이어 스케일과 유사한 것을 처리 할만큼 빠르지 않습니다.
위치 는 RAM에 있어야합니다 . (예 : 플레이어 캐릭터가 세계에 있습니다) DB를 작동 메모리로 사용할 수 없습니다. 당신은 할 수 있지만, 이것은 끔찍할 것입니다.
위치가 변경 될 때마다 정기적으로 위치를 저장해야합니다.
또한 모든 위치를 동시에 저장하지 마십시오. 서버 충돌시 지속성을 유지하려면 가능한 한 자주 게임의 여가 시간에 위치를 저장해야합니다. 배치별로 간단히 수행하십시오.
여유 시간이있는 동안 30 개의 위치를 저장하십시오.
클라이언트에 관해서는. 서버 소프트웨어 연결을 통해 (관련된) 게임 상태 업데이트를 받아야합니다. DB에서가 아닙니다 ... 그것은 비현실적이며 느리고 나쁘고 악하며 힘이 교란됩니다.
500 개 정도의 게임 틱마다 파일에 저장하기 위해 대기열에 별도의 스레드가 있습니다. 그렇지 않으면 모든 것을 RAM에 저장해야합니다.
내가 서버에서하는 일은 플레이어 방향 (벡터)과 마지막 위치를 저장하는 것입니다. 플레이어가 속도를 가지면 2 초마다 플레이어의 새 위치를 계산합니다.
클라이언트는 물론 자신의 위치를 가지고 새로운 방향 (벡터)을 서버로 보냅니다.
서버는 위치에 대한 권한이 있으며 마지막 확인 이후 클라이언트가 특정 거리를 이동 한 경우 위치 패킷을 보냅니다 (이로 인해 클라이언트가 동기화되지 않은 고무 밴드 효과가 발생할 수 있음).
이 모든 것은 물론 메모리에서 발생합니다.