[CF-Devel] sounds system

[Mark Wedel]

Michael Toennies wrote:

>
     
     
     >
     
      i saw this kind of sounds.
     
     >
     
     
     >
     
      ambient sound
     
     >
     
      effect sound
     
     >
     
      static sound source
     
     >
     
      dynamic sound source
     
     
 Agree.


>
     
      Ambient sounds
     
     >
     
     
     >
     
      Ambient sounds are the background sounds. it *can* be music too, but i think
     
     >
     
      more about noices like
     
     >
     
      dropping water, bird noices, wind noices, etc.
     
     >
     
      In CF we can insert here a static system which depends on the map makers
     
     >
     
      idea about it.
     
     >
     
      The sounds will played randomly in a loop - after one noice has ended, the
     
     >
     
      other starts.
     
     >
     
      It is good to make here a 2 or 3 layer system (= channels) so some sounds
     
     >
     
      can overlap - this
     
     >
     
      will give a nice "sound ambient".
     
     >
     
      In some games, the have very nice ambient sounds - if you ever can, try ot
     
     >
     
      the game "Giants",
     
     >
     
      the have some big ambient sound files in the sound folders.
     
     >
     
      We must here assume that we don't have access to this ass kicking sounds -
     
     >
     
      so we make it somewhat
     
     >
     
      easier.
     
     >
     
     
     >
     
      In other programs, the server analyze the map tiles and the structures - and
     
     >
     
      generate from this a
     
     >
     
      ambient sound table. This is often chained to sound sources, so this both
     
     >
     
      systems can overlap here.
     
     
 A few questions/clarifications:

When you say the next sound is played, does that mean that each terrain type may
have multiple sounds associated with it, or does that mean it may play the
forest sound, then the water sound, then the xxx sound, etc?

 Are sounds ever played simultaneous (ie, wood sound with the water sound at the
same time), or is that done in the looping I described above?

 I would presume that volume/type of sounds would change as the player moves
around the map.  As the player moves away from the water and into the forest,
the water should disappear and he should get forest sounds.  Obviously, we
probably don't want to have every space have its own ambiant sound, or if you
do, certainly don't send them all when a player first enters a map.

 My personal though would be to send the ambiant sounds to play each time the
player moves.  This shouldn't take much space (I can't see more than 4
bytes/sound, and probably some realistic low limit on the number of sounds to
send).  I suppose if bandwidth is a real big issue, you could send this every so
many ticks/spaces moved (so if the character is just wandering between a few
spaces, you don't send it, but if he wanders across the entire map, you do).

 My concern with sending the ambiant sounds when the player first enters the map
are this:
1) To keep the number of sound sources low, it would seem you need to just place
a select number of the map, which then introduces inaccurancies (ie, ever woods
space can't have an ambiant sound that gets sent, otherwise you hvae a humongous
list).  So instead, you need to place a few sources of ambiant sounds within the
woods.  This would generally work OK where you have big blocks of the same type,
but work less good where you have many intermixed terrain tapes.
2) This doesn't work very well with tiled maps.  In tiled maps, you don't really
have a concept of entering one tiled map when you move to the next one - this is
all invisible.  Plus, this gets tricky, as if you're at the edge of one map, you
really should be getting the ambiant sounds of the map you are right next to (as
you can see everything on it).  But if we envision the world becoming a huge set
of tiled maps, you obviosuly can't send ambiant sound information for all of
those.  To do this in any reasonable way means you need some way of sending a
new/supplemental ambiant sound list.  But this gets tricky as far as the client
is concerned, as the coordinates may end up getting pretty weird.


>
     
      Effect sounds
     
     >
     
     
     >
     
      Effect sounds are fired and forget - like a spell noice. The client get
     
     >
     
      sound name and pan/volume data
     
     >
     
      and mix it in. Its all of this spell sounds or hit noices, etc.
     
     
 Yeah - this is basically what we have now.  Sending name is certainly better
than number.  Currently, the client gets x,y offset if I recall - that allows it
to better determine volume and balance on its own.  I suppose if you had a
surround sound system, you could have a system that did an even better job (ie,
client could do forward and back as well as left and right.  Of course, right
now it only does left and right)


>
     
     
     >
     
      Static sound sources
     
     >
     
     
     >
     
      This sound sources works like torches in a dungeon. Instead of "lit" the
     
     >
     
      dungeon with light, they flood
     
     >
     
      it with sounds. This is used for several sounds and the sound itself is not
     
     >
     
      static. A waterfall for
     
     >
     
      example will become a rushing water sound as sound source ... when the
     
     >
     
      player comes in, the noice
     
     >
     
      starting and getting louder when they come nearer the waterfall. So, a sound
     
     >
     
      source needs pan/volume information too.
     
     
 Ok.  So ambiant sounds are always played with constant volume then?

 And for static sound sources, this may then go into what I described with the
ambiant sounds above - since these change as the player moves, they could be
piggybacked on the map command for example (or a seperate command - not a big
deal either way)

