本コラムの第5回で、ゲームの実行環境としてSilverlightを使えるかどうかをテーマにしたときは Silverlightの表現力や性能を中心に解説しました。正式にSilverlight 3がリリースされた今では、ビットマップの生成やエフェクトによるピクセルの変換も可能になったため、2Dベースのゲームであれば十分な表現力を備えていると評価できます。今回は、Silverlightの通信機能を応用したオンラインゲームの可能性についてご説明します。

Silverlightの魅力はビジュアルな表現力だけではありません。ブラウザのプラグインとして動作するSilverlightアプリケーションは、ブラウザの機能やWebサーバーと連携した高度な通信機能を備えています。既存のWeb資産を再利用しつつ、Silverlightに移行する手法も検討できるでしょう。Silverlightがサーバーと通信する手段は、大きく2つに分かれます。

  • System.Net.WebClient クラスによる HTTP 通信
  • System.Net.Sockets.Socket クラスによるソケットを用いた低レベル通信

一般的なWebアプリケーションではHTTP通信でサービスにアクセスしますが、常にクライアントからサーバーに要求しなければ新しいデータを取得できない問題があります。HTTPはサーバーからデータを引き出すプル型の通信であり、サーバーから任意のタイミングでクライアントにデータを送るプッシュ型の通信ができません。HTTP通信はデータをリアルタイムで同期させることが苦手なのです。Cometと呼ばれる仕組みも考えられましたが、サーバーとクライアントの双方で特殊な実装が必要になります。

HTTPの要求と応答

Silverlightであればセキュリティの都合から通信範囲は限定されますが、ソケットも利用できるため、適切にプログラムすればオンラインゲームの通信にも応用できます。ソケットはHTTPよりも低水準な通信インタフェースであり、サーバーと接続を維持してデータを送受信できます。もし、すでにTCPで通信するサーバーが実装されているのであれば、サーバー側に大きな変更を加えることなくSilverlightのクライアントを開発するだけでゲームをWebベースに移行できます。

ソケットの接続

HTTP通信はURIで識別可能なリソースを操作することに適しており、多くのネットワークで認められている通信方式なので管理外のネットワークに属している状態でも利用しやすいという特徴があります。一方で、接続を維持しないため、通信が発生するたびに相手が誰で、どのような状態なのかを確認しなければなりません。ソケットはアプリケーション層のプロトコルから設計できるため、対象のゲームに最適な通信方法を選択できます。

Silverlightアプリケーションでのソケットは、多くのセキュリティ上の制約を受けるので注意してください。まず、Silverlightのソケットは外部からの接続を待機するリスナにはなれません。Silverlightアプリケーションはクライアントで動作するものであり、サーバーになることはないので当然でしょう。Silverlightのソケットが接続できるポートは4502-4534の範囲であり、この範囲外への接続は失敗します。サポートされるプロトコルはTCPのみで、現時点でUDPは使えません。到達順序や信頼性が重要ではないメッセージを扱う場合はUDPベースのほうが効率が良いため、将来のサポートに期待したいところです。

加えて、Silverlightのソケットがアクセスするサーバーは、セキュリティポリシーを配信しなければなりません。Silverlightのソケットは、最初にサーバーに接続するときに943番ポートに対してセキュリティポリシーを要求します。要求には、単純に次のような文字列が送られます。セキュリティポリシーは XML で表現されており、ポリシーファイルとも呼ばれます。

ポリシーファイルの要求

 <policy-file-request/>

サーバーは、943番ポートで通信を待機し、接続があればポリシーファイルを送信します。ポリシーファイルには、通信を許可するプロトコルやポート番号が記されています。ポリシーファイルの要求と解析はSilverlightの内部で暗黙的に行われ、サーバーが通信を許可すると判断されればソケットが接続されます。開発者は、ポリシーファイルを提供するサーバーを実装する必要があります。サーバーがポリシーファイルの要求に応えない場合、通信は失敗します。

ポリシーファイルの例

 <?xml version="1.0" encoding ="utf-8"?>
  <access-policy>
   <cross-domain-access>
    <policy>
     <allow-from>
      <domain uri="*" />
     </allow-from>
    <grant-to>
     <socket-resource port="4505" protocol="tcp" />
    </grant-to>
   </policy>
  </cross-domain-access>
 </access-policy>

上のポリシーファイルは、TCPのポート4505番を許可することを表しています。このポリシーファイルによる仕組みによってSilverlightクライアントは許可されたサーバーにのみ接続できます。

ソケットによる接続を維持した通信であれば、サーバーとリアルタイムな対話が可能となります。例えば、サーバー側にセッションルームを作成して他の参加者を募り、人数が揃ったところで通信対戦を開始するという流れを実現できます。誰かがサーバーに接続すれば、サーバーは現在接続中の他の参加者にメッセージを送って状態が変化したことを通知できます。HTTPでは実装が難しかった、多人数参加型のオンラインゲームも実装しやすいでしょう。

HTTPとソケットは排他的なものではなく、組み合わせて利用することもできます。認証やコンテンツの配信には既存のWebプラットフォームを再利用し、より低水準で細かい制御が要求される通信はソケットを使うという方法も考えられるでしょう。

近い将来Open Socialのような Web サービスと連動した多人数同時参加型のゲームなど、新しい遊びが登場するかもしれません。加えて、モバイル版Silverlightがリリースされれば、場所を問わずゲームにアクセスできるようにもなります。すでにFlashで実装されているオンラインゲームが数多くあるように、Silverlightもまたオンラインゲームの実行環境として大きな可能性を秘めています。

著者プロフィール:赤坂玲音

フリーランスのテクニカルライタ兼アプリケーション開発者。主にクライアント技術、プレゼンテーション技術が専門。2005年から現在まで「Microsoft MVP Visual C++」受賞。技術解説書を中心に著書多数。近著に『Silverlight入門』(翔泳社)などがある。