Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sounds (various ideas - long)



>----------
>> Date: Wed, 13 Dec 95 10:29:46 GMT
>> From: mwedel@pyramid.com (Mark Wedel)
>> 
>> Sound Improvement:
>> 
>>  Raphael mentioned that he would like to improve sound code, but wait for
>> client/server to do it.  A few thoughts:
>> 
>>  IT seems to me that rewriting the sounds config file isn't really dependant
>> on client server.  [...]
>
>I could of course re-write the part of the code that reads the config file
>without waiting for the client/server split.  But I also want to be able to
>play these sounds, and this is where the problems begin...  It would be nice
>if each user could choose to enable or disable some sounds, for example.
>Thus each player would need his/her own config file.  Adding such features to
>the current code would be a nightmare.

 I agree.  I think it will be really nice for the the player using a client
to say that I don't want these sounds, but do want these.  And this will
work best with symbolic sound names, so that the client user can see that he
doesn't want the "player hit monster" sound, vs "bap.au" or "sound 53".

>
>>  I guess Raphael's thought is more that the server will send truly symbolic
>> commands to the client (ie, "play hit door" sound, vs "play bash.au" sound
>
>Right.  Although I am starting to change my mind...  In some cases, the
>people who run a server may want to add a special sound effect and the best
>way to do this would be to send the sound file directly.  Hmmm...
>

 The problem is sound files can be quite large.  If you are on a low
bandwidth connection, do you really want to freeze up for a few seconds as
that sound gets sent down the pipe?

 There could be several ways to do this.  Have a common list of symbolic
sound names between the client and server.  At startup, have the server send
down what it thinks are the proper sound (.au) files for each symbolic name
- client is free to do whatever it wants with this information.

 I do certainly believe that support for special unique sound effects needs
to be supported.  Perhaps in the case, there is a slight variation of the
play sound that specifies the sound file to be played (client might already
have it, if the player visited that spot before.)  I guess the question
would be, however, is how the client goes and gets that sound if it doesn't
have it.  One method woudl be to request it from the server, and just have
th server send it down.  This would probably work pretty good (you get a
minor delay as the client first sees it doesn't have the sound file).  Still
have the problem of possible saturation - the only real method to avoid that
would be to have something in the client that asks a question before it goes
and gets the new sound.

>The parameters which should be sent by the server are:
>- Sound type (i.e. "hit door", "arrow", "large lightning", ...)
>- Attenuation.  This tells how much the maximum volume of the sound (set by
>  the client) should be reduced because of the distance between the source
>  of the sound and the player.
>- Priority.  Some machines will only be able to mix a limited number of
>  sounds, so there should be a way to specify which ones are the most
>  important.  For example, the sound of the player being hit should have a
>  high priority, even if it doesn't have a high volume.
>

 Priority gets to be a strange issue (different people will think different
actions have different importance).  But I guess that between symbolic sound
names and priority, it would be pretty easy for the client to do filtering
(only play monster_hit_player if priority>80 type of thing.  But this would
assume that priority would vary)

>Among the "other events" should be the ambient sounds, such as the sound of
>the leaves of a tree in the wind, or water dripping.  I will have to find
>new names for these, such as:
>
>ambient water drip  = drip.au, 10
>ambient waterfall   = waterfall.au, 20
>ambient leaves      =                   # Empty entries are allowed too
>ambient wind        = wind.au, 10
>ambient storm       = wind.au, 20; lightning.au, 50; wind.au, 20; wind.au, 10
>ambient silly example = chill.au, 100
>

 Perhaps a repeat/sleep time between them should also be in place?  Or how
does an ambient sound differ from a normal sound?  I would assume that
ambient sounds would repeat, but in the case of somethign like drip.au, you
don't want it on continuesly - probably want it every 20-30 seconds.  But
you then need some mechanism for turning them off and stuff (could get
pretty complicated.  Suppose there are 2 wells that generate the drip
sound.  you walk within range of one, and start getting the drop.  You keep
iously leave some extension in the protocol to
specify which channel (for quite a while, it may just be ignored, or
certainly clients probably will).  But at least that way, when it does start
to get use, the protocol doesn't need to be expanded.

>There should be a way to have background music too, although I don't think
>this is so important.  One way to do it would be to have more entries in
>the config file (for example, "music 1", "music 2" and so on).  All sound
>types beginning with "music" would be played in a loop instead of being
>played only once.  And only one of them can be played at a time.  But using
>simple numbers for background music would not help people to set the right
>atmosphere for their map.
>

 I don't necessarily know whether numbers or actual names would work
better.  I guess it depends on the music (some you just can't really
describe in 1 word, but there could be types.)  In any case, it would be a
trivial matter to use some field (preferably a string format) in the map
object to specify what background sound to play.

 Perhaps even have some mechanism/special object that would change the
background music (so you step over one onto a new one and it changes.)

 A more interesting idea would be to expand the msg parsing for npcs, magic
mouths, etc, to specify sounds to play.

>-Raphael
>

 --Mark