> Now they're in development hell: they can't stay on the current version of Construct because it's got a showstopper bug. But they can't update to the newest version of Construct with the fix, because the hack they used in their project won't work. They have no good options and can't rely on official support.
About this: I've been doing consulting work on many games for a while and from experience, this does happen. It's just that it's never EVER that simple. And it's not only on Construct, this kind of stuff happens all the time, because it's expected when making larger scale games. You WILL write bad code that WILL cause problems. You WILL stop updating your engine (not only due to hacks, but also to avoid regressions, and to make the engine codebase more stable for late development) and you WILL cry because an engine bug was fixed 10 versions later. You WILL learn to deal with it, and you WILL find a way to still release.
I just want to jump in and say this is a really good summary of how game development works, and I want to show my support. I've released two games, and both times we used different libraries and extensions that users had changed to do what the engine couldn't do on its own (not c3 in my case). When you do this, you know there's a risk of these things being discontinued.
I don't know how often this creates company backlash, but I can't imagine serious developers using things like Skymen's experimental add-ons without knowing the risks (maybe it's more common in the C3 community). This isn't a post saying Scirra should do this or that, but it's not often I see someone explain game development as well as in the paragraph above, and I wanted to point that out.