Introduce releases and versioning

[simjnd]

With fixes being rolled out, documentation being updated and features being added it would probably be a good idea to have explicit version numbers and releases in order to communicate changes with users. Currently there has been no breaking change but it might come up in the future and will be really needed then.

This also begs the question of "What version is NobleEngine currently at?" and if not 1.0, what needs to be done to bring it to 1.0.

Here is a unordered list of things that I think could be good additions to NobleEngine (in no special orders) that we could pick and choose from:

• Define a config object that can be passed in Noble.new and Noble.config to customise the behaviour of the engine (as mentioned in Graphics.sprite.setAlwaysRedraw to false by default #36

• Allow specifying font variant directly in Noble.Text.draw (Inside Playdate - Variants)

• Allow specifying draw mode directly in Noble.Text.draw (e.g. by default text can be drawn in NXOR so that if you write on black pixels it will by default be white) (Inside Playdate - Drawing mode)

• Add a headphoneChanged custom event to inputHandler, and a config for Noble to automatically redirect audio output when this event is triggered (Inside Playdate - Audio Output)

• Add better primitives for working with the microphone, potentially custom events (config a custom sound level threshold and trigger an event when the mic detects it) (Inside Playdate - Mic Input)

• Provide a custom threshold to determine when a button is held (currently hardcoded at 3 frames)

• Add event handlers for charging / battery status (Inside Playdate - Power)

• Add event handlers to game lifecycle's callbacks, so that each scene can easily register different actions to perform (Inside Playdate - Game Lifecycle)

• Some optimization / performance pass on the entire codebase to minimize the performance overhead of the engine even further (Lua Performance Tips, Lua Optimisation Tips, Increase the performance of a Lua program)

• Have some sort of an established benchmark / test suite, to test for performance improvements/regression (on hardware)

• If we choose to go with Use lists instead of positional arguments to supply optional parameters to methods #35 (which I advocate for of course 😋), it's going to be a pretty big breaking change, so the earlier the better?

---

Stuff that could be good but should probably be external tools / released independently

• An adapter to have Panels integrate nicely with NobleEngine now that it can be used as a library for cutscenes (https://github.com/cadin/panels/releases/tag/v1.1)
• Since text rendering performance is known to be pretty bad, a module for Noble.Text to support rendering text as sprites and have the lazy re-rendering done automatically
• A CLI to scaffold project, keep the engine and the SDK up-to-date, add scenes from a set of templates, build, run and transfer to playdate

[Mark-LaCroix]

I was just thinking about this yesterday. I have made fewer breaking changes than I expected in the last year, and it seems that people are actually using Noble Engine! Both of these things are a surprise to me, but it does seem like I need to at least add some tags to the git tree, if not do a full release.

Some of the playdate callbacks you mention are best handled by the SDK itself, but I could see something like headphoneChanged being scene-specific. Perhaps a NobleScene.deviceEventHandler object, similar to NobleScene.inputHandler can house those methods (we can move the accelerometer/orientation stuff into that, too) instead of clogging inputHandler with extra functions that move it too far away from the SDK's definition.

As for performance benchmarks, optimization tooling, or CLI tools, I think frankly those things are out of scope for me. I don't know enough about Lua (nor do I have enough time) to confidently focus on that. I'd prefer to focus on functionality and (especially) usability, and let performance be something that I just keep an eye on. Noble Engine is going to introduce some overhead, and I'm okay with that. I'm happy to accept for help/advice in these areas, though.

The main thing is that I always want Noble Engine to be easy as possible for users starting from scratch, with literally no knowledge of Lua or any dev tooling, and I'm willing to sacrifice a lot for that. This means reducing the number of new things a user needs to learn to get the recommended experience.

[simjnd]

Some of the playdate callbacks you mention are best handled by the SDK itself, but I could see something like headphoneChanged being scene-specific. Perhaps a NobleScene.deviceEventHandler object, similar to NobleScene.inputHandler can house those methods (we can move the accelerometer/orientation stuff into that, too) instead of clogging inputHandler with extra functions that move it too far away from the SDK's definition.

This is a great idea, I can start working on a PR that implements this and submit it to see what you think!

As for performance benchmarks, optimization tooling, or CLI tools, I think frankly those things are out of scope for me. I don't know enough about Lua (nor do I have enough time) to confidently focus on that. I'd prefer to focus on functionality and (especially) usability, and let performance be something that I just keep an eye on. Noble Engine is going to introduce some overhead, and I'm okay with that. I'm happy to accept for help/advice in these areas, though.

Of course I wasn't trying to throw all of this on you and thought about what I could handle myself, especially for all of these more adjacent items. I'm still learning Lua (had no prior experience before getting my Playdate a few days back), but got lost in the rabbit-hole of Lua performance and was curious of what I could apply to NobleEngine, but definitely not a priority for me either.

The main thing is that I always want Noble Engine to be easy as possible for users starting from scratch, with literally no knowledge of Lua or any dev tooling, and I'm willing to sacrifice a lot for that. This means reducing the number of new things a user needs to learn to get the recommended experience.

This is a great vision, and one I can try to align more with in my future contributions!