#184 Sounds specified by data rather than code.
With mention of sound on IRC it is not uncommon for negative comments to be made about sound in Crossfire.
The current sound system uses restrictive code to determine what sounds to play and when to play them. See, for example, the references to SOUND_ defines in:
server/sounds.c
server/player.c
server/attack.c
server/spell_effect.c
and other files under the types directory in the server codebase.
The sound system might be more easily modified/improved if sounds were triggered/specifiable with game items, actions, or attributes.
1) Archetypes could specify a sound to associate with particular archetypes. The sound might need to be played only under certain conditions. For example, maybe when a fountain/drink is applied, a water splashing or drinking sound is played, or when a save bed is applied someone booes/hisses ;-), etc. Different sounds might be played when different doors are opened - some doors might creak, others squeak, whereas the current system is restricted to one sound for all doors.
Imagine that not only the sound is identified, but some use flag is also required. IE. If the item is applied, one sound is played, but if it is dropped, another, etc. Damage to items could trigger special sounds. Also, imagine that an audio cue indicating acid damage to an item may more effectively warning that the player may need to consider not meleeing this particular monster.
When a player steps in a puddle... etc... a special sound might be played.
2) Sounds could be associated with skills.
For example, lockpicking, find traps, disarm traps, opening a chest, etc. could trigger a special sound. Depending on the capabilities of the system, the sound might be restricted or changed based on whether the skill was used successfully or not.
This might be a bit more delicate than it initially seems as some skills are combative and some are for detecting attributes of items, etc.
3) Sounds could be associated with communication commands. When a player issues a command like burp, cackle, sneeze, etc., an associated sound could be played.
4) Sounds could be associated with other commands: IE ready_skill, killpets, usekeys, peaceful, etc.
Probably to prevent hard-coding symptoms, all commands could have a sound association capability, but many would be set NULL where it is up to the developers whether a particular command should or should not have a sound mapped to it.
5) Perhaps system events could be mapped to sounds as appropriate.
For example, death of another player signals a sound.
6) Sounds could be associated to announce changes in core statistics or permissions. This might make it easier for players to accept clients that have these stats hidden on tabbed notebooks and might serve as a clue that something critical changed (stat/level loss) that might mean they might want to change tactics if fighting a monster that steals XP etc.
7) The ability to map sounds to particular spells should be retained.
8) Magic mouths could support sound playing. For example, in the red town tower, there is an invisible key in one room. A magic mouth says "Klang" as a clue that the player might want to cast detect invisible... An audio cue could be played in addition to the textual cue.
Probably, along the lines of the current ~/.crossfire/sounds (client/sound-src/sounds.dist) file, sounds would be given a logical name rather than a file name so that a player could customize their sound preferences by changing the location/name of a sound.
Some care must be taken to make sure that playing sound did not get to be out of hand as it would be bad to drown the player in audio clutter or cause sounds to no longer be synchronous with game play in the event that sounds take a long time to play. In this vein, perhaps the sound server could selectively ignore the playing of a particular sound if it is played too closely in succession.
Certainly some design work may be needed, but the point of the request is to move sound closer to the data-domain rather than the code-domain so that it is easier for mapmakers to enhance the game experience without requiring coding skills.
Logged In: YES
user_id=697549
Originator: YES
g/^6/s/permissions/protections/
Logged In: YES
user_id=697549
Originator: YES
9) Sounds might be contained in special archtypes that can be "connected" to allow them to play in response to in game action... or some better method of associating the sound with a connection might be considered.
Logged In: YES
user_id=303511
Originator: NO
This work was started. There are some sounds defined, the server will send enough information for the client to find the correct sound to use, based on emitter's name and sound type. See http://wiki.metalforge.net/doku.php/dev_todo:fix_sound for more detail.