最新のC ++とゲーム開発に関する考え方

ゲーム開発者にとっての新年は、Aras PrankevichiusによるModern C ++に関する苦情の発表後、C ++標準化委員会に寄せられた批判の波から始まりました。 重大な疑問が生じました。標準化委員会は現実との接触を本当に失ったのでしょうか、それともその逆ですか、そしてゲーム開発者は他のC ++コミュニティから分裂したのでしょうか？



Blizzard、Electronic Arts、BullfrogでC ++開発者およびチームリーダーとして長年働いていたゲーム業界のベテランである Ben Deanの人気投稿の翻訳を提供します。

TL; DR：C ++標準化委員会には、ゲーム開発者のニーズを無視するという隠れた目標がなく、「最新の」C ++は「デバッグされた」言語にはなりません。

先週、Twitterで活発な議論が行わ れましたが 、その間に、多くのプログラマー、特にゲーム開発の分野で働くプログラマーが、「モダンC ++」の現在の開発ベクトルはニーズを満たしていないと発言しました。 特に、通常のゲーム開発者の観点から見ると、言語でのデバッグパフォーマンスはすべて無視されるように見え、コードの最適化が期待され、必要になります。



私は2019年にゲーム業界で23年以上働いてきたという事実のために、ゲーム開発に関するこのトピックの観察に基づいて自分の意見を持っています。これを共有したいと思います。 ゲーム開発者にとって「デバッグ」は重要ですか？それはなぜですか？ それに関連する問題は何ですか？



はじめに-歴史に少し脱線します。



多くのC ++ゲーム開発者は、Microsoft Visual C ++で作業しています。 歴史的に、Microsoftプラットフォームを中心にゲームの巨大な市場が形成され、これは通常のゲームプログラマーの典型的な経験に影響を与えてきました。 90年代と2000年代、ほとんどのゲームはこれらの状況を念頭に置いて書かれました。 他のメーカーのコンソールの出現とモバイルゲームの人気の高まりにもかかわらず、今日の多くのAAAスタジオと多数のゲームプログラマーの資産は、Microsoftが作成したツールです。



Visual Studioは、おそらくC ++向けの世界最高のデバッガーです。 さらに、Visual Studioは、フロントエンド、バックエンド、STLの実装など、プログラムのデバッグに関して最も優れています。 過去5年間で、MicrosoftはC ++開発ツールの開発に大きな進歩を遂げましたが、それ以前であっても、Visual Studioのデバッガーは常に非常にクールでした。 したがって、Windows PCで開発しているときは、常に世界クラスのデバッガーを手元に置いています。



上記を踏まえて、バグのないコードを取得するプロセスを見てみましょう。 ゲームを扱っていないプログラマーの観点から見た機会。 ゲーム開発者が直面している制限と同様に。 「現代のC ++開発のベクトル」を支持して主な議論を言い換えると、型、ツール、およびテストに限定されます。 この考えに従って、デバッガーは最後の防衛線になるはずです。 それを達成する前に、次のオプションがあります。

機会No. 1：タイプ

必要なだけ強い型付けを使用して、コンパイル時にバグのクラス全体を排除できます。 強い型付けは、疑いもなく、最近のC ++の進化が私たちに与えた機会です。 たとえば、C ++ 11以降、次のようになりました。

• type traits
  
  
  
  重要な拡張;
• Cの遺産と戦うためのnullptr
  
  
  
  やscoped enum
  
  
  
  などの革新-弱い型付け。
• GSLおよび補助ツール。
• C ++ 20の概念 。

一部の人は、テンプレートのメタプログラミングを好まないかもしれません。 他の人は、ほぼ普遍的にauto



を使用するコーディングスタイルを好まないかもしれません。 これらの設定に関係なく、C ++でリストされたスタイルを使用する主な動機は、ここで明確にトレースされます-これは、コンパイラーを支援するという願望です。



ゲームプログラミングについて話す場合、ここでの強い型付けは研究の広い分野であり、実際にC ++アプリケーションスキルを向上させることに興味がある私が知っているゲームプログラマーによって積極的に使用されています。 ここで重要なのは、コンパイル時間への影響とコードの可読性への影響の2つです。