>
     
     
     >
     
      The problem is, that this noices will played from client sound system in a
     
     >
     
      loop.
     
     >
     
      Because the server has no knowledge about the status of played sounds of the
     
     >
     
      clients, the server
     
     >
     
      can't give here cmds, except from "start playing sound source xxx" and "stop
     
     >
     
      playing...".
     
     
 Thats one advantage with putting sound information in the map command as the
player moves - player can more easily see what to do - ie, waterfall sound
should now be played at a lower volume, or not at all.

>
     
     
     >
     
      So, best is, give the client, when the player entered a new map, a list of
     
     >
     
      set sound source - even in
     
     >
     
      big maps that will not be many. Than the client can count the sound
     
     >
     
      sources - but for this, we also
     
     >
     
      need the player map position. The client then loops the sounds. If the
     
     >
     
      player is "out of reach" of
     
     >
     
      a sound source, the client stops playing of it.
     
     
 As I said in another message, player map location IMO starts to open up things
much more to make clients that cheat and make play much easier.

 The other problem with this approach is that it may discourage map makers from
using sounds for things that should.  For example, you may want to have some
clue like 'the treasure is behind the waterfall'.  If the player knows right
when he enters the map where the waterfall is, this may making things much
easier compared to if he actually has to explore things.

 The trivial 'cheating' client would just dump out all the sound sources when
the player enters the map, ie something like:

 torch.wav (5,10)
 torch.wav (15,12)
 waterfall.wav (20,3)

 to either one of the text windows.

 There was a thread a few months ago about sending player coordinates on the
map.  One problem with this is that it lets the player know much more about the
map than he might.  For example, if the furthest north they got was at y +10,
that might be a very big clue that there is a secret door/passage somewhere
there that lets them get to the remaining 10 spaces.  Not knowing the y value,
you may not know this.

 Also, such 'send sounds when map is entered', doesn't work very well for tiled
maps as previously described.

 It might be good if you can clarify the difference between static sounds and
ambiant sounds.  Is it just a matter of volume and whether that changes, or is
it something else?

 
>
     
      Dynamic sound sources
     
     >
     
     
     >
     
      Well, this is more tricky. Assume this: You stand before a door. Behind the
     
     >
     
      doors are 10 dragons.
     
     >
     
      Well, moving dragons should make some noices. So, we include "dragon
     
     >
     
      sounds", like heavy steps and
     
     >
     
      deep breathing.
     
     >
     
     
     >
     
      The problem is to determinate, the pan/volume of the sound, also, we don't
     
     >
     
      want play 10 of them.
     
     >
     
      This is maybe realistic but it will mess up your sound system. we don't talk
     
     >
     
      here about real or not -
     
     >
     
      we talk about to fake it in a way, the player accept as real.
     
     >
     
     
     >
     
      The solution is, that every dragons has a attached dynamic sound source. But
     
     >
     
      the server stores only one
     
     >
     
      of it. When server goes through the map, he use only the nerarest dynamic
     
     >
     
      sound source, relative to the
     
     >
     
      player. So, the player hears always only ONE moving sound from the nearest
     
     >
     
      dragon. Same for 50 orcs.
     
     >
     
     
     >
     
      This is not real trivial and when you look at it, you will see that many
     
     >
     
      games has here some problems.
     
     >
     
     
     >
     
      And what is which looping? Here comes the trick: All sound are about 1.50
     
     >
     
      seconds long - and the server
     
     >
     
      only update the dynamic sounds all 2 seconds. This is the easiest methode,
     
     >
     
      all other start to be very
     
     >
     
      complex.
     
     
 Is this 'play only the nearest dynamic sound source', or 'player only nearest
dynamic sound source of each time'?

 For example, suppose player is in a hallway - to the left is a room of titans,
to the right is a room of dragons.  They use different dynamic sounds.  Player
is slightly closer to the dragons, but not a lot.

 Does he only get to hear the dragons, or does the titan, being a different type
of sound, also heard?

 If the former, this would actually be pretty easy to do - it wouldn't be too
hard to extend the MapSpace structure on the server to have fields for things
like dynamic sound, static sound, and ambiant sound.  While processing the
spaces to get sent to the client, it would be that hard to do something like 'if
dynamic sound on this space and this space is closer than any other dynamic
sound, then store information to send this dynamic sound to client'.

 And if your going to do that, it wouldn't be hard to do the same thing for
static sounds, or ambiant sounds for that matter.  But it then seems to me that
if that approach is used, defining the different between static and dynamic
sounds would need to be relevant.  So far, the only difference I have seen is
the nature of the object they are attached with.

 It would be easy to track all these sounds in the MapSpace structure - it would
basically be the same as how lighting is tracked - when an object is added, if
it has a sound, set the sound in that space appropriately.  If an object is
removed, same thing.  Or this could just as easily get done in update_position -
depending on how far sounds travel of course.