[crossfire] Background music

[Mark Wedel]

Nicolas Weeger wrote:
> Replying to various threads in the same message :)
> 
> Ok, so what about: server merely sends item's name, client-type, and event 
> type?
> For instance, 'goblin <monster type> death' or 'dragon <monster type> move' 
> or 'icestorm <spell type> move'.
> 
> Then client handles those values however it wants - play a sound, play a 
> random sound, don't play anything, blink the pic somewhere, ....
> 
> The type can also be used as a fallback method - no 'High Goblin' sound, play 
> regular monster sound.

  That mostly sounds good.  However, I still think some standards are needed.

  What is put in <monster type>?  Remember, monsters don't actually have unique 
type values - do you mean archetype name?  If so, that makes sense.  OTOH, it 
could also mean that there is a huge number of sound combinations - think of the 
number of different monsters we have in crossfire just in the archetypes - 
probably more than 100.  I'd think a fair number of those may have some common 
aspects (goblins, orcs, and ogres could/should share some common sounds).

  While the ideal case would be to have unique sounds for every monsters, I 
don't think there is any way we could come up with 1000 different sounds - we 
need to be practical and keep that in mind.

  I also think that it will be a requirement to be able to set what sound in the 
object - going by monster name really isn't good.  The most obvious case is the 
'boss' monsters, which tend to be uniquely named - you really don't want the 
client to have to know about the sounds for 50 boss monsters - you want to be 
able to set up the boss monster to use some particular sound (this may be the 
sound that archetype normally uses, could be the sound a different archetype 
uses, or could be a unique sound for bosses).

  You also want to be able to specify what objects do and do not have sounds - I 
don't think we want implicit sounds (this monster is moving, therefor play a 
sound), unless something is set for that monster to say we should play sounds. 
Another example here:  Having orcs make a noise whenever they move would be 
really annoying (annoying enough that most people would probably disable it 
through whatever way).  However, it may be desirable for the boss orcs to make 
noise.

  I'd personally suggest that various sound_... fields be used that describe 
what to play.  Once again, these could be general (a directory of sounds files) 
or a specific sound file.

  These can then get updated as new sounds show up (I now have a specific sound 
for a troll moving, so I don't need to use the ogre movement sound, etc) - 
simple archetype change, and things are good to go.

  It should probably also be discussed what type of events are needed. 
Remember, it should be more than just monsters - items the player uses also need 
events (firing a bow, shooting a wand), spells need events, etc.  And for all 
this to work, these event names need to be somewhat standardized - while it 
could be nice to have arbitary sound_<event> strings, like sound_burned_up, 
there still needs to be logic on the server of when to play sounds.

  A quick list IMO:
sound_move (monster moves)
sound_attack (monster attacks - should also be on weapons the player uses)
sound_apply (sound when applying something, like a clock)
sound_fire (sound when firing something, like a bow)
sound_destroyed (sound to play when something is destroyed, like burned up)
sound_active (sound for objects active, like a gate)

  In addition, there probably needs to be a secondary flag which states if that 
sound is always made or done once.  For example, for a gate, you probably want 
to run just one cycle, but for something like a fountain, should be continuous.


> 
> 
> Concerning sound files themselves, we should handle them like pics: client has 
> the 'standard' set, and can request from server specific sounds if needed. 
> Will need to check various issues (max packet size, ...)

  I disagree with that - it adds a fair amount of complexity and isn't really 
the right direction to go in.

  In the past, it has even been discussed that the server actually shouldn't 
server images, but that get offloaded to some other service.  Main issue being 
bandwidth (server may have limited amount).  But images are somewhat special - 
if there is a new object and you run accross it but don't have an image, there 
really isn't anything very good the client can do.

  But sounds are really purely optional - I doubt anyone would die because their 
client is missing a sound - the fact that a lot of people probably don't even 
play with sound at all basically says that sound shouldn't be a required part of 
the game (and any map that makes it so should probably state that fact, just 
like they do for multi player).

  Also, I'd expect sounds to change a lot less.  So putting them on an ftp 
server someplace works just fine.  And that saves a bunch of complexity on both 
the client and server.  If as I suggested, symlinks are used so one sound file 
could be used for multiple selections, handling this logic gets a lot trickier 
(how does the server know the goblin_die.wav should go in both 
effects/goblin_die and effects/orc_die for example?)

  Now what would probably make sense is for the client to have some logic to 
know if its sound file is out of date.  The easiest way to do this is to have 
something like a .version file in the different tar archives (that gets 
increased each time it changes).  The client can read that .version, and the 
server can say what it thinks the latest version of the sound files are, and if 
the client has an older copy, could pop up something to the player.  The server 
could also have an entry which says where to get the sound files, eg, 
ftp://foobar.com/serverbar-sounds-1259.tar.gz).

  In the case of this communication, this versioning would apply for the server 
sound files (eg, sounds/foobar/.version would contain the version string), so 
each and every server could have a unique versioning.

  This adds a little extra bother to players, but as said, I don't expect sound 
files to change very much - certainly not at the same rate as archetypes/images.