率直に言って、コンパイル時間は簡単に無視できます-ただし、ゲームをプレイせず、作成可能なコードをコンパイルするために確立された内部インフラストラクチャと無限の計算能力を持つ非常に大企業のプログラマーである場合に限ります。 これらの大企業はコンパイルのコストを心配しています-したがって、彼らはモジュールを使用します-しかし、原則として、これは個々の開発者に痛みを引き起こしません。 同時に、ほとんどのゲームプログラマーはそうではありません。 インディー開発者には、構築するファームがありません。 AAAゲーム開発者はIncredibuildのようなものをよく使用しますが、10年以上のコードベースで簡単に作業できるという事実を考えると、ビルドプロセスには15〜20分かかります。



ハードウェアを追加する相対的なコストとプログラマーの時間のコストについて議論することができますが、ハードウェアはより安価であるという見解に同意します。

• ハードウェアは実際の一時的な費用であり、現在の四半期の予算に割り当てられます。これに対して、時間/雇用/などの有形の費用は長期にわたって分配されます。 人々はそのような妥協案を支持する決定にうまく対処できず、企業は短期的な利益を最適化するような方法で特別に構築されます。
• インフラストラクチャにはサポートが必要であり、リリースエンジニアになるためにゲーム業界に行く人はほとんどいません。 C ++が使用されている他の分野と比較すると、ゲーム開発者の給与はそれほど高くありません。また、ゲーム以外のエンジニアの給与はここではさらに低くなっています。

また、コンパイル時間がそのような状態になってはならないという事実を推測することもできます。 そして再び私はあなたに同意します。 これの価格は絶え間ない警戒であり、これもリリースエンジニアによるものであり、理想的には、ビルドのビルドに必要な時間の変化を追跡できる自動化ツールです。 幸いなことに、CIシステムの出現により、今日ではこの目標をはるかに簡単に達成できます。

機会No. 2：ツール

警告、静的分析、サニタイザー、動的分析ツール、プロファイラーなど、利用可能な最大限のツールを使用する必要があります。



私の経験では、ゲーム開発者は可能な限りこれらのツールを使用していますが、ここでは業界全体にいくつかの問題があります。

• これらのツールは、 Microsoft以外のプラットフォームでより適切に動作する傾向があり、前述のように、これは典型的なゲーム開発シナリオではありません。
• これらのツールのほとんどは、「標準」C ++での作業を目的としています。 すぐに使用できるのはstd::vector
  
  
  
  サポートしていますが、仮想エンジンの自己記述クラスCStaticVector
  
  
  
  はサポートしていません。 もちろん、ツールを非難することは役に立たないが、これは依然として開発者が克服しなければならないツールの使用に対する障壁の1つである。
• これらのすべてのツールを実行するCIチェーンを作成して維持するには、リリースエンジニアの存在が必要です。前述のように、ゲームに直接関係のないエンジニアリングジョブの人員を雇用することは、ゲーム業界の体系的な問題です。

では、これらのツールは標準のC ++で非常にうまく機能するのに、なぜゲーム開発者はSTLを使用しないのですか？



この質問に対する答えはどこから始めればいいですか？ おそらく、次のエクスカーションからゲーム開発の歴史へ：

• 90年代前半まで、私たちはCコンパイラを信用していなかったため、アセンブラでゲームを作成しました。
• 最初から90年代半ばまで、Cコンパイラを信頼し始めましたが、C ++コンパイラはまだ信頼していませんでした。 コードはCで、C ++スタイルのコメントを使用しており、構造体のtypedefを常に記述する必要はありませんでした。
• 2000年頃、ゲーム開発の世界でC ++革命が起こりました。 これは、 デザインパターンと大規模な階層の時代でした 。 当時、コンソールでのSTLサポートは望まれていなかったため、コンソールが世界を支配していました。 PS2では、GCC 2.95が永遠に行き詰っています。
• 2010年頃、さらに2つの革命が始まりました。 大規模な階層を使用することの苦痛は、コードに対するコンポーネントアプローチの開発を刺激しました。 この変更は、Entity-Component-Systemアーキテクチャの形で今日も進化を続けています。 これを手にしたのは、マルチプロセッサアーキテクチャを活用しようとする2番目の革命でした。

