Wwiseヘルプ

プロジェクトを小さいWork Unitに分けます。プロジェクトの規模が大きくプロジェクトデータを全て複数のDefault Work Unitに入れてしまうと、Wwiseのレスポンスタイムが遅くなる上に1人が変更を加える度に他のチームメンバーもマージする必要があり、マージ問題やコンフリクトの危険性が大幅に増えてしまいます。Work Unitでプロジェクトを小規模なグループに分けることで、全員の作業効率が上がり、情報へのアクセスも速くなり、各自が別の部分で作業できるので、マージ問題の可能性が減少します。

グローバル（全体にかかわる）Work Unitの責任者を決める。このようなプロジェクトエレメントの変更を1人の担当者に限定するか、少なくとも全ての変更を把握している担当者を1人確保すると良いでしょう。

プロジェクト全体に影響するグローバルなプロジェクトエレメントを、効率的に管理する。グローバルなプロジェクトエレメントであるStateやGame Parameterに対して名前変更や削除を行ってしまうと、プロジェクト内の他の多数のオブジェクト、例えばそのエレメントを使用するサウンドオブジェクトやコンテナなどが、全て変更されるかもしれないので、注意してください。変更を保存してチェックインしてしまうと、他人が作業をしている多数のプロジェクトファイルにも影響するかもしれません。このような変更による影響範囲を限定するために、できるだけ早い段階でグローバルなプロジェクトエレメントを設定して、以後は変更しないように心がけてください。初期設定の後に変更する必要がある場合は、以下を行ってください。

ファイルのステータスを確認する。Work Unitで作業を開始する前に、File Managerを見て、読み取り専用のファイルを確認してください。読み取り専用のWork Unitを変更しても、プロジェクト内でそのファイルを保存できません。

ローカルファイルを定期的にバックアップする。中央レポジトリにあるファイルは定期的なバックアップ計画の対象かもしれませんが、ローカルマシンにあるコピーは対象外です。データ紛失を防ぐために定期的に自分のプロジェクトファイルをバックアップすると良い習慣であり、特にファイルに大幅な変更を加えた場合バックアップが大切です。

チェックイン前にインテグレティレポ。Work Unitをチェックインする前にインテグレティレポートを生成して、プロジェクトエラーがないかを確認すると良いでしょう。エラーがあった場合は、解決してから、Work Unitをチェックインします。

新しいワークセッションを始める前に同期する。新しいワークセッションを開始する前に自分のプロジェクトファイルをサーバと同期し、最新の変更が手元にあることを確認してください。

同期前にWwiseを閉じる。ファイルをサーバとシンクする前に、Wwiseを閉じて情報の紛失を防止してください。Wwiseが開いた状態だと、メモリにそのコピーが残ります。同期すると自分のディスク上のファイルが変更されますが、プロジェクトの自分の旧バージョンがメモリに残ります。現在開いているプロジェクトを保存する時に、ディスクに保存された他人による変更を上書きしてしまうかもしれません。

This only applies if you are not using a source control plug-in. When you sync using a source control plug-in, you are automatically prompted to reload the latest version of the project.

サブミットを頻繁に行う。大きな変更を行い他のチームメンバーに影響する場合は、頻繁にファイルをサーバにサブミットして他のメンバーがその変更メリットを取り入れられるようにします。時間が開きすぎると、コンフリクトの確率も高くなります。小規模で的を絞った変更をサブミットすれば、必要に応じて簡単にプロジェクトの旧バージョンに戻すことができ、コンフリクト発生の際の解決も容易です。

役に立つコメントを添付する。ファイルをコミットまたはチェックインする時に、どのような変更を加えたのかが明確に分かる説明を添付してください。

ソースコントロールシステムの理解を深める。Wwiseプロジェクトのファイル管理にソースコントロールシステムを採用する前に、その機能を充分に理解しておくべきです。ソースコントロールシステムの細かい仕組みを知ることで、問題を回避して効率的で有力な制作パイプラインを構築できます。

WwiseプロジェクトのXML構造の理解を深めるファイルをマージする前に、WwiseプロジェクトのファイルのXML構造を理解する時間を確保してください。場合によってXMLをアップデートする必要があります。理解不足はプロジェクトの崩壊を引き起こしかねません。もしXMLを編集した場合は、ファイルをソースコントロールシステムにチェックバックする前に、必ずプロジェクトをWwiseで開いてください。XMLの変更した部分が有効で予定通りの内容であることを、確認できます。

頻繁でオープンなコミュニケーションを推進する。In any team environment, it is key that you communicate openly and frequently with the other members of your team. オープンなコミュニケーションを頻繁に行うことでコンフリクトが減り、ファイルマージの時間を短縮できるので、制作パイプラインの効率化につながります。例えば、他のチームメンバーに影響するようなWork Unit変更を実行する前に、各自の変更をチェックインして、連絡するまで作業の同期や再開を保留するように依頼します。

File ManagerのUsage列で、Unusedとマークされたファイルを削除する前に、プロジェクトを一旦閉じて再度開き、この情報が最新であることを確認する習慣をつけると良いでしょう。

SoundBanks are configured in Work Units in the SoundBanks tab of the Project Explorer. The Work Unit files are in the <project>\SoundBanks\ directory, and are XML files with the extension .wwu. You can reduce the frequency of changes to these files by populating them with objects such as Containers instead of, for example, individual Sound SFX.

Generated SoundBanks are created by Wwise, by default in the <project>\GeneratedSoundBanks\ directory. They are binary files with the extension .bnk. Since they can always be generated from the project, we recommend you exclude them from source control. See 「Using Wwise with your source control system」.