완벽한 MMO 서버 아키텍처에 대한 정보


9

원활한 MMO 서버의 모든 자료를 찾고 있습니다! "Massively Multiplayer Game Development"책과 "Game Programming Gems 5"에 몇 가지 기사가 있습니다. 누구든지 그 주제에 대해 경험이 있거나 그것에 관한 기사를 알고 있습니까?

나는 "높은 수준의 뷰"와 구현에 관심이 있습니다. 이것은 내 석사 논문의 주제가 될 수 있으며 실제로 논문을 시작하기 전에 그러한 시스템을 작성하는 것이 얼마나 어려운지 알고 싶습니다. 지금은 사용할 언어를 결정하지 않았으며 Java 또는 Scala에 대해 생각하고 있습니다. 얼랭은 선택의 여지가 있지만 그 일을 한 적이 없습니다.

참고 : 기본 요구 사항은 이동입니다. 다른 게임 시스템은 선택 사항이며 "보너스 크레딧"을 제공합니다.

이제 "원활한 서버"의 의미 : 모든 노드가 정적 경계를 사용하여 게임 세계의 일부를 제어하는 ​​서버 클러스터를 설정하려고합니다. 플레이어는 이제 인스턴스를 전환하거나 "텔레 포터"를 치지 않고도 세계의 한쪽 끝에서 다른 쪽 끝으로 이동할 수 있습니다. 와우가 그렇게 생각합니다. 그러나 백엔드에서는 플레이어가 한 서버에서 다음 서버로 전환합니다.


얼마 전 각 WoW 서버에 5 개 이상의 블레이드가 포함되어 있으며 각 대륙 및 데이터베이스마다 1 개가 있습니다. 이전에는 교차 영역 연결을 허용하기 위해 자체 클러스터에 상주한다고 가정하지만 던전과 전장으로도 사용되었습니다. 간단히 말해 대륙은 한 서버에서 유지됩니다. 대륙을 변경하지 않는 한 다른 서버로 전환되는 시점은 없습니다.
관용

흥미 롭습니다. 어디서 읽었는지 기억하십니까? 내가 말했듯이, 나는 절대 와우를하지 않으며 대륙의 크기를 모릅니다. 그러나 각 대륙이 하나의 별도 서버에 호스팅되어 있다고 상상할 수 없습니다.
Lurca

3
와우 서버 통계 : 총 13,250 개의 서버 블레이드, 총 75,000 개의 CPU 코어, 112.5TB의 RAM (GDC Austin 09 기준). 참조 여기 ; 반드시 모두 와우에 전념 할 필요는 없지만 합리적으로 충분히 가깝습니다.

@Josh Petrie : 감사합니다. 오늘이 기사를 찾았습니다. 그러나 나는 여전히 완벽하거나 지속적인 서버 아키텍처에 대한 것을 찾고 있습니다.
Lurca

답변:


5

이러한 시스템을 관리하는 데있어 주요 복잡성은 시스템이 얼마나 원활한 지에 따라 결정됩니다. Josh가 말했듯이 한 서버에서 다른 서버로 엔티티를 전달하는 문제를 해결하는 것이 패키지의 핵심 부분입니다.

그러나 이것이 유일한 문제는 아닙니다. 여러 서버의 엔티티가 한 작업의 일부로 상호 작용해야하는 경우 이제 진행하기 위해 각 시스템에서 다른 시스템의 데이터가 필요한 동기화 문제가 발생하지만 데이터가 도착할 때까지 이미 유효하지 않습니다. 한쪽을 되돌려 놓으면 롤백 기능이있는 작업을 여러 메시지로 분류하여이 문제를 해결할 수 있지만 "Massively Multiplayer Game Development"의 3.1 장에서 보았 듯이 이로 인해 게임 로직 이 크게 복잡해집니다. 이 작업을 수행하십시오. Scala와 Erlang은 메시징 시스템을 올바르게 구축하는 데 도움을줍니다. 10 줄 기능이었던 기능을 현재 추적해야하는 여러 가지 메시지와 상태로 분해하는 데 도움이되지 않습니다.