これらのパラダイムシフトの間に、ゲーム開発プラットフォーム自体が絶えず変化し、真剣に変化しました。 セグメント化されたメモリは、フラットなアドレス空間に取って代わりました。 プラットフォームはマルチプロセッサになり、対称的であり、それほどではありません。 Intelアーキテクチャでの作業に慣れているゲーム開発者は、MIPS（プレイステーション）、異種CPUを備えた特別なハードウェア（PS2）、PowerPC（XBox 360）、さらに大きな異種（PS3）に慣れなければなりませんでした...それぞれ新しいプラットフォームには、プロセッサ、メモリ、およびドライブの新しいパフォーマンス機能が搭載されています。 最適なパフォーマンスを実現したい場合は、古いコードを何度も書き直す必要がありました。 インターネットの人気の出現と成長、およびプラットフォーム所有者が開発者に課した制限によって、ゲームがどの程度影響を受けたかについても言及しません。



歴史的に、ゲームプラットフォームでのSTL実装は不十分でした。 STLコンテナがゲームにあまり適していないことは秘密ではありません。 ゲーム開発者を壁に押し込めば、おそらく彼は、 std::string



はまったく問題なく、 std::vector



はデフォルトで妥当なオプションであると認めます。 ただし、STLに含まれるすべてのコンテナには、割り当てと初期化の制御の問題があります。 多くのゲームでは、さまざまなタスクのメモリ制限を心配する必要があります。ゲームプレイ中にメモリを動的に割り当てる必要がある可能性が最も高いオブジェクトには、 スラブまたはアリーナアロケータがよく使用されます。 割り当てはプログラムの実行中に発生する可能性のある最も「高価な」ものの1つである可能性があるため、 一定時間の償却は良い結果ではありません。 。 ゲーム開発者として、事前にメモリ要件を管理する必要があります。



一般的に他の依存関係についても同様の話が得られます。 ゲーム開発者は、各プロセッササイクルに必要なもの、メモリの各バイトがどこで、いつ、何のために、各実行スレッドがどこで、いつ制御されるのかを知りたいと考えています。 最近まで、Microsoftコンパイラは各更新でABIを変更していました。したがって、多くの依存関係がある場合、それらすべてを再構築するのは苦痛なプロセスでした。 ゲーム開発者は通常、簡単に統合でき、たった1つのことを行い、できればCスタイルAPIを使用して小さな依存関係を好み、多くの企業で使用されており、パブリックドメインまたは無料のライセンスを持っています著者の表示が必要です。 SQLiteとzlibは、ゲーム開発者が好むものの良い例です。



さらに、C ++ゲーム業界には、「ここで発明されていない」症候群の患者の豊かな歴史があります。 これは、完全に新しい機器で独自の何かを作成し、他のオプションを持っていなかった単一の愛好家で始まった業界から期待されるはずです。 とりわけ、ゲーム業界は、プログラマーがクレジットに特定の順序で示されていない唯一の業界です。 さまざまなものを書くのは楽しいですし、それはあなたのキャリアに役立ちます！ 既製のものを購入するよりも、自分で何かを構築する方がはるかに優れています！ また、パフォーマンスが非常に心配であるため、利用可能なリソースを無駄に浪費する一般的なソリューションを採用する代わりに、プロジェクトに特に適した方法でソリューションを適応させることができます。 Boostへの敵意は、そのような思考がゲーム開発でどのように現れるかを示す主な例です。 私は次のようなプロジェクトに取り組みました：

