Adding such a joint was only like 10 lines of code, but it was never added to c2 despite a fair number of people asking for it.
IIRC, this was because the situation was something like: we were using an asm.js build of Box2D physics based on an older version of Box2D that did not have support for prismatic joints. By then asm.js had fallen out of favor and WebAssembly had taken over. So upgrading the physics engine meant more or less a full migration to a whole new technology for the physics engine, including figuring out how the new toolchain works, and going through the inevitable round of bug fixes for a few months as we figure out a bunch of unexpected breaking changes that came from the technology upgrade. And as ever we're being asked for 100 different things at the same time, so it just takes time to get round to that and take on a big upgrade job like that.
This kind of thing is why I wrote the blog post The unexpected complications of minor features, which basically argues that there is no such thing as a minor feature when you work with complex software like Construct. I think most of the time when someone thinks something is straightforward it is actually much more complicated than they think. But people still see things like this and think "Scirra are lazy" or "they just don't care". I don't really know what we could do to mitigate this, as often we don't know what the complications are until we start the work, so we can't always explain why things will take longer than expected ahead of time. All I can do is ask for people's patience and please read that blog post to understand the kind of thing we routinely deal with when implementing "minor" features.
Basically, its seems like Scirra recognizes the need for engine tweaking to support behavior interaction, but is adamant that isn't how you should develop
Let me explain what went wrong with tweaking the engine code:
- Some third-party developer adds some plugin that tweaks some internal code to do some interesting feature and releases it.
- The plugin gets wide adoption over time.
- Eventually - perhaps even years layer - we come to upgrade that part of the engine, perhaps to add some major new feature, optimize it to be 2x faster, or some other significant improvement. We have no idea that some plugin manipulates this code, so in the process of changing everything, even though we check Construct officially remains backwards compatible, we break all projects using the plugin.
- Users update to the latest version of Construct and see their project is broken. Who do they go to? They contact us and complain. Often they get the impression we're incompetent as in their view, we can't even update Construct without breaking everything. Cue angry customers, refund requests, claims they'll leave Construct forever for other tools, etc. Sometimes it also results in corrupt projects, and for years afterwards we end up answering occasional support requests where someone has a corrupt project, and often it's extremely difficult to help them recover their work. (And a surprising number of people don't keep backups.)
- Meanwhile by then the original third party developer may left the community and have no idea what happened. Sometimes they even blame us anyway, claiming we're incompetent and should have kept backwards compatibility.
There are other ways this can go equally wrong, merely by tweaking an action in an official plugin or behavior and releasing it.
In other words it's a total disaster for us and our customers, and often the third-party developers think it's fine, or have no idea anything ever went wrong.
The solution to this is: define and document a public API with specific methods that you promise to support indefinitely. Then we know the feature set we have to support when making changes. This is the standard and widely accepted approach in the software industry.
Of course if the public API doesn't do quite what you want, it can be a tough situation to be in. But this is still a much better situation overall. The inability to cause compatibility disasters is a feature, not a bug.
I am well aware that tweaking things to suit your specific needs is important. However it must be done in a way that avoids compatibility disasters, or the entire development of Construct could descend in to a development hell where it's impossible to make improvements to the product without causing chaos.
We do have multiple ways to customize things. For example most behaviors have the ability to directly manipulate the movement vector. This is sufficient to add extra features like wall-jumping and climbing to the Platform behavior. If you need even more advanced features, perhaps you run in to some fundamental limitation of the behavior itself. But this is also why we have the custom movement behavior, which provides the kind of basic building blocks things like the Platform behavior are made from, as well as coding features so you can custom-code things like in any other engine, and also a full addon SDK so if you wanted you could even come up with an entirely new form of a Platform behavior (distributed maintained separately from the official one, so avoiding compatibility problems). So I think there are a range of options for customization already there, with a sliding scale from works-out-the-box to custom-code-everything. And none of those are responsible for major compatibility disasters. I think it's part of our job to be responsible in ensuring people can't do things that end in disaster, so even if it might be frustrating that you can't do something like tinker with a random part of the internal engine, please know that it's for a good reason, and we're trying to guide people to better alternatives.