C++/CLI環境でのOpenGLゲーム開発の是非

質問

こんにちは。さっそく質問させていただきます。

C++でOpenGLを用いたゲーム開発は一般的ですが、C++/CLIでのゲーム開発はあまり一般的ではないように思えます。これは邪道なのでしょうか?

私は現在OpenGLで個人的にゲーム開発をしています。それに関連するちょっとしたアプリケーションを作ろうと思い、CLIに手を出した(.Net系言語経験はありません)次第なのですが、これが非常に便利なので気に入りました。

そこでゲーム本体もCLIで開発してみたいと思ったのですが、最初に書いたとおり、これは邪道なのでしょうか。私がそう感じたのは、C#やJavaに関する情報は山ほどあるのに、CLIに関する情報はそれと比べると遥かに少ないからです。ましてやOpenGLと組み合わせているサイトは数える程しかありませんでした。

おそらくCLIがC#や新しいC++/CXに埋もれていたり、MSがCLIを非推奨にしたことや、通常のゲームでは.Netの機能が不要なことが理由なのだとは思います。そういう理由なら私はあまり気にしないのですが、もしCLI環境で開発することによって何らかの致命的な不具合が生じる恐れがある(Windowsに限定されるというのは気にしません)なら、検討し直さなければなりません。

具体的にどういうものかは思いつかないのですが、例えばネイティブコードに劣っている点があるとか、ネイティブで出来ることが出来ないとか…。

要領を得ない質問・分かりにくい文章で申し訳ございません。

ご存知の方、どうかご教授いただきたいです。

回答No.1

axsies

私の意見としては、「C++/CLIの利用価値はグルー言語以外にないから」ですね。
実際、.NETでメインを張る言語として使うにはC#に比べてかなり貧弱です。

まず、用意されてる構文が.NET 2.0相当の最小限のものだけです。
匿名メソッドや、イテレータブロック、LINQ式みたいなものはありません。
プロパティ定義も、C#の int MyValue { get; set; }みたいな、略記構文もありませんし。

.NETのライブラリは名前空間の階層が非常に長くなりがちです。
ですが、C++のヘッダにusing宣言を書くことはできません。
そのため、ソース側のあちこちでusing宣言書かなければならなかったり、直接System::hogehoge::mogemoge::function()みたいな書き方をしなければなりません。
非常に読みづらいコードになりがちです。

デバッグも非常にやりづらい。
VSのデバッガはネイティブ／マネージ混在モードというのがありますが、これがまた結構使いづらくて、
ネイティブモード中ではマネージコードの変数を見ることが出来ず、逆もしかりです。

IDEエディタのコーディング支援もあまりありません。

マネージコードの数値計算はピュアなC++の１０倍くらい遅いです。
ゲームロジックの数値計算（キャラやカメラのマトリクスを計算など）くらいはマネージコードでも十分ですが、
下回りのヘビーな計算（パーティクル、当たり判定処理、etc...）を書くには荷が重いケースが殆どです（当然、ゲームで求められるものによりますが）。
だからこそ、ネイティブコードでSIMDを使った計算や、ポインタベースでメモリアーキテクチャを配慮した高速化を書きたいわけですが、
混合アセンブリ中では肝心のSIMDやそれに関する型が使えません。（__m128型とか）
更に、ネイティブコードとマネージコード間では型変換が必要なので、
これをかなり巧く設計しなければパフォーマンスに影響を与えます。
ここがボトルネックになると、ネイティブコードを書くメリットが薄れてしまいます。

あげれば切りが無いのですが、結局こうした事情に加えて、実績のなさと資料の少なさがとどめを刺し、
「C++/CLIはネイティブコードのラッパーにとどめておいて、ゲームロジックはC#使った方が便利じゃん」
もしくは、
「ラッパー作るのめんどくさい！C++一本で作った方が楽だ！」
みたいなことになるわけです。

以上が私の所感ですが、まあ、やはりご自身で簡単なゲームかなんかを作ってみて判断するのが最良です。（無限湧きする敵をひたすら打ち落とすだけのシューティングとか、モデルビューワーとか）
言語は所詮プログラムを作るための道具ですので、
ご自身の目的を達成するのにこの言語は十分使える、と判断して使うのであればそれが王道ですし、
「誰も使ってないから」とか、他人が「アレは○○だからダメだ」と言っていた、という理由で使わないのであればそれは邪道です。
どのようなスタンスに到達しても、ご自身の経験としてマイナスになることはないかなあ、と思います。