ありがとうございます

なるほど、ソリューション構成ではなくプロジェクトごと切り替えれば良いってのは確かにその通りですね。

データファイルによって挙動を切り替えれば exeのエディションとデータファイルのエディション不一致によるエラーも起こりませんし、

プロジェクトを切り替える方式ならソリューション構成を増やさずにビルドオプションを切り替えたりする事ができますね。

とても参考になります。
ありがとうございました

ゲームではないですが、他の製品で製品版と体験版を作ったことがあります。

基本方針は、dicさんが書かれているような、変数を使って動作を変えるというので変わりはないですが、その変数を設定するメインを含むexeのプロジェクトを、製品版と体験版で別々に作りました。

ただそうすると、実際のアプリケーションの処理は、exeのプロジェクトに入れるとメンテナンスが面倒だったので、それらはライブラリ(dll)へ分離し、exe側から参照するような仕組みにしました。
application()がゲームアプリケーションのエントリーポイントで、試用版のmainからはtrueで呼び出し、製品版ではfalseで呼び出すといった感じです。で、applicationの本体は、別のライブラリプロジェクトに入れておくと。

私だけのやり方に話が偏って、一般的にどうやっているかはわかりませんが、

製品版のデータが入っているフォルダにEXEを入れれば製品版として動作するし
体験版のデータが入っているフォルダにEXEを入れれば体験版として動作みたいな？

私一人に限っていえばそうなります。

他の方はどうやっているのかも知りたいところですね。

ありがとうございます。

マクロではなくて変数で切り替える、という感じですね。
マクロ切り替えだと false 側のブロックがまるごとスキップされてしまい
構文チェックも行われないので単純なエラーを見過ごすこともあり、
私も変数で切り替えるのがベターだと思います。

ところで変数で対処したとしても、結局製品版と体験版のどちらをビルドしたいのか
どこかで指定する必要がありますし、生成される実行ファイル名が全てのエディションで
同じになってしまいますが、そのあたりってどうされていますか？

ファイル名に関しては単純に生成後に自力でリネームという感じなのでしょうか？


あるいは、製品版でも体験版でも EXE は名前も中身も完全に同じで、
読み込ませるデータファイルによって振る舞いが変わるという感じですかね。

製品版のデータが入っているフォルダにEXEを入れれば製品版として動作するし
体験版のデータが入っているフォルダにEXEを入れれば体験版として動作みたいな？

Visual Stduio での話になると思いますが、
私の場合は、構成マネージャーではなく、
仕様を先に決め、体験版はここまで
製品版は全部
体験版の制限に必要な変数や仕組みを仕様としてあげ
そのソースコードに製品版のコードも一緒に組み込みます。

なので、使うといえば、Debug, Release の２つだけです。

綺麗にいけばいいですけど、やっぱり所々で
ソースコードがちょっと汚くなってしまうこともあります。

cpp_game さんのやり方は組み合わせの問題で爆発的に
管理するものが増えるのでたしかに困ってしまいますね。

限定公開も、制御する変数を用意し、それを使って
限定公開するものを作成します。

参考になるかわかりませんが、私の場合は仕様書を先に作っておきます。

C言語というよりも Visual Studio C++ の使い方に関してなのですが、
ゲームを開発していると、製品版と体験版など同一製品で異なるエディションというものがあります。
私はこれらの切り替えをマクロで行っているのですが（#ifdef TRIAL とか）

これをコンパイルのたびに TRIAL の定義を切り替えるのは面倒ですよね。

そこで構成マネージャを使って、デフォルトの Debug, Relase に体験版用の構成 TrailDebug, TrialRelease を追加し、TrialDebug, TrialRelase のときはプリプロセッサの定義に TRIAL を入れておくという使い方をしているのですが、これは「構成マネージャ」が想定している使用用途としては正しいモノなんでしょうか？


このやり方は製品版と体験版だけならまだ良いのですが、
例えばさらに Android 版と Steam 版などという分類が加わると

android_debug (android 製品版 デバッグ可能。"ANDROID _DEBUG" が定義済み)
android_release (android 製品版　最適化あり。"ANDROID NDEBUG" が定義済み)
android_trial_debug (android 体験版 デバッグ可能。"ANDROID TRIAL _DEBUG" が定義済み)
android_trial_release (android 体験版　最適化あり。"ANDROID TRIAL NDEBUG" が定義済み)
steam_debug (steam 製品版 デバッグ可能。"STEAM _DEBUG" が定義済み)
steam_release (steam 製品版　最適化あり。"STEAM NDEBUG" が定義済み)
steam_trial_debug (steam 体験版 デバッグ可能。"STEAM TRIAL _DEBUG" が定義済み)
steam_trial_release (steam 体験版　最適化あり。"STEAM TRIAL NDEBUG" が定義済み)

という風に、構成がドンドン増えていってしまいます。こんなもんなんでしょうか？




上記の話は1つのソリューションに1つのプロジェクトだけが含まれている場合なのですが、
仮にこれをゲームエンジン部分 (engine.vcxproj) とゲーム実装部分 (game.vcxproj) に分けたとしますと、

engine.vcxproj には
debug
release

の2構成だけが含まれていればよいですが、
game.vcxproj には

android_debug
android_release
android_trial_debug
android_trial_release
steam_debug
steam_release
steam_trial_debug
steam_trial_release

の8構成があることになります。
ここでは engine.vcxproj の構成と game.vcxproj の構成を正しく組み合わせないといけません

engine(debug) + Game(android_debug)
engine(debug) + Game(android_trial_debug)
engine(debug) + Game(steam_debug)
engine(debug) + Game(steam_trial_debug)

engine(release) + Game(android_release)
engine(release) + Game(android_trial_release)
engine(release) + Game(steam_release)
engine(release) + Game(steam_trial_release)

これで、「限定公開版」とか「スペシャルエディション」みたいなものが増えていくと、
わりと気軽に大変なことになると思うのですが、
普通は皆さんどんなふうに整理しているんでしょう？