ゲームのSTL、そうですか、それとも否定ですか？[閉まっている]

すべてのプログラミング言語には、コンテナ、アルゴリズム、およびその他の有用なものの標準ライブラリがあります。C＃、Java、Pythonなどの言語では、標準ライブラリなしで言語を使用することは実際には考えられません。

しかし、私が取り組んできた多くのC ++ゲームでは、STLをまったく使用しなかったか、ごく一部を使用したか、独自の実装を使用しました。それが私たちのゲームにとって健全な決定であったのか、それとも単にSTLの無知から作られたものなのかを判断するのは困難です。

だから... STLはぴったりですか？

プロのゲーム開発で働いていたとき、STLは未熟すぎて肥大化していました。しかし、それは10年以上前でした。

現在、私は軍事シミュレーションで働いています。軍事シミュレーションにはさらに厳しいパフォーマンス要件があります（フレームレートがFPSを下回ることはありません）。軍事シミュレーションでは、STLが至る所で使用されています。

STLを使用しないようにと言う人の中には、それが常に完璧であるとか、問題に対する最善の解決策でさえないという主張を使用する人もいます。しかし、それは質問への答えではありません。質問は次のとおりです。ゲームでSTLを使用することに本質的に問題はありますか？いいえ、ほとんどの場合、STLはユーザーが自分で思いつくものよりも優れた実装です。

STLの使用方法を知っていることを確認し、それをゲームで使用してください。いくつかの本を読んで、使用しているSTLの実装コードを見てください。

どうしてSTL を使用したくないのかを正確に把握していない限り、頭の中で、STL を使用することをお勧めします。

STLの特徴は次のとおりです。STLは、あなたよりも賢い人々によって開発されています。それは攻撃的であることや何も意図されていません。STLが実際にSTLを構築している人々によって開発されているというだけです。プラットフォームが許す限り実際に高速になり、一般的にはホームロールソリューションよりもはるかに堅牢になります（そして、ゲームのニーズのために、これは生の速度を心配するだけでなく、それと同じくらい心配になるはずです）堅牢性は、速度を必要とするよりもかなり多く、後者は前者なしでは意味がありません）。

STLが「世界の狭い視野」を強制しているという不満は、少しばかげているように感じます。それらはコンテナです。コンテナの操作セットは限られているため、それらの操作セットは限られています。これでジャイブしないことを何をしていますか？

ゲームにSTLを使用しない理由はほとんどありません。

メモリ割り当ての問題については、多くの人はこれを知りませんが、STLコンテナークラスのカスタムアロケーターを作成できます。アロケーターは基本的に、テンプレートに渡して割り当ての実行方法を決定するポリシークラスです。これらを使用すると、通常、選択したプラットフォームで問題のあるメモリの問題を回避できます。

もちろん、STLを使用していて、文字列を大きな非ポインター型にマップするなどの愚かなことをしている場合、手に大きな問題があります。

デフォルトのSTLにはかなりの数の問題があり、特にメモリの調整に関しては、ゲームでの使用が困難になっています。

EA STLなどのカスタマイズされたバリアントは、ゲーム用に特別に設計されており、メモリパフォーマンスとコンソールの使いやすさを大幅に向上させることができます。2016年にBSD-3条項の下で、GitHubにリポジトリを備えたオープンソースになりました。

マイク・アクトン（Insomniac Games of Spyro the Dragon、Ratchet＆Clank、Resistanceの名声）のエンジンディレクターは、ここで尋ねられたときにこのことについて言わなければならなかったものです。ゲーム開発者での使用に関連して、STLとBoostの両方について一般に尋ねられたことに注意してください。

STL / Boost、gamedevに属しますか？それの一部だけなら、どれですか？

ここで2つの異なることについて尋ねていますか？STLとBoostは別々に。しかし、実際には、私の答えは同じです。どちらかそれ自体に問題はありませんが、それらの使用はお勧めしません。いずれかの使用は、人々を奨励し合うのではなく、問題の解決策を見つける問題に対する解決策を。このソリューションは、手元のデータやハードウェアの制約などに対して常に適切である必要があります。STLとBoostはどちらも「世界」の視野が非常に狭く、その適切な使用は限られています。本当に、プログラマーを間違った方向にすぐに導くので、私は彼らを落胆させます。

