게임 아키텍처 설계의 핵심은 처음부터 효율성을 고려하는 것입니다. 지표, 로깅, 원격 측정 및 수익 창출에 너무 일찍 초점을 맞추면 게임 아키텍처가 과도하게 부풀어오르는 결과를 초래할 수 있습니다. 런타임 시 이 모든 것을 게임 서버에 포함시키면 실제로 투자 수익(ROI)이 줄어들고 총 소유 비용이 늘어날 수 있습니다.

대신 가능한 한 빨리 MVP(최소 실행 가능 제품)로 시작하세요. 서버를 실행하고, 클라이언트를 작동시키고, 넷코드와매치메이커시스템을 잠근 다음 거기에서 구축하세요. 또한호스팅 공급자를조기에 확보하는 것도 고려해야 합니다. 호스팅 공급자는 개발 시간을 절약할 수 있는 사전 구축된 솔루션과 인프라를 제공할 수 있습니다.

게임 디자인에 있어 단순한 것은 어떤 모습인가요? 위 이미지는 게임 서버 인스턴스뿐만 아니라 매치메이커, 로깅 및 메트릭 실행 파일을 포함하여 동일한 시스템에 있는 많은 보조 프로세스가 포함된 복잡한 디자인을 보여줍니다.

이러한 복잡성은 대규모 테스트를 시작할 때까지 반드시 명백해지지 않습니다. 이때 수천 명의 플레이어가 있을 때 이러한 것들이 제대로 작동하지 않는다는 것을 깨닫기 시작할 수 있습니다. 또한 보조 서비스에는 리소스 펜싱이 없을 수 있으므로 시스템의 리소스를 잠식하고 플레이어 성능에 영향을 미칠 수 있습니다. 일을 단순하게 유지하면 이러한 문제를 완화하는 데 도움이 될 수 있습니다.

게임 서버 설계 측면에서 단순이란 단일 실행 파일과 같은 단일 서버 인스턴스와 탄력적인 매치메이커(머신이 아닌 백엔드 서비스에서 호스팅될 수 있음)에 항목을 포함하는 것입니다. 이렇게 하면 게임 서버 중 하나가 손실되더라도 다른 플레이어가 이를 가져가지 않고 영향을 받는 영역이 작게 유지됩니다. 대규모로 보면 이러한 디자인의 게임 서버가 오작동하더라도 플레이어 경험에 영향을 미치지 않습니다.

비용 위험을 최소화하려면 디버깅, 감시자, 매치메이킹과 같은 보조 프로세스를 동일한 컴퓨터에 유지하지 마세요. 게임 서버가 중단되고 확장 가능한 클라우드 머신이 있는 경우 보조 프로세스는 "좀비" 상태가 됩니다. 여전히 리소스를 소비하고 있어 스튜디오 비용이 많이 들고 종료할 방법이 없습니다.

대신, 게임 서버의 매치메이킹 및 디버깅 하위 프로세스와 같은 보조 프로세스를 만드는 것을 고려하여 단순하게 유지하세요. 그런 다음 게임 서버가 손실되면 백그라운드에서 실행되도록 두는 대신 하위 프로세스도 함께 사용합니다. 이 경우 서버가 작동을 멈추면 "좀비" 프로세스와 관련된 추가 리소스 및 비용 없이 다른 서버를 가동할 수 있습니다.

세션이 오래 실행되는 멀티플레이어 게임에서는 메모리 누수, RAM 사용량 증가 등의 문제가 발생할 수 있습니다. 이러한 문제는 게임을 대규모로 실행할 때까지 나타나지 않을 수 있습니다.

장기 실행 게임 세션과 관련된 몇 가지 위험은 다음과 같습니다.

