サーバ
オンラインゲームクライアントあれこれ
LAMP構成はサーバのお話です。サーバは誰かに何か要求されて初めて仕事が出来ます。その「誰か」に当たるのがクライアントです。あるサーバが別のサーバに要求する時、要求する側のサーバはクライアントの立場になります。要はサーバに何か言う人はみんなクライアントです。
LAMP構成を作ったのは、これをゲームサーバにしたいからです。では「ゲームクライアントは？」という話になるわけです。
① OS上かブラウザ上か…
ゲームクライアントがする事は「サーバに対して何か要求する事」です。例えばゲームで獲得したスコアをサーバに登録する。これも立派なクライアントの要求であり、サーバの仕事です。つまり、ゲームクライアントは「サーバにリアルタイムで要求を出せる」能力があれば、それがブラウザ上だろうと独自の実行ファイル上だろうと構わない訳です。
商用ゲームのような専用機はさて置き、PCやモバイル機を主眼とすると、ゲームクライアントが動く環境には「OS上」と「ブラウザ上」に大別されるかなと思います。
OS上で動くものとして、例えばWindowsであればexeファイルをダウンロードさせて提供するという方法が取れます。OS上で動くゲームクライアントの良い点は、OSに依存した動作や描画が出来るという事です。サーバと通信する部分さえ確立してしまえば、後はOSが許す限り何でも出来ます。DirectXでゲームを作っても、Windows
APIでも別に構いません。また、クライアントの環境にデータを残す事に特に制約もありません（セキュリティーは確保できなくなりますが…）。そのためかなり高品質で高負荷なゲームも作れます。ただ、これらの事は逆にデメリットにもなります。そのOS（環境）に依存する分、別のOSでは動かなくなります。その為、OS上で動くクライアント環境をマルチプラットフォームに対応させる必要が生じます。これは、OSの差異を埋めるミドルウェアを通すなどしなければ大変なのです。
一方、ブラウザは色々なOS上ですでに動いています。そして、ブラウザは「OSの垣根を越えた描画の仕組み」を提供してくれています。その仕組みの上に乗ったゲームクライアントを作ると、原理的にはWindowsだろうとMacだろうとUbuntuだろうと、そのゲームは動く事になります。これは大変なメリットです。デメリットは色々な環境で共通して動かすために、描画やパフォーマンス等の制約が厳しい事、そして「ローカル環境へのデータ保存」が基本的には出来ない事です。そのため、高負荷なゲーム作りは難しく、また永続的にゲームを続けるにはデータの保存先となるサーバの存在が不可避となります。また、ブラウザはいつでも閉じられる可能性があります。ゲームをしている最中にももちろんそれは起こります。その為サーバ側は次にブラウザ上のゲームが開かれた時に、直前までの状況を可能な限り再現する必要が出てきます。これを満たすため、ブラウザ上のゲームはかなり頻繁にサーバとやり取りをして現状をサーバに残していきます。常にセーブを続けている訳です。
ブラウザベースのゲームは殆どがサーバに依存しています。OS上で動くゲームクライアントにしても、サーバに情報を置くスタイルを取ると、クライアントだけでゲームが成立しなくなります。つまり、ゲームサーバがネット障害などで動かなくなるとゲームそのものが出来なくなってしまいます。またゲームサーバの運用が終わってしまうと、そのゲーム自体出来ません。これはクライアントサーバ型のゲームを作る上でとても重要な事に思います。
じゃ、OS上かブラウザ上かという話です。ん～今の流行を考えるとブラウザ上で動くゲームクライアントなのかなぁと思いますが、その判断にはゲームクライアントの現状をちょっと調べる必要がありそうです。
② ブラウザ上のゲームクライアントの選択肢
ブラウザ上でのゲームクライアントに必要な機能は何か？ん～～…、まずは「毎フレーム画面更新出来る事」かな。ブラウザは基本静的（出来あがった物を見せる）ですが、ゲームはその後に動き続けなければなりません。後は…「サーバと通信ができる事」。これは当たり前ですが、その方法を知らないといけませんね。あ、「ユーザの操作を受け付ける事」というのもあります。これらがあればサーバと通信をするネットワークゲームクライアントとして成立しそうです。
ブラウザに文字や絵が出るのは「HTML」のタグの指定があるからです。でも、それらは単に「表示して下さい」という指示です。ゲームを動かすには毎フレーム（もしくは描画しろと命令した時に）描画プログラムを実行する必要があります。毎フレームサーバに新しいHTMLを要求する事はもちろん無いわけですが、ブラウザ上で動くゲームがあるってことは、ブラウザにきっと毎フレーム呼び出しをする「何か」があるはずなんです。それを調べてみます。
足がかりとなる解説がありました（佐藤カフジの「PCゲーミング道場」：http://game.watch.impress.co.jp/docs/series/pcgaming/20100528_370220.html）。こちらの記事によると、方法論が4つ程に大別できるそうです。それは、
(1) CGIタイプ
(2) Ajaxタイプ（DHTML + JavaScript）
(3) 標準プラグインタイプ（Adobe Flash、Microsoft Silverlight）
(4) 独自ブラウザプラグイン
ほう…。自分なりに再解釈してみます。
(1)のCGI（Common Gateway Interface）とは、サーバがクライアントの要求を判断して「動的に」画面を作りだしてクライアントに渡す仕組みです。例えばアクセスカウンターはその代表の一つです。ユーザがあるホームページを見ようとサーバにURLを投げた時、サーバはそのURLに該当するファイルをクライアントに渡します。普通このファイルはHTMLとかJPGなどでしたが、これに「プログラム（例えば.cgi）」を指定する事が出来るようにしたんです。.cgiがURLに指定されると、サーバは指定のプログラムを起動します。そのプログラムは最終的にHTMLを出力します。でも、どんなHTMLを作るかはプログラムが呼ばれた時に動的に決まります。アクセスカウンターの場合は、直前の訪問数に1足した値を計算して、その数字を表現する絵を並べたHTMLを出力するわけです。これによって、ユーザは同じURLを指定しているのに別のカウント数を見る事になるというわけ。CCIを使うと確かに動的に画面は変わります。でも、サーバ側からHTMLが来るとそのページのリロードが発生してしまうため、リアルタイムなゲームというよりは、掲示板とかブログなどに向いている手法です。
(2)のAjaxタイプ…んと「えーじゃっくす？」…、調べましょう。AjaxのWikipediaによると、Ajax（Asynchronous JavaScript + XML）は「ブラウザ上で非同期通信とインターフェイスを構築する仕組み」とあります。もうちょっと噛み砕くと「JavaScriptを使った、ブラウザ上でいつでも通信ができて、動的に画面の一部を変更する仕組み」という事かな。お～、ゲームっぽい事が確かに出来そうですね。CGIにあったリロードが起こらないというのが大きな違いで、これはブラウザの機能の一つである「DHTML：Dynamic HTML」という仕組みを利用しているとの事。なるほど、ブラウザにはリロードしなくても画面の一部を変更する機能が元々備わっていて、それを利用したぜっというカラクリです。Ajaxを利用したページにGoogle Mapがあるそうです。なるほど、あれはマップを摘まんで動かすという物凄い動的な事ができちゃっていますが、あれはAjaxで作られている訳か…。Ajaxを用いたブラウザゲームも沢山あるようです。ほぉ～～。Ajaxの欠点は動かすプログラムをクライアント側にロードする必要があるため、起動に時間がかかるというのがあるそうですが、まぁそれは最初だけですから。
(3)の標準プラグインタイプ及び(4)の独自ブラウザプラグインというのは、要はブラウザの機能そのものを拡張しちゃおうというものです。標準プラグインの「標準」というのは業界で広く使われているという意味です。その一つAdobe FlashはAdobeが開発した2D描画に特化した描画システムで、ブラウザは表示をする役目をするだけにとどまり、ゲーム等の動作の本質はほぼすべてFlash側に任されます。なので、Flashがサポートする機能を駆使して何でも出来てしまいます。なのでFlashを使ったブラウザゲームは星の数ほど沢山あります。ただ、これはプラットフォーム（OS）がFlashをサポートしてくれなければならないんですが、MacのiPhoneとiPadはFlashを非サポートです。Microsoft Silverlightも標準プラグインの一つで、こちらも2D描画に特化していますが、.NET Frameworkを用いて開発出来るのが強みです。Flash程認知されている訳でもない気がしますが(^-^;、動的な画面をブラウザ上で作れるのは確かのようです。ただMac上ではMac版のSafariなど限られたブラウザでしかサポートされていません。サポートの実体はこちらのサイトにまとめられています（Silverlight システム要件：http://www.microsoft.com/ja-jp/silverlight/requirements.aspx）。標準プラグインを選択するというのは、こう見るとMacユーザをサポートするか否かという事に見えます。ん～…。
(4)の独自ブラウザプラグインは、そのプラグインですらも自分で作ってしまおうというものです。こうなるともうOS上で動くゲームを開発するのとほとんど変わりません。Windows用のプラグインを作れば、DirectXだって動かせてしまうわけです。もちろんブラウザで動かせるゲームではありますが、FlashやSilverlightと同様にブラウザは描画やユーザとのインタラクティブな所だけを担うに留まり、エンジン部分はそのOSの機能をフルに使えるわけです。独自ブラウザプラグインの最大の難点は、そのOS用のプラグインを開発しなければならないという手間です。これは…大変なわけです(^-^;。
という訳で、どうやらゲームとしてまともに動かせるのは(2)以降のようです。(2)は何かできるかもしれない、(3)は2Dであればかなり採用したい所、(4)はさすがに大変過ぎるので不採用…、となるとやはり多くのブラウザゲームが採用しているAdobe
FlashかMicrosoft Silverlightが選択肢！…と思ったのですが、いや待て、台頭する物がまだあるようです。
③ Unity web playerとHTML5
(3)の標準プラグインの強みは何と言ってもプラグインがもう開発されているという事でした。でも、Adobe
FlashはMacで動かない、Microsoft SilverlightもMac環境ではサポートしていないブラウザが多い…。これは両者ともちょっと先行き不安な感があるわけです。じゃぁやっぱり(4)か？となるのですが、こちらは開発コストが大変にかかります。これからWebゲーム作りたいなぁという人（＝今の僕(^-^;）がやれるものではありません。あら困ったな、選択肢が(2)になってしまう。
ところが、(4)の独自ブラウザプラグインの開発問題を解決してしまっているゲームエンジンがあります。その一つが「Unity」です。UnityはGUIベースで大変に高品質なゲームを開発できる環境を提供してくれています。何が素晴らしいって独自のプラグインなので3Dゲームだってガンガン作れます。Unityのブラウザ用プラグインである「Unity
web player」をクライアントPCにインストールしてもらえば、WindowsだろうとMacだろうと同じゲームが（原則的には）動くわけです。それだけではありません。Unityは例えばiPhoneやAndroidなどのモバイル環境、さらにはXbox360やPS3などでも動く環境を作ってくれます。しかも凄い事に、Unityは基本的にこれらの機能を無料提供しています！Unityには様々なライセンス（パッケージ）があり、ライセンス毎に出来る事、出来ない事が決まっています。その一覧はこちら（Unity
ライセンス：http://japan.unity3d.com/unity/licenses/）。これを見ると、無料版Unityでも十分なゲーム開発が出来そうです。特に「www機能を通してウェブデータにアクセス」がサポートされている。ここ重要！ネットワークを使ったゲームも無料版の機能だけで開発できるという事です。さすがに最新の描画等技術を駆使した凄い凝った事をしようと思ったら、Unity
Proなどの有料ライセンスを使う事にはなりますが、有料版Unityって他のゲームエンジンから見ても格安です(^-^;。個人で手が出せる範囲に値段設定しているのがまた抜け目な無い所。こういう事からも、Unityをブラウザクライアントの開発に使うのは物凄いありです！
「お、じゃぁUnityで」となりますが、もう一つ注目の仕組みが出来つつあります（2012.9現在）。それが「HTML5」。これはWikipediaによるとHTMLの5回目の大幅な改定案の事のようで2014年に正式に開始しようと策定しているようです。最大の特徴はそれまでのブラウザはドキュメントを見る機能が主だったのに対し、「アプリケーションを動かす機能に向上させよう」という積極的な試みがなされている点にあります。動的な2D描画を行うcanvas要素や3Dゲームをブラウザ上で表現するWebGLなどが盛り込まれています。つまり、もうブラウザの規格としてゲームを作れる環境を整えてしまおうというのがHTML5という訳です。2010.9現在で、WikipediaにあるようにHTML5を動かせるのはWikipediaから抜粋すると「2008年以降に発表されたウェブブラウザの多くは
HTML5 に段階的に対応している。Google Chrome 3.0 以降、Safari 3.1 以降、Firefox
3.5 以降、Opera 10.5、Internet Explorer 9 などであり主に audio要素・video要素・canvas要素への対応が進んでいる（2010年3月現在）」だそうです。3Dゲームを作るのに必要なWebGLの対応は2012.9現在のWilipediaによると、
【PC】
・Mozilla Firefox 4
・Google Chrome 8 (8は要設定、9から標準で有効)
・Safari 5.1 (要設定)
・Opera 12
【モバイル】
・Firefox for Mobile (Maemoは1.0から, Androidは4から)
・Android ブラウザは非対応
・iOS 5 は iAd の広告のみ対応
・Opera Mobile 12
となっているようです。なるほど、PCはそこそこな対応ですがモバイルは現時点ではあまり積極的ではないようですね。まぁ3Dだし(^-^;。でも今後のモバイルの高性能化とユーザ要求からして、モバイルのブラウザでもWebGL対応はなされると思います。あ、でも。WebGLについてInternet Explorerは現在未対応。Silverlightを推し進めるMicrosoftとしては自社のDirectXがあるわけで、そりゃそうなりますわな…。今後も不透明…。つまり、「HTML5を選択すると3Dゲームだと出来る人が限られる」という制約が付く事になります。2Dゲームならcanvas要素で何とでもなりそうなイメージがあります。
④ さっくり作りたいならAjaxかHTML5、マルチ環境でゴージャスならUnityで
ここまでWeb上の情報を頼りに調べてきて、FlashやSilverlightはかなり有用に思えました。しかし、これらは将来性がちょっと危ぶまれている感があります。一方で後発のUnityは独自のプラグインを作っているので、あらゆるブラウザに対応できているのが大きい利点です。これは今後のブラウザでもサポートがなされるという保障にもなっています。またHTML5はほぼ間違いなく近い未来のHTMLのスタンダードになるので、これを使ったネットワークゲーム作りを学んで置くのは貴重なスキルになるはずです。Ajaxはライトなゲーム開発に使えそうな気がしますが、昨今の流れからするとちょっと候補として下がるかなと感じます。
今自分がやりたいのは、クライアントとサーバが通信をするゲームの練習です。その為にUnityを持ちだすのはちょっと大げさな感じがします（実は楽なんだろうとも思いますが）。なので、ここは将来への布石の意味も込めて、HTML5で簡単な2Dベースのサーバクライアント型ゲームを作ってみようかなと思います。今の段階で、何をどうしていいかさっぱり知りません！さ～～楽しくなってきた(^-^)