Hi, are there any videos on YouTube where some examples are shown?

Hey ! No there isn't! I don't plan to record video for my add-ons at the moment but they come with detailed documentation and examples and I can help people who get them on Discord :)

Obfuscating the runtime is not an accidental or unintentional stuff to do. And yes it does matter that it could be avoided easily by not deliberately removing us our guarantee to be able to fix and create features ourself. It would be working against your users who pay you a subscription to enhance the engine, not to waste resources to lock down their own creations. Again, the whole point of this thread.

You seem to put real effort to not understand or ignore our concerns. All this feels like a big waste of time. Betting on construct long term or even just for making professional projects with it feels like a risky gamble.

Our experience reporting feedback to you is the same experience you describe reporting feedback to Apple / relying on them for your business.

The analogy with Apple VS Open Web works well on different aspects. Example : Apple prevent other browser to exist on their platform that would allow healthy alternatives to exist for their 3rd party dev and users. It sounds familiar to me. No roadmap, half-baked features, everything locked on purpose, no action taken on the most requested stuff and deliberate moves to prevent 3rd party dev to create solutions for those themselves, everybody dependant on someone who obviously don't share their interest. Even the bad faith reason given by apple is similar: "security"

Again that was the first point of my first message in this thread : we love to know that you can have the flexibility to change any part of the engine to make it better, without needing to support indefinitely undocumented methods, so we should use them with caution etc. Skymen often say he would love if any of his addons could be deprecated in favor of a vanilla solution.

Totally preventing us from accessing those methods removes us the control to develop our own features and fix the issues/limitations we're facing, it just makes the engine worse. Recently, I find more value in the features built by advanced C3 users for advanced C3 users facing actual issues, and above all the features i built myself for my own private use than in the Vanilla updates. It's like if I was able to develop the engine very fast toward the specific direction i want it to be for my needs.

Knowing that you plan to remove all this, is actually like as it already happened. It's not a weighted risk on each thing individually, it's a certitude that our experience with C3 will downgrade as whole, that all effort to achieve our game vision are vain and that every tiny thing we need will need to get through the feature request process (rewriting the same feature request every year, praying Scirra push it while it's almost certain it won't - for legitimate OR arbitrary reasons) while before it would just take 5 minutes for us to do it.

I think perhaps a good way to do this would be to put the addon SDK behind the scripting interfaces used when doing JavaScript coding in Construct.

The reason we use undocumented features is precisely because builtin features doesn't allow us to do what we want. Scripting API are often even more limited than Eventsheet features, and i know by experience requesting an obvious Scripting API corresponding to existing eventsheet feature can take more than a year to be pushed and even never happen.