また、ほとんどのプロゲーム開発者は、C ++よりもCに向かって努力していることに気付きました。

何らかの理由でSTLに既に存在するものを書き換えていることに気付いた場合は、停止します。STLを使用します。

STLは長年の分析と時間をかけて最適化されており、おそらくもっと効率的なものを書こうとはしないでしょう。それは、より単純な解決策が可能な場合にSTLを使用する必要があるということではありません（つまり、stl :: listではなく、既知の量があるときに配列を使用します）が、マップの独自の実装を書いている場合（基本的なデータ構造であり、ゲームの世界地図ではありません）、あなたはそれを間違っています。

STLはゲームに適していますか？絶対に。ゲームはソフトウェアの複雑な部分であり、STLは複雑さを管理するのに役立つ機能を提供します。

プラットフォームに適していますか？必ずしも。コンソール用に書いている場合は、メモリとキャッシュの使用に非常に注意する必要があります。STLはこれを非常に簡単にしません。

「ゲーム」を「組み込みハードウェアまたは特注のハードウェアで実行される高性能リアルタイムゲーム」と間違えることがよくありますが、区別することが重要です。一定の60fpsでフルスクリーンで実行しようとしないWindowsゲームを作成している場合、標準ライブラリが提供するツールを避ける理由はありません。

私はこれがパーティーに非常に遅れることを知っていますが、時間の変更と答えはとどまります。C ++ 11には大幅な変更があり、その多くはC ++と標準ライブラリのパフォーマンスを向上させるためです。STLやBoostを使用していない人は、新しい標準に追いついていない傾向があり、重要な改善を欠いているホームスピンソリューションはもちろん、常にそうとは限りません。

EAでの短い時間を除き、90年代半ばから今日までのすべてのプロジェクトでSTLを使用しました。反STL側には、それを使用しないというわずかに合理的な理由があると思います。それらはほとんどなくなりました。カスタムアロケーターは1つのソリューションであり、リザーブを使用することは別であり、値で物を渡すことは3番目ですが、これらは非常に単純であり、プログラマーはこれらを知っている必要があります。さらに重要なことは、アルゴリズムの使用です。コンパイラの作成者は、for_each（）の機能を正確に把握しており、コードを最適化できます。これは、ホームロールループでは発生しません。constオブジェクトのfor_each（）はさらに優れています。Microsoftは、シリアル化を含む多くの方法でfor_eachを最適化します。また、parallel_for_each（）があるAMPライブラリもあります。機会があれば、これについてコンパイラエンジニアに相談してください。コンソールコンパイラは使用されるものを最適化するため、鶏と卵の問題のビット。マイクロソフトはC ++ 11で非常に重くなり、次のXBoxも変わりません。PS4についてはわかりませんが、まだ入手していません。

カスタムアロケーターは、メモリの問題を処理する1つの方法ですが、別の（しばしば見落とされがちな）オプションは、クラスベースの新規および削除を使用することです。これにより、パフォーマンスが大幅に向上します。

BoostとSTLが問題を解決するという狭い視野を持っているという概念は、純粋な狂気です。STLとBoostには、特性とポリシーを介してカスタマイズ可能なものがいくつあるのか、驚きました。例として、大文字と小文字を区別しない文字列比較を探します。

長いリンク時間とコードの膨張に関して、新しい外部テンプレートがこれに役立つはずです。一般に、長いコンパイル時間は過剰な結合とpchの誤用に起因することがわかります。

ホームスパンでSTLを使用する最も説得力のある理由は、STLを支援できる何百万人もの人々がいることです。いつものように、時期尚早に最適化しないで、テスト、テスト、テストしてください。

これは、ゲーム開発のホットトピックです。おそらく上記のEASTLを除いて、個人的にはお勧めしません。ゲームのSTL（STLはもはや名前ではないため、技術的には「C ++標準ライブラリ」）には2つの主な問題があります。1）STLが使用されている場合、動的メモリ割り当ては多くの場合、ゲームのランタイムを浪費します。2）STLの使用は、ゲームアーキテクチャへの構造体配列アプローチを推奨しますが、配列構造体アプローチは、はるかにキャッシュフレンドリーです。

場合によります。プロジェクトの規模、プラットフォーム、タイムラインはどのくらいですか？

