jakubg1 / OpenSMCE

Game engine which allows creating a broad range of marble popper games.
MIT License
14 stars 11 forks source link

Make defining sound_event json files optional #117

Open bchantech opened 1 year ago

bchantech commented 1 year ago

Currently, sounds are specified via sound_event, however, most if not all of the time it only contains path containing the sound file of the same name.

When the game plays a sound event that is not defined, it should try to play the sound file of the same name using the default parameters.

Example:

/sound_events/sound1.json is specified in UI

If sound_events/sound1.json is not present, it should create a new sound_event with the following info:

{
    "path": "sounds/sound1.ogg"
}

If the game cannot find the sound, then path will not be included. If the game can find the sound, and detects it is stereo, flat will be set to true.

jakubg1 commented 1 year ago

I will consider this during the sound event overhaul (#95). This might make resource handling more complicated though (passing sound files directly instead of sound events means that all class configs will have to check whether it's a sound or an event; on the other hand, specifying deliberately nonexistent sound event files might be too unintuitive).

ResourceManagers may be able to create sound events on the fly when a path to the sound file is passed in a :getSoundEvent() call, though.

bchantech commented 6 months ago

I'm closing this since with ff71f34 sounds can be placed in any directory so we can't assume that they will be present in the /sounds folder.

jakubg1 commented 6 months ago

Reopening since providing a path to a sound file whenever a Sound Event is expected should generate an implicit Sound Event to avoid creating unnecessary boilerplate Sound Event files of which the only purpose is to exist - as a QoL for modders so that they need to change/create one file less. This part has nothing to do with the resource placement, as you need to provide a full path to any resource anyways.

jakubg1 commented 6 months ago

Also, relates to #123 and is a part of a bigger plan to iron out all inconsistencies in the way expressions are defined, resources are referred (#103), etc. that will be carried out throughout the rest of the Beta 4.x cycle.