なぜオンラインゲームではFlashが使われないのか？

質問

• オンラインゲームでは、最近はゲーム会社独自のアプリをインストールしてゲームをプレイする方法が普及しています。
• 一方、Flashを使う方法はあまり見られません。
• これは、Flashが大規模なゲームや3Dゲームには向いていないためです。

回答No.6

natu2000 · ベストアンサー

>やはりFlashは表向きだけで、裏ではデータベースとはじめ色々なプログラムが動いてますよね。
>ネットワーク部を担っているのはJAVAでしょうかね？ここらへんでパケットやらの通信手段の話に入るわけですね。

そうですよね。質問内容からかけ離れすぎているし
また長い話を書き込みするのですがご容赦を(苦笑)

でまぁ仮にネットワークゲームを作るとすると(なんかもう作る前提の話になってますが、苦笑)
ゲームの進行状態(イベント進行中とか)とか(アイテムの有無など)状況だとか
少なくともそういう逐一セーブする必要が出てくるでしょう。
そうなるとデータベースなどにその状態を格納すると良いでしょう。

よくある3D系のMMOなRPGの(インストールするタイプのもの)場合、
クライアント側(クライアントソフト)の処理をパケットでサーバー側(サーバーソフト)へ送ります。

受け取ったパケット情報はサーバーソフト側で判断して、データベースに反映したり、
クライアント側へパケットを出します。これをクライアント側が受け取ります。

例えば、何かアイテムがあって、これを使用すると違うアイテムに変化するというアイテムが
あったとしましょう。

その場合は概ねこんな感じ。

クライアント側で、○○アイテムを使う
↓
○○アイテムを使うことをサーバーにパケットで伝える
↓
パケットを受け取ったサーバーは、まずデータベースを参照して○○アイテムの有無を確認
↓
該当する○○アイテムがあったので、そのアイテムの数を減らしてデータベースに反映する
↓
サーバー側でランダムで変化するアイテムを決める(結果は■■アイテム)
↓
サーバーは、変化した結果が■■アイテムであることをクライアント側にパケットで伝える
↓
クライアント側は、パケットを受け取って、結果○○アイテムの数が減って、■■アイテムを得る

という流れになります。

一見するとクライアント側でランダムで決めて結果を送る方法だといいように思いますが
そういう設計をするとクライアント側で都合のよい結果を送ってチートの温床になりかねません。

また大半をクライアント側で処理すようだと、
例えばこれがトランプみたいな種類の数と枚数の上限が決まっているようなカードゲーム系であれば、
勝手にクライアント側で決めていくと、場にスペードのエースが2枚とかなりかねないので
やはりの所でサーバーで判断しなければならないでしょう。

それで話をFlashに戻してみますが、
操作したりインターフェース的な見せ場な所はFlashで問題ないでしょう。
Flashもその気になればデータベースにアクセスできますからね。

http://www.adobe.com/jp/devnet/flash/articles/bfp_top.html

しかしalteilは、データベースのアクセス部分で
phpつかっているような気もしますので・・・・(多分、以下のとおり)

クライアント側はFlash(ActionScript)+phpを使用して、
サーバー側は何かサーバーソフトとデータベースって感じですね
(phpは、データベースとの連携が良いので良く使われていますので)

このときのサーバーソフトですが、まずFlash(ActionScript)では駄目でしょう。
この駄目な理由ですがFlash(ActionScript)の性質としてFlashファイルにアクセスしたときに反応して動くと思いますが

実行型のexeファイルみたいに実行して常駐したり待機して、何かの動作や情報がパケットとして流れたときに
反応できるような事ができないとサーバーソフトとしては難しいでしょう。

このあたりの動作仕様はFlashファイルをブラウザかFlashプレーヤーではじめて意味をなすタイプと違い
根本的に違うわけでFlash(ActionScript)では難しそうだと思います。
まぁそれがかなり先、Flashが進化をしてバージョンアップしてこういうことも可能になるとサーバーソフトもつくれるかも知れませんが今の現状では難しいでしょう。Flashはコンテンツとして見せるのには優れていますが、
そういうこととなると向いていないと思います。

