マッチングの解放

マッチングの解放

マッチングサーバー上のマッチングリソースが不要となり、またゲームサーバー側でも新たなマッチングを扱えるようになったら、マッチングリソースの解放をする必要がある。

これを行うのが ClearMatchNotify で、ゲームサーバーからマッチングサーバーへ送信する。

ClearMatchNotify 送信

GameServer の turnRun() に、ゲーム実装と終了処理が書かれている。 後半の INSTANT_MATCH に囲まれた部分が、ClearMatchNotify の送信処理である。 

#if !(INSTANT_MATCH)
         {
            nine::match::ClearMatchNotify msg;
            msg.domainIndex = i;
            msg.tagRoomId = m.tagRoomId();
            post(m_matchCommId, &msg);
         }
#else

domainIndex と tagRoomId でクリアするマッチングルームを指定し、送信している。

RoomModule::onClearMatch

ClearMatchNotify を受けたマッチングサーバーは、モジュールの onClearMatch を呼ぶ。 ここにルーム解放の処理を記述する。

また、マッチング使用中にゲームサーバーが切断されたなど、ルーム割り当てが消えた場合にも呼びだされる。

void SampleRoomModule::onClearMatch(Room* _pRoom)
{
   SampleRoom* pRoom = static_cast< SampleRoom* >(_pRoom);

   pRoom->unmatch();
   transactCloseRoom(pRoom);
}

bool SampleRoom::unmatch()
{
   return stateUnmatch();
}

まずは SampleRoom::unmatch() を呼ぶ。この関数はマッチング状態を終えるために定義した公開関数である。やっていることはベースクラスの stateUnmatch() を呼び、状態を遷移させているだけである。

SampleRoom::unmatch() を呼んだ後で、RoomModule の transactCloseRoom を呼び出している。 これは部屋を閉じるためのフレームワーク関数である。

このサンプルの仕様では、マッチング完了時には部屋を閉じることにしているので transactCloseRoom を呼んでいる。部屋を維持するような仕様では、また別の記述が必要となる。

ゲーム開始後すぐにマッチングルームを開放する場合

サンプルには、ゲーム開始後すぐに、部屋の割り当て自体を返上するコードも書かれている。

これはクライアントがゲームサーバーを提供するケースで使えるであろう。 というのも、クライアント上のゲームサーバーでは次のような要求が想定される:
  • ゲーム中に、マッチングサーバーの処理は不要。よってただちに解放してよい。
  • ホストできるゲームサーバーは一つ。よって新たなマッチングは受け付けない。
マッチングルームの割り当てそのものを消してしまえる。 
void GameServer::handleLoginGameRequest(LoginGameRequest* pMsg)
{
  ...

#if INSTANT_MATCH
      if (pMatch->isPlaying()) {
         nine::Communicator* p = getTransceiver()->getCommunicator(m_matchCommId);
         p->closeLater();
      }
#endif
}

行儀良く解放するには UnassignRoomRequest を送るべきであるが、ここでは手を抜いていきなり切断してしまっている。

マッチングフレームワークは、マッチングクライアントが強制切断した場合でも、正しく手じまい処理を呼ぶようになっているので、このように書いても問題ない。

親トピック: マッチング処理