battle_chatter
Tuning battle chatter
\
Battle chatter is primarily speech events played during battle. The purpose of battle chatter tuning is to ensure that battle chatter is spoken in context and at the correct frequency. There are a lot of speech events in the game and the player should not be too often hearing repeats of the same chatter event.
\
\
If you look through speechevent.h in src/game, you will see a list of all the speech events in the game. We are interested in only the first 400 lines or so of this list. Some of these events qualify as battle chatter and are hooked up as such. Each speech event may, and often does, have a number of variations. They all mean the same thing, they just provide some variety. In cases where there are more than 10 variations, the speech event is duplicated and an extra speech event with _more at the end of it is created. See the following example:
\
#define STAT_Grp_LosingBattle 131157
#define STAT_Grp_LosingBattle_More 131158
\
This is all handled transparently by the battle chatter engine and is not a concern for tuning.
\
While it is not supported by the game code right now, eventually we will be able to tune the relative frequencies of each variation. Time permitting, we will also add a historical heuristic to the variation to prevent random repetition. Once again, this will be transparent to the battle chatter engine.
\
So in conclusion, we have speech events with variations in them. Battle chatter is just a way of triggering speech events.
\
\
There is a number of probability numbers we can tune for battle chatter events.
-
Global frequency modifier (not yet implemented).
-
Probability of a given speech event being spoken.
-
Distance probability curve.
-
Historical probability curve.
-
Repeat proximity curve.
\
These 4 probabilities are multiplied together to get a probability of a particular speech event being spoken. Most battle chatter events are evaluated once every ½ second. Some are evaluated many times every ½ second. There will be a list below describing these evaluation criteria.
\
The probability curves are defined by a maximum (distance, time since last spoken, proximity) and an exponent. The exponent enables a variety of curve geometry’s which are useful. See the following example of different exponents on the distance probability curve.
\
\
\
\
\
\
\
\
\
\
\
\
\
To see how this is useful, consider the case of a speech event such as STAT_Fighter_WingmanChased, where the leader of a wing says things like “You’re sliding off line, correct!” and “You’re losing wing lock.” These speech events are really only applicable when the camera is looking right at the fighter. In this case, we’d use a high exponent, perhaps 5, to ensure that it is most often spoken up close.
\
In another example, STAT_Grp_StartBattleDisadvant, the pilots say things like “I’ve got a bad feeling about this.” As this is something of a report intended for the rest of the battle group, it should be spoken somewhat regardless of the distance from camera. As such, a low exponent of about 0.2 would be useful.
\
An exponent of 1 is a linear probability ‘curve’. The probability would decrease evenly based on distance from the camera.
\
I’ve explained the distance probability curve but the other curves behave similarly. The historical probability curve varies from 0% immediately after the event is spoken to 100% after the “minWavelength” has expired. Use of the term wavelength may be confusing at first but it is the inverse of frequency. Here you specify an amount of time in which the likelihood of the speech event being spoken again increases to 100%. A high exponent would ensure that the speech event would not be repeated until close to the expiration of its “wavelength”. A low exponent would be used in cases where you don’t care if the speech event is repeated.
\
The proximity curve controls the likelihood of a speech event being played in the same place as it was spoken last. You specify a distance and an exponent for the probability curve. This feature is useful in cases where you don’t want a speech event being repeated a lot unless it’s said far away. For example, suppose you had 2 battles going on and they’re both getting beat up badly. If one battle says “We’re getting our asses kicked here, fleet!” and then you zoom to the other battle, it would be appropriate for the other battle to say the same thing. It’s repeated in a short span of time, but in different parts of the universe. A high exponent would make sure it’s never repeated within the same part of the universe. A low exponent would be used in cases where proximity does not matter so much.
\
Not all chatter events have all three curves. What chatter event use what curves is determined by the battle chatter code. In general, if there is a curve defined for a speech event, leave it there. If you want one of these curves and there is none there, let me know and I’ll hook it up. If you don’t want a time or proximity probability curve, specify a minWavelength or a minRepeatProximity of 1, which will mean that it will be 100% likely all the time.
\
Finally, I’d like to point out that when I say 100% likely, I mean for that curve only. There are up to 3 curves which are multiplied together (30% * 30% * 30% = 2.7%) with the “randomWeight” value. The “randomWeight” is not specified as a percent, but as a number from 0 to 1.
\
Here is a chart that breaks down the effect of various exponents on the various curves.
\
Members to tweak
Purpose of max/min value
Effect of high exponent
Effect of low exponent
Overall probability
randomWeight
1 means 100% for this ‘curve’.
N/A
N/A
Camera distance
maxDistance
expDistance
Maximum distance from camera this event can be heard (metres).
Will only be spoken very close to camera
Distance from camera not important, up to the maximum.
Historical probability
minWavelength
expWavelength
Amount of time during which the probability of repeating event increases to 100% (seconds).
Will not be heard again until wavelength expires.
May be repeated freely.
Repeat proximity.
minRepeatProximity
expRepeatProximity
Distance from where the event was last spoken (metres).
Will not be repeated within distance specified.
Distance form place last spoken not so important.
\
\
In order to make this complex tuning process simpler, I will implement a few pieces of code:
-
You will be able to disable all events but one, to avoid aural clutter.
-
There will be a global modifier to tune the total probability of chatter. This may be incorporated into the front end as part of the audio settings. Some people like lots of chatter, others less, Daly none.
-
You will be able to re-load these chatter settings real-time.
\
Not all chatter events are implemented currently. Notably missing are all the capital-ship-specific battle chatter events. This first pass of tuning will help us tune the new chatter events, as they become available. For now, however, we will have to tune the ones we have and leave the other ones to be tuned later. As the new events are added, there will be a greater number of overall chatter. This can be tuned down by adjusting the global chatter frequency modifier.
\
See here later for more detail