[SUG][PLAYER] Allow theme.nxmi to specify custom sounds

[WillLem]

I'm wondering if it could be made possible to allow the theme.nxmi file to specify custom sounds for "ohno", "letsgo", "zombie" and all of the other current default sounds.

This would obviously be good for custom sprite sets such as Lemminas as Millas, but there are likely to be other possible uses as well (such as using the SEGA sounds for an SMS-themed pack/style) or even just replacing the occasional individual sound for preference purposes.

As I imagine it, each sound could have an identifier, such as LETSGO, and the custom sound would be specified in a similar manner to the theme colours, except instead of referring to a hex code it would refer to a file in the "sound" folder, e.g:


$SOUND
    LETSGO WL_letsgo_lemmina.ogg
    OHNO WL_ohno_lemmina.ogg
    ZOMBIE WL_zombie_lemmina.ogg
$END

[namida]

Possible alternative: Allowing packs, rather than styles, to do this.

(I am not stating that I personally favor one or the other, just raising another similar option that should probably be discussed together with this one rather than as two seperate discussions, as the results may depend on each other.)

[WillLem]

Possible alternative: Allowing packs, rather than styles, to do this.

When I originally started this topic, it was to suggest that packs could do this.

I then realised that it may make more sense to link the custom sounds to a theme (such as Lemminas, Millas, or any other custom sprite set which may require their own sounds). That way, any levels or packs created using these sprites/themes would have the correct sounds.

Doing it by pack, on the other hand, means having to make sure the correct sounds are included with every release, which seems a bit more cumbersome. That said, it would certainly be a good enough way to do it, if it was the only way.

[namida]

The point is that both ways have their merits (and it is even possible to consider allowing both, though in this case there'd need to be a decision about which one takes priority). There is also a factor that either would be a fair bit of work - not an insurmountable amount, but it's not the simplest of changes either - so this is one of those cases where it would need to have a decent amount of interest, not just a single person asking.

On the subject of amount of work vs doing both though, I will note that there is significant overlap, so the step from "none to one" is much bigger than the step from "one to both", though the latter is still a fair bit of work too.

[WillLem]

To be honest, I wouldn't be surprised if the poll ended up showing that not many people would use this feature in their own content, since not many people create their own sprite sets.

However, that's not to say that the same people wouldn't enjoy content from other users that was allowed to be customised in this way.

For one thing, Armani expressed enthusiasm for my idea of using the "Badass Lemminas" recolouring for zombie sprites. However, I'd only give this idea further consideration if I was also able to modify the sound.

[mantha16]

i wouldnt have the knowledge or patience to utilise this I dont think

[WillLem]

i wouldnt have the knowledge or patience to utilise this I dont think

Would you enjoy other people's content who made use of this idea, though?

And if so, enough to want to see the suggestion get implemented?

[mantha16]

id enjoy it sure but im not sure im invested enough to explicitly care if it gets implemented

[namida]

It does not matter how many people would enjoy content that uses this feature if there isn't much content that uses it. The question being asked is if people would use it in their content.

[Proxima]

When I originally started this topic, it was to suggest that packs could do this.

I then realised that it may make more sense to link the custom sounds to a theme (such as Lemminas, Millas, or any other custom sprite set which may require their own sounds). That way, any levels or packs created using these sprites/themes would have the correct sounds.

Doing it by pack, on the other hand, means having to make sure the correct sounds are included with every release, which seems a bit more cumbersome. That said, it would certainly be a good enough way to do it, if it was the only way.

I have a different take on this issue, and I hope we can disagree amicably.

As I see it, the content of NeoLemmix is levels (and therefore packs). Styles are tools to create content.

That means it should really be the level/pack designer who decides which sound is "correct" for the content they choose to make -- although the end user is of course free to modify it on their own copy! I am thinking here particularly of a complaint I've raised before: some styles have a theme.nxmi prescribing a background colour I can't tolerate, so if I want to use those styles, I have to either select the theme of a different style (awkward because then one-way arrows, builder bridges etc will be in incorrect colours) or else set the level's background to a single-colour image. (Of course, now that proxima_tile contains several single-colour background images, the latter is a non-issue now, but this wasn't the case when I first started this discussion.)