(Also we can already easily use Scripting API in Addons, so it's not as if we were losing something while winning something else... We're just losing possibilities. The opposite is also true, today we can use the full power of the Addon SDK in js scripting easily, soon, we'll only have access to the <1% exposed stuff with all its obvious holes)

But anyway we already explain this, and as often, you don't seem to acknowledge the point we're raising, denying our experience with the engine and the hard work we're putting into making our games, as if vanilla features were fitting any gamedev need that could ever exist. This is exactly why we don't want to depend on you to fix every single issue we might face.

This is a Apple vs Open Web situation here, I'm sure you can relate. Yes Apple is a huge company, but that is precisely why we can understand the logic behind their shady moves. Shareholders, dillution of responsibility ect. Here it just feel like a unipersonal decision at the expense of all paying subscribers and C3 users and shows again a lack of empathy and shared goal with the C3 community.

On top of every drawbacks already mentionned, obfuscating the runtime would make the 3rd party porting solutions to console orders of magnitude harder (if not impossible) to develop. The best solutions are litteraly alternative runtime like Chowdren : construct.net/en/forum/construct-2/general-discussion-17/chowdren-fast-construct-134395

It would be 100x harder or impossible to develop an alternative runtime without being able to take a look at the vanilla runtime. So it won't be possible to create Playstation or Nintendo Switch porting solutions

So at the very least 3 of the main drawbacks of C3 are about to become worse

- Porting to console is incredibly tedious

- premade blackbox tools might create unsolvable limitations for our games

- Not enough 3rd party devs empowering and providing value to the community

I would point out nothing has changed. That warning has been there for a long time and it has always meant this. If this was not clear to you, I am not sure how to make it any clearer. Do you think the wording should be different? If so, what should it say?

This whole thread is about it, so it might be worth rereading everyone's comments ? There is a major shift with your recent statements.

It went from "undocumented features could change or be removed at any time" which is perfectly fine and understandable to "we plan to make sure nobody could ever access and use an undocumented feature".

There is a full world between an engine that let you customize/extend/create new features at your own risk (like any other game engine let you do) and an engine that don't let you the control over such things.

Everything vanilla is using undocumented feature, so we can't do anything relevant using documented feature. There were not thought to be used, not battletested, and there is no cooperation with 3rd party devs to make things better.

Ok thanks a lot for the clear answer : So it looks like preventing us to access undocumented Runtime features is in your plans. "the sooner, the better"

To me this is very bad news, it would be a loss for everyone. It will put more expectations on you to fix everybody issues and to integrate the features every single advanced/complex/specific production needs and it makes the engine 10x less powerful for advanced users than it is today.

Anyone who tried to do anything with the Editor API knows how impossible to do anything relevant with it because how limited it is. This is exactly the same with the documented part of the Runtime API. My experience is that asking Scirra to expose even the tiniest obvious obfuscated method in the Editor API requires an unbelievable amount of time and energy for a very unlikely chance to happen.

One of the biggest drawback of construct is the lack of being able to customize our Editor experience (extra window/tools at edit-time). And instead of enhancing that aspect, the Runtime is about to fall into the same situation. Making the overall level of control over our own work 10x worse than it is today.

i don't see how any C3 user could benefit from this, and i don't see how any C3 user wouldn't be impacted negatively by it in some ways

Even people who don't use addons benefits from :

• lowering the number of feature the community expect Scirra to develop
• successful games and active community result in more chance for the engine to grow over the years (+ more tutorial, resources, word of mouth marketing)
• a bunch of the most interesting features ever released officialy to c3 mainly exists because 3rd party devs like Skymen or RexRainbow made them first (Tweens, JSON, Touch fix/extra features, 3D Shape for the older ones, Dynamic Layers, Follower, CSV to name some of the most recent)
• knowing community-made solutions to the most annoying limitations exists and are available to download (for free most of the time) at any time. A C3 user might not need a tweak/custom feature now, but what will happen if they're facing a wall at some point in their production ? they will be screwed, no addon dev will be able to help them anymore. I'm not sure anyone like to know any issue they might face would be unsolvable.

Overall, it really hurts my trust/faith in Construct, and I'll think more carefully about my choice of game engine for upcoming projects. I know by experience that I need to use custom features very often to develop the game i want to make, especially as many vanilla C3 features are super opinionated or because achieving modularity / making logic reusable across project is otherwise impossible.

But anyway, I appreciate your transparency !

Single features changing or even disappearing is something entirely different to obfuscate all internals at some point.

And that was the question, "is it your plan to obfuscate all internals at some point?"

That's a big difference in quality and quantity.

^ This basically

So you can guarantee the Runtime API won't become like the Editor API in the future where only the documented exposed stuff is accessible while the rest is obfuscated and impossible to use ?

To me what you are saying here isn't clear.

I think we all know about that warning and that we should use undocumented features with caution.

The difference here is that you mentioned several times those past months that you would like those undocumented feature to be totally unavailable for us. Which is completely different

The only thing we want is to keep being able to access undocumented methods (that all official features relies on including all official Behaviors/Plugins that never changed in 6+ years) at our own risks when we need it. It's nothing like forking/hacking the engine.

Anyway could you just please answer this simple question so we can plan our projects accordingly : do you plan to obfuscate the whole undocumented runtime and only let us use the documented features ?

I think it would be fair to give us a clear answer

Hey Ashley, I totally understand why you're saying us to not use undocumented internals. It allow C3 to evolve pretty fast without Scirra needing to worry about rewriting some chunk of the runtime. You don't have to support indefinitely every method etc.

However please, never obfuscate it / make the undocumented runtime unavailable.

Being able to acces the runtime internals (at our own risk) is essential to allow us to workaround engine limitations or create very specific features we need for our own games and that Scirra couldn't want to implement (for legitimate reason - too specific, would bloat ACE lists, taking too much time to implement, too hard to grasp for beginners).

For any complex game production no matter the game engine, the gamedev sometimes need to tweak, hack or extend the engine to make something work. I avoid it as much as I can, and I don't plan to release publicly addons making heavy use of it but for my own purpose, i need it very often and making it unaccessible at some point would just make any dev at the mercy of what Scirra has the time/wants to implement. (And most likely very specific issues hapenning on specific game productions aren't Scirra priority)

