Is there a method to access engine internals from JS blocks?

Putting the addon sdk behind the scripting interfaces doesn't do anything! How does that address the question of expanding the api? That intentially limits it, as others have said, all the while ignoring the issue at hand!

No other engine offers infinite stability. Their api evolves, becomes depreciated, then eventually expires. And none of them face a pr fire because of it. This has allowed them to have cake and eat it too, and is a much better solution than -don't expand api, because then construct will stagnate- which is what it IS doing from a user perspective.

> Do actually believe that behavior alone addresses all needs within the genre in a scalable, and sensible way?

Maybe the behaviors don't do everything. They are designed to be flexible. But beyond that, you can use custom logic in event sheets, or JavaScript coding within a project, to implement things like custom movements. You don't have to jump to hacking the engine internals. There are usually several ways to get things done.

"Usually" isn't always, and as always, you keep missing the entire point, which is that we aren't talking about the "usual" problems here.

I've explained many times, in multiple posts over the years, including through suggestions. In the past, "intentional implementation" was a common word I heard when describing limiting bugs in official behaviors. The included behaviors are, as others have said, opinionated in their implementation, and only flexible if you share that opinion. In all other cases they are mediocre substitutes.

I'd love to see you edit the node connections in the pathfinding behavior with events (oh snap, there aren't aces for that) or get it to work with hexagons. For that matter, you can't even make an rts with it. Either you have to recreate the whole behavior from scratch... and since many api aren't public, you have to recreate those as well, or you hack it.

If behaviors were so flexible, they would be designed from the ground up to be component based, in and of themselves, regardless of the engines api, but they aren't. Instead they are rigid solutions for a particular set of problems.

And yes, you can indeed make custom character handlers through events, but they can't be abstracted and easily re-used. Which pushes any complex project towards purgatory, which is what I'll call it since you clearly think you get to gate-keep dev-hell.

It is not feasibly performant to recreate a collider engine/solver, or component architecture, or pathfinding in events. All the official behaviors CHEAT in that regard, in that there is hard codes solutions and dependencies in the engine for them to communicate by. That is bad architecture for a game engine when the devs do it but expect their users to get by without it - the api not being encapsulated is hardly the concern, but the actual architectural pattern.. You can't keep talking about how all the other engines have encapsulation, when all the other engines also don't require hacks to accomplish basic objectives like extending the engine.

As an alternative, scripting editor side has a huge problems if you wish to use it with eventsheets or frequently interface through JS blocks - for performance reasons, it becomes better to not cross scripts and modules with events. Which leaves the addon sdk, which is performant through eventsheets.

I'm not going to rescript/duplicate the entire sprite/collision backend (nevermind not being able to create an editor tool for it) in each behavior that I need, just so I can do something the engine is already doing!

That would be insane.

This whole thread is more like a battle with Scirra team to convince them to support the community around, but they look reluctant to hear us out. Construct wouldn't be so popular if it wasn't because of many 3rd party addons that made it easier to use, and stroger to compete with other engines, considering the fact that Scirra team is always "busy". The community is developing functionality that Scirra is not willing to implement, we all are basically helping the company be more succesful, but I'm very surprised by the position of "it will be your problem if something breaks", instead of aiming to provide more robust tools/apis/documentation to create better addons, which has proven to leverage other engines in the market, were even some 3rd party addons ended up being part of the core of those engines (like unity).

To be honest, Construct SDK is weak and poorly documented, we wouldn't be able to create more complex games if it wasn't for the fact that we dig into the core of the engine to create our custom solutions. If Scirra ever decides to obfuscate the whole thing, we would expect the SDK to be way more robust and offer more functionalities than now, otherwise I can say that many of us would definitely drop the engine at some point. You guys need the community's work.

I'm running out of ways to say this, but just to emphasise, hacking internal APIs will end in disaster. It already has for us in the past, and this point is obvious to experienced software engineers. It is the whole reason encapsulation was invented. I think it is likely that in 2030 and beyond we will still be dealing with painful compatibility issues caused by the internal engine hacking that people are doing now.

Providing source code is not the same thing as providing a stable API. Other tools which have a public, documented API, which they change over time, sometimes in backwards-incompatible way, is not the same as letting people loose on the internal engine. That example of public APIs that evolve over time in a responsible fashion is in fact the thing we want to aim for. As I said, that's the industry standard, and what Construct has at the moment is a uniquely bad situation due to the poor encapsulation of JavaScript. This is not just a technical point: it is a matter of support and maintenance and what you promise customers and developers. I don't think everyone here has fully appreciated that.

If everyone is insisting we do something that has and will end in disaster causing both us and our customers to suffer as a result, and insisting that actually don't worry, everything will work out just fine - sorry, software development for a tool used by hundreds of thousands of people that is maintained over a span of more than a decade just doesn't work like that. Our own experience has shown that, and it's widely understood stuff in the software industry; if you don't accept that, I don't really have anything more to add, and so I will stop responding to this thread accordingly. I am so convinced by this point, that I would heartily endorse all our competitors doing what you are asking us to do, because it will end in disaster for them, and if we can avoid that then it will turn in to a competitive advantage for us.

If we put the addon SDK behind the scripting interface, then we solve our problem of how to have a public API with encapsulation that we promise to support in the long term. This can be thoroughly and widely used and will most likely not cause any disasters even years down the line. I know this does not give unfettered access to the engine, but as I say, that's the industry standard when it comes to API design (not source code), and it still gives you a lot - there is a broad and fully documented API there. Then we have a single place to add new APIs which are instantly accessible to both scripting users and addon developers, which is much more manageable than having to effectively maintain and document two separate APIs, and means we can move quicker and expose more APIs in the long term. I think that is the best direction to go in, and I think we will start to look at a "v2" SDK along those lines in the near future - as the sooner we can move away from the serious risk of disaster that we are currently facing, the better.

