6

他のクライアント側スクリプト言語に関するスタックオーバーフローの質問をたくさん見てきました

インターネットは、コンテンツが豊富でダイナミックな場所になりつつあります。HTML と CSS の仕様は、Web を次のレベルに引き上げようとしています。全二重のクライアント サーバー通信に非常に適した WebSocket のサポートを得て、いくつかの魅力的なデザイン パターンを出現させています。また、JavaScript での WebGL の実用的な実装もあり、これまでのところとても楽しいものでした。

しかし、これは、少なくとも私にとっては、いくつかの懸念を引き起こしました. 私はデスクトップ プログラマーで、C/C++/Objective-C です (プラットフォームによって異なります)。具体的には、レンダリング アーキテクトです。JavaScript は私たち全員に素晴らしいサービスを提供してきましたね。2DリニアWeb サイトで基本的なユーザー インタラクションを取得し、単純なイベントに応答し、それらすべてを HTML と CSS と組み合わせるために使用しました。

リアルタイム通信と GPU 駆動の視覚化の扉が Web に開かれたという事実を考えると、これは JavaScript に何らかの影響を与えるでしょうか? Dart や JavaScript を追い出そうとするその他の試みに対する反応を見てきました。JavaScript は弱く型付けされており、私にはあらゆる種類の警告が鳴ります (速度に依存する激しい数学ライブラリを考えると、不必要な実行時チェックは楽しい時間ではありません)。

多くのコードを GPU に移行しましたが、それでも社内のレンダラーは単に CPU バウンドです (HD6990 が問題になることはありません。デスクトップ/組み込みエンジンを駆動するコードは言うまでもありません)。

だから、ここにそれがあります：

  • インタープリターの設計により、コードはむき出しになっています。レンダリング技術とソリューションは、多額の価値があります。それは私の会社の唯一の基盤であり、請求書を支払っています。難読化はそれをカットしません（間違っている場合は修正してください）。VM で処理できるバイトコードの形式への中間コンパイル プロセスがないのはなぜですか?

  • 弱く型付けされています。行列、ベクトル、クォータニオン、配列、および高度にインタラクティブなアプリケーションに共通するその他すべての種類のデータをジャグリングすると、ランタイム チェックで処理が肥大化するだけです。最終的には GPU 側に行きますが、JavaScript によって行き詰まる CPU 側でかなりの量の作業を行う必要があります。

  • プロトタイプベースのパラダイムは、WebGL/WebSockets の採用を推し進めることができる主要なプレーヤーからレンダリング コードを移植する努力を弱めます。(その多くは CPU によって駆動されることに注意してください)。ますます多くのユーザーが忠実度の高い 2D/3D コンテンツを要求し始めるにつれて、プロトタイプベースのパラダイムは存続するでしょうか?

  • WebSockets は、動的な Web サイトは言うまでもなく、Web ゲーム (BrowserQuest) への美しい新しい追加要素であることが証明されており、将来、多くの人々によって素晴らしいコンテンツを開発するように推進されるでしょう (私の会社は、 WebSocket によって駆動される 3D 環境での小さな MMO )。

それで、私の懸念は現実に何らかの根拠がありますか？

これらの問題に関して何か新しい動きはありますか？

このトピックに対する回答があれば、個人的な意見を少し追加していただけますか? それが「Stackexchange の方法」ではないことはわかっていますが、他のすべての質問は正当であり、回答は実際に基づいている可能性があるため、害はありません。

4

3 に答える 3

6

あなたの懸念は、Javascript ランタイムがどのように機能するかについての誤解に基づいており、実際にはほとんど根拠がありません。

  • 現在、すべての Javascript コードは JIT 化されています。中間のバイトコード言語は不要であり、Web の最大の美点である移植性を妨げる可能性があると当初は考えられていました。アプリがバイトコードとして配布されていなくても、Python、Ruby、PHP などのプログラミング言語のような最新のスクリプトはうまく機能します。いずれにせよ、コードは最終的に JIT されるため、バイトコード ステップは必要ありません。JIT に提供できる資料が多ければ多いほどよいのです。実際、Java では、JIT コンパイラーが混乱するため、最近のバージョンではバイトコードの最適化を無効にしました。

  • JIT コンパイルは動的型付けの問題を最適化できますが、静的に型付けされたパフォーマンスが得られることはありませんが、十分なパフォーマンスが得られる可能性が高くなります。http://www.scirra.com/blog/76/how-to-write-low-garbage-real-time-javascriptにはいくつかの問題がありますが、Javascript の実装はこの種の問題を回避するために改善されています。たとえば、Mozilla Audio チーム (どちらかというとデモ チームに似ているようです...) は、Javascript ランタイムを最適化するための資料を用意するためだけに 3D デモを作成しています。

  • プロトタイプベースのアプローチが高忠実度と関係がある理由がわかりません。これらは2つのまったく別のものです

  • 現在、Google NaCL のような代替アプローチは、他のブラウザー ベンダーによって承認されておらず、Microsoft と Apple は Google のみのテクノロジを採用せず、Mozilla は NaCL をオープン Web に対する脅威と見なしているため、今後も承認されることはありません。

