ゲームへの案内

プロトコルは、マッチング完了後は次のような手続きを踏んでゲームを開始するようになっている:

1. マッチング完了の認識
2. MS->GS: ゲーム準備リクエスト
3. GS->MS: ゲーム準備OK
4. MS->CL: ゲーム案内通知
5. CL->GS: ゲーム接続

ReadyGameRequest には以下のメンバ変数が含まれている:

class ReadyGameRequest: public ExtMessage< 0xD2, ReadyGameRequest >
{
      uint16_t domainIndex;
      uint16_t matchIndex;

      uint16_t tagRoomId;
      std::vector< MemberInfoIon* > members;
};
class MemberInfoIon: public ExtIon
{
      std::string userId;
      std::string secret;
};

domainIndex

AssignRoomRequest をした時のドメインインデックス。

複数のルーム集合を扱う場合は、この値でどのドメインかを判定する。

matchIndex

AssignRoomRequest では複数のルームを確保する。このルーム集合に対し 0 から振られたルーム番号。

マッチングサーバー上でのルーム番号とは異なるので、混同しないように注意。

tagRoomId

マッチングサーバー上でのルーム番号。ゲームサーバーで使うことは無いが、ReadyRoomReqeust の応答に含める必要がある。

members

部屋に入っているメンバー情報。ユーザーID とシークレット文字列である。

シークレットは、マッチング完了時に生成していたもの。マッチングサーバーからゲームクライアントに渡され、ゲームクライアントがゲームサーバーへログインする時に示される。

このシークレット情報をどう扱うかはアプリケーションが決める。特にセキュリティの要請が無ければ、単なるワンタイムパスワードとして用いればよいだろう。

さて、サンプルゲームサーバーのハンドラ関数は次のようになっている:

void GameServer::handleReadyGameRequest(ReadyGameRequest* pMsg)
{
   ResponseMessage res(pMsg);
   uint8_t err;
   printf("<< ReadyGameRequest\n");

   res.setDomainIndex(pMsg->domainIndex);
   ReadyGameResponse::SetTagRoomId(&res, pMsg->tagRoomId);
   if (! checkMatchId(pMsg->domainIndex, pMsg->matchIndex)) {
      err = ResponseMessage::ERR_BADPARAM;
      goto fail;
   }
   {
      Game* pGame   = &m_vecGame[pMsg->domainIndex];
      Match* pMatch = &pGame->vecMatch[pMsg->matchIndex];
      if (! pMatch->open(pMsg)) {
         goto fail;
      }
   }
   goto fin;

  fail:
   res.setResult((err != 0)? err: ResponseMessage::ERR_UNKNOWN);

  fin:
   post(m_matchCommId, &res);
   printf(">> ReadyGameResponse: %d\n", res.getResult());
}