Valve のような企業はどのようにして 3 つの主要なゲーム プラットフォームすべてにゲームをリリースすることができたのでしょうか? 特に Windows、Xbox360、PS3 間でのコード共有に関するベスト プラクティスに関心があります。理想的な解決策は、プラットフォームごとにすべてを書き直すのではなく、できるだけ多くのコードを再利用することです。
7 に答える
同時開発を行うのは素晴らしいことです。1つのプラットフォームだけでは見つけられないあらゆる種類のバグが見つかります。
DOSのプログラマーは、低メモリへの書き込みですぐにクラッシュしなかったため、常にnullポインターを使用していたことを覚えています。Amiga、Atari ST、またはMacintoshに移植すると、ブームになります。DOSプログラマーに、すでに出荷されているゲームに2つのnullポインターがあることを伝えたのを覚えています。彼は数秒間考えて、「それはいくつかのことを説明している」とニヤリと笑った。
ゲームの予算が非常に大きいので、マーケティングと広告の予算を無駄にしないように、すべてを同時に出荷することが重要です。
同時開発に関する私のアドバイスは、1つのリードプラットフォームを選択することですが、他のプラットフォームが1週間以上遅れることは決してありません。コードのどの部分がすべてのプラットフォームに共通で、どの部分が異なるかをプログラムすると明らかになります。違いを1つ以上のプラットフォーム固有の領域に引き出します。
私の経験はC/C++です。異なる言語(JavaやObjective-cなど)に対して移植する必要がある場合は、より大きな問題になります。
この質問は、2 つの別々の質問に分けることができます。「移植可能なコードを書くにはどうすればよいですか?」および「主流のゲームプラットフォームの異なる要件は何ですか?」.
最初の質問は比較的簡単に答えられます。移植性のないコードを抽象化するためのベスト プラクティスは、移植性のあるコードを書く: http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=frontcoverで説明されています。
理論を実践に移すと、Quake 3 のソース コードは、さまざまなプラットフォームを C コードベースの個別の領域に分割するという非常に優れた仕事をして います。プラットフォームごとに 1 回実装される、抽象インターフェイスなどの C++ パターン。
あなたの質問の 2 番目の部分、「主流のゲーム プラットフォームの多様な要件は何ですか?」より厳しいです。ただし、最大の変更領域は依然としてレンダラー、オーディオ サブシステム、およびネットワークであることは注目に値します。
各コンソール プラットフォームには一連の認定要件があり、それぞれのコンソール所有者との契約に基づいて利用できます。この要件は、ユーザー エクスペリエンスの一貫性を促進するものであり、ゲームプレイや定性的な高レベルの問題には焦点を当てていません。たとえば、あなたのゲームではかなり興味深いアニメーションの読み込み画面を表示する必要があるかもしれませんが、黒い画面は受け入れられません。
このドキュメントをできるだけ早く入手することが、特定のコンソール プラットフォーム向けの開発において正しい選択を行うための鍵となります。
最後に、コンソール開発キットを手に入れることができない場合は、コードを Windows から Mac に移植することをお勧めします。Mac は、ユニバーサル バイナリをサポートしている場合、Windows に縛られないことを保証する OS ポートとプロセッサ ポートを取得します。これにより、コードがエンディアンに依存しないことが保証されます。
PC と Mac の両方をサポートしている場合は、将来アクセスできるようになった場合に、第 3 のプラットフォームをサポートすることができます。
あなたが書いた補遺:
理想的な解決策は、プラットフォームごとにすべてを書き直すのではなく、できるだけ多くのコードを再利用することです
多くのゲーム移植シナリオでは、理想的な解決策は、できるだけ多くのコードを再利用することではなく、プラットフォームごとに最適なコードを記述することです。コードはプロジェクト間で再利用でき、エンジンが取り込むコンテンツに比べて比較的安価です。より合理的な目標は、変更せずにすべてのプラットフォームで実行される最小公分母のコンテンツを目指すことです (メディアのコンテンツをパックするビルド フェーズ)。大丈夫だ)。
数年前、Opera CEOはインタビューで、独立したプラットフォーム向けに開発するための鍵は、単一のOS/プラットフォームライブラリから離れることであると述べました。彼は続けて、OSのパフォーマンスを向上させる独自のライブラリを開発したと述べました。
私の想定では、大企業には共通のXbox、PS、Windows、FooOS、別々のチームがあります。プラットフォームごとに異なる方法で調整する必要があり、異なる実装方法が必要です。すべてのプラットフォームで1つのソースを実行しているとは思いません。むしろ、OSごとに1つ作成し、効率を向上させます。EAがPCバージョンよりも早くいくつかのコンソールゲームをリリースしていたことを覚えています。その逆も同様です。
もう1つの問題は、コンソールごとにハードウェアが異なるため、必要なプログラミング手法が異なることです。
極端な例は2つあり、すべてに適合する1つのソース(たとえばJava)を構築しますが、非効率になるリスクがあるか、40バージョンを作成します。プラットフォームごとに最適化されたもの
オープン ソースの例が必要な場合は、Quake 1、2、および 3 エンジンのソース コードを参照できます。それらは非常に移植性の高い構造になっています。(もちろん、ps3 または xbox360 のサポートはありませんが、同じ原則が適用されます)
友人が教育用コンピュータ ゲームに携わっていたとき (The Learning Company がこの分野を全滅させる前)、彼はあらゆることを行うためのクロスプラットフォーム ライブラリを作成することの大ファンでした。
これは、他のアプリよりもゲームの方が簡単です。たとえば、Mac と Windows で実行するワープロ アプリがある場合、Mac では Mac アプリ、Windows では Windows アプリのように見え、動作する必要があります。ゲームを作成しても、ネイティブの動作、ルック アンド フィールに準拠する必要はありません。