vb.Netのゲーム開発

Question

VB.Netの大きな制限は、人々がゲームを開発するための言語として使用したくないことです。

Answer 1

通常、上位レベルの言語のスピードは、CやC++が最高の国である「深刻な」ゲーム開発から解放されます。しかし、ますます多くのゲームがゲームロジックをLuaやPythonのようなスクリプト言語にさらしています。

私はVBで開発されているインディーズゲームについて聞いたことがあります。例えば、ゾンビスマッサーズシリーズは、VBでJames Silvaによって開発されました。最近、C＃.netでDishwasher Dead Samuraiというゲームをしました。

マイクロソフトが出したXbox Live Arcadeフレームワーク（XNA）を調べることができます。あなたはVBやC＃でそれを使うことができます。

Answer 2

これは大きな問題であるVB.NETではなく、.NET Frameworkです。

具体的には、ゲーム開発は一般にC/C++で行われ、パフォーマンスは一気に向上します。 .NETフレームワークはこれに適していません。それと

は

Answer 3

VB.NETは、他の.NET言語と違いはありません.NETで開発されているゲームがあると述べました。

VBが遅いという認識はもはや当てはまりません。

ここにVBNA for XNA（ゲーム開発ツールキット）のlist of tutorialsがあります。

Answer 4

それの一部は、まだ低速な言語であるvbにまだ付いています。 （これは、それほど真実ではありませんでした.net frameworkの共通性のために以前のようでした）

あなたが高いフレームレート、高いレベル3-dグラフィックス、エッジゲームを出血して、必要なパフォーマンスを得るためにCまたはC++でそれを書いています。しかし、あなたが今日の多くのフラッシュベースのゲームで見るもののようなものをやっているならば、古いゲームで見ることができるものさえあれば、ほとんどの言語でIMHOできます。

Answer 5

ゲームプログラマにとっては、「遅い」ため、C++をC言語でも受け入れるのに時間がかかりました。私はすぐにマルチコア時代になると、並列実行はできるだけ速く単一のスレッドを実行するよりもずっと重要になるため、ゆっくりと消えてしまうと考えています。

現在、ピクセル/頂点/ジオメトリシェーダを使用してGPUで多くの処理が行われています。だから私たちは、「遅い」言語と考えられるもので書かれているかなり高度なゲームを見ている。

最後に、.NETは遅くはありません。ゲーム開発にとって厄介なのは、ガーベジコレクター（GCが大規模なボス戦で起きて遅れを引き起こす - それほど良くない）と、C＃とネイティブコード間で発生するマーシャリングの予測不可能性です。

幸いにも、GCとランタイムを含む.NETの仕組みを深く理解することで、これらの両方の障害を克服することができます。

VB.NET、C＃、Python、Rubyなど、管理された言語でゲームを試作することを強くお勧めします。それが遅すぎると判明した場合は、その一部をC++に変換します。

。NETはC++を管理しているため、ネイティブコードとマネージコード間の相互運用性はかなりシームレスになります。これにより、必要に応じて本当に重要な部分をネイティブに書くことができます。しかし、私はこれが事実であるとは思わない。最初に最も重要な最適化は、データ構造、アルゴリズム、および全体的なアーキテクチャに起因するものです。

Answer 6

他の人が指摘したように、ネットが遅いではなく、ゲーム開発のためにそれに立ち向かういくつかあります：ガベージコレクションの

1. 非決定論
2. 低ポータビリティは（Cに比べて特にVB.Netを使用するためとして）
3. 成熟したゲーム開発ツール/ライブラリ/フレームワークの欠如

。親愛なる主人はなぜですか？ :-)

Answer 7

グラフィックスにはMicrosoft XNA Frameworkを、Regualr WinFormsアプリケーションにはすべてのコードを含めることができます。 XNA Frameworkをインストールし、VB WinFormsアプリケーションからリファレンスを追加するだけです。

XNAが提供しなければならないすべての機能を利用したい場合は、XNAがうまく統合されているC＃を使用する必要があります。

Answer 8

スピード部分については、XNAベースのVisual3D.NETのようなエンジンは、管理されたゲームエンジンから優れたパフォーマンスを得ることは不可能ではないと私に確信しています。さらに重要なのは、C＃の使用が影響を与える唯一の部分であるデモンストレーションのいずれにおいても、CPUはボトルネックのようには思えません。 CPUが限られているにもかかわらず、エンジンがまだまだシングルスレッドなので、まだ50〜60％しか進んでいないため、今日のデュアルコアとクアッドコアCPU、そして明日のオクタボーダやヘキサデカコアでは改善の余地が非常にあります。私は多核時代にうまく拡張するアルゴリズムを最適化することが、使用する言語よりも重要になると思います。

エンジン全体に管理言語を使用することの良い点は、ゲームロジック/ AIに同じ高水準言語を使用するのが簡単だということです。ネイティブエンジンでは、このためにはるかに低速なスクリプト言語が使用される可能性があります。

C＃/ VB.NETなどの管理言語を使用すると、物理などのCPUベースのものが制限されることがありますが、もう一度、完全管理された物理ライブラリJigLibXがXNAに非常に感銘を受けました。

これはすべてC＃ですが、VB.NETにも当てはまりますが、最終的に同じILにコンパイルされているので、私は認識していないVBコンパイラにはいくつかの制限があります。