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/embedded-app-sdk

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

There are 64 suggestions on the platform rn, not that close to 100 and it's normal it went fast during the first days because people posted their most wished/relevant suggestion from the old platform as there was a reset. We all make different games (Art-Heavy/Data-Heavy/UI-Heavy/simple hypercasual/Multiplayer/Performance-sensitive), for different platforms (Web/Mobile/Desktop/Consoles), have different skills (VisualScripting/JS/AddonDev/HTML/CSS/Shaders ?) so it's normal most suggestions don't please us.

Again community voting is the best way to help prioritazing stuff we could imagine, no need to think too far and no one is expecting every single issue to be implemented in the last beta.

Github provide a bunch of way to filter and sort issues.

Just sort them from the "most recent" to see the new ones, "recently updated" to see recent discussions, or use searching syntax to filter only last month.

For me the only annoying thing with Github is that the Likes are displayed only if you sort them by Likes. But you could still filter issues from last month only (or any filtering you want) + sort them by likes.

Being able to add tags like "Behavior", "Editor" could help indeed but i suspect tags are reserved for Scirra to set status for the requests "In Developement", "Planned", "Will Not implement" etc. I wonder if using tags for both would be possible, it implies only a few tags are available to use for the users (categories but not development status), if it's possible it would be cool.

FWIW Godot, the most "democratic" game engine out there also use Github issues, doesn't limit the amount of suggestion per user and don't care about having 3955 opened issues (with about 7 new ones per day), given their incredible growth and speed of developement i would say it works quite well.

Sorry, you're right. I always forget that our job is to overwhelm the engine developers with a ton of work.

This u ?

770 bug reports.

I mean i'm thankful for all the work you put into this and it's useful for all of us in many situations.

But please don't speak about overwhelming the devs, especially since all bug reports are always treated as urgent while it's not clear if anyone on earth will even face them once. There is not any kind of community voting/prioritization for bugs as opposed to feature suggestions. Also we all know feature requests are not meant to all be developed and pushed, only the most popular/easy-to-add/relevant, so it's less an issue.

Bugs are about technical issues, Feature request are about useability/UX/limitation issues.

I would argue a painful workflow that the whole community is required to do every X minutes in the engine or a big limitation impossible to overcome no matter how skilled you are at JS/Addondev/EventsheetTrick is far more important to report and urgent than a very obscure bug that happens in 10% of the time when you smash your keyboard randomly in a full moon evening (especially since sometimes fixing that weird bug takes 50x more time than exposing an existing method to the Addon SDK for exemple and that would solve several of the most annoying C3 limitations in 1 shot)

IMO, reducing the number of your bug reports to keep only the ones that actually matter wouldn't slow down the speed of developement of the engine, quite the opposite. But no one is trying to enforce Scirra to stop you from doing this, so I would appreciate if you let other users provide feedback to Scirra Team as well

The community filters the idea themself thanks to the voting system.

Reducing the number of idea reduce the quality of feedback Scirra receives, and will slow down the speed of useability/power improvement of the engine by not giving a chance of the tiny clever ideas to pop out.

Also it would incitate users to request a bunch of things in a single request while it's more efficient if each thing is requested as seperate suggestions, or it would incitate to only submit the very big brand new feature stuff while sometime a "quick tiny" ACE/SDK addition can be a real game-changer.