[CF-Devel] Client Sound Server

crossfire-devel-admin at archives.real-time.com crossfire-devel-admin at archives.real-time.com
Thu Mar 6 22:14:31 CST 2003


     phil at theperlguru.com
     
      wrote:
>
     
      On Wed, 05 Mar 2003 22:11:08 -0800, Mark Wedel wrote:
     
     >
     
     
     >
     
      ...
     
     >
     
     
     >>
     
     and try to make more clever decisions, etc).  I think its pretty unlikely that a 
     
     >>
     
     player hearing an event they didn't hear before isn't likely to significantly 
     
     >>
     
     change any maps.  The most likely case I'd see is where you have cases of 
     
     >>
     
     objects like gates/buttons used for effects the player shouldn't really notice.
     
     >
     
     
     >
     
     
     >
     
      Assuming that it isn't too CPU intensive, if a player can magic map
     
     >
     
      the square with the sound event, and it's not too far away, they
     
     >
     
      should be able to hear it.  
     
     
  the magic map stuff actually is quite cpu intensive.  This isn't that big a 
deal, since it is used very rarely.

  If this was a real concern, one could always track the connected spaces in the 
map or flags.  IF something changes that would block/unblock spaces, just 
re-calculate for the entire map.

  However, for sounds, I'd probably do something a bit simpler.  Presumably, all 
sounds would have some range, potentially variable (eg, ticking of a clock may 
be a 1 space range, grates moving may be 10 spaces).  When a sound is played, 
first do a simple check to see if any players are within range (by going through 
the players list).  If so, then do a quick path check between the player and 
sound.  Depending on what is on the space, have different dampening factors. 
open spaces would have a factor of 1 (eg, consume 1 space of the range).  A wall 
might have a factor of 5.

  Thus, in the case where the grate range is 10, a double wall will always block 
someone on the opposite side from hearing it.  A single wall would reduce the 
range by 5 spaces - now, the wall has to with X spaces of the intervening wall, 
and player within Y spaces, where X+Y < 5 (10 - 5).  Easier to just code that is 
- as you traverse each space, increase range by 1, if a wall, increase by 5 - 
this would be a quick check, as well checking is just a matter of checking the 
flags for the space, and not the objects themselves (one could very easily add 
something like a 'blocks_noise flag, which basically adds a range factor of 100 
or whatever).

  This isn't perfect, but does help in some other cases.  For a real life 
example, I can be in a room with the door closed, yet can still hear things not 
in the room, but they are muted.  Thus, that big dragon behind a door could be 
heard from a player on the opposite side of the door.

  To follow up on this, one could even add something like a 'hear noise' skill - 
use it in a direction, and it reduces the blocking factor somewhat.  However, in 
this case, you'd probably print something out to the players screen in addition 
to perhaps playing a sound.

  The magic map case also isn't perfect.  Think of the case of a maze - there 
could be a noise just 5 spaces from you as the wiz walks, but to actually walk 
there is 20 spaces (do to twisting passages or whatever).  The fact it is within 
5 spaces and magic mapping can reach it still probably shouldn't mean you can 
hear it.



>
     
     
     >
     
      -Philip
     
     >
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel
     
     
    


More information about the crossfire mailing list