• DDoS 공격: 지속적인 게임 세션 모델에서는 게임 인스턴스의 IP가 변경되지 않으므로 DDos 공격 가능성이 있습니다.
• 높은 클라우드 비용: 플레이어가 게임을 플레이하지 않더라도 항상 또는 거의 항상 활성화된 게임을 유지하려면 많은 비용이 드는 리소스가 필요합니다.
• 패치로 인한 중단: 게임을 패치하기 위해 종료해야 하는 활성 경기가 있어 플레이어 경험이 저하될 수 있으므로 패치 적용은 관리하기 어려울 수 있습니다.

짧은 게임 세션에는 여전히 위험과 플레이어 경험 고려 사항이 있습니다. 2인 게임이 단 2분만 진행되더라도 수십만(또는 그 이상)의 동시 매치를 진행하려면 비용이 많이 들고 위험도 따릅니다.

짧은 게임 세션에 대한 몇 가지 고려 사항은 다음과 같습니다.

• 높은 백엔드 로드: 짧은 게임 세션을 촉진하기 위해 백엔드에 대한 지속적인 API 호출은 막대한 부하가 될 수 있으므로 탄력성이 있어야 합니다.
• 인프라에 어려움이 있음: 짧은 세션 사이에 서버가 다시 시작되면 프로세스 로드 시작 시 CPU 및 RAM 스파이크가 나타날 수 있으며 이는 비용이 많이 들 수 있습니다.
• 강력한 매치메이커가 필요합니다: 짧은 세션의 경우 새 세션, 재연결 등에 대한 매치메이킹 티켓을 처리하려면 효과적인 매치메이커가 필요합니다.
• 서비스 품질(QOS): 물리적 위치가 아닌 실제 원격 측정 및 데이터를 기반으로 서버 지역을 결정하려면 게임 클라이언트에 IP 주소 목록을 실시간으로 보낼 수 있는 공급자가 필요합니다.
• 측정항목 및 원격 측정 데이터가 필요합니다. 문제가 발생하면 플레이어는 오류를 보고하기보다는 종료하고 다른 세션을 시작할 가능성이 더 높습니다. 짧은 세션에서 지표와 원격 측정을 얻지 못하면 게임에서 잘못되는 부분을 놓칠 수도 있습니다.

짧은 세션 기반 게임의 장점과 단점은 다음과 같습니다.

장점:

• 긴 런타임을 위해 안정화할 필요가 없습니다.
• 더 빠른 패치 지원
• 축소 용이성
• 유휴 상태 없음
• 각 세션의 로그 파일을 사용하면 더 쉽게 문제를 해결할 수 있습니다.

단점:

• 더 많은 콜백은 규모에 따라 더 많은 로드를 의미합니다.
• 재시작을 위한 클라우드 컴퓨팅 비용은 규모에 따라 사소하지 않습니다.
• 경쟁 조건
• 시작 시 MEM/CPU 급증
• 매치메이킹이 더 복잡해졌습니다.
• 기계 성능 문제를 숨길 수 있음

MMO와 같이 지속적으로 진행되는 멀티플레이어 게임에는 특정한 문제와 위험이 있을 수 있습니다. 예를 들어, 서버 간 플레이어 마이그레이션과 같은 상황을 지원한다는 것은 값비싼 서버와 강력한 하드 드라이브를 포함하여 보다 강력한 백엔드 시스템이 필요하다는 것을 의미합니다.

지속적인 게임 세션 설계에 대한 몇 가지 고려 사항은 다음과 같습니다.

• 예산 책정이 문제가 될 수 있습니다. 영구 세션을 수행하려면 보다 강력한 백엔드 시스템이 필요하므로 이것이 자신에게 적합한 세션 디자인인지 이해하려면 사용자를 기준으로 유지 관리 비용이 얼마나 될지 계산해야 합니다.
• 클라우드는 실현 가능하지 않을 수 있습니다. 지속적인 게임 세션에 대한 수요가 높기 때문에 클라우드는 프로젝트에 너무 많은 비용이 들 수 있습니다.
• 네트워크 품질은 매우 중요합니다. 지연 시간 및 지연 시간 관리는 플레이어를 위한 지속적인 게임 세션을 만들거나 중단시키므로 좋은 플레이어 경험을 위해서는 네트워크를 조기에 엄격하게 테스트하는 것이 필수적입니다.
• 패치 적용은 어렵고 위험합니다. 유지 관리와 관련된 가동 중지 시간은 플레이어에게 결코 좋은 경험이 아닙니다. 전반적인 경험을 개선하는 데 필요한 경우에도 마찬가지입니다. 유지 관리 시간에 관해 지역 사회와 소통하는 것이 중요합니다. 또한 여러 게임 버전을 동시에 실행하고 시간이 지남에 따라 패치를 적용하는 것을 고려할 수도 있습니다.