• まず、特定の問題を解決するために、Boostのライブラリをプロジェクトに接続します。
• すべてがうまく機能します。 更新する必要がある場合、多少の苦痛はありますが、他の依存関係を更新する場合と同じです。
• 別のゲームは私たちのコードを使用したいと思っていますが、つまずきのブロックはBoostを使用しているということです-Boostの経験は非常に上手く行っているという事実にもかかわらず。
• Boostを使用してコードを削除しますが、今では新しい問題に直面しています。前に解決したのではなく、Boostのライブラリが解決した問題を解決する必要があります。
• 基本的に、必要なBoostコードの部分を独自の名前空間にコピーします。
• 後で、必然的に、元のコードを破棄しなかった場合に既に元のコードに含まれていた追加機能が必要になるという事実に何度も遭遇します。 しかし、私たちはこのコードの所有者であるため、引き続きサポートする必要があります。

同時に多くのことをしようとしている、またはコンパイル時間に影響を与える可能性のある巨大なものは好きではありません-これは非常に合理的です。 人々が何度も間違いを犯すのは、今日想定される痛みを受け入れることに反対しているということです-一方、この決定のために、彼らは他の誰かを犠牲にして何かの支援で非常に現実的ではるかに大きな痛みに直面します-今後3年間で経験しなければならない予算。 残念ながら、STLとBoostの料理をうまく使用したゲームの形での証拠の存在は、人間の心理に影響を与えず、ゲーム開発者を説得することはできません。



これらのすべての理由により、多くのゲーム会社は、STLが行うことをカバーする独自のライブラリを作成し、さらにゲーム固有のユースケースをサポートしています。 一部の大手ゲーム会社は、独自の本格的でほぼ完全にAPI互換のSTL置換の開発を圧倒することさえできましたが、その後、このプロジェクトをサポートするために莫大なコストがかかりました。



std::map



改善された代替案を見つけるか、 std::vector



で小さなバッファーの最適化を適用するのが賢明です。 algorithms



またはtype traits



独自の実装をサポートする運命にあることは、あまり受け入れられませんが、ほとんど利点はありません。 私にとっては、ほとんどの開発者にとって、STLが単なるコンテナであることは残念です。 開始時にSTLを学習するとき、STLに関して言えば、ほとんどの場合、 std::vector



意味しstd::vector



が、実際にはstd::find_if



について考える必要があります。

機会3：テスト

広範なテストを実施し、TDDおよび/またはBDDがカバーできるすべてのコードをカバーし、バグは新しいテストを作成して対処する必要があると主張されています。



それでは、テストのトピックについて説明しましょう。



私の経験から判断すると、ゲーム業界での自動テストは実際には使用されていません。 なんで？

1.正確性はそれほど重要ではなく、実際の仕様がないため

ゲーム業界の若いプログラマーとして、私は何かを現実的にシミュレートするよう努力するべきだという考えをすぐに取り除きました。 ゲームは煙と鏡であり、短い道を探します。 シミュレーションがどれほど現実的であるかは誰も気にしません。 主なことは、それが楽しいことです。 「ゲームが正しいと感じるはず」以外の仕様がない場合は、テストの対象が欠落しています。 バグのおかげで、ゲームプレイはさらに良くなります。 多くの場合、バグがリリースに組み込まれ、ユーザーの愛にさえ勝ちます（ Civilizationの同じGandhiを思い出してください ）。 ゲームは、C ++を使用する他の分野とは異なります。 ここで、正確性の欠如は、誰かが最終的に貯蓄を失うという事実につながりません。

2.難しいから

もちろん、できる限り自動化されたテストを作成する必要があります。 これは、最終結果が明確に記載されている一部のサブシステムで実行できます。 もちろん、ゲーム業界のユニットテストは存在しますが、原則として、低レベルのコード（前述のSTLアナログ、文字列変換手順、物理エンジンメソッドなど）に限定されます。 コードの実行可能セクションに予測可能な結果があるケースは、通常、ユニットテストでテストされますが、ここではTDDは使用されません-ゲームプログラマーは自分の人生を単純化することを好み、逆も同様です。 しかし、ゲームプレイコードをどのようにテストしますか（ポイント1を参照）？ 単体テストを超えるとすぐに、ゲームのテストが非常に難しいという別の理由にすぐに出くわします。

