Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Best practice of managing audio dialog in large projects?

Discussion in 'General Discussion' started by elmar1028, Oct 29, 2016.

  1. elmar1028

    elmar1028

    Joined:
    Nov 21, 2013
    Posts:
    2,353
    Hi guys,

    This question has been bugging me for a while! I've been wondering what's the most accepted and commonly used method of storing and managing audio dialog files in games like Witcher 3 and Call of Duty? How are they stored and then quickly located by game developers?
     
  2. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,521
    The actual implementation varies by engine. By engine I mean the high level framework like what's exposed in the Dragon Age Toolset, Gamebryo/Creation Kit, etc. Whatever the engine, studios usually take great care to manage these assets because a large game can have many thousand audio clips and corresponding lipsync animations.

    Further complicating it is that there can be any number of lines for a character. When you have a model, naming is fairly straightforward; just name the model after the character (more or less). With audio lines, naming isn't so obvious.

    Even further complicating it is that, despite the director's best efforts, lines will have to be re-recorded. Maybe the audio levels on some lines aren't right, or maybe some content has to be cut and the surrounding lines re-recorded to work around the cut content.

    You can find some good tips for managing scripts, voice actors, and assets on gamasutra.com, and if I recall correctly the IGDA's Game Writing book has good advice, too.

    Most engines manage a database that links dialogue lines to audio and lipsync assets, usually with a specific naming scene. For example, in the Dialogue System, lines are called dialogue entries. Every dialogue entry has a unique entrytag in a format that you can specify, such as Character_Conversation_LineID.

    In most engines (including the Dialogue System), you can export a voice script, which is typically a spreadsheet containing columns such as:
    • entrytag / asset name
    • dialogue to record (possibly one column for each language, or each language in a separate voice script)
    • director notes (e.g., "spoken with anger")
    The voice director sends these off to voice actors and in return receives a set of asset files, preferably using the asset names specified in the voice script. Then the animators get a shot at the audio assets to create corresponding lipsync assets, often with the same name but a different extension (e.g., someDialogue.MP3 and someDialogue.FBX).

    Then they're put into the project using some kind of cataloging system indexed by asset name. For example, in Unity, they could be in Resources folders or asset bundles. Then the Unity game can use Resources.Load or AssetBundle.LoadAsset to actually load the assets. Usually there's a layer on top of Resources.Load/AssetBundle.LoadAsset to manually unload assets when they're not likely to be used again any time soon.
     
    Billy4184 and angrypenguin like this.
  3. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,301
    For each spoken or voiced line you'll have a some sort of "dialogue entry". For each supported language one "dialogue entry" will store text (for subtitles), reference to audio file, reference to a lipsync file, and additional data (whatever the game may require), maybe animation file as well. Dialogue line may be also firing some sort of scripting or animation events, so I wager it could be linked to some sort of animation track as well.

    That's pretty much the usual way to go, and I'm not aware of any standard here. In unity you'll be probably making a "DialogueLine" information a derivative of a ScriptableObject and it'll be sitting in your project... or maybe you'll implement some sort of custom solution based on json, xml, or whatever suits your fancy - so you'll be able to integrate it with some sort of external workflow or 3rdparty tool.