I think the current balance is good: Scirra warn us to not use it, but advanced dev knowing what they're doing still can use it for their own purpose instead of spending months/years to beg for missing features that might never happen, or moving to an other engine.

As Scirra has limited resources/small team and far too many suggestions this is the best balance for 2 reasons : Scirra can rewrite any part of the internal at any time AND If a user REALLY need a specific feature, at least he's able to do it using undocumented features.

If this become obfuscated, we wouldn't have any ways to implement features ourself, the documented Addon SDK is just far far too limited. (and will always be, because no one knows what will be the very specific/advanced needs of any complex game production)

I would definitely like to use that throughout our codebase

Are you really considering to do it ? Your message could let us think that this is actually planned which would be really worrying. Could you give us any guarantee that this will or will not happen ? This kind of thing would have a major impact on my business and mid/long term plans. Imagine if you knew the Construct 3 engine you're developing for 15 years as a whole had a 50% chance to just permantently break with no workaround at any time because major Browsers decided to do so ? This is basically the situation you're putting some of us in with this kind of statement. (in fact it's even worse as we're paying a subscription to fund the development here)

Some of us are C3 subscribers or customers for 10+ years and i think we desserve to know if such an important change is about to happen. If a game engine moves from "a workaround is likely possible if you really need something" to "no workaround no matter how experienced you are and how hard you try", it's not the same kind of game engine anymore.

Regarding the SDK integration itself yeah I agree it shouldn't be too hard to do for me or an other 3rd party dev.

I was mostly thinking about guidelines on how to make a Construct 3 HTML export to work properly as an Embedded Game in Discord as it looked intimidating at first to be honest.

Discord launched a new Embedded Game SDK that will allow to ship webgames for Mobile/Desktop/Web via their platform.

discord.com/build

discord.com/developers/docs/developer-tools/embedded-app-sdk

It looks like a big deal for webgames as new way to monetize and distribute them.

Several other JS frameworks or engines already shipped or are working on Templates/Integrations for it. (Raylib/Phaser)

Would Scirra be up to take a look into it and potentially provide us ways to ship to this platform ? :)

I'm actually personally running relatively low on new suggestions, and I'd rather see added robustness to the existing stuff. Aka more exposed ACEs, added functionality etc.

But adding ACEs and tiny/subtle functionalities to existing stuff are in fact considered as feature suggestions. Most of the ideas on the new GitHub platform are about that

(I could implement almost any ACE that were requested right now as add-ons if i wanted to btw - in fact 4 suggestions on the 2024 platform are already done in addons I released)

So that would mean asking for an obviously missing ACE would be considered as the single suggestion you're able to ask. I find it pretty counter-productive and inefficient