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

Re: Sounds (various ideas - long)




>  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.

It seems to me that the best way (bandwidth-wise) to handle something
like this is to have the client store all sound files with itself (a
default selection of sounds could come with the client app).  Then,
when the client connects to the server, the client can ask it which
sounds it has (by number?) and then request any new sounds that have
been added to that server.  Thus the only data files that are
transmitted over the network are exactly the ones needed, and they are
transferrred before the real game session starts so it won't be
interrupted in the middle.  (The same thing could be done with the
graphics.)  If a player has a sound he likes better than one of the
default ones, he could just replace the appropriate one with the new
one (either by renaming the physical file or, better yet, editing a
configuration file which binds each sound number to a specific sound
file).  And if for some reason the client doesn't have a sound that
the server told it to play, it could just ignore the command.

>  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)

Well, would the server or client handle priorities?  And how exactly
are the priorities to be used?  I interpreted it to be something like:
the server has three sound events to be processed; it checks the
sounds' priorities, finds that sound #2 has the highest priority, and
sends a command to the client to play sound #2.  Obviously, this is
ignoring the possibility of mixing multiple sounds.

> >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.

I like the idea of "background" sounds, but I have mixed feelings on
music.  First of all, if you add background sounds, crossfire could
get quite complex "audially" (does such a word exist?).  What I mean
is that you could potentially have a lot of sound effects going on
"simultaneously".  Having music on top of that could make things just
too noisy.  Also, there is the question of musical format.  MIDI has
some nice features, but coding a MIDI player is not trivial and many
systems don't have one, I believe.  Protracker-style (.mod, .669,
.s3m, etc.) modules have the advantage that they give you good quality
music for relatively little data size and such players (at least for
the most basic .mod format) are ubiquitous.  But playing .mod files
can often eat up a lot of CPU to handle the sound mixing (except for
those with hardware that can handle the mixing, like a GUS in an
ix86-based system).  Besides, what kind of music would you like to have
while playing crossfire?  I personally can't think of anything that
good.

>  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.)

With MIDI or .mod files, you could even have it jump to another place
within the same song without much trouble.

Also, what about stereo?  If a well is on your left, have a dripping
sound come out of the left channel, if your hardware has one?  This
would make the background sounds much more ambient and would probably
be easy to implement (the server can just add an extra parameter to
the "play this sound" command to specify which channel(s); a client
with only mono sound could just ignore the channel specification).
The only problem I can see with this from the client's point of view
is the situation where the server tells a monoaural-sound-only client
to play one sound each on each channel within a very short time (so
the two should be playing "simultaneously").  Does the client try to
mix them together, or just interrupt the first one when the second
needs to start playing?  Either way, I guess this would be purely a
client issue (clients on different platforms could handle it
differently).

-Michael