[Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:fix_sound

[no-reply_wiki at metalforge.org]

A page in your DokuWiki was added or changed. Here are the details:

Date        : 2007/09/28 04:52
User        : kbulgrien
Edit Summary: Expand on idea to put sounds in archetypes.

@@ -8,9 +8,28 @@
    * Send which sound to play, as a string instead of number.
      * Or send numbers, but first let the client fetch a table of which numbers correspond to which sound names.
      * Eliminate the need for the ~/.crossfire/sounds file
    * Make new sounds
-   * Allow arches to define sounds for things
+   * Allow more data-centric elements in the game define sounds to play:
+     * Archetypes could specify a sound to associate with particular items. 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.
+     * 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.
+     * Sounds could be associated with commands.
+       * When a player issues a communication command like burp, cackle, sneeze, etc., an associated sound could be played.
+       * 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.
+     * Perhaps system events could be mapped to sounds as appropriate.
+       * For example, death of another player signals a sound.
+     * Sounds could be associated to announce changes in core statistics or protections. 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.
+     * The ability to map sounds to particular spells should be retained.
+     * 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.
+     * Along the lines of the current ~/.crossfire/sounds (client/sound-src/sounds.dist) file, sounds would be given a logical name/code 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.
    * Some form of allowing the client to download sounds from the server and cache
      * So sounds can be added on the server, without having to have a new client sound package release
      * Include a full sound cache on clients by default, so this only has to be used for new sounds or updates to sounds
      * Given how sound files are not small, might it lag the server too much to send a sound to a client?


IP-Address  : 66.137.82.229
Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:fix_sound?rev=1158940682
New Revision: http://wiki.metalforge.net/doku.php/dev_todo:fix_sound

-- 
This mail was generated by DokuWiki at
http://wiki.metalforge.net/