この記事について

オンラインゲームの一般的なシステム構成戦略についてまとめてみました。

私自身、オンラインゲームの開発PJに関わったことは数回しかありませんが、毎回毎回高い技術が必要で刺激的な仕事でした。PJ終了後も、次回携わったときはどうすればもっと良いシステム構成が作れるだろうと1人で考えたり勉強したりしておりました。

この記事では、業務経験こそ少ないながら、私が実務経験を通じて学んだオンラインゲームのシステム構成のパターンについてまとめました。

なお、エンジニアリングの知識があまりない方でも読めるように配慮しましたが、必要に応じて以下の記事などを読んでください。

オンラインゲーム開発に興味がある方に読んでいただけましたら幸いです。

P2P型システム構成

P2Pはもっともメジャーなオンライン対戦システムのシステム構成かと思います。Nintendo Switchなど、ゲーム機系のオンラインプレイはこの方式が多いかと思います。

P2PとはPeerToPeerの略でコンピュータ同士を直接つなげてゲームプレイをします。

クリックすると拡大できます

全くサーバなどを利用しないかというと必ずしもそういうわけではなく、以下の図のように司令塔的役割の管理サーバが存在し、そのサーバが最初の認証処理や対戦したい相手のアクセス先などを管理していることが多いようです。

クリックすると拡大できます

ここまで「ようです」「思います」という言葉を並べましたが、実は私自身、このP2P構成のオンラインゲームを開発したことはありません。

私自身WEBアプリエンジニアのキャリアが長く縁がなかったというのが理由かなと思います。※一応WEBにもWEBRTCという技術があり、一応WEBアプリでもP2P型ゲームは開発可能です。

P2P方式の問題点とその対策

P2P方式には一方で問題もあります。実務経験がない状況ですが、よくある問題点とその対策について簡単に触れます。

問題点１:ネットワークによっては使えない

P2Pシステムは端末のネットワーク環境によってはゲームプレイができないケースも多いです。典型的なケースはプロバイダと契約して自宅のインターネット回線に繋いだPCでゲームプレイをするケースです。

クリックすると拡大できます

プロバイダの契約、あるいは自宅のルーターによっては、クライアントBのように外のコンピュータへの送信は許していても外部からの受信を許しておらず、ルーターで止められてしまっているケースがあります。

元々、WIFI環境につながる端末はプライベートIPしか付与されておらず、外部からの通信をそもそも遮断しているという状況でした。メジャーなプロバイダや最新のルーターはNAT越え（NATトラバーサル）といった技術を採用して対応していることも多いですが、全ての環境が実現できているわけではありません。NAT越えの対応ができないと、P2P型のゲームを遊ぶことはできません。

問題点2:不正プレイの対策ができない

プレイヤーによってはクライアント端末のゲームアプリを改造したりしているケースがあります。ゲームプレイ中はクライアント同士の通信であるために第３者が監視することができず、いわゆるチートプレイを排除することができません。

クリックすると拡大できます

もしもランキング対戦をする場合、チートプレイ対策は重要です。P2Pだとシステム管理者の介入が難しく、ゲームプレイ中の直接的な対策がやりづらいという欠点があります。

一応アプリの定期アップデート、通信対戦前に管理サーバが認証を行い、アプリの不正改造検証などで対策をとっているそうですが、間接的な対策になってしまうというのが現状です。

以上がP2Pの概要でした。私自身経験がないシステム構成のため理論上のお話しかできませんでした。以降は私自身が構築経験のあるもう一つの方式、クライアントサーバ型システムについて解説したいと思います。

クライアントサーバ型システム

クライアントサーバ型のシステムとは、対人対戦であっても、ユーザー同士の直接的な端末接続は許さず、必ずゲームサーバが媒介となってゲームプレイをするシステム構成です。

クリックすると拡大できます

クライアントサーバ方式は必ずサーバを介するため、ゲームサーバがチートプレイの監視をすることができるという特徴があります。もしも不正なクライアントが不正なコマンドを入力してきても、ゲームサーバがチートの確認を行い、チート行為であった場合はそこで反則負けにしたり、正常なデータに書き換えることで、ゲームプレイを続行させたりすることができます。

クリックすると拡大できます

クライアントサーバ方式の弱点

以上のようなメリットを持つクライアントサーバ方式ですが、一方でP2Pでは発生しなかった弱点も生まれてしまいました。発生してしまった弱点を並べてみます。

弱点1:通信遅延が発生しやすい

まず、通信遅延が発生しやすいという弱点があります。

クリックすると拡大できます

P2Pであるならば、クライアントと直接接続しているため、通信遅延はクライアント間の距離だけですみました。しかしながら、クライアントサーバ方式ではサーバが必ず媒介するため２重の通信遅延が発生します。せいぜいミリ秒レベルの違いですが、この違いは格闘ゲームのようなコマンドと同時にアクションをさせるゲームとなるとシビアになり、何らかの工夫が求められます。

弱点2:ゲームサーバの負荷がたまる

２つ目の弱点が、ゲームサーバに負荷がたまりやすいという点です。

クリックすると拡大できます

P2Pの場合、対戦したユーザー同士の端末のリソースだけを考えれば問題ありませんでした。しかしながらクライアントサーバ方式の場合、１台のサーバでも複数組の対戦を処理することは当たり前にあります。こうなるとサーバに負荷がたまりがちになってしまいます。いかにサーバ側の負荷を減らすかを考える必要がでてきます。

クライアントサーバ方式の対策