最新の JIT コンパイルがどのように機能するかについては、PyPy ブログhttp://morepypy.blogspot.com/を参照してください(Javascript 固有ではありません)。彼らは、最新のコンピューター サイエンスがコードに適用する JIT 最適化の種類を詳細に説明しています。

「Web のようなデザイン パターンが 3D で実現できること」については、3D コンテンツの jQuery のようなフレームワークである tQuery を参照してください https://github.com/jeromeetienne/tquery

乾杯、ミッコ

于 2012-04-06T12:40:51.397 に答える
2

  • Javascript コードがむき出しになっている: ご質問は「知的財産」の保護に関するものと思われます。コンパイルが提供する保護を過大評価していると思います。コンパイルは、適切な難読化よりもわずかに優れているだけで、アルゴリズムを隠します。優れた逆コンパイラは、とにかく隠そうとしているもののほとんどを明らかにします。コンパイルと難読化は、あなたのアイデアを盗もうとする人々からではなく、好奇心旺盛な人からあなたを守るだけです。コードの形式を保護したい場合、それが著作権の目的です。また、Web プラットフォームの成功の理由の 1 つは、実際には「ソースの表示」にあることも指摘します。これは、優れた Web サイトや Web アプリケーションの設計方法を学びたい人にとって、おそらく最高の教育ツールです。

  • Javascript は型付けが弱い: 確かに、大規模なデータセットで数学演算を行う場合は、固定サイズで、固定型/サイズの要素を持つ型付き配列を使用します。さらに、型推論 (Firefox 9) により、変数参照に関連するパフォーマンスが大幅に向上します。

  • Javascript はプロトタイプ ベースです。プロトタイプ ベースの継承は、標準のクラス ベースの継承よりも表現力があり、いくつかのシュガー関数を使用すると、Javascript でかなり標準的なクラス ベースの継承を行うことができます: http://www.crockford.com/javascript/inheritance.html

  • WebSockets : WebSockets に関する質問はなかったと思います。はい、それらはプラットフォームへの優れた追加機能です。特に、型付き配列と Blob データを直接送受信できるようにするプロトコルと API の最新の反復です。

意見:

WebGL と Javascript のパフォーマンスは、最新の AAA ファースト パーソン シューティング ゲームを移植できるレベルにはまだ達していません。しかし、近い将来 3D ゲームで実際に稼げるのは、カジュアルな Web ゲームだと思います。これは、Web 上のカジュアル 2D ゲームですでに証明されており、WebGL は十分に普及しており、カジュアル 3D ゲームを成功させる機が熟しています。

また、C/C++ 3D ライブラリに多額の投資をしている場合は、Javascript を対象とし、驚くほど優れたパフォーマンスを発揮するコンパイラであるEmscriptenを検討することもできます。

于 2012-04-06T14:15:04.293 に答える
1

これは非常に興味深いと思います。特に難読化の部分です。私自身、6 ～ 7 年前のように Web に切り替えるまで、何年もコンソール/デスクトップ ゲーム業界にいました。最初、ビューソースは私にとって非常に奇妙でした。しかし、徐々にそれが好きになり、テクノロジー ソリューションについて別の考え方をするようになりました。

確かに、ハイエンドの技術を開発するには多額の費用がかかります。また、アイデアやソリューションをコピーするのは非常に簡単です。また、公開した時点で著作権を取得したり、保護したりすることができないことも事実です. しかし、それは本当に問題ですか？この感動的な話だと思います...

http://www.ted.com/talks/lang/en/johanna_blakley_lessons_from_fashion_s_free_culture.html

...それがファッション業界でどのように機能するかについては、本当にうまくいきます. あなたが出したものは何でも完了し、歴史、次は何ですか？

あなたがまだ持っている利点は、私の経験から、実際のレンダリング部分よりも高価で複雑なツールとパイプラインです。そして、あなたはすでに経験豊富なチームとゲームを立ち上げており、うまく収益化できることを願っています。

また、余談ですが、オンライン体験は、多くの点でサーバー側に存在し、保護されているグラフィックよりも、ソーシャルな側面に関するものだと思います.

あなたのゲームを楽しみにしています！

于 2012-04-07T16:01:09.593 に答える