（※2010年2月5日に書いた記事を転載しました）
ネット上で多少リアルタイム性のあるゲーム……と考えると、やはりソケット通信が必要になってくる。１秒ごとにサーバにあるデータを（PHPやら通して）見に行ったりするのは遅いし管理も大変だし何も起きてないのに毎秒サーバに意味のない負担をかけたりで不効率だ。
そこでソケット通信を採用し、何かあったときにクライアント（ゲームのプレイヤー側）またはサーバが自ら情報を送るようにしたいということになる。これなら無駄な通信も減るし、何より速い（とはいえ１つのクライアントが毎秒10回以上も通信するようなソフトは怖くてまだ作りたくないが）
ソケット通信に必要なもの
ただ、ソケット通信をするためには
のどちらかが必要になる。
１．は通信が増えるほど自分が普段ネットをするときの帯域が絞られたり家に知らない人の通信がバンバン飛んできたりでちょっと気持ち悪い。
そこで２．だが、一般人がウェブサイトを公開するために使うようなところではもちろんダメだし、多少の自由度があるところでも「同じサーバを共有している人に迷惑がかかるかもしれないので」独自ソフトを走らせることはできないのが普通だ。
どんなレンタルサーバと契約するのか
端的に言えば「root権限をもらえる」ところと契約しなくてはならない。「専用サーバ」と銘打ってるところと契約すればまず大丈夫だし、最近では共有サーバでも限りなく共有者に迷惑をかける可能性が低い「VPS」というサービスがより安価に登場してきている。
専用サーバなら、有名なさくらインターネットのエントリープランで月額７８００円。むろんこれより安いところもある。VPSならば月額３０００円くらいが普通で、１０００～２０００円くらいのところも出てきている。個人ユーザーに十分手が届く金額だ。
サーバを選ぶときの注意
専用サーバやVPSなら独自のサーバソフトを走らせられるわけだが、若干の注意も必要である。
「マネージメントサーバ」の存在
専用サーバでも、様々な管理を業者側でやってくれる代わりにこちらのできることを絞っているのが結構ある。マネージメントサーバ、マネージメントサービスなどと銘打っている。これは「やることはシンプルだけど、膨大な来訪者や膨大なデータをさばく必要がある」企業向けのサービスと考えていいだろう。「やることは複雑だけど、来る人はさほど多くない」個人のネットゲームには向かない。
そもそも自作のサーバソフトを動かせないことも多い。
ポートが自分で一切空けられないサーバ
ネットゲームではウェブサイトの閲覧、メール送信、FTPでの接続といったものと違うポートを扱うことになるわけだが、この自由が全くないと専用サーバやVPSでも全く意味がない。あまりこういうサーバはないのだが、念のため確認しておくべき。
お試しできるところ、初期費用が安かったり最低契約期間が短いところを選ぶ
実際のところ何ができるのかは、やはり使ってみないとわからないということもある。最近ではお試し期間を設けているところも多いので、まず使ってみるのがいいだろう。Web上から管理ができるところ／できないところ、最初からあれこれソフトが入ってるところ／入ってないところ、最初から色々動いてるところ／動いてないところ、色々違いもある。その過程で自分の手に余ることに気づいたり、知識が増えることもある。またお試し期間がなくても、１か月や３か月で契約を終えられて初期費用＋毎月費用が合計数千円……といったところならば諦めもつく。
国内の業者、国内のサーバ
やはり日本語のサポート・資料があるというのは心強い。また、国内にサーバがあると当然通信にかかる時間は短くなる。単純な通信でも
くらいの差は出る。リアルタイムでの応答が求められるゲームでは100ms(0.1秒)の差は決して無視できない。
ただし日本語で書かれている業者でもサーバが国外に置いてあることもあるので注意すること。
できればウェブサイトの公開場所は別に確保
ネットゲームを作りたいと思うような人ならすでに今ウェブサイトを持っていることがほとんどだろうが、VPSや専用サーバを契約したからといって今持っているページごと全部移動するのは避けたほうがよい。というのも、個人で契約するような安いところはたまにサーバダウンや障害が発生していることもあり、全部そこに任せるとウェブサイトすら見られなくなってしまうからだ。またウェブサイト用のデータ通信をよそに任せることで、ネットゲームの通信に専念させられるということもある。
サーバのプログラム
これについてはやはり自分で調べて作るということになると思う。というのも、ネット上で通信するゲームは通常のゲームと比べて格段に個々の環境による差が大きいからだ。ある環境で問題なく実行できた・機能したプログラムがよそではコンパイルエラーだらけで実行すらできない、なんてことはザラにある。
それを踏まえた上で勉強するなら、「チャットサーバ」で検索をかけてみるといいだろう。チャットサーバが作れれば原理的にはネットでリアルタイム通信するゲームは作れる。「誰かがサーバに発言を送る→サーバが参加者全員にその発言を転送」という文字情報のやりとりが、ゲーム情報のやりとりに変わるだけだ。
クライアント（Flash側）のプログラム
これはサーバのプログラムができれば比較的簡単である。
こんな感じで検索をかければいいだろうか。
Flashでソケット通信するときの注意
Flashはセキュリティのために、ソケット通信をするときにはサーバ側が「どこからのアクセスなら受け付けるか」という情報を返さなくてはならない。
http://www.google.co.jp/search?hl=ja&rlz=1C1GGLS_jaJP291JP303&q=843%E3%83%9D%E3%83%BC%E3%83%88+Flash
詳しくはこんな感じで調べるとわかる。
流れとしては、
こんな感じだ。
つまりこの場合なら、
この２つをサーバ側で常時動かしておけばいいということになる。
で、実際にやってみると……うまく行くこともあるが、上手く行かないこともあるという不安定なことになる。書いたプログラムが悪かったのかもしれないが、843ポートにまず \0が来て、情報を返したはずなのにその後9642ポートに \0が飛んでくるといったことが結構な頻度で発生する。仕方ないので、今は
というややしょっぱいプログラムを書いている。
ソケット通信のときはcrossdomain.xmlを置いておく手法は無理！
Flashが自分のファイルが置かれているのと違うサーバのデータを取得したい場合は、crossdomain.xmlというファイルを置いておき、「どのサーバからの要求に応じるか」を書いておくという手法をとる。
例えばhakagi.comにあるFlashから、gamebaku.comにある画像ファイルを取得して表示するなど。この場合gamebaku.comに「hakagi.comからのファイル要求に応じますよ」というcrossdomain.xmlを置いておく。しかしこれはただファイルを取得する通信のためのやり方で、ソケット通信のときには通用しない。
Adobeのサイトでも微妙に説明が混じっていてわかりにくいので注意。ググったときもよくcrossdomain.xmlを置いておく手法が見つかるので混同しないようにしよう。