분명히이 문제는 완전히 새로운 것은 아니며 관계형 데이터베이스는 모든 데이터를 중앙에 저장하고 여러 클라이언트가 필요에 따라 트랜잭션을 롤백하여 필요에 따라 쿼리하고 변경하도록함으로써 이러한 종류의 문제를 지원합니다. 이것은 대부분의 정확성 요구 사항을 제공하지만 불행히도 비현실적인 성능 문제를 야기하고 게임 로직 구현을 어색하게 만듭니다 (논리의 대부분이 데이터베이스 저장 프로 시저에 작성되므로). 다른 종류의 데이터베이스는 특히 대부분의 RDBMS가 제공하는 안정성 요구 사항을 기꺼이 제거하려는 경우 여기에 좋은 솔루션을 제공 할 수 있습니다.

대부분의 프로페셔널 게임은이 문제를 해결하지 않고, 모든 플레이어를 하나의 서버에 놓을 수있을 정도로 작은 크기를 유지하고, 실제로 상호 작용하지 않는 부분으로 세계를 분할함으로써이 문제를 해결합니다 (위 주석의 WoW 예제 참조). 또는 지리가 아닌 기능에 따라 서버에 게임을 배포함으로써 (예 : 모든 전투는 한 서버에서 이루어지고, 모든 대화는 다른 서버에서 대화 함) 경쟁 할 '이음새'가 없습니다.


3

나는 "높은 수준의 뷰"와 구현에 관심이 있습니다.

구현은 일반적으로 합리적으로 깊이 관여하며 아마도 여기에서 많은 이야기를하지 않을 것입니다. StackExchange 소프트웨어는 이러한 종류의 토론에 적합하지 않으며, 누군가의 시간에 대한 상당한 투자가 필요하다는 것은 말할 것도 없습니다.

그런 시스템을 작성하는 것이 얼마나 어려운지 알고 싶습니다

다른 시스템보다 훨씬 더 어렵지 않습니다. 요구 사항과 운전하려는 기능에 따라 다릅니다. 사소한 구현을 사소하게 작성할 수 있지만 사소한 것은 물론 훨씬 더 어려울 것입니다. 더 큰 문제 중 하나는 시스템이 실제로 WoW 및 기타 게임에서 작동 하는 "대규모"수준으로 확장되는지 알 수있는 실제 클라이언트가 충분하지 않다는 것입니다 .

MMO는 마법이 아닙니다. 그들의 기술 대부분은 격리 된 상태에서 특별한 것이 아니며, 단지 몇 개의 더 작고 간단한 기술 비트가 매우 지능적으로 결합되어 일부 공유 세계 상태의 대규모 병렬 연결된 시뮬레이션을 가능하게하는 것입니다.

모든 노드가 정적 경계로 게임 세계의 일부를 제어하는 ​​서버 클러스터를 설정하고 싶습니다. 플레이어는 이제 인스턴스를 전환하거나 "텔레 포터"를 치지 않고도 세계의 한쪽 끝에서 다른 쪽 끝으로 이동할 수 있습니다.

본질적으로 당신이 말하는 것은 시뮬레이션 핸드 오프입니다. 이것은 매우 간단하게 수행 할 수 있으며 반드시 MMO 관련 기술 일 필요는 없습니다 (피어 투 피어 게임은 호스트 마이그레이션을 구현하기 위해 동일한 기본 메커니즘을 모두 지원하는 경향이 있습니다). 기본 전제는 각 서버가 서버 주변의 서버 토폴로지를 이해하도록 (특히, 월드 노드 A 용 서버는 시뮬레이션 인접 월드 노드 용 서버에 대해 알고 있어야 함) 고려해야하는 버퍼를 정의하는 것입니다. 인접 서버에 "가까운"특정 시뮬레이션 된 엔티티.

엔터티가 "닫기"버퍼에 들어가면 인접한 서버에도보고를 시작합니다. 엔터티가 실제 임계 값을 초과하면 엔터티의 전체 상태와 함께 메시지를 인접한 서버로 보내고 인접한 서버가 엔터티를 인계해야한다는 메시지를 보냅니다. 분명히 당신은 이것이 가능한 한 신뢰할 수 있기를 원합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.