ゲームライブラリプロジェクトの管理方法について

現在C/C++（VisualStudio2008　academic edition）でライブラリのようなものを作成しているのですが悩んでいることがあるので相談させてください。

ライブラリの実装として、

・ネットワーク
・ファイル入出力
・描画系
・オーディオ再生
・数学系
・アルゴリズム
・シーングラフ管理システム
・メモリ管理システム
・デバッグシステム＆プロファイラー

のようなものを１つのプロジェクトで管理しています。
しかし、いろいろあってファイル入出力のシステムだけ使おうとしても1つのプロジェクトに描画やらネットワークやらいらないシステムも芋づる式にくっついてきてしまいます。

「そういうふうに作ったんだから当たり前だ」と言われてしまえばそれまでなのですが、普通はこのようないろんなシステムが入ってくる場合、どのようにプロジェクトを管理するのが適切でしょうか？

私なりにいくつか考えたものでは

1：現状のまま使っていき不要なライブラリがあるのも承知でそのまま利用する

2：1つ1つのシステムごとにプロジェクトをわけてパスを通して別プロジェクトだが1つのシステムのように扱う（当然共有すべきヘッダーやクラスが出てきたりするし、ライブラリファイル(.lib)やDLLがたくさんできあがる）

3：1つ1つまったく別プロジェクト、別ソリューションとして作成し、共有するヘッダーを作らないようにする（同じことが書いてあるヘッダーが各ソリューションのフォルダに入ったりすることもある（当然1つを変えるとすべてを手作業で編集する作業が必要になる））

以上です。
3番目以外は試してみたのですが、
1番は、いらないシステムまでくっついてくる（1つのシステムを利用するのにヘッダーの管理がべらぼうに大変）
2番は、パスの通っているプロジェクトから通っていないプロジェクトへの管理が大変
（たとえばプロジェクトがA,B,CとあったとしてBはAのプロジェクトにパスが通っていてヘッダーをincludeしていると仮定する、CはBのプロジェクトにパスが通っているとする。この時、CがBのプロジェクト内のヘッダーをincludeするとCからAに対してパスが通っていないためコンパイルエラーとなる）


表現方法があいまいで伝わらない個所もあるかもしれませんが、これ以外に適切な管理方法や、こんな方法でやると便利などといった情報があれば教えてください。
よろしくお願いします。

No.1 ベストアンサー 回答者： sha-girl 回答日時： 2010/12/08 13:01

>「そういうふうに作ったんだから当たり前だ」と言われてしまえばそれまでなのですが、普通はこのようないろんなシステムが入ってくる場合、どのようにプロジェクトを管理するのが適切でしょうか？

芋づる式に色々ついてくるライブラリーは実際結構あります。
名前はいえませんが、有名なエンジンもそうだったりします。なので何でもライブラリというもの有りだとは思います。
少し話がそれますが大規模なものだと問題になってくるのがリンク速度です。libファイルが巨大になると、とにかくリンクに時間がかかります。
たかがcppファイルを1行変えただけなのにリンクに5分待たされるとか、たまらないです。(トライ＆エラーの効率が悪いです)
たとえばデバッグ版はdll、リリース版はlibで動くとかの工夫をしておくと後で幸せになれると思います。

>・ネットワーク
>・ファイル入出力
>・描画系
>・オーディオ再生
>・数学系
>・アルゴリズム
>・シーングラフ管理システム
>・メモリ管理システム
>・デバッグシステム＆プロファイラー

・デバッグシステム＆プロファイラー
・メモリ管理システム
・ファイル入出力
・数学系
・アルゴリズム
まずこの５つはどんなアプリだろうがほぼ必要になります。これはひと括りにまとめてよいと思います。
「基本ライブラリ」とでも呼びましょう。※後書いてないですがスレッド管理とかも

・描画系
・オーディオ再生
これはそれぞれ分離することができると思います。ただし下位レイヤーに「基本ライブラリ」は必要です。
(ゲームがターゲットなライブラリなので描画系とオーディオ再生は一緒にしてもよいかとは思います。好みの問題。)

・シーングラフ管理システム
　シーングラフ管理システムが何をするかよくわかりませんが、
　名前からだとアプリケーションのレイヤーだと思います。(描画系と基本ライブラリに依存)
　※もし描画エンジンに特化したものであれば描画エンジンにいれる

とりあえず上記４つ(基本、サウンド、描画、グラフ)若しくは３つ(基本、サウンド/描画、グラフ)にプロジェクトをわけてみてはどうでしょうか。



>3：1つ1つまったく別プロジェクト、別ソリューションとして作成し、共有するヘッダーを作らないようにする（同じことが書いてあるヘッダーが各ソリューションのフォルダに入ったりすることもある（当然1つを変えるとすべてを手作業で編集する作業が必要になる））
これは無いかと思います。
includeパスの設定を各プロジェクトで行いヘッダは共有するのが普通かと思います。

No.2 回答者： sha-girl 回答日時： 2010/12/08 20:16

No.1です。

すいません。「ネットワーク」が抜けていました。
「ネットワーク」を「基本ライブラリ」と分離するべきかどうかは難しいですね。
結局、ライブラリを細分化しても単体で使うことがないのならば意味がありません。

例えば描画を必要としないゲームのサーバーを作る場合、
「基本ライブラリ」+「ネットワークライブラリ」で構成できます。
ゲームのクライアント側は
「基本ライブラリ」+「ネットワークライブラリ」+ 「描画/サウンドライブラリ」
が必要ですが、
どちらにしても「ネットワークライブラリ」は必要になるので
「ネットワークライブラリ」は「基本ライブラリ」に含めてしまって良いと考えることができます。
ただしオフゲーを作る場合は「ネットワークライブラリ」は余分なものになりえます。

そこを許容するかどうか、あるいは許容できるかどうかは
それぞれの事情に依ります。
例えばコードサイズを極力小さくする必要があるのなら分けた方が良いです。
※リンカで最適化される場合もありますが、期待できない場合もあります。

最初にも言いましたが何でもライブラリというのも有りです。



>（たとえばプロジェクトがA,B,Cとあったとして
>BはAのプロジェクトにパスが通っていてヘッダーをincludeしていると仮定する、
>CはBのプロジェクトにパスが通っているとする。
>この時、CがBのプロジェクト内のヘッダーをincludeするとCからAに対してパスが通っていないためコンパイルエラーとなる）
2番を実践されているようですが、少し気になったので補足します。
基本的にはプロジェクトにincludeパスを設定します。
例えばorelib(俺ライブラリ)というライブラリを作ったしたなら
どのプロジェクトのソースからも
#include <orelib/network.h>
#include <orelib/sound.h>
でコンパイルエラーにならないようプロジェクトにパスを設定してください。

boostを入れたことはないでしょうか？
例えばboostで正規表現を使いたい場合は
#include <boost/regex.hpp>
とヘッダをincludeします。