3.コンテンツが関係しているため

自明ではないシステムのテストには、おそらくそれが実装されるコンテンツの提供が含まれます。 ほとんどのエンジニアは、このコンテンツを自分で作成するのがあまり得意ではないため、有意義なテストを行うには、コンテンツを作成するための適切なスキルを持つ人を引き付ける必要があります。 その後、出力で得られるものを測定する問題に遭遇します-結局、これはもはや線や数字ではなく、画面上の画像や時間とともに変化する音です。

4.練習しないから

単体テストは、可能な入力と出力を知っている関数です。 ただし、ゲームプレイは予測不可能で動的に進化する動作であり、このような現象をどのように適切にテストできるかはわかりません。 私がテストできるもの-もちろん、マネージャーからこれに十分な時間を割く許可を得ない限り-これは、例えば、パフォーマンス、またはマッチメイキングのような高レベルの機能であり、分析することができます。 このようなインフラストラクチャの作業は、一部のゲームプログラマーにとってエキサイティングかもしれませんが、ほとんどの場合、それは単に面白くないだけでなく、ウォレットの所有者からの承認とサポートが必要です。 ゲームプログラマーとして、高レベルのテストの作成を練習する機会はありません。

5. [会社]は自動テストの必要性を認識していないため

私たちの主な目標は、ゲームをリリースすることです。 私たちは、ヒットのマーケティングコストが最大化される販売の最初の月に収益を最大限に活用するヒットで前進する業界の時代に生きています。 コンソールのライフサイクルは、どのような場合でも、コードはそれほど長くは続かないことを教えてくれました。 オンラインゲームに取り組んでいる場合、マッチメイキングやサーバーの負荷をテストするための追加の時間が得られる可能性が高くなります。 ゲームのリリースにはパフォーマンスを整える必要があるため、少なくともパフォーマンステストを実行する必要がありますが、このプロセスを自動化しないでください。 ゲーム業界の管理者にとって、自動テストは時間とお金の無駄に過ぎません。 その実装には、作業を実行する経験豊富なエンジニアを雇う必要があり、その結果はほとんど目に見えません。 同じ時間を新機能の開発に費やすことができます。 短期的には、QAスタッフを使用してゲームをテストする方がはるかに有益であり、次のポイントに進みます。

6.一般的に、テストはゲームの二流アクティビティとして分類されるため

質の高いQAプロフェッショナルが大好きです。 私にとって、彼らは金でその重さの価値があります。 彼らはあなたの心を決して越えない方法でそれを壊すことによってあなたのゲームをより良くする方法を知っています。 彼らは、あなたが理解していない、そしてほとんど理解していないという点で、あなたのゲームプレイの専門家です。 彼らはあなたがすべてを正しくするのを助ける超能力コンパイラのチームよりも優れています。 私の仕事の長年にわたって、いくつかの素晴らしいQAスペシャリストと仕事をする機会があったことを嬉しく思います。



私はほとんど常に彼らをチームに留めるために戦わなければなりませんでした。



大規模なAAA企業では、QA組織は通常、開発チームとは完全に独立した部門であり、独自の管理および組織構造を備えています。これは、テスト中に客観的になるように行われたと言われています。実際には、すべてがとても美しいというわけではありません。



それらは、巨大なメカニズムで歯車のように扱われます。これは、多くの場合、警告なしにプロジェクト間でスローされ、一般的に誰もが作業を処理できるかのように扱われます。プロジェクトが締め切り日から「外れる」とき、エンジニアは自分の肌でクランチを感じることができますが、夜勤と週末に仕事をしなければならないため、QAははるかに強くなり、さらに、現在の憂鬱なニュースをもたらすという事実も得ますプロジェクトの品質ステータス。



