Even then, the more I think about it the more I realise that the way addon SDK v2 is designed right now can only lead to more issues, or less addons.
In the future, when addon devs will inevitably reach the same problems we've faced with v1 (aka feature exists in C3 but is undocumented because arbitrary reasons, and Scirra doesn't want to add it because of other constraints) we will be left with only radical options.
For example, I recently made a SetFOV addon that contains essentially 4 lines of code. These same 4 lines of code are now in C3, but at the time the only way to do that would have been to access runtime internals.
For such an addon, the new way to do it according to the ideal design is to write my own camera system. However, the camera system in C3 is deeply tied to the layout system and the canvas renderer. So I need to rewrite those as well.
So now, to be able to change the FOV of my game I am left with 3 options:
- Beg scirra to add it
- Do even more aggressive engine hacks
- Write my own renderer
None of these options are good. None of these options are workable.
Let's take another example:
In my addon Reset Variable, I access the class that manages the variables inside of C3's event sheet system. All variables (global, local, static) have an internal "reset value" function, but C3 only exposes an action to reset ALL global variables.
There is no way to reset ONE variable, and there is no way to reset local variables (static or not). Which means the engine has a feature that exists, works and is just there, but does not use it at all, and does not want me to use it.
With V2, I am left with the following choices:
- replace the event variable class with my own class that gives me access, which is a BIG engine hack
- write my own system that, every tick, tracks the value of event variables, stores initial states, and lets me set their values to the stored initial state. This would create a lot of issues related to state sync, because there is no way to be 100% sure the value I am currently holding is correct.
- write my own variable system that is completely decorrelated from every other feature in C3.
Again, none of these options are good, which means the only solution is to not make that addon.
Now you might think "oh well its fairly easy to do this with events, just use another variable" however if you're doing this on a project with several hundreds of variables, there is no way in hell this will actually be feasible. And it's especially a bad idea knowing the feature is already there and works perfectly fine.
One last example:
In my addon LocalStorage Snapshot I am trying to solve an issue where a game has every system deeply integrated with LocalStorage and now needs to save and load everything to and from a file instead.
What this addon does is use the undocumented features C3 has to get all the data currently saved to C3's localStorage system, package it all in a JSON string, and allows me to load that JSON string back into the system.
The only way to do this with V2 would be to copy paste C3's localstorage system on both worker and domside and mess with the final indexedDB it saves to and pulls from, which might create conflicts. Also, if at any point in the future, C3's localstorage system changes, my addon explodes and creates issues whereas the first implementation has good chances to keep working, and even if it fails, it's very likely it's just a matter of changing what functions to call which is far easier to maintain that to rewrite the entire thing.
These addons have all been made and published to solve very real problems people I've helped have encountered. The solutions are far from ideal, sure, but with addon SDK v2, the alternatives become far worse, and IMO, would lead to way bigger issues down the line.
It reminds me of how back in the Construct 2 days people would copy paste addons, change 5 lines of code and republish them as "Text+" and that lead to issues whenever the main Text object would get a new feature because we'd now have 2 separate codebases to maintain.
In Construct 3, this issue was largely avoided because the engine internals made it easy to do these simple changes while keeping the main code base the same, and while keeping the risks of failure relatively low. Losing access to this means the only alternative will be to go back to how things were done in C2 aka copy chunks of the engine into your addon just to be able to access one feature, or change one value.