限られたリソースと大きなタイムラインと予算で大規模なプロジェクトに取り組んでいる場合、50万行のコードベースを見ている避けられない地獄を回避することで、多くのトラブルを回避できます。 STLが散らばっていて、フレームレートを30以上に保つことができず、さらにいくつかのアセットに適合するのに十分なRAMを消費し、構築に2時間かかります。

ただし、他の状況では、STLおよびBoostを適切に適用すると非常に役立ちます。私は、STL / Boostを選択して使用するタイトルに取り組んでおり、コーディングの絶対的な夢でした。バグ/リークが少なく、コードを維持しやすいということは、楽しい新機能をコーディングする時間が増えます。特に趣味プロジェクトの場合、それはモチベーション部門で大きな勝利です。

利便性のためにパフォーマンスをトレードするタイミングを知ってください！

私見私はそれがSTLがすでにうまく働いて、そしてそれが作られたタスクのために最適化されるのでそれが良い適合であると言うであろう。その上、あなたはゲームに取り組んでいるので、手元にあるツールを使用して、生活を楽にし、コードがバグを起こしにくくします。

ゲームのAI、ユーザーエクスペリエンス、またはそれ以上のような何かにまだ取り組むことができるのに、なぜ車輪を再発明する必要があるのか​​。テストとデバッグ？

STLは、よく理解している限り、ゲームでの使用にはまったく問題ありません。私たちのエンジンはかなり広範囲に使用しており、これまで問題になりませんでした。コンソール開発の経験はまったくありませんが、これはまったく異なる話かもしれませんが、すべてのPCプラットフォーム（Windows / Mac / Linux）で十分にサポートされています。

最も重要なことは、各コンテナタイプの長所と短所を理解し、実行しているジョブに適したコンテナを選択することです。

私の前の雇用主は、堅牢なカスタムコンテナクラスのセットの使用からSTLに移行しました。ビルド時間が長くなり、デバッグの容易さが低下しました。どちらもかなり重要です。最初から始めていた場合、STL（おそらくより使いやすい）は理にかなっていると思われますが、STLへの切り替えで、動作する高速でデバッグ可能なコードを捨てることを正当化する何かを得たことは私には決してわかりませんでした。

私の個人的なプロジェクトでは、STLが適合するかどうかはプロジェクトに依存します。Mike Actonスタイルのデータ駆動型のメモリおよびキャッシュアクセス最適化作業を実行しようとする場合、少なくとも独自のカスタムデータ構造を展開することを検討します。アルゴリズムやゲームプレイのプロトタイプを作成していて、パフォーマンス、スケーラビリティ、ターゲットプラットフォームなどを気にしない場合は、自動的にSTLを取得します。

これに関する私の2セントは、STLがうまく機能するということです。私はPC用の3Dゲームエンジン（AAA品質ではなく、十分に高度な-スクリプト化されたエンティティタイプ、遅延レンダラー、統合されたBullet物理学）を開発しており、コンテナーが主なボトルネックになるのをまだ見ていません。誤った3D APIの使用と貧弱なアルゴリズムは、私が入って、もう少しパフォーマンスを追求しようとするたびに（プロファイリングによって決定される）最良のターゲットでした。

私はSTLを使用してゲームを作成しましたが、気に入っていますが、うまく機能しているようです。

良い質問！より具体的な質問は、STLとBoostでは満たせないゲームの一般的な要件をいくつか示します。

私の経験では、コンソールハードウェアの厳しいメモリ制限により、カスタムアロケーターがどれほど賢いかに関係なく、あらゆる種類の動的なサイズのコンテナーは悪い考えになります。意図的な境界のないコンテナは、プログラマがデータセットの境界を制約しないコードを書くことを奨励します。追跡が困難な無数の変数によっては、メモリの制限を超える場合があります。私は、これが現代のゲームの不安定性の主な原因の1つであることを予感しています。

さらに、テンプレートを使いすぎると、大きなコードベースでコンパイル時間が非常に長くなり、実行可能ファイルのサイズが大きくなり、ps3の補助コアなどのキャッシュに収まらなくなります。

