マルチプレイヤーゲームの実現には、ゲーム本体の開発の他に、他のプレイヤーとマッチングさせるために何らかのマッチメイキングシステムの開発が要求されます。このマッチメイキングシステムを設計する上で、その形態の違いが区別して認識できていると役に立つことがあると感じ、文章をしたためてみます。
マッチメイキングシステムの形態には2つの方法がある
プレイヤーをマッチングさせるマッチメイキングシステムの形態には、主に2つの方法が考えられます。1つは、1人のプレイヤーがルームを作成し、そのルームに他のプレイヤーが続々と入室することでマッチングさせる方法です。もう1つは、プレイヤーの参加リクエストを一時的に別の場所（プール）に蓄え、システムがそのプールから一緒にプレイさせるプレイヤーを選出することでマッチングさせる方法です。本記事では、前者の方法をルームベースのマッチメイキング、後者をキューベースのマッチメイキングと表現します。
ルームベースのマッチメイキングの特徴
ルームベースのマッチメイキングは、文字通りルームを基準にプレイヤーのマッチングを行います。ルームが基準になることで、以下のような特徴を持つと考えられます。
プレイヤーのリクエストに対して同期的にマッチング処理が進行する
ルームベースのマッチメイキングにおいて、プレイヤーがマルチプレイモードをプレイしたいなら、自分でルームを作成して入室しプレイヤーを募集したり、他のプレイヤーが作成したルームを検索して入室したりします。このようなルームに対して行ったアクションは、処理が同期的に進行するように実装されます。プレイヤーからすれば、起こした行動がゲーム内で即時に反映されることを期待しているはずだからです。
マッチングの主体はプレイヤー
ルームの作成・検索・入室は、基本的にはプレイヤーの主体的なアクションによって実行されます。プレイヤーは許可されているルームの作成・検索・入室するアクションの範囲内で、プレイヤー間で自由にマッチングのやりとりができるのです。つまり、マッチングの主体はプレイヤーに委ねられている、と言えそうです。
マッチングの文脈で登場するホストやゲストといった関係性は、このルームベースのマッチメイキングにおけるプレイヤー間のやりとりの一例です。ルームを作成したホストは、ゲーム内や外でゲストに招待メッセージを送り、ゲストはその情報を元にホストが待機しているルームに入室します。またホストは、基本的にはゲストよりもルームの操作に対して強い権限を持っています。例えば、ルームにパスワードを設定し、パスワードを知っているプレイヤーだけが入室できるようにしたり、ルームにプレイヤーが集まり次第、好きなタイミングでゲームを開始することができたりする権限を持っています。
マッチングが形成されるまでの演出が表現しやすい
ルームベースのマッチメイキングでは、プレイヤーがルームに逐次入室してくるため、その度にマッチングの情報が更新されます。これを利用して、マッチングが形成される演出が表現しやすいことも特徴として挙げられそうです。プレイヤーが続々とリアルタイムにルームに入室してくる演出は、昨今のゲームでもよく見られると思います。
キューベースのマッチメイキングの特徴
キューベースのマッチメイキングは、マルチプレイモードに参加したいプレイヤーのリクエストを一旦それを蓄える場所（マッチメイキングプールと呼ばれます）に移動させ、その場所から、定義した評価方法に基づいてプレイヤーを束ねることでマッチングさせます。このような仕組みを取ることで、以下のような特徴を持つと考えられます。
プレイヤーのリクエストに対して非同期的にマッチング処理が進行する
キューベースのマッチメイキングにおいて、プレイヤーがマルチプレイモードに参加したいなら、プレイヤーはその参加をリクエストするだけです。ゲームの UI に表示されている「参加ボタン」を押下するだけでマッチングに参加できるイメージです。システムは、このプレイヤーのリクエストに一旦応答し、以降はシステムでマッチングが行われることをプレイヤーに知らせ、非同期的にマッチング処理を進行させます。他のプレイヤーからのリクエストも受け付けているため、1プレイヤーから受け付けたリクエストと同じセッションでマッチング処理を進めることができないからです。
マッチングの主体はシステム
キューベースのマッチメイキングでは、プレイヤーはあくまでマルチプレイモードへの参加表明をするだけです。マッチングが成立して結果が分かるまでは、全てシステム側でマッチング処理を進行します。プレイヤー間のやり取りは、マッチングの過程では行われません。ホストやゲストといった関係性が生じることもありません。
一方システムは、集まっているプレイヤーのリクエストに含まれるプレイヤーの属性値を使用して、定義した評価方法に基づいてプレイヤーをグルーピングします。この評価方法は、ゲームへの成熟度に基づいたマッチングであったり、地理的に近いプレイヤー同士でマッチングであったり等、ゲームやそのモードによって特徴が表れる部分にもなるかと考えています。
このように見ていくと、プレイヤーはシステムにマッチング処理を一任し、システムが主体的にプレイヤーをマッチングさせている、という見方ができます。
マッチング形成の演出の実装を省きやすい
ゲームによっては、今誰とマッチングしているか、よりも、最終的に誰とマッチングされたか、をプレイヤーに提示したい場合があると思います。マッチングに時間がかからない評価方法を実現できているのであれば、わざわざマッチング形成過程の演出を用意する必要はなく、それを省いて他の実装に注力した方が都合がよいかもしれません。
キューベースのマッチメイキングでは、プレイヤーはあくまで「マルチプレイモードに参加したい」というリクエストだけをしています。そのため、最終的にマッチングが成立して無事に参加できた、というレスポンスが返却できれば、その過程で何が行われたかという情報が無くてもプレイヤーは納得感を得られます。このレスポンスは早く返却できるほど、よりプレイヤー体験を向上できると考えます。
評価方法をシンプルにすることがレスポンスの早さに繋がる
キューベースのマッチメイキングでは、レスポンスの早さがプレイヤー体験の向上に直結します。特に演出を省いた場合、プレイヤーからすればゲームの反応速度が唯一の期待項目になり、重要視することになるからです。
そこで、演出の実装を省く代わりに、マッチメイキングの品質向上に注力する場合に注意したいことがあります。それは、マッチングの条件を複雑にすることが必ずしもプレイヤー体験の向上に繋がるかどうか、です。これには一考の余地があります。
開発者は仕組みを知っているが故に様々な条件を入れてしまいがちです。その結果、条件に見合う相手が見つかりにくくなってしまっては、本来の「マルチプレイモードに参加したい」というプレイヤーの純粋な要求に対して逆の働きかけを助長することになり、非常にもったいないです。
プレイヤー体験の向上は、マッチングに参加するプレイヤーの母数の増加に繋がります。母数が増えればマッチングするプレイヤーが見つかる機会も増えるので、さらにマッチングが形成される時間も短縮できる、という良い連鎖が生み出せます。マッチングを素早く成立させるために条件をシンプルに整えることが、キューベースのマッチメイキングでは却ってゲームの品質向上に寄与するケースもあると考えています。
特徴の違いの認識が何の役に立つか？
これまで述べてきたことから、ルームベースとキューベースとでは、特徴が対照的になっていると推測できます。以下に対照表を示します。
| ルームベースの特徴 | キューベースの特徴 | |
|---|---|---|
| 処理進行 | 同期的 | 非同期的 |
| マッチングの主体 | プレイヤー | システム |
| マッチングの形成演出 | 表現しやすい | 実装を省きやすい |
この違いを認識することは、マッチメイキングの設計を考える上で重要だと私は考えています。なぜなら、これらのマッチメイキングシステムの形態の特徴は、ゲームの仕様や提供したいプレイヤー体験に関係してくるからです。
例えば、プレイヤーに操作の手間なく他のプレイヤーとマッチングさせてマルチプレイモードに参加させたい、という要件があるとします。この場合には、システムが主体としてマッチングを行うキューベースのマッチメイキングを選択する方が有効だと考えます。ルームベースのマッチメイキングを選択した場合、プレイヤーが部屋を作ったり、検索させて入室手続きをさせる必要があり、プレイヤーの操作の負担がかかってしまいます。キューベースであれば、プレイヤーの操作の手間もなく、不必要な演出も省けるので、マルチプレイモードへの参加を早く促すことができます。
他の例として、知っている友人同士のみでマッチングができる機能を提供したい、という要件があるとします。この場合には、キューベースのマッチメイキングを選択するよりも、プレイヤーが主体としてマッチングを行うルームベースのマッチメイキングの方が向きます。プレイヤーからすれば、ゲームの開始タイミングは友人が全員集まって準備が整ったことを確認した上で判断したいですし、開発者側からしても友人が集まってきているという進捗の演出が、ルームベースの方が表現しやすいですね。
このように、ルームベースとキューベースとでは、こちらの方が常に良い、ということではなく、プレイヤーに提供したい体験やそれを実現するゲームの機能及び演出によって、マッチメイキングシステムの形態を正しく選択することが肝要だと考えています。
Amazon GameLift を用いたマッチメイキング
AWS には、セッションベースのマルチプレイゲームの環境を提供する、専用ゲームサーバーをホスティングするマネージドサービス Amazon GameLift があります。GameLift では、ルームベースのマッチメイキングとキューベースのマッチメイキングのどちらも実現できます。
ルームベースのマッチメイキングの場合、GameLift がホスティングする専用ゲームサーバーに対してゲームセッションの作成(CreateGameSession または StartGameSessionPlacement)を行い、そのゲームセッションを対象にプレイヤーセッションを追加する(CreatePlayerSession または CreatePlayerSessions)、という段取りを踏みます。これらの操作は、GameLift API として提供されており、必要に応じてプログラムから AWS SDK 経由で該当する API を呼び出します。詳細についてはまた別の記事として執筆したいと思います。
キューベースのマッチメイキングの場合は、マッチメイキングに特化したマネージドサービス Amazon GameLift FlexMatch を使用することで手早く構築できます。マッチメイキングプールやプレイヤーのマッチングを処理する実行基盤は、AWS クラウド上でマネージドで提供されています。開発者は「FlexMatch ルールセット」と呼ばれる評価方法を定義する JSON ファイルを作成して指定することで、本来取り組みたいマッチングルールの調整に集中できます。FlexMatch については昨年執筆した拙著記事で取り上げているので、こちらもご覧いただけたら幸いです。
まとめ
マッチメイキングシステムの形態の特徴の違いを抑えた上で設計方法を選択するとよい、といったことを伝えたく、文章を書いてみました。
マルチプレイモードを搭載するゲームの仕様と、マッチメイキングシステムの設計方針がマッチするかどうかの意思決定に、1つの考え方として本記事がご参考になれば幸いです。
(免責) 本記事の内容はあくまでも個人の意見であり、所属する企業や団体とは関係がございません。