Skip to content

Sound handling in EOLib #375

@ethanmoffat

Description

@ethanmoffat

After some discussion in 404 and a couple days thinking about it I'm leaning towards removing non-packet SFX references from EOLib.

Reasons:

  1. Sound is a concern of the UI/client, and not for a library that should be used more generically
  2. Signaling intent to play sfx/mfx is baked in to the protocol, but this should really just indicate "play this sfx" or "play this mfx" and let the implementing client handle what that means
  3. Hard-coding magic-number constant sfx IDs in handlers and calling a notifier to play them is an anti-pattern

Specifically regarding 3. I'd prefer to rely more heavily on the notifiers to signal an intent and let the implementing client determine which actions to take due to that intent. One existing example of existing use of SFX from a handler is ShopTradeHandler.

The current method is to a) update the domain model and b) play the sound effect (since the sfx should only be played upon receiving the packet). An improvement would be to a) update the domain model and b) indicate "shop buy successful". This would allow EndlessClient to play an sfx, while EOBot or a CLI application could ignore it or show a message or play a chime or something else, decoupling the implementation of sound from things that aren't explicitly sound-oriented.

While this approach might result in more boilerplate and more specific notifiers, it also allows scoping the sound effect notifiers to the very specific action of "I received a packet saying play a sound effect", which was the original intent for these notifiers anyway.

For additional context:
https://discord.com/channels/723989119503696013/724236292665114694/1273193756471853096
image

Metadata

Metadata

Assignees

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions