Okie doke... it's like this, folks: the current sound system needs some tweaking to result in better audio.
Most of us who're modders are familiar with the problems- the fact that sounds are currently being exaggerated or drowned out during play, over-loud unit acknowledgements, etc., much to the detriment of creating good sound for our games.
Based on my experiments and reading through the current source, my feeling is that the current system will never be satisfactory for game designs that aren't very much like OTA, and are even problematical for them. The sound system used today is the result of people trying to get things to work generically, without having modders configure their mods properly, and I don't think that the majority are well served by this approach. For example, weapon sounds are tied to their Default damage values, just as so many other things were, such as the special effect.
In short, we need modder-configurable sound parameters, and preferably a couple of new tags... and a better sound system will result.
Here's what I'd like to propose. As usual, this is just my opinion and feel free to disagree or to offer alternative proposals.
1. All sounds should be listed in a textfile, called "sounds.tdf" or something like that. If sounds aren't listed there, they will be loaded and played (for backwards compatibility purposes) but they will end up with default parameters.
Here's how they should be listed:
Code: Select all
[SOUND]
{
soundname=MachineGun01Quiet;
soundfile=MachineGun01.wav;
soundradius=1000;
soundscale=1.0;
echo=1;
echoscale=5;
echotime=0.5;
doppler=1;
dopplerscale=1.0;
}
soundname gives the engine a name to use when getting the sound, much as it does now- but with a twist: because the name and the filename aren't the same things, we can use the same sound, with different settings, under different names. So, for example, if I want a machine-gun that can be heard a long way away, and another that can only be heard a short distance from the viewpoint, I can make two different named instances of the sound, with different parameters.
soundfile actually refers to the WAV that will be stored in memory.
soundradius is the maximum distance that the sound will be played at maximum volume. After that, the sound will taper off, depending on the distance from the current viewpoint. Designers who want their sounds to be audible, but quieter, over very long distances, can get the effect they want by working with scale.
soundscale is a value with a minimum of 0, that states how much sounds are scaled down once we're past the radius value. A value of 1.0, for example, might mean that for every 100 units the camera, the sound might lose 10% of its volume. A value of 0.5 might mean a 5% reduction, and so forth. How scale is set up doesn't matter a great deal, so long as it's well-documented how it works, so that modders can adjust things transparently. It obviously needs to be tied to distance from the viewpoint and to volume, but the exact relationship can be determined by both coders and modders through some experiments and trial and error.
Have a sound (like, say an "emergency" noise) that you need players to hear at full volume, no matter where they are? Don't do it through hard-coding it into the game engine- simply set up the sound, set up the conditions in COB or in the Unit Acknowledgements to get it to play, and give it a soundscale of 0. Then it will always play at full volume, everywhere. Simpler than the current mess, and better, too.
echo is, pretty obviously, a big request. In fact, if nobody's interested in it, by all means ignore it and doppler and please just consider the stuff above. However, I think that being able to specify that a sound can echo would add tremendously to the feel of Spring mods. Echo would be a integer- a value of 0 means no echoes, while any number from 1 to whatever would be the number of echoes played. Obviously, for performance reasons, modders are rarely going to use more than 2.
echoscale would give us a scalar value to use, just like soundscale, that would tell us how much quieter each echo is than the original sound. In this case, I want the echo to be 50% lower than the original sound, so I've used a value of 5. The next echo, if I had more than one, would be 25% of the original volume, and so on.
echotime specifies how long after the first version of the sound plays we hear the echo start. Modders could do all sorts of things with this, from giving a long echo time and big scale, for Giant Tank Cannons of Doom, to having a very short time and a very small scale for sounds that are actually repeats of one very short sound. Combined with the sound-playing code in COB, we could do some very cool things with this, without being performance-crippling.
doppler specifies whether the speed ratio between the viewpoint and the object making noise has an effect on the sound. BIG NOTE: if the viewpoint is in motion or not, that should not effect the calculations- the sound system should continue to act like the viewpoint isn't moving!
Doppler is a really useful effect for adding realism to soundscapes, especially for fast-moving units.
dopplerscale this scalar value raises/lowers the amount of doppler based on speed. Setting it really low means that there's hardly any doppler, and the default is 0. Setting it really high means that even small amounts of relative motion will result in dramatic changes in the pitch of the sound. Very useful for things like Kbots, where we might want a very generic "walking" sound (some mechanical "zeep" sound, followed by a light "crunch" )... we could specify these as two different sounds, have the COB play them right after one another ( "zeep... crunch" ) and then have the "zeep" be subject to doppler- the source of the "zeep" is in motion, whereas the source of the "crunch" is not. This would give us very lifelike sound with minimal problems on the content-design end.
