Overview of Character Barks

Before beginning, it is instructive to examine the existing vanilla player soundsets to understand how they work.

Asks Blueprint

Start by searching for one of the player soundsets blueprints. In KM/Wrath these are of the form PC_Male_XXX_Barks/PC_Female_XXX_Barks. For example, PC_Female_Cunning_Barks. The RT equivalents are of the form RTMaleXXX_Barks/RTFemaleXXX_Barks. BubblePrints is recommended, although you can also look at the appropriate JSON blueprint (PC_Female_Cunning_Barks.jbp) found in blueprints.zip in the game's install folder (for KM download the dump) using a text editor like Notepad++ if you prefer. The first thing to note is that the type is a UnitAsksList blueprint. If using BubblePrints you can use this as a filter in the search bar by typing t:BlueprintUnitAsksList. We'll need to create our own custom blueprint of this same type with our own unique values and inject it into the game. In the Component list we can see a couple of items of note up the top, like the PreviewSound (what you hear when you click on the name in the Voices list in the character creator), which we'll circle back to later.

The meat of the blueprint is the actual Barks themselves, starting with Aggro. Each of these have one or more AkEvent entries, which are the in-game triggers that fire a given audio file. This is part of the "AkSoundEngine", i.e. the game engine side of Wwise. The Asks blueprint links a particular AkEvent, or group of AkEvents, to a particular Bark. In Wwise you link your audio to Events which match the AkEvent names in your soundbank. The Barks also have a set of variables that control things like whether a sound will interrupt an already playing sound, the cooldown before one of the Bark's AkEvents can trigger again, the random chance of an AkEvent actually triggering a sound, etc. The AkEvents themselves similarly have a number of variables, primarily related to how the randomisation works in a collection of multiple AkEvents.

There are a couple of Barks that have no AkEvents defined in the vanilla soundsets: RefuseUnequip (presumably for curses), StormRain, and StormSnow. While none of the vanilla PC soundsets use these Barks, it is possible to make use of them in a custom soundset. But more on that later.

The last Bark is AnimationBarks. This is a particular sub-class of Barks that, as the name suggests, are linked to specific animations. Thus they have an AnimationEvent as well as an AkEvent. The vanilla player soundsets only have two defined, AttackShort and CoupDeGrace, but there are number of others available.

On a final note, this is the full array of available Barks, as defined in Kingmaker.Visual.Sound.UnitAsksComponent.Bark. However, as noted above there are a number of additional AnimationEvents that can potentially be added to a custom soundset. These are defined in Kingmaker.Visual.Sound.MappedAnimationEventType. Of primary interest for player/merc soundsets are the spell casting AnimationEvents, which will be covered later.

SoundBank Structure

To get a clearer understanding of how the Barks relate to individual sounds, we can look at SoundbanksInfo.xml found in the game folder (\Wrath_Data\StreamingAssets\Audio\GeneratedSoundBanks\Windows). Open the file in Notepad++ or another text editor. Search for <Path>PC_Female_Cunning_GVR_ENG.bnk</Path> which will take you to the start of the PC_Female_Cunning soundbank definition block. You will see a list of Wwise Events which match the AkEvent names in the blueprint and their attached sounds (IncludedMemoryFiles). There are 44 Events, although two of these - Poisoned and AttackPower - are not linked to any Barks in the blueprint. There are 133 sounds specified, of which 4 are duplicates and 12, all the poisoned and 4 of the AttackPower/PowerAttack, aren't used at all.

More importantly, this gives a breakdown of how individual Barks introduce randomisation into the sounds they play, particularly common events like selecting a unit or engaging in combat. It also reveals how the Wwise setup handles certain game factors like a unit being in stealth through game syncs like Switches and Game States.

For more detailed information on the internal structure, you'll need to use wwiser alongside the appropriate names list - KM / Wrath / RT (rename to wwnames.txt). Peruse the wwiser readme and doc for detailed information on how to use the program and what it can do, but the brief overview is to put the vanilla Init.bnk, any soundbank/s of interest (e.g. PC_Female_Cunning_GVR_ENG.bnk), SoundbanksInfo.xml, Wwise_IDs.h, and the aforementioned wwnames.txt in the same folder as wwiser.pyz. Run it, load the BNKs, let it process the names, tick the checkbox to allow duplicate TXTPs, then click the Generate TXTP button. This will export a text file for every container inside the bank, detailing the container's settings (randomness, etc.), its contents (audio files), the Event it is linked to, and any related game syncs (RTPCs, States, etc. - refer to the Wwise section). You can also choose Dump Banks to output an XML map of the structure of all the supplied banks that you can view in a web browser. This is primarily of use when trying to reverse-engineer the contents of Init.bnk, but typically won't be of much use/interest to most users.