彼らは真剣に低賃金です。対象分野で長年の専門知識を持つ最も経験豊富なテスターは、中間レベルの開発者に支払うものの半分未満を受け取ります。追跡とアラートを使用したパフォーマンステスト用のパイプラインを作成し、APIのテストと負荷テスト用のフレームワークを作成し、「本物のエンジニア」の時間にふさわしくない他の多くのタスクを実行した最も賢いQAエンジニアと協力する必要がありました。これらの最も優秀な人々は、他の大規模なテクノロジー企業で働いていれば、さらに多くを獲得できると確信しています。



彼らは信頼されていません。テスターが他の開発者から分離されていることは珍しくなく、彼らのバッジにより、彼らは自分たちが働いている建物のその階にのみアクセスできるようになります。



彼らは従わざるを得ません。テスターは、しばしば他のエンジニアを邪魔しないように言われます。バグを直接報告する必要がある場合は、「H。Mr.」や「Mr. Y.」など、エンジニアに丁寧に連絡するよう求められます。時々、QA部門のイライラする上司から呼ばれました-そのような場合、共同調査のためにバグを検出した人々に連絡しました。



これはすべて恐ろしい話のように聞こえ、誰もがそのようなことに対処する必要はありませんが、残念ながらこれは非常に頻繁に起こります。エンジニアが頻繁に考えるようになります-おそらく一定のストレスの下で、それは言い訳にはなりません-QAの仕事は自​​分のバグを探すことであり、さらに悪いことにQAをバグのせいにすることです。



私が協力しなければならなかった最高のチームでは、私たちのチームは私たちと一緒に働く独自のQAエンジニアを持っていると主張しました。しかし、彼らは客観性やより良い結果を達成したいという欲求を失いませんでした。彼らは、自動化されたテストを書く際にプログラマーからの助けを喜んで受けました。確かに疑いの余地はありませんが、ゲーム業界が自動化をより頻繁に行うことが有益であることです。

デバッグパフォーマンス

前述、デバッグの習慣、まだ成長しているAPIとツールのプラットフォーム、および自動化されたテストの複雑さ（文化の欠如と組み合わせて）に基づいて、ゲーム開発者がデバッグ機能を主張する理由が明らかになります。



しかし同時に、デバッグ自体の問題や、ゲーム開発者が現在のC ++開発ベクトルにどう対処するかという問題が残っています。



デバッグの主な問題は、スケールしないことです。この投稿を読んでいる開発者のゲーム開発者の中には、私が説明した現象が彼らの実践で観察したものと一致しないと決める人がいます。これは遅かれ早かれ彼ら自身がデバッグのスケーラビリティの問題に対処しなければならなかったという事実による可能性があり、彼らはそれを回避する方法を見つけました。



言い換えれば、バグをキャッチするために、十分な大きさの代表的なデータセットでアプリケーションを実行できる必要があることが多いため、生産的なデバッグが必要です。しかし、実際には、このポイントに達すると、デバッガーは通常、あまりにも無礼なツールになり、生産的であるかどうかに関係ありません。もちろん、データにブレークポイントを設定する（データブレークポイント）中規模の問題をキャッチするのに役立つかもしれませんが、実際のバグに遭遇した場合はどうでしょうか？ネットワーク負荷の下で、またはメモリ不足の場合、またはマルチスレッド機能の制限で動作する場合、または他の数百万人のプレイヤーを背景にした小さな未確認のサブセットでのみ発生する、またはゲームのディスクバージョンでのみ発生する、またはドイツ語のアセンブリで、または安定性テストに3時間を費やした後（浸漬テスト）？



2行目、1つのデバッガーのみに依存できます。この場合、私たちはいつもやったことをします。問題を特定し、より頻繁に発生させようとしています。ロギングを追加し、プログラムをふるいにかけます。タイマーとフロー設定を調整します。ビルドでバイナリ検索を使用します。コアダンプとクラッシュログを調査します。コンテンツを最小限にトリミングすることで問題を再現しようとしています。問題の原因を考えて議論します。



