バージョン

menu_open

Workgroupに関する、コツとベストプラクティス

Wwiseでソースコントロールシステムを採用する前に、以下のセクションに目を通して、オーディオ開発プロセス全体を通してチーム作業やプロジェクトファイルを効率的に管理するための、コツやベストプラクティスを参照してください。

プロジェクト計画の段階で

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

  • グローバル(全体にかかわる)Work Unitの責任者を決める。Master-Mixer HierarchyやPresetなど一部のプロジェクトエレメントは、追加したWork Unitにさらに分割することはできません。 このようなプロジェクトエレメントの変更を1人の担当者に限定するか、少なくとも全ての変更を把握している担当者を1人確保すると良いでしょう。

基本的なワークフロー

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

    • 他のチームメンバーに、グローバルエレメントが変更されたことを警告する。

    • チームメンバー全員に、自分の変更をチェックインしてもらう。

    • 自分のファイルをチェックインする。

    • チームメンバー全員に、各自のプロジェクトファイルを更新してもらう。

    • 以上の処理を行えば、他のチームメンバーが更新するだけで新ファイルを入手でき、マージする必要がない。

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

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

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

ファイルの同期

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

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

    これはWorkgroupプラグインを使用しない場合に限ります。Workgroupプラグインを使用中に同期すると、プロジェクトの最新バージョンを再ロードするよう自動的にプロンプトが表示されます。

ファイルのチェックイン

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

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

ソースコントロールシステム

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

プロジェクトの不整合

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

Communication

  • 頻繁でオープンなコミュニケーションを推進する。どのようなWorkgroup環境においても、他のチームメンバーとオープンな情報交換を頻繁に行うことが重要です。オープンなコミュニケーションを頻繁に行うことでコンフリクトが減り、ファイルマージの時間を短縮できるので、制作パイプラインの効率化につながります。例えば、他のチームメンバーに影響するようなWork Unit変更を実行する前に、各自の変更をチェックインして、連絡するまで作業の同期や再開を保留するように依頼します。

使用中ファイル

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

SoundBank

  • プロジェクトに変更がある度にSoundBankを編集しなくてもよいように、SoundBankのセットアップを、Work Unitやフォルダを使って再現します。WwiseがSoundBankのエレメントと、プロジェクトのエレメントの間のアクティブリンクを維持するので、これらのWork UnitをSoundBankに追加すれば、SoundBankが自動的に更新されるので、編集が一切不要となります。


このページはお役に立ちましたか?

サポートは必要ですか?

ご質問や問題、ご不明点はございますか?お気軽にお問い合わせください。

サポートページをご確認ください

あなたのプロジェクトについて教えてください。ご不明な点はありませんか。

プロジェクトを登録していただくことで、ご利用開始のサポートをいたします。

Wwiseからはじめよう