そういう訳でサーバー機がWindowsであればソフトは何かWindowsソフトでしょうし
サーバー機がlinux系ならLinux系のソフトが動いていると思います。

あとこの時サーバーソフトがJAVAならサーバー機がWindowsだろうがlinux系だろうが
問題ないので面白いとおもうので、もしかしたらありえるかもしれませんが
JAVAはスピード的に弱いのであまりなさそうです。

しかしこの時点で少なくとも
・ゲーム部分の方でのFlash(ActionScript)が理解できるFlashエンジニア
・データベースと連携する為にphpとと連携ができるＷｅｂエンジニア
・サーバーソフトが作れてデータベースの連携ができるプログラムエンジニア

とか、それぞれ3タイプの分野の人か
何か全てを理解しているエンジニアが必要です。(Flashエンジニア兼Ｗｅｂエンジニア兼プログラムエンジニアみたいな人)
ここまであまりにもバラバラ過ぎると、よほど仕様か連携を決めていかないと
絶対暗礁に乗り上げるタイプのチョイスですね

つまりクライアント側のゲーム部分でFlashエンジニアが作るものの
明確な仕様がハナから決まっていないと、データベースとサーバー側が決まりにくいです
またFlashエンジニアがFlashしかわからない場合、話が難航してゆきます。
できれば全てを満遍なく理解しているエンジニアが必要になってくるわけですが
1つのプロジェクトに多種多様の言語が必要になってくると暗礁しやすい訳で・・・・・・

まぁそれよりもクライアント部分のFlash(ActionScript)+phpの個所ですが
インストール型でWindowsソフトのゲームを作った場合、この部分はまるまる解決します。

つまりWindowsソフトのゲームであれば、何も動的な部分でFlash(ActionScript)しなくて良いし
データベースへアクセスするのにphpでかかなくても良い訳です。
つまりFlashエンジニアもＷｅｂエンジニアもこの場合必要ありません。

仮にWindowsソフトのMMOゲームのクライアント側をプログラムエンジニアが作ったとしましょう。
続けてサーバー側もプログラムエンジニアが作製できる訳です。

まぁ実際に1人でつくるのはシンドイし時間も掛かるのでそういうエンジニアが複数必要なのは
目に見えるでしょう。しかしながらFlashエンジニアとプログラムエンジニア同士とか
ＷｅｂエンジニアとFlashエンジニア同士とか・・・・異なった言語同士で仕様をきめたり打ち合わせをしたりより
プログラムエンジニア同士の話なので少なくとも話も仕様決めるのもスムーズです。

ですので主にWindowsソフトを作れてデータベースにアクセスするソフトを書いたことがある
プログラムエンジニアが数人いれば、サーバーの部分、クライアントの部分がつくれるようになります。
(サーバーはWindowsということになりますが。)

また一般的にWindowsソフトといえばVB++とかVC++で作られていますが、
基本的に、複数の人数で作製することを想定しているので、1つのソフトを各モジュールごと割り振って
ライブラリやＤＬＬなどを各々が決めた仕様にそって作製して分担が可能です。

という事はですね
Flashエンジニア1人、Ｗｅｂエンジニア1人、プログラムエンジニア1人で計3人のコストより
プログラムエンジニア3人のコストで分担して作製したほうがコストが安あがりといえます。
(判りやすく数少ないように話をしています。)

まぁそう考えると優位なところ(制作コスト・工期短縮・モジュールごと割り振りとか)が無いので
こういう部分でインストール型のゲームが多いような気もしますし、
採用するにしてもFlashではカード系のみしかゲームにならないとか問題が多そうです。

ただアレですねFlashでは、ゲームの前にアップデートだとか必要なさげで良いし
ブラウザのFlashでプレイだと、MacやLinuxなんかでも動作できそうなので
そういう意味でもFlashはよさげですよね。

お礼

返事が遅れてしまって申し訳ありません。
こんなに長く付き合っていただいて本当にありがとうございました！残念ながら仰られる事すべてを理解することが出来なくて恐縮ですが、理解できるようにプログラミングやゲーム開発について勉強したいと思います！

本当に、本当にありがとうございました！！