業界のゲームでC ++はC#に置き換えられていますか?


23

業界のゲームでは、Quake、CoDなどのような意味です。


7
控えめに言っても非常に奇妙なアイデアであるため、アイデアを与えたものを簡単に説明すると役立ちます。
コンラッドルドルフ

2
Quakeの検討はCで行われます。;-)
共産主義者ダック

私はこの質問を自分で疑問に思っていました!
ジェフ

2
「業界ゲーム」では、通常「AAAタイトル」と呼ばれるものを意味するように聞こえます。
カオス

回答:


53

ある意味では、C ++は実際に置き換えられています-C#だけでなく、他の多くの言語によって置き換えられています。しかし、あなたが尋ねると、それは完全に置き換えられますか?-答えは間違いなくノーです。

これは、C ++が伝統的に2つの機能で使用されているためです。まず、ゲームエンジンを作成します。リソースをロードする低レベルコンポーネントで、物理シミュレーションでポリゴンをスクリーンに押し込み、数値を計算します。第二に、ゲームのロジックをコード化するために:ゲームプレイを行う実際のルール。

この2番目の容量には、C ++の長所(低レベルの詳細を完全に制御するなど)は必要ありませんが、その弱点(バグが発生しやすい手動コードメモリ管理など)に苦しんでいます。また、この2番目の容量では、C ++はさまざまなスクリプト言語に置き換えられています。多くの開発者がLuaを使用しています。Pythonを使用する人もいます。ただし、.NETまたはMonoのいずれかの形式でCLIプラットフォームが利用可能な場合、それは優れたスクリプトホスト候補となります。これらのプラットフォームは非常に高速で信頼性が高く、広く知られている言語(C#)と包括的な基本クラスライブラリを提供します。ツールを忘れないでください。MSVisual studioとSharpDevelop / MonoDevelopは、世界で最高のIDEではないかもしれませんが、非常に優れています。

そうは言っても、ゲームエンジンはC#(またはLua、またはPythonについて)で作成されることはありません。どうして?彼らは十分に速くないからです。

多くの一般的な信念に反して、今日の最大のパフォーマンスヒットはメモリレイテンシによるものです。これは、メモリへのアクセスが深刻なビジネスであることを意味します。また、マネージ言語では、ユーザーがメモリアクセスを制御することはできません。そのため、そもそも「マネージ」されています。そのため、マネージド言語では、非常に高速なゲームエンジンを記述できません。実際、私が考えることができるすべての大きな「C#」エンジン-XNA、MOGRE、Unity-はネイティブ C ++コードに基づいています。ただし、C#でゲームロジックを記述できます。

要約すると、 C#はC ++または他の言語の代わりに使用されます。しかし、少なくとも遅延のないインスタントアクセスメモリが発明されるまで、C ++に置き換わることはありません。


16
+1 Visual Studioは非常に優れたIDEです。それはダークサイド...であっても
マイケル・コールマン

1
Bah、私の経験では、C#はシミュレーションにも十分な速さではありませんが、それでも人々が挑戦するのを止めません。
BigSandwich

@Nevermind「マネージ言語」とは何ですか?
クアジイルファン

3
@iamcreasy広い意味で、「管理言語」とは、何らかの形式のガベージコレクションやメモリ管理を含む仮想マシンで実行される言語を意味します。より厳密には、マネージ言語は、共通言語ランタイム(の一部の実装)を対象とする言語ですが、私の答えはそれらだけに当てはまりません。
ネヴァーマインド

あなたの意見では、参照カウントされたGCスキームはこのカテゴリーに該当しますか?
weberc2

6

言語の選択はプラットフォームに大きく依存します。現時点では、Microsoftプラットフォーム以外では、実装として.NETが実際に必要になることはほとんどありません。

従来の知恵では、小さなプラットフォームは性能を発揮するために金属に近づける必要がありますが、一方で、管理されたプラットフォームはより安全です。これがおそらくWindows Phone 7で.NETの使用を強制される理由です。

新しいXboxがマネージドプラットフォームを必要とした場合、それは確かに興味深いでしょう。電話機のハードウェアがそれを処理できる(実際に処理する)場合、フルサイズのコンソールでそれらを使用しているのは確かです。すべてのゲームコードをスクリプト言語で記述せずにクロスプラットフォームのゲームを作成するのは難しいため、コンソールエコシステムをかなり混乱させます。その場合、C#はC ++に置き換わることはありませんが、密接に関連しています。

現在、Monoをスクリプティングバックエンドとして使用できます(Unityと同様)が、ほとんどのエンジンメーカーは独自にロールバックするか、C#よりもLuaやPythonのようなコンパクトなものを使用したいと考えています。

いずれにせよ、それはすべて、適切な仕事に適切なツールについてです。とにかく両方の言語を学ぶ必要があります。C#を使用すると特定の処理(ツール開発、サーバー開発など)が簡単になり、場合によってはC ++以外は使用できないためです。


現在、3年後、ゲーム開発のC#の状態はさらに進化しています。Mono-ProjectはXNA Game Studioを選択し、MonoGameにブランド変更しました。SharpDX、SlimDX、およびOpenTKは、すべて非常に適切なopengl / directxラッパーです。C#の物理エンジンもいくつか登場しました。Mono / MonoGameを使用すると、ゲームを一度構築して、Android、Linux、Mac OS、iOS、Xbox 360、PS3、PS4、およびWiiに自動移植できます。
ライアンマン14

3

ありそうもない。C ++には低レベルであるという利点があり、開発者は実際に最も細かい詳細を微調整して、可能な限り最高のパフォーマンスを得ることができます。

C#と.NETを使用すると、非常に便利なガベージコレクションがありますが、メモリとリソースが限られているプラ​​ットフォーム(ポータブルコンソールとある程度ホームコンソール)で作業する場合、最大限に活用するにはメモリをできるだけ制御する必要がありますリソースの。マネージ言語がメモリを割り当てて解放できるようにすると、多くの問題が発生する可能性が高くなります。

速度も問題になります(おそらくそうではありませんが)。時間が経つにつれて、マネージ言語がC ++コンパイラと同等のパフォーマンスを発揮できるようになると確信しています。

全体的に、とにかく私の経験では、ゲーム開発者はメモリ、CPU時間、およびリソース(可能な限り多くのパフォーマンスを絞り出すため)に関してはコントロールがおかしい傾向があるため、C / C ++が主に使用される言語です。


2

AFAIK .NET GC は、ワールドスタイルのアルゴリズムを停止するという問題を依然として抱えています。これはさまざまなアプリケーションに適していますが、ゲームのようなリアルタイムアプリには受け入れられません。

実際、GCにいくつかのブレークスルーがあるまで、リアルタイムプログラムにマネージ言語を効果的に使用することは非常に困難です。


1

いいえ。.NETに依存することは、PS3のような利用可能なフレームワークのないプラットフォームの大規模な書き直しを意味し、パフォーマンスの欠点はPCまたはLive Arcadeゲームでは完全に受け入れられるかもしれませんが、より大きなゲームではコンソールのパフォーマンスが十分に速く実行されます。それ以上に、C ++には既存の巨大なコードベースがあり、アップグレードしたとしても誰もアップグレードする余裕がありません。C ++はゲーム業界にあり、長い間そこにとどまるでしょう。


慣性は存在しますが、C ++コードベース自体はそれほど古くはありません-せいぜい10年です。3Dアクセラレータ、プログラム可能なパイプライン、データ駆動型アーキテクチャ、およびスクリプトのサポートのために、それらのほとんどすべてのコードがその期間中に置き換えられました。AAA開発者がC#に完全に移行したい場合、おそらく3つのゲームのスペース内で最小限のコストで実現できます-最初にツールおよびスクリプトホストとして使用し、次にゲームロジックレイヤーをそれに移動し、3番目のポート管理されたDX / GLラッパーを使用するレンダラー。

1
Monoには、PS3用の商用.NETソリューションがあります。
ダン・オルソン

。あなたはモノに対して、またはmonogame(XNAの交換)をC#でゲームを構築する場合、出向、あなたは内蔵のPS3 / PS4、Wiiとは、Xbox 360、アンドロイド、最大OSなどへのポートにそれをすることができます
ライアン・マン

0

ガベージコレクション言語がプログラマからメモリ制御を奪い、パフォーマンスが低下する可能性があるため、コンピュータのパワーが乏しい時代には、すべてをCまたはC ++でプログラムする必要がありました。

今日、コンピューターは高速になっていますが、Knuthが言うように、簡単に言えば、最適化は悪です。

  • 低レベルのコア機能を最適化する必要があることは明らかです。3Dジオメトリ、物理学、衝突、照明を計算すると、利用可能な最高のプロセッサがすぐに膨張する可能性があるためです。マシンの視覚的品質が上がると、ほとんどの場合パフォーマンスが大幅に低下することがわかります。

  • 現在、ゲームの状態、AI、サウンド、入力、ネットワークなどの他の機能があります。これらはゲームではまだ重要ですが、コンピューターリソースをほとんど使用しません。これらの機能は、ほとんどの場合、最適化する必要はありません。これがスクリプト言語とガベージコレクション言語の目標です。低レベルのものをコーディングしていない場合、これらの言語で書くコードは決してならないので、メモリの一貫性とアプリケーションの組織について考える必要はありません。ボトルネック。

2つのケースの例

  • トラックで500kgの家具を発送します。
  • ボートで30トンの材料を出荷します。

どちらも500 kmの距離にあります。

どちらの場合も、船/トラックをより速く動かすことができることを知って、全体の輸送時間を短くするために、積み降ろしプロセスを速くすることが重要ですか?

答えは次のとおりです。トラックで問題になりましたが、ボートでは問題ではありませんでした。

この比phorを理解しているかどうかはわかりませんが、ある意味では、数学的な問題を想像させることができます。これは答えを理解することよりも重要です。

スクリプト言語を使用すると、C / C ++でプログラムされたエンジンが既にある場合にゲームを高速化できます。3Dエンジンは低レベルの問題を解決するため、スクリプトでゲームを作成する必要があります。

ただし、低レベルのコンパイル済み言語を絶対に置き換えることは絶対にできないということを忘れないでください。静的に型付けされたコンパイル済み言語はパフォーマンスの中核であり、カーネル、3Dエンジン、グラフィックカードドライバーのいずれであっても、それらを除外することはできません。

しかし、もちろん、ゲームがグラフィカルにシンプルで、多くのベクトル計算を必要としない場合、ゲームプレイに集中して最適化を忘れることができます。この場合、マシンは非常に高速であるため最適化に対処する必要がないそのために

DSにポートを移植する場合を除きます。しかし、私はそこで停止します。


1
「最適化は悪である可能性があります」は、私が読んだ彼の声明の中で最も役に立たない変異バージョンです。

よく私はそれを説明している、それは私が彼の声明全体を引用するのに役に立たなかった理由である、それは非常に長い文であり、実際に説明されていない...より広範なソフトウェアKnuthが話したかったのです。
jokoon

あなたは、入力が多くのコンピュータリソースをほとんど占有しないことについて言及します。プレイヤーがゲームにより物理的に接続されるようになるにつれて、これは真実ではなくなることを指摘したいと思います。たとえば、kinect。入力の形式ですが、利用するには多くのコンピューティングリソースが必要です。
ポンカドゥードル

0

見て、私はこれが暴言であることを知っているが、私は毛を割っているだけではない。ほとんどのプログラマーはこれを実際に組み合わせていないように感じます。言語自体は、実行速度/パフォーマンスとは関係ありません。それはコンパイラ/フレームワークです。gccをcl(2010年以前のMicrosoftコンパイラー)またはmsbuild(2010年の現在のc ++コンパイラー)に対して議論した方がよいでしょう。これらのコンパイラはリリースごとに改善されるため、以前のバージョンと比較する必要もあります。私は.netに非常に感銘を受けており、優れたパフォーマンスを発揮しますが、わずかに優れたパフォーマンスであったとしても、それを引き継ぐことはありません。1つの理由:移植性です。

AAAゲームは、Windows、Linux、Mac、XBox、PS3、任天堂などに搭載されたい


確かにコンパイラー実装が役割を果たしますが、異なる言語はコンパイラー駆動の最適化に異なるアフォーダンスを提供し、プログラマーは通常の言語ルールを回避してハードウェアと直接対話するために異なるアフォーダンスを提供します。言語とターゲット自体は、パフォーマンスに大きく関係しています。

構文と標準ライブラリは異なるアプローチを好むため、言語は実行速度/パフォーマンスに大きく関係します。たとえば、すべてのオブジェクトがポインターであるために連続メモリの配列を使用するのが困難な言語は、配列またはベクトルを効果的に使用できる場所よりも多くのキャッシュをスラッシングする傾向があります。
キロタン

愚かな人々をin辱することなくあなたがしたかもしれない非常に良い点を+1、彼らは彼らが誰であるかを知りません。
火のカラス

を除いて、今日の時点で、モノに対して構築することができ、それはほぼすべてに移植されます。例えば、今では非常にポータブルです。
ライアンマン14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.