Similarly, I'm worried that if custom sounds are tied to the theme.nxmi, this will create the situation where level authors who don't want the custom sounds (or don't want those particular custom sounds) will have to use the theme of another style -- again, messing up one-way arrow colours etc.

I can absolutely see that creators who both make styles and then use those styles in levels might want custom sounds that are tied thematically to the style -- Lemminas and Millas are examples, and my own Persia and Metroid styles are others. (Indeed, thinking of the Persia style in particular prompted me to vote "yes" in the current poll.) I also see that for such creators, having the custom sounds intrinsically tied to the style is more convenient. I am just not completely sure it's the right way to go.

[WillLem]

It does not matter how many people would enjoy content that uses this feature if there isn't much content that uses it. The question being asked is if people would use it in their content.

I see what you mean, and of course it comes down to whatever factors are most important to you as the creator of NeoLemmix. However, let's say for example that only one user creates one pack using this feature. It could be that every NeoLemmix player downloads and enjoys that one pack. The number of people that would enjoy the feature in other people's work is, therefore, a worthwhile factor as well as the number of people that would use it.

The converse of this is that everybody could create packs using this feature, and then have 0 downloads of their content because nobody is interested in playing packs which use it.

Granted, both of the scenarios that I've outlined here are extremes that are both very unlikely, but the point is to illustrate that end-user opinion can be just as important as creator opinion, particularly when it's a feature that not many people are likely to use in their own content.

Having said this, it seems that there are in fact a healthy enough number of people who would like to use this feature in their content anyway, which I have to say comes as a pleasant surprise!

Similarly, I'm worried that if custom sounds are tied to the theme.nxmi, this will create the situation where level authors who don't want the custom sounds (or don't want those particular custom sounds) will have to use the theme of another style -- again, messing up one-way arrow colours etc.

I can certainly see how that would be an issue.

To be fair, if the end result of this suggestion is that the feature is implemented as a "per-pack" feature only, that would be more than good enough.

I just think that sounds, similar to background colours/sprites/mask colours/etc, are more of a 'theme' thing than a 'level pack' thing. I can see your point that tying it to the theme means that other content creators who don't want those particular sounds have an extra step to take if they want to use that theme in their content. But, it could easily be argued that if a creator wants to use a particular theme, it's because they like all of the particular features of that theme.

As far as end-users are concerned - again, I can understand that if someone doesn't like a theme that a creator has used, they too would have to modify it. But, as a counterpoint to what you've said:

Surely it's better for an end-user to only have to modify a theme.nxmi just the once, and then whenever they download content using that theme, it's already tailored to their preferences. If the feature was implemented 'per-pack', the user would have to modify each and every pack individually.

So, it's swings and roundabouts really. Neither option is necessarily better or worse than the other, but it still seems to me that tying it to theme makes more sense and is potentially easier for everyone.

[Dullstar]

There's something I don't like about theme.nxmi, and that is that some aspects (e.g. lemming sprites) would be desirable to choose on a per-pack basis, but others (e.g. one-way-wall colors) are desirable to choose on a per-style basis (on the other hand, allowing the theme to specify these is convenient). This sounds option would exacerbate the problem, but I think it would be sufficient to allow packs to provide a theme.nxmi that overrides anything provided by the theme.nxmi specified by the level. This would allow a pack to specify a set of lemming sprites and, if this suggestion passes, custom sounds, without needing variant themes for every single combination of one-way-wall colors and custom lemming/sounds the pack wants to use.

[WillLem]

I think it would be sufficient to allow packs to provide a theme.nxmi that overrides anything provided by the theme.nxmi specified by the level. This would allow a pack to specify a set of lemming sprites and, if this suggestion passes, custom sounds, without needing variant themes for every single combination of one-way-wall colors and custom lemming/sounds the pack wants to use.

Good idea.

[namida]

I've put up a new poll regarding possible implementations. (I want to rule out per-level - that would just get messy.)