多くの場合、クラッシュの本当の原因に到達するまで、他のいくつかの問題を修正する時間があります。つまり、問題を解決し、最終的にデバッガーを使用することは、このプロセスのほんの一部にすぎません。そのため、デバッグ速度は素晴らしい追加機能ですが、それが不足していてもエンジニアであり続けることはできません。コアダンプを解析し、最適化されたアセンブラーを読み取る機能など、他のスキルも必要です。



「モダンC ++」を使用する場合、通常と同じ方法でデバッガーを使用します。私は新しく書かれたコードを見ていきます。興味のあるデータにブレークポイントを置きます。デバッガーを使用して、なじみのないコードを調べます。 「モダンC ++」の出現により、これらの変更はありません。そして、はい、STLが_ glyい_識別子を使用していても、STLの魔法を作りません。 STLが「内部で」行うことを確認したり、ステップオーバーしたりすると便利な場合があります。または、今できるように、デバッガを使用してライブラリコードを非表示にします。



パフォーマンスの問題のデバッグに出くわすと、「モダンC ++」が遅くなることは通常ありません。実際、この時点で私はすでにやり過ぎです。タイプ、ツール、およびテストとは異なり、デバッガーを使用してもスケーリングしません。



私自身は、C ++コードがますます最適化を必要とするという問題を心配しており、これに関するコンパイラ開発者の意見に興味がありました。実際には、単一の答えはありません。私たちはすでに連続しており、コードをデバッグする能力を損なうことなく、この方向にさらに進む機会があります。現在、私たちのコンパイラは、一時オブジェクトのコピー削除を実行します。、この最適化の実行を依頼しなくても。これは、アプリケーションのデバッグ機能には影響しません。デバッグビルドには、デバッグ中に気付かないような方法で行うことができるNRVOまたは半ダースの最適化が含まれるようになったと不満を言うことはありません。私はC ++がその方向に動いているのではないかと疑っています。

エピローグ：現代のC ++の方法

ゲーム開発の分野でプログラマーとして働いていて、C ++が進んでいる場所が気に入らない場合は、基本的に、さらなるアクションのための2つのオプションがあります。

1.何もしない

まだC ++コードを作成しようとしていると仮定すると、以前と同じように言語を使い続けることができます。これを行わない場合は、新しい機能を使用する必要はありません。現在使用しているもののほぼすべてがサポートされ続けます。そうすることで、今後数年間はコンパイラを改善する利点を享受し続けるでしょう。



これは、自分自身で、または志を同じくする人々のチームで働く人々にとって、完全に適切な行動戦略です。 C ++ 98は、いくつかの新しい機能とともに、ゲームを作成するのに適しています。



ただし、大企業で働いている場合は、遅かれ早かれ、言語を変更する必要があります。チームを増やし、新しい人を雇う必要があるからです。同様に、C ++開発者を雇うとき、これは「最新の」C ++で開発者を雇うことを意味します。世代交代が発生します-アセンブラー、CおよびC ++ 98で既に発生しているように。コードベースで許可されるものと許可されないものに制限を設定すると、プロセスを管理できますが、このソリューションでは長期的には節約できません。そして、この場合、あなたは何をすべきですか？

2.参加する

1年に1回だけGDCに行くのではなく、CppConにアクセスして、会社がチケットに費やしたお金からより多くの利益を得ることができます。標準の議論に参加します。グループに参加してニュースレターを購読します。ドラフト標準を読み、著者にフィードバックを提供します。委員会の会議にも出席できる場合は問題ありませんが、そうでなくても、他の人に自分の意見を伝えるために多くのことができます。



C ++委員会のメンバーは誰でも参加できます。 SG14、SG7、SG15-またはあなたの関心分野に関連する他のワーキンググループの作業に参加したい人に必要なすべての情報-isocpp.orgで見つけることができます。委員会には秘密の計画はありません-実際、200人以上のプログラマーが共通の議題に同意できると本当に思いますか？ここでは、委員会の「ボス」でさえも、しばしば彼らのアイデアを「削る」ことに失敗します。



意見を聞きたい場合は、TwitterやRedditではなく、意見を聞くことができる場所で話し始める必要があります。このアドバイスを受けてください-私たちの議論を楽しみにしています。