以上のような弱点を踏まえて、クライアントサーバ方式も様々な工夫が施されています。この記事では、２種類の対策について紹介してみようと思います。

必要な処理をクライアント側に寄せる方式（従来型アーキテクチャ）

まず、メイン処理をなるべくクライアント端末に寄せ、ゲームサーバが行う処理を不正対策検知など最低限のレベルに押さえ、送受信するデータも最小限にすることでサーバ負荷、通信負荷を抑える方式です。

クリックすると拡大できます

基本的にこの対策が今の主流ではないかと思います。一方でクライアントに処理を寄せすぎているが故にPCスペックが重要になるという弱点があります。快適なプレイをするには必然的に高スペックPCを用意する必要が出てきます。スペックの低いPCだとカクカクしてしまったり、最悪ゲームプレイさえできない可能性があります。

サーバのスペックを強化したり負荷強度を高めることによってサーバ側に処理を寄せる方式

近年Google Stadia、Amazon Lunaといった巨大プラットフォームサービスが全く違う方式のオンラインゲームのアーキテクトを出しています。

この方式ではGAFAが持つ資金力、技術力を生かして、高スペック・大規模なサーバを用意しほとんどの処理をサーバが担当します。このようにすることで、クライアント側はコマンドの操作と、サーバから送られるゲーム画面を表示させることだけに専念できるので低スペックなPCやスマートフォンでも遊ぶことができるようになります。

クリックすると拡大できます

もっともこの方式も万能ではないと私個人は思います。特に通信遅延の課題は別アプローチで解決する必要があります。そのまま採用してしまうと、通信環境の良い状態では快適なプレイはできるものの、通信環境の悪い場所ではプレイができない恐れがあります。

５Gの登場で高速通信がますます実現されつつあるので、時間の問題かもしれません。それでも、なるべく多くの人がプレイできるようにと考えると、4Gなども配慮することになり、何らかの工夫が必要になると言えます。

クライアントサーバ方式の全体構成例

最後にクライアントとサーバの通信に限らず、クライアントサーバ方式の全体構成例をご紹介しようと思います。ポイントとしては以下2つです。

ゲームサーバに余計な負荷をかけない

サーバサイドではゲームプレイを担うゲームサーバに最も負荷がかかります。そのためにランキング管理など、ゲームプレイ以外でゲーム管理上必要な処理はなるべくゲームサーバが担当させないようにする必要があります。

クライアントとサーバの通信を最小限にする

すでにサーバが間に挟んでいる時点でP2Pよりも通信遅延が発生しがちです。そのため、サーバ間通信が発生しないように対戦中のプレイヤーは１つのサーバでプレイさせるなど通信を最小限にする工夫する必要があります。

あくまで一例ですが上記ポイントを対策したシステム構成が以下になります。

クリックすると拡大できます

工夫したポイントは以下３点です。

対戦状況管理サーバを用意して処理分散の基礎を作る

各ゲームサーバには対戦状況管理サーバに対戦状況を定期的に記録させます。逆にゲームサーバがゲームプレイ以外で行う処理はこれだけにし、あとはゲームプレイの処理だけに専念させるようにします。

対戦アサインサーバを設けてゲームサーバの負荷分散と冗長化を実現

対戦アサインサーバは対戦状況管理サーバのデータをみて、新規対戦希望ユーザーが対戦を求めているユーザーが現在どのサーバで待機しているのかや、どのゲームサーバが一番負荷的に余力があるのかを確認します。この確認を通じてゲームプレイをするのに適切なサーバをユーザーにアサインします。

このように新規プレイユーザーの初めてのアクセスの時は、ゲームアサインサーバを最初にアクセスさせることで、ゲームサーバの負荷を分散させるとともに、サーバの冗長化も実現しています。

ランキング集計は対戦結果集計サーバが担当

対戦状況管理サーバはメモリ管理の短期記憶が得意なミドルウェアを選定し、データの読み取りと書き込みが容易になるようにしています。もっともこのサーバだけだとデータの長期保存ができずランキング集計ができません。そこで対戦結果集計サーバが定期的に集計処理をバッチ処理として実行し、長期記憶が得意な対戦結果管理データベースに保存させます。このようにして、ランキング集計などは他のサーバが担当し、負荷を分散しています。

終わりに　ーさらなる学習をしたい人にー

以上が簡単ですが、オンラインゲームのシステム構成戦略のまとめでした。

今回扱ったものはあくまで概要で、実際の開発運用には今回触れなかった問題が数多く存在します。もしも本格的に学んでみたい方は以下の本をお勧めします。古い本ですが、私が初めてオンライゲームのサーバサイドを担当した際、何度も何度も読み返して勉強しました。

なお、私はまだ読めていませんが、こちらの本の著者が新しい本を出したようです。目次を見る限り、近年の新しいトレンドなどを踏まえた内容が記載されているように思えます。こちらもご興味がありましたら是非手にとってみてください。

また、今回はネットワーク通信やサーバ負荷の対策にフォーカスし、実際のグラフィック処理やゲームロジックなどには触れませんでした。どこかのタイミングで、グラフィックやゲームロジックの基本的なところも記事に起こしてみたいと思っていますが、この辺りを学びたい方は以下を紹介します。この本も古いものですが、ベースとなるところは勉強になるかと思います。

この記事を通じて、オンラインゲームに限らず、システム構築の面白さを感じていただければ幸いです。最後まで読んでいただきありがとうございました。

Photo by Javier Garcia Chavez on Unsplash