Windows と Mac の両方で動作するいくつかのゲームに取り組んでおり、Visual Studio 2010 と Xcode 4.3 を使用しています。
複数の IDE を使用している開発者にとって、メイン プロジェクト ファイル、リソース ファイル (サウンド、テクスチャ、設定)、およびプラットフォーム固有のファイルに関して、あなたの組織はどのように見えますか?
ありがとう!
Windows と Mac の両方で動作するいくつかのゲームに取り組んでおり、Visual Studio 2010 と Xcode 4.3 を使用しています。
複数の IDE を使用している開発者にとって、メイン プロジェクト ファイル、リソース ファイル (サウンド、テクスチャ、設定)、およびプラットフォーム固有のファイルに関して、あなたの組織はどのように見えますか?
ありがとう!
ほとんどの開発者は同じIDEとバージョン(VS2010など)を使用しますが、他の開発者や異なるツールを使用する開発者は、独自のプロジェクトファイルを維持する責任があります(VS2008とVS2010は* .csprojファイルを共有できますが、*。slnは異なります)ファイルなので、大きな問題ではありません)。
プロジェクトは通常の方法でレイアウトされます。ルート内のソリューションファイル(IDEに従って名前が付けられます。例:「Foobar-VS2008.sln」および「Foobar-VS2010.sln」)。その後、各プロジェクトはルートの下およびルート内に存在します。各プロジェクトのは、IDE間で共有される*.csprojファイルです。
しかし、私はもっと複雑なプロジェクト、特に人々がVimやVCでCをハックするのが好きな大規模で人気のあるオープンソースプロジェクトに携わってきました。このような場合、プロジェクトファイルとソリューションファイルは実際にはルートから離れた独自のディレクトリに存在し、以前と同様に、各IDEの開発者がプロジェクトファイルの保守を担当します。構造は次のようになります。
PopularProject (Empty)
PopularProject\src (Root for all the *.c and *.h goodness)
PopularProject\bin (Where the myriad build systems dump their output in a suitable subdirectory (e.g. \bin\VC9\IA-64 or \bin\gcc\x86)
PopularProject\prj\VC9 (Where VC9 project and SLN files go)
PopularProject\prj\gcc (Where GCC makefiles and other files go)
PopularProject\prj\Eclipse (Ditto, but for Eclipse)
プロジェクトを整理しますが、実際には大規模なプロジェクトでのみ機能します。小さなものの場合、それはやり過ぎであり、多くの場合、単一のプロジェクトと* .slnファイルを持っているだけの方が簡単です。誰かが自分のプロジェクトを追加したい場合は、自分のマシンでのみそれを行うことができます(つまり、少数派に自分のファイルを追加させないでください)。 、差別的ではなく、物事をシンプルで管理しやすいものにするため)。
プラットフォーム固有のコードを使用するプロジェクトの場合、ソースに#ifWIN32または#ifLINUXプリプロセッサ定義のリベラルなアプリケーションがあります。
すべてのサードパーティまたはインポートされたライブラリは、プロジェクトルートから離れた「lib」または「ref」サブディレクトリに配置される傾向があります。
私はゲームに直接取り組んだことはありませんが、アセットはファイルシステムの別のツリーにルートから離れて保存されます。開発者は、ローカルマシンとソース管理の間で差分をとるときにそれらが含まれることを望んでいません(バイナリも差分するのが難しいです)。結局のところ、彼らは別のチームである(と思われる)アーティストの責任です。