javascript - HTML5/WebGLでのMMO 3Dゲームの実現可能性

Question

誰かがこれについて考えたかどうかはわかりませんが、World of Warcraft、Lineage II、または Aion のようなゲームは、WebGL を介したブラウザー フロントエンドで実行可能ですか? これらの新しいテクノロジーを使って本格的なゲームを作りたい場合、考慮しなければならないことは何ですか? また、どこから始めるのが良いでしょうか？

Answer 1

これはあまりにも自由すぎるかもしれませんが、突き刺します。

まず、私の知る限り、期待どおりに出力するモデリング プログラムはありません。なぜなら、javascript を出力する必要があるからです。

一部のブラウザーはハードウェアを使用してグラフィックを高速化しますが、これは保証ではなく、他のタブと共有して CPU を少ししか使用しないため、思い通りにスムーズに動作しない場合があります。

プログラムを実行するために大量のデータをダウンロードする必要がある場合、これはユーザーにとって問題になります。

基本的にすべてを手作業で行う必要があるため、モデリング プログラムは本当の課題だと思いますが、これを設計しない限り、非常にスムーズではないという事実が問題になります。

ただし、一部のゲーム デザインでは、WebGL が優れた選択肢となるはずです。

Answer 2

ゲームがハイトマップのいくつかのキューブを超える必要がある場合、それが可能だとは思いません。

• JS での大量のコーディングにブラウザーの癖が乗算されます。(はい、JQuery は知っていますが、万能薬ではありません)
• ブラウザ キャッシュの小さなスレッドに大きなリソースがかかっている
• Firebug などの多くのブラウザ ツールに公開されている、すぐにハッキングされるクライアント コード

このようなゲームは、特にハードウェア 3D を備えた今後の 11 バージョンのプレーヤーでは、Flash でよりリアルになります。

Answer 3

In fact it is fully possible, and we will se such games.

We can expect libraries like O3D to take care of the browser quirks. We already have these problems on desktop platforms and libraries takes care of multi-platform portability there.

Browser cache can be a slight problem, but not a big one. It is possible to assign more cache to games, and we also have proxy servers like squid that can cache very large resources. If a group of players on a LAN share a proxy server they will also share large resource objects, if the game are well designed (ie the resource cannot have multiple generated names, but be have a common URL for all players.)

Also there are discussions about adding local storage possibilities for web applications. And "ready to be hacked" is not a mayor issue. There are nothing to stop hackers from manipulating Flash or C++ applications, anti-cheating tools are already rendered useless. Blizzard is already relying on spotting "bot-like behavour" rather then try more anti-hacking measures.

However, I do not think that WoW will be the first flash-based games. In fact it will be Quake (http://playwebgl.com/games/quake-2-webgl/) as there is already a Quake-port for WebGL... There will be web games that makes use of WebGL, but do not count on Blizzard supporting it in the near future.

IE is the only browser that does not support WebGL and to be honest that does not matter. All other browsers do, and users will not mind running Chrome or Firefox. Or running both and choose the one that is faster for their game.

Who cares of marginalized browsers like IE and Opera. They are equally unimportant. Unless you count IE6 which will never support any of the stuff we are discussing, as it is discontinued and unsupported.

Answer 4

ローカル ファイルをキャッシュするには、現在 Chrome にあるファイル システム API を調べる必要があります。これにより、仮想ファイル システムへのプログラムによるアクセスが可能になり、ローカルに保存するリソースを制御できます。

アプリケーション キャッシュは、ゲームに必要な HTML、CSS、JavaScript などの静的リソースの処理に役立ちます。ただし、無制限のストレージを取得するには、「インストール済みの Web アプリ」として (たとえば、Chrome Web ストア経由で) 実行する必要があります。ブラウザーは、これを容易にするためにクォータ管理システムを構築しています。

WebGL は優れており、それを容易にするためのライブラリが登場しています。明確な「勝者」はありませんが、選択肢はたくさんあります。

CrankShaft などの改善のおかげで、最近の JavaScript は非常に高速です。パフォーマンスをさらに向上させるために、Native Client を使用して C/C++ コードを実行し、メッセージを JavaScript とやり取りすることができます。

私が見ることができる2つの大きな問題があります。1 つは、ミドルウェア企業が自社の作業を JavaScript または Native Client に移植するのを支援することです。2 つ目は、JavaScript から WebGL にデータを移動する速度を向上させることです。

Answer 5

「大量の（おそらくギグ）リソースを転送するコストを最小限に抑える方法を見つけることができれば」実際、httpには、静的リソースのギグを転送するための最小コストがすでにあります。ネイティブのリソース割り当てスキームであるURLにより、究極のキャッシュ機能を備えています。ブラウザは静的リソースをURLでキャッシュする方法を知っているだけでなく、テラバイトのデータを処理できる高速で効率的なプロキシサーバーが存在します。

これの主な秘密はHTTPHEADリクエストセットです。ここで、プロキシサーバーのブラウザは、リソースの最新バージョンがあるかどうかを効率的にチェックし、再同期できます。また、HTTPヘッダーを介して、リソースを永遠または非常に長寿命（不変）としてマークすることもできます。その場合、再同期は不可能になります。代わりに、新しい名前で新しいリソースを作成することによって更新が行われます。

HTTPは、実際には非常に効率的に設計されているにもかかわらず、リソース転送システムとしてはどういうわけか非効率的であるという神話があります。

プロプライエタリプロトコルを使用するWoWおよびその他のクライアントは、HTTPベースのクライアントと比較して非効率的であることが知られています。これらのクライアントは、プロキシサーバーを使用して高速化することはできません。Windows Update、Apt、Yumはすべて、OSリソースをHTTPで更新し、アカマイの膨大なグローバルネットワークのプロキシサーバーを他の同様のリソースの中で活用して、1あたり数ギガバイトの規模でURLリソースを効率的に転送できるという共通点があります。クライアント。