지속적인 세션 기반 게임의 장점과 단점은 다음과 같습니다.

장점:

• 서버는 항상 가동되어 실행됩니다.
• 더 짧은 게임 루프 가능
• 백엔드의 부하 감소

단점:

• 디자인하기가 더 어렵습니다.
• 시간이 지남에 따라 불안정함
• 세션 정리
• 유휴 상태 설계 필요
• 중매인을 인식해야 함
• A/B 패치에는 시간이 더 오래 걸릴 수 있습니다.

규모에 따른 잠재적인 플레이어 경험 문제에 대비하는 것이 좋습니다. 멀티플레이어 게임을 시작하고 실행하고 업데이트하는 것은 혼란스러울 수 있으므로 "카오스 탄력성"에 대한 상황별 테스트를 수행하고 게임의 백엔드가 이러한 혼란을 처리할 수 있도록 설정되어 있는지 확인하는 것이 중요합니다.

예를 들어, 모든 사람이 게임에서 충돌을 일으키고 동시에 매치메이킹으로 돌아오려고 하면 어떻게 될까요? 해당 상황에 대한 백엔드의 대응을 파악하고 해당 문제를 처리하도록 설정하면 장기적으로 골치 아픈 일을 줄일 수 있고 평판을 보호하는 데 도움이 될 수 있습니다.

출시 중에 게임을 패치해야 할 가능성이 높습니다. 그렇기 때문에 프로덕션 및 출시 중에 패치를 적용할 수 있는 기능을 갖춘 인프라를 구축하는 것이 중요합니다. 이를 통해 출시일의 혼란과 즉각적인 패치를 훨씬 더 빠르고 원활하게 만들 수 있으며 플레이어에게 미치는 영향은 제한될 수 있습니다.

이에 접근하는 한 가지 방법은 여러 버전의 게임을 동시에 실행하는 것입니다. 그러나 인프라가 여러 버전을 처리할 수 있는지도 확인해야 합니다. 또한 다양한 버전이 모두 포함된 샌드박스가 있어야 합니다.

여러 버전을 동시에 실행할 수 있는 기능을 이미 내장한 경우 패치를 적용할 때 다운타임이나 플레이어 중단이 발생하지 않습니다.

빈번한 규모 테스트는 매우 중요하므로 이를 도와줄 수 있는 제공업체를 찾는 것이 서비스 선택 시 주요 고려 사항이 되어야 합니다.

테스트를 확장하는 데 있어 중요한 것 중 하나는 서버 테셀레이션과 조각 모음입니다. 서버 테셀레이션은 중요한 비용 고려 사항입니다. 기본적으로 먼저 호스팅을 위해 저렴한 금속 기계를 사용하고 싶습니다. 플레이어 기반이 변동함에 따라 더 비싼 클라우드 시스템을 신속하게 제거하는 것이 더 비용 효율적입니다.

Game Server Hosting (Multiplay)비용이 많이 드는 시스템에 할당하는 것을 방지하므로 플레이어 수가 감소할 때 해당 시스템을 더 빨리 제거할 수 있습니다.

이를 수행하는 우리 시스템의 능력은 매치의 수명에 따라 달라집니다. 일치 기간이 짧을수록 값비싼 컴퓨터에 대한 할당을 더 빨리 종료할 수 있습니다. 경기 시간이 길어지면 경기가 끝날 때까지 기계를 종료할 수 없습니다.