[CF-Devel] Sounds, continued

Thu Apr 29 02:27:47 CDT 2004

Nicolas Weeger wrote:
>

      Been thinking again about sounds, here's what I'm gonna do.

     >

     >

      Put .snd files with archetypes, format:

     >

          sound goblin_death

     >

          file goblin_death_1      <- .raw omitted voluntarily

     >

          volume 'normal' volume

     >

          text a goblin die        <- client could display 'you hear <text>'

     >

          <more info if/when needed>

     >

          endsound

  Looks good.

  I'd document that you probably want to have more generic names, unless there 
are going to be that many sound files (eg, should you use goblin_death with 
orcs?  It would seem confusing if you do)

>

     >

      .raw files will just stay where they are (in the future maybe client 

     >

      could request a sound, but let's first make the big part, improve sound 

     >

      support :)).

  The sound files should really get moved into the client CVS area, vs being 
their own checkout, but thats not a major deal.

>

     >

      Those .snd will get collected by collect.pl, and make a sounds_arch file.

     >

      This file get parsed by server at startup, assigning a unique identifier 

     >

      to each unique name (thus ignoring duplicate names) and trashing the rest.

  In practice, the collect should deal with removing duplicate names, like it 
does faces, and complain if two different files use the same sound name but are 
different.  Otherwise, I'm sure someone will run into the case of adding a new 
sound and it not working as expected, because he chose a duplicate name of 
another sound.

>

     >

      Add sound lines to archetypes:

     >

          Object goblin

     >

          ....

     >

          sound death goblin_death <optional info if/when needed>

     >

          ....

     >

     >

      Server at loading links the sound with event ('death', 'apply', ...) and 

     >

      makes sure sound actually is defined.

     >

      Of course, 'sound' could get 'overriden' in artifacts, like other fields.

     >

      Maybe simply be an array of values, mapping event => sound number.

  I'm not sure what you mean by that last sentence of event->sound number. 
Pretty much it is almost aways better to use english/words in the files than 
just numbers.

  I'd also note that you should be able to define more than one sound element to 
an event, eg, something like:

sound death goblin_death1 ...
sound death goblin_death2 ...
sound death goblin_death3 ...

>

     >

      Now this sounds_arch file is parsed by client too, merging info from the 

     >

      sounds with same name.

     >

     >

      When server sends a sound, giving identifier and volume, client finds 

     >

      the group of sounds with that name, and uses one randomly. Each sound 

     >

      has its 'nominal' volume, to adjust it correctly.

  I take it this is to cover the case above - you might have three different 
goblin_death definitions?

  I'm not sure I like it - it means it that it is more likely that you'll need 
to set up more sound info lists for objects.  Eg, lets say the goblin does have 
3 death sounds.  Lets say that I want to use one and only one of those for the 
orc, plus a couple others that may get shared (maybe one from the ogre also or 
something).  this may mean that the number of .snd files could easily be many 
times the actual number of sounds.  It also means it is harder to use already 
defined sound files for map customizations.

  But the other case is this oddity - since the client would choose which sound 
to play, if there are multiple sounds associated, two players on the same map 
could get different sounds even though they are hearing the same event.  This 
would seem particularly odd if those two players are in the same physical room, 
and thus hear the sound from the others computer.  I think it'd make more sense 
for the server to choose the sound to play, so that everyone gets the same sound.

  If you do that, it also means that as part of the optional parameters for the 
sounds, you could have different weightings.  Eg, something like:

soundinfo
death goblin_death1 30
death goblin_death2 10
death goblin_death3 40
endsoundinfo

  Thus, goblin_death2 is played only 10% of the time, compared to 30 and 40 for 
the other ones (and perhaps if the totals are less than 100, then have that 
remainder 20% have nothing played?  EG, I could certainly see cases where you 
want the sound played some of the time, but not all the time the event happens.

  I also changed the way the sound events are listed - put it in a 
soundinfo/endsoundinfo block - I think this would make it easier on the editor - 
I'm not sure how the editor deals with fields that start with the same apparant 
name - it might strip some of those out.

>

     >

     >

      The choice of putting all info (client and server) into .snd is to have 

     >

      only one sounds_arch file shared between client & server.

  seems reasonable.

>

     >

      Also, it wouldn't be hard to have a 'sounds_maps' file, with info from 

     >

      special sounds in maps (text to congratulate a player on defeating a big 

     >

      bad boss?), and parse it too at client/server startup.

  The problem here is that at startup, the server needs to know it has has that 
sound it needs to associate.

  I personally don't think there is any need for this - to add a congratulate 
player event, you're going to have to add the sound to the list of available 
sounds, and if you've already done that, making up a .snd file should be trivial.

>

     >

      The only link between client & server is the 'sound name'. Server has no 

     >

      idea of different sounds for one event.

  Which as said above, I don't quite think is correct, as it would mean 
different players would here different sounds even though they should here the 
same thing.  And I think at some point, it'll be found that the server will want 
to customize the sound based on other events.

  For example, right now, when you hit something when attacking, different sound 
it played based on the amount of damage - I'd probably say you don't want to 
have 5-6 different hit sound lists - rather, it'd be nice to have just one 'hit' 
event, and through some mechanism, the server can choose which one to play based 
on damage.

>

     >

      This could also be used for 'server' events like 'player login/logout', 

     >

      and why not background music (special event 'sound background'?)

  Certainly a list of sound events that the server players, or perhaps have 
event_type tag in the the sound information itself.  Thus, you could hve 
something like:

#define SOUND_PLAYER_LOGIN 1
#define SOUND_PLAYER LOGOUT 2
#define SOUND_PLAYER_DIE 3

...

  and then

sound player_die
type 3
....
endsound

  (player die could be used for something else).  But I'd rather have some form 
of mapping like that, vs the code specially looking for sounds by name. 
Although, I suppose you could do something like:

#define SOUND_PLAYER_DIE "player_die"

  or whatever.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel