Also, are these settings writable by the game itself in an intuitive manner?
5.0 will change the save data handling so that games no longer have to share the same save file folder. How that works is you set a "save ID" in the JSON manifest and miniSphere uses that as the name of the folder. If you have want to have sequels be able to share save data, you can just give them the same save ID.I'm thinking there should be a standardized format for save IDs to avoid clashes, something like this maybe (inspired by Android app IDs):Code: [Select]com.authorname.gamename
com.authorname.gamename
New Sphere v2 Sample object (analogue to the v1 SoundEffect API):https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-api.txt#L1001-L1047In the spirit of reusing a sample for multiple playbacks of a sound effect, the playback parameters (pitch, speed, volume) get passed as options to play() instead of being associated with the Sample object. I always found the way Sphere v1 handled that to be weird and unintuitive, never sure whether setting a value would apply to currently playing instances of a sound or only future playbacks (spoiler: it's the latter). At least this way the API is very clear.
I'm planning a 4.6 release soon, but there are a few more changes I want to work out first (such as the engine not installing on Ubuntu 16.10 and later). Should be within the next couple of weeks if all goes well. I was originally going to hold off on doing any more releases until 5.0, but there are a few annoying bugs that need to be fixed--Dispatch jobs rendering in the wrong order, for example--so an interim release is called for.