第11回 Release配布と素材確認

作ったゲームを実行できる形へまとめる

手元で制作しているゲームをRelease構成でビルドし、実行ファイルと素材をまとめます。開発中のフォルダー以外から起動し、作った画像、音、ルールが配布物にも反映されているか確かめます。

画像とアニメーションの設定は第02回、状態との接続は第05回で扱いました。この回では、出力先の素材、音声の対応、読み込み結果、ライセンス文書、配布構成を確認します。

Release構成でビルドする

使用する環境はVisual Studio 2026、C++17、x64です。DxLibと環境変数DXLIB_VC_DIRの設定は、配布ファイルを参照してください。

手元のAutoShooter.slnを開き、ツールバーで構成をRelease、プラットフォームをx64にします。その状態でソリューションをビルドします。

DebugとReleaseは別のビルド構成です。Releaseでは最適化などの設定が変わります。Debugで作った実行ファイルを使い続けないよう、今回の出力先と生成時刻を確認できます。

配布版の出力先は、プロジェクト内のx64/Releaseです。プロジェクト設定で変更した場合は、その出力先を使います。

Play.cmdで起動する場合は、プロジェクトフォルダーから次を実行します。

Play.cmd Release

Play.cmdはビルド済みの実行ファイルを起動します。ソースをコンパイルする処理ではありません。引数なしではDebugを起動するため、Releaseを確認する場合は引数を付けます。

Pythonの補助ツールを使う場合は、次のコマンドでRelease構成をビルドできます。

python Tools/Build.py --configuration Release

実行ファイルとAssetsの関係

素材の相対パスは、実行時の作業フォルダーを基準に読み込みます。

L"Assets/Images/Player.png"

Visual Studioでデバッグ実行するときは、プロジェクトのLocalDebuggerWorkingDirectoryに設定した$(OutDir)が作業フォルダーになります。

Play.cmdも、実行ファイルのあるフォルダーを作業フォルダーに指定して起動します。

for %%F in ("%GamePath%") do start "" /D "%%~dpF" "%GamePath%"

これらの起動方法では、実行ファイルの隣にAssetsがあり、その中にImages/Player.pngがある構成で読み込めます。ゲーム自身が作業フォルダーを変更する処理ではありません。

ビルド時には、プロジェクト側のAssetsを出力先へコピーします。日常の素材編集ではプロジェクト側を変更し、再ビルドします。出力先だけを編集すると、プロジェクト側の素材と異なる状態になります。

場所	役割
プロジェクト側のAssets	制作中の画像・音声・マップと利用条件
x64/Release/Assets	Release実行時に読み込む素材
配布フォルダーのAssets	配布する実行ファイルが読み込む素材

新しく追加した画像や音声も、定義に書いたパスと出力先の実ファイルが一致するか確認します。

配布物は別フォルダーへまとめ、その中の実行ファイルを直接起動して、素材が読み込まれるか確かめます。Visual StudioやPlay.cmdでの起動確認とは分けて、実際に渡す構成と起動方法で確認できます。

効果音の対応と差し替え

SoundManager.cppのDefinitionsで、効果音IDとファイルを対応させています。

constexpr SoundDefinition Definitions[] =
{
    { SoundManager::Id::Shot, L"Assets/Sounds/Shot.wav", 70 },
    { SoundManager::Id::Hit, L"Assets/Sounds/Hit.wav", 70 },
    { SoundManager::Id::Damage, L"Assets/Sounds/Damage.wav", 110 },
    { SoundManager::Id::Level, L"Assets/Sounds/Clear.wav", 110 }
};

列はID、読み込むファイル、再生音量です。配布版では、LevelというIDがClear.wavを参照しています。ファイル名だけで、どの出来事に使う音かを判断せず、IDと再生箇所を対応させます。

同じファイル名で交換する

例えば発射音を変えるなら、プロジェクト側の次のファイルを、用意した音声へ差し替えます。

Assets/Sounds/Shot.wav

再ビルドして起動し、発射時の音を確認します。配布版の定義はWAVファイルを使っています。拡張子を変えるだけでは音声形式の変換にはなりません。

別のファイル名を登録する

例えばMagicShot.wavを使う場合は、Assets/Soundsへ配置し、Shotの定義1行を置き換えます。

{ SoundManager::Id::Shot, L"Assets/Sounds/MagicShot.wav", 70 },

GameModel側でShot.wavという名前を指定する必要はありません。既存のShotイベントを受けた音声側が、この定義に従って再生します。

再生のタイミングを読む

Game.cppのHandleEventsでは、GameModelからの通知を使います。

if (events.shot && shotWait <= 0)
{
    sounds.PlaySe(SoundManager::Id::Shot);
    shotWait = 0.12f;
}

shotWaitは、音が過密に重ならないようにする待ち時間です。弾を発射した回数と、音が鳴る回数は常に一致するわけではありません。

命中音にも別の待ち時間があります。被弾音はevents.damage、レベル関連の音はevents.levelを使います。新しい出来事に専用音を付ける場合は、通知、SoundManagerのIDと定義、HandleEventsの再生処理をつなげられます。