And just in case anyone asks for my response to this:

IMO this would be fixed by just letting addon devs specify a version range for which addons are made for, and have the editor warn you that the addon may be unstable if the current version falls outside the range (with a button to continue at your own risk)

That does not solve the problem. Sooner or later people absolutely have to update Construct, whether it's for bug fixes, essential new features, or just to keep up with the latest publishing requirements on platforms like Android. If someone can't update because of a third-party addon, they are stuck in development hell: they absolutely have to update, but they can't. This is the same problem as addons unexpectedly breaking in future, and compatible version ranges or warning dialogs just puts a bit of metadata around that without affecting the core problem.

As I say, it's easy to throw around ideas that sound like they work, but when you have maintained software for thousands of people for a decade, it's obvious they won't work. There is a well-understood and widely-used solution in the software industry: a public API with encapsulation.

Again, I understand your point and reasoning, but I frankly don't know how you can look at your userbase dead in the eye and say "this change you all unanimously find stupid is great for you actually".

Maybe it will be in 2030 when the SDK v2 reaches a point of maturity where it's usable enough to make stuff with, but again the whole issue is we're all making games today not in 6 years. The scripting runtime came out years ago and it's arguably only reached "fairly usable" status this year. I have no reason to believe a complete rearchitecture of the SDK won't feel like 1000 steps backwards for the next 5 years.

I still think a version range would be a good thing to do to neatly notify users that an addon might not be the right version installed btw, beyond all of this.

+ You say that people will be in development hell if they can't update due to a 3rd party addon but drastically changing the entire SDK structure sounds like the best way to make that happen on a large scale. Do you just expect people to port all of the addons to that new even more limited SDK for free?

Hell, even if they wanted to, a lot of the most popular addons that have been commonly used for almost a decade at this point might straight up not be compatible.

To me, this all sounds like the best way to create a mass exodus of users. Still, you seem dead set in doing things your way and there seems to be no words I can say that will convince you to listen, so all I can do is hope you keep your promise of actually doing your best to make that change be as non disruptive as possible for everyone. I will keep giving you the benefit of the doubt and trust your decisions, but you don't make it easy.

Why don't I see such scandals in other game dev communities?

Because they use public APIs with encapsulation. Again, providing source code is not related to that.

Again, I understand your point and reasoning, but I frankly don't know how you can look at your userbase dead in the eye and say "this change you all unanimously find stupid is great for you actually".

We have a responsibility to our customers not to cause their years-in-the-development projects to get ruined by development hell. We also have a responsibility to protect the business and prevent Construct itself falling in to development hell, which in extreme cases, risks the failure of the product and business.

I know addon developers don't like it if that means they can't customize the engine as much, but as I say, often there are other workarounds which people can and should be using instead, and overall, in my view, it is better this way round. The way I see it, there's lots of addon developers wanting to do things that we know will cause disasters, but claiming it will in fact all work out fine; our job is to avoid disaster, which we will do whether or not addon developers understand why, because we understand just how terribly awful things get down that path.

I totally understand both sides of this. However these 3rd party plugins we have thanks to this being possible is what makes construct 3 an option for serious projects. Just knowing that if I run into a limitation of C3 I can still probably find help solving it thanks to some 3rd party magic. This have happened multiple times, so without this reassurance I would almost not dare to start a bigger project in C3 to be honest.

I work at a big game studio and we work in Unity as the game engine. Once a project is started, we pretty much lock that development in to that version of Unity.

We also use 3rd party plugins which our current version of Unity supports. And as long as we are fully aware of this risking to break before we start to use the plugin it is up to us to decide if we should use it or not, knowing it might break in the future.

And later down the line we might update Unity for reasons and realize a plugin we used isn't supported anymore.

What do we do then? We fix it, either the plugin itself or replace it with another solution. Sure, it can be a pain, but we knew it could happen and we still made the decision to use it.

What we would never do though, is to blame Unity or any other game engine we used. It is entirely our own fault. I feel like anyone that is experienced enough to install plugins should understand this as long as there was a warning about it.

I mean there are so many things a beginner developer could do wrong in their projects that will turn out to completely break their projects down the line. It is just a matter of learning what risks to take and not take based on project scope.

So I think the easiest and best solution would be to CLEARLY warn users when installing these plugins. You as a user should understand that Construct is not responsible if this plugin breaks in the future.

Just my 2 cents about this discussion.

It's literally just this meme at this point.

From both sides.

Well, a limited public API with encapsulation is the norm in the industry. So it's normal that you work with that and either rely on workarounds or feature requests. Perhaps in an ideal world the APIs would be broader, but that is always improving, at least in the script APIs (which would be the basis of a v2 SDK).

Another thing people routinely underestimate is seemingly minor features can have difficult complications. I've lost how many times I've thought "this is only a few lines of code" and then ended up spending a couple of weeks on it. Over the entire lifespan of a feature, let's say it's over 10 years of support and maintenance, writing the initial code for a feature and getting it working is probably about 25% of the work. The rest is long-term support, maintenance, refactoring, optimization, and upgrades which are sometimes very tricky to do in a backwards-compatible way. There are many things that might look obvious from the outside but get much more difficult when you have hundreds of thousands of lines of code used by hundreds of thousands of users maintained for over a decade.

Again, I understand. But what am I supposed to do? Beg for features only for them to be added in 9 months on average?

That's my entire point. There is no alternative.

If C3 had a proper 3rd party addon versioning system like it does for vanilla addons, again that would not be as much of an issue. I could just make my addon for all the versions prior to the one that adds the feature in the future and all is well.

But with both a restrictive SDK and a lack of versioning system, there is just nothing left.