Priority Range

[sgossner]

The old priority range is as follows:

 100= emergency use only (undefined overhead)
  90= required (voiceover, you are under attack warning)
  80= rather important (battle sounds, death, destruction)
  70= rather important (building)
  60= not so important (resources)
  50= fluff (ambient - birds, etc.)
  Allowing for priority ranges between values.

Things we like about it:

• It leaves room for adding intermediate priorities.

Things we do not like about it:

• It only leaves room for expansion downwards.
• The order isn't quite right.

Things we need to account for in our priority range:

• Ensure there is room to expand on both sides.
• Split up tactical battle sounds (destruction/capture/etc.) versus background battle sounds (spears/swords/impacts).

Questions/concerns:

• Most games I've seen prioritize looping ambiances as the highest priority, as if the ambiance is disrupted, it may not be restarted correctly and can cause random drop outs which break the immersion. Unimportant ambiance elements like a separate sound of a bird chirping, but stuff like a waterfall or river flowing should probably remain high priority, especially if we loop them.
• One thing we might want to consider is 'priority group voice limits', e.g. there can only be 10 arrow sounds going on at once, for example.

Sam's proposed base solution:

80: Environmental background sound (including on-screen non-periodic emitters like waterfalls and rivers)
70: Unit and building selection and orders, UI interactions (confirmatory responses essential to gameplay)
60: Alarms, notifications, and warnings (very useful, but not genuinely essential)
50: Structure destruction/capture, unit deaths (important cues into the direction of the battle)
40: General weapon sounds and impacts (nice 'window-dressing' but not completely essential)
30: Gathering, building, and movement noises (non-essential)
20: Incidental, periodic ambiance (a gust of wind, birds chirping by trees, etc.)

70-80 are situations where if the sound does not occur, or if the sound is stopped at any point, it would be immediately noticeable/audible or possibly cause confusion. 60 are very valuable, but won't lead to catastrophic failure if they don't sound. 50 are useful and helpful, but even less essential. 20-40 are coloration which improve and enhance the game, but do not contribute significantly nor would be truly missed if one did not sound.

Sub Priorities

Another problem we face with sounds is situations where an excessive number of sounds may be called in a single tick. For this reason, we may wish to organize 'sub priorities', which sit between the levels and ensure the most important or noticeable sounds in a given range have priority. For example, a battering ram is more important/noticeable than one of 10 archers.

Sub priorities would be optional; not all ranges would have it necessarily, only those where there is a clear hierarchy of sounds within it.

Sub priorities might work something like this (draft):

49: 
48: (other)
47: other siege
46: siege bolt-throwers
45: swords
44: pikes
43: spears
42: javelins
41: slings
40: bows/arrows

Priority/Sub-Priority Voice Limits

These sub-priorities could be used to specifically limit how many of a certain sound is played in a tick, the 'priority group voice limit' discussed above. For example, now if 40 requests for an arrow fire sound arrive in the same tick, you get a really unpleasant result and it takes up a ton of voices for no good reason. Instead, if we, for example, limited the arrow sub-group to 6 voices, only the first 6 requests would be honored (the others ignored). This happens on a tick by tick basis. Sound requests that do not fit in the tick they were requested in do not 'roll over' to the next tick and are simply ignored.

We do this often in sample libraries to avoid a situation where a single note can be played and layered over and over, using up too many voices. The reason we do this is to significantly cut down on voice count during dense parts of music. The aural difference between 1 voice and 2 is much more than the difference between 6 voices and 7, and even more so than 20 and 21. Limiting voices in this way will help preserve voices in busy situations, making the engine need to use priority less and run more efficiently with fewer needs for sounds.

A XML file could exist to specify priority group limits (e.g. alarms may not have a limit, but weapons perhaps to 6 or 8, etc.). This could be in terms of individual priorities (e.g. priority range 40-49 has a total of 10 voices per tick to split up, meaning if there are 9 bolt-thrower attack sounds in a tick, only one sword sound in that same tick would get to play and no arrow sounds) or individual sub-groups (priority 40, 45, and 46 each have voice limit of 5, meaning the 9 bolt-thrower attacks would only play 5 sounds, then only 5 sword sounds, then only 5 arrow sounds). In this way, battles can be balanced aurally to ensure no one sound dominates in a case where ticks align.

Note that situations of many sounds appearing on the same tick are somewhat uncommon. It usually happens in a situation where a number of units are told to attack simultaneously.

This solution will help with the issue of running out of voices/channels, at least until we can implement Intensity.

Please feel free to propose different concepts, questions, or solutions in the comments!

[Porrumentzio]

Your proposal is great :)

I like the priorities you proposed. I did not understand well that about subpriorities, but if you could technically develope that, it would be great!

I'll merge this on the Roadmap

[sgossner]

Your proposal is great :)

I like the priorities you proposed. I did not understand well that about subpriorities, but if you could technically develope that, it would be great!

I'll merge this on the Roadmap

Updated as requested! I hope it is more clear now. :)

[Porrumentzio]

Now I understood better that about sub-priorities :) I think we could create a list according to (sub)directories or sound XML files, to be easy to change anytime with a script.

About the Voice limits, is it same of Threshold, mentioned in the Roadmap?

What do you think?

[sgossner]

Threshold was supposedly going to be used as the scaling factor for when to switch to a higher Intensity:

...To keep things simpler for itself, once the sound manager reaches the point where its playing a given amount of sounds or more simultaneously from the same audio group, then it will switch to playing a single sound effect of multiple hits. This value is, as far as I can determine, the threshold at which this group would stop and the one above it would start. From: https://trac.wildfiregames.com/wiki/SoundGroup

Threshold is a part of Intensity. The idea of Intensity is to save resources by replacing a bunch of simultaneous sounds with one sound.

The idea of the Voice limits is instead to save resources by preventing excessive use of a single sound [by only allowing a certain number to be used in each tick]. This is necessary in one of two cases:

• Until we have Intensity set up, this is completely necessary.
• For any sound which does not have additional intensities, this will remain necessary to prevent that sound from 'spamming' the audio engine.

Edit: If we wanted, we could alternately set up voice limits as part of the XML files, rather than relying on threshold to do it. This might be easier actually...

[Porrumentzio]

Understood. I would implement it as a parameter on XML, so they can be easily changed :) Is this possible to develop?

[StanleySweet]

Isn't there a parameter already for this?

[Porrumentzio]

I would say that no.