ただし、PCのみの開発の場合、STLとBoostは非常に優れていると思います。一般的なケースのソリューションは必ずしも理想的ではありませんが、多くの場合十分です。問題に対するあなたの最初の解決策は理想的とは決して言えず、不十分な点を十分に改善するか、改善します。

STLがゲームに適している場合、STLはゲームに適しています。

開発中に行われるすべてのテクノロジーの選択と同様に、長所と短所を比較検討する必要があります。独自のライブラリをローリングすると、単純にSTLを使用するよりも有益なメモリ使用量、パフォーマンス、生産性が得られますか？おそらく。ただしvector、より多くのメモリを使用する実装を作成するのは同じくらい簡単で、速度が遅く、既存のものと比較して機能を維持するには大量のメンテナンスが必要です。

他の人はゲームでSTLを使用することを避けるため、人々はゲームでSTLを使用することを避けるべきではありません。すべてのオプションを比較検討し、別の実装によって製品の品質が向上すると真に信じている場合は、使用しないでください。

ほとんどの質問と同じように、答えは決して「はいまたはいや」、黒または白ではありません。STLはいくつかの問題に適しています。それらの問題にSTLを使用しても問題ありません。役に立たないと想定するのは間違いですが、あらゆる状況で使用することが適切であると想定することは間違いでもあります。

ゲーム開発でSTLを使用する際に注意すべき最大の問題は、メモリの割り当てです。STLのデフォルトのアロケーターは、ゲーム開発の優先割り当て戦略にうまく適合しないようです。もちろん、カスタムアロケーターを使用することもできますが、STLを非STLコードベースに追加するかどうかを検討している場合は、これによりアイデア全体の魅力が失われます。

これに加えて、コードベースが非STLの場合、カスタムアロケーターを正しく実装するためのSTLまたはテンプレートの概念に精通している人がいない可能性があります。

この議論は次のように要約できると思います。

平凡に記述されたアプリケーション固有のコード<適切に記述された汎用コード<適切に記述されたアプリケーション固有のコード

自社開発のソリューションがカテゴリ3に分類される場合は、特定の問題に対する元の質問に対する答えを確実に知っています。STLはカテゴリ2に分類されます。そのため、「STL を使用すべきか」という質問をする必要がある人にとっては、おそらく答えはイエスです。

STLは、その高度な仮想メモリシステムにより、慎重なメモリ割り当ての必要性が少し低くなります（ただし、非常に注意する必要があります）。仮想メモリ機能が制限されているかまったくないコンソールや、途方もないキャッシュミスコストがあるコンソールでは、予測可能なメモリ割り当てパターンや制限されたメモリ割り当てパターンを持つカスタムデータ構造を書くのが恐らく難しいでしょう。（そして、PCゲームプロジェクトでも同じことをするのは間違いありません。）

私はこの質問は本当に大きな質問ではないと思う-私は私のYにXを使うべきですか？本当に答える唯一の方法は、自分で試してみることです。Xがうまく機能していると思う人は誰でも、それが恐ろしいと言う人を見つけるでしょう。そして、両方とも彼らのプロジェクトにとって正しいです。

他のほとんどの分野とは異なり、ソフトウェアの素晴らしい点は、希望どおりに機能していないことがわかった場合、後からいつでも変更できることです。このプロジェクトでSTLが機能していないことが後でわかりますか？それを取り除いて、その場所に何かを置きます。オブジェクト間で職務をどのように分けたかは気に入らないでしょうか？リファクタリング。オブジェクトを使用したことが気に入らない？それらをストレートCメソッドに置き換えます。それらを操作するためにすべてが構造体とメソッドに格納されているのが好きではありませんか？それらをC ++オブジェクトに置き換えます。

私はSTLに否定します。私の理由は非常に簡単です：

1. ゲームを書くのにSTLは必要ありません。大きなものでさえありません。
2. STLはコンパイル時間を劇的に増加させます。
3. コンパイル時間が長いと、開発の反復が少なくなります。

私は反復カウントを最も重要であると考えているので、STL、および反復を遅くする他の開発手法（そのための設計、コンパイルが必要なスクリプト言語など）には近づかない。

費用のかかる反復は、実際にほとんど何も起こらずに何かを成し遂げようとする人々の巨大な開発チームにつながります。私はそれを見て聞いたが、犯人の1人はテンプレートライブラリのコンパイル時間のようです。