効果音が聞こえない場合は、ファイルの読み込みだけでなく、イベントが成立しているか、待ち時間の条件を満たすかも確認できます。

素材の読み込み結果を確認する

Game::Initializeは、表示用素材と音声を読み込んでからゲームを開始します。

LoadResult Game::Initialize()
{
    auto images = renderer.LoadAll();

    if (!images.succeeded)
        return images;

    auto sound = sounds.LoadAll();

    if (!sound.succeeded)
        return sound;

    model.Start();
    shotWait = hitWait = 0;

    return {};
}

LoadResultは、成否とエラー情報をまとめる構造体です。

struct LoadResult
{
    bool succeeded = true;
    std::wstring errorMessage;
    std::string errorDetail;
};

succeededがfalseなら、ゲーム開始へ進まず結果を呼び出し元へ返します。errorMessageは表示用、errorDetailは詳細情報を扱う文字列です。

現在のGame::Runは、読み込み失敗時にerrorMessageをデバッグ出力とメッセージボックスへ渡します。

if (!loaded.succeeded)
{
    OutputDebugStringW(loaded.errorMessage.c_str());
    MessageBoxW(nullptr, loaded.errorMessage.c_str(),
        config::WindowTitle, MB_OK | MB_ICONERROR);

    return false;
}

素材の読み込みは、画像管理や音声管理の処理が担当します。Gameは結果を受け取り、開始できるかを判断します。この分担により、ゲームの移動や攻撃の処理へファイル読み込みの分岐を入れずに済みます。

読み込み失敗の表示から調べる

画像が見つからない場合や、画像の分割数と寸法が合わない場合、アニメーションが存在しないコマを参照する場合などは、ファイルと設定を確認します。

表示・症状	確認する場所
画像や音声が読み込めない	実行ファイル側のAssets、定義のパス、ファイル形式
シートを等分できない	画像全体の寸法、columns・rows
アニメーション範囲が不正	画像ID、firstFrame、frameCount、frameSeconds
マップの寸法が合わない	2枚のCSVの大きさ、画面を覆うタイル数
起動するが音が鳴らない	音量、イベント通知、再生条件

エラーは表示された対象から調べられます。例えばPlayerHurt.pngを追加した作品なら、そのファイルが出力先にもあり、PlayerClipsの画像IDと読み込み定義が対応しているかを確認します。

素材不足時の表示を確かめたい場合は、配布確認用に作ったコピーで、読み込むファイルを別の場所へ移した状態を試せます。そのコピーは欠損確認用として分け、実際に渡す配布物は必要なファイルがそろった構成で作ります。

ライセンス文書と追加素材をまとめる

Assets/ThirdPartyには、外部素材の出典、作者、ライセンス文書、著作権表示があります。配布時に必要な表示や文書は、それぞれの同梱文書に基づいて確認します。

自分で追加した素材についても、第02回から記録してきた出典や条件を、配布物で使うファイルと対応させます。加工した画像や音声は、元素材の条件も確認対象です。

プログラムやライブラリの文書も含め、使用しているものに必要な表示を配布物へ入れます。既存プロジェクトにある文書と、追加したものの利用条件を使い、何を同梱するかを決めます。

実行に必要な部品は、プロジェクトのリンク設定と配布条件に基づいて確認します。このプロジェクトのDxLibは静的リンクです。配布のためにDxLib本体一式を実行ファイルの隣へコピーする構成ではありません。

配布フォルダーを作る

Releaseの出力を使い、配布用フォルダーへ次の内容をまとめます。

内容	確認すること
AutoShooter.exe	今回のReleaseビルドで生成した実行ファイル
Assets	実行に使う画像、音声、マップ
ライセンス・著作権表示	同梱文書と追加素材の条件に対応するもの
操作案内を付ける場合	実際の操作・起動方法との一致

フォルダー名や案内は作品に合わせて決められます。実行ファイル名を変える場合は、Play.cmdなど、その名前を参照する起動方法も対応させます。

ソースを含めて渡す場合は、Source、Assets、ソリューションとプロジェクト、必要なツールやテスト、文書をまとめます。実行用の配布物と、開発を続けるためのプロジェクトは目的が異なります。

配布物そのものを起動する

作成したフォルダーの実行ファイルを、Visual Studioからではなく直接起動します。開発環境の外へコピーした素材と実行ファイルの組み合わせで、作品が動くか確かめます。

開始時のHP、武装、解放条件、ウェーブは、自分の作品の設定と比べます。配布版の数値へ合わせる作業ではありません。

独自の攻撃や取得画面へ進み、画像と音声が読み込まれるか、ゲーム終了や再開がつながるかを確認できます。Rキーを残している作品では、連続して再開しても、独自ルールの状態や候補の位置などが開始設定になるかを見ます。

他のPCでの確認では、起動の成否に加え、文字、音、操作、処理負荷も確かめられます。同じPCでのビルド成功だけで、別環境の動作まで分かるわけではありません。

配布フォルダーを圧縮した場合は、そのアーカイブを展開して起動すると、まとめた内容を確認できます。制作を続けた後も、配布物へ新しい実行ファイルと素材が反映されているかを照合します。

第12回では、完成ゲームとして全体を遊び、作品を仕上げます。