It is good time to make the Construct great again

> 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.

Truth of the matter is i burnt myself once by using a lot of Rex' old add-ons back in the day and ever since then i stay away from 3rd party things, even though there's great stuff being done.

So true.

me too.

Truth of the matter is i burnt myself once by using a lot of Rex' old add-ons back in the day and ever since then i stay away from 3rd party things, even though there's great stuff being done.

If we were able to fully block all engine hacks like other engines, then it's unlikely anything would have gone wrong in the first place, and everyone could trust that third-party addons will work reliably. I think that would be a much better situation.

I'd also add: if you choose to stay on an old version of Construct, and you run in to a showstopper bug, you still have a way out: update to the latest version of Construct. Even if there are regressions when you update, you can file issues with us and we'll provide official support and sort everything out.

If you use engine hacks, that becomes impossible, and basically you're just screwed. That's why it's a uniquely worse situation.

sure, then their would need to be a bigger effort in extending the sdk so there is less need to hack in stuff.

I personally don't see how not being able to solve an issue at all is better than taking the risk of something breaking in the future.

Yes, that's not possible.

WackyToaster, is this because the official plugins use undocumented features or is it because their code is not publicly available in a plugin-like package?

Whenever I see negative comments about C3 (mostly from users of it), it dumbfounds me.

I am no sycophant, but I think that C3 is a brilliant piece of software that is extremely underrated both in the community, and out of it, too.

C3 is vastly overrated by most users inside the community (making small games typically) and vastly underrated by outsiders. c3 is best in class. It knocks gamemaker out of the water in specific circumstances. But in others, it comes up short. Same thing for Unity or Unreal. It depends on what your needs are (talking about 2d only). If you need shaders, custom rendering, lights, onstruct probably isn't for you and that makes sense. But there are still ways in which construct could possibly better support some areas.

I think from Ashley's participation in the forum, and the ability for us to create small-medium games pretty rapidly, that you would "miss it when it's gone"...

Don't get the negativity wrong. The vast majority of salt on these forums comes only because people know this is a great product, they just have run into problems - I spend no time on Unity's forums because it is basically pointless. Ashley spends alot of time here, and I think that is worth volumes, even if he is just saying no. But sometimes he says yes, and sometimes he fixes the "bug" you want fixed. Unity can go for years with breaking problems in some systems and ignore it. It's pretty rare to be able to speak directly to the developer like this.

Yeah we all want to see this software go far, Scirra's team and subscribers alike. Hope we get to a good middle ground. Maybe the solution is beyond what's been suggested here and needs a whole new approach. Anything that bridges the gap between freedom and safety.

If we were able to fully block all engine hacks like other engines, then it's unlikely anything would have gone wrong in the first place, and everyone could trust that third-party addons will work reliably. I think that would be a much better situation.

Yeah, it also would have not "gone at all", let alone right or wrong - in a few cases. Though I admit you are right in the majority of cases, you do use words like "most" and "usually", and I agree, most users didn't need the hack, just like most users don't need to worry about function call overhead - but there are some who do.

Also, gamemaker and unity have a much more robust api. locking down construct to be like the other engines ignores the fact that the other engines manage to get away with it by have a much larger feature set exposed. Construct has alot of those features, it just doesn't expose them.

The example with no collision information I think is perfect. On overlap, where is the contact point, what is the surface normal of that contact...? That isn't something alot of small games need, it isn't something most beginner or intermediates will ever touch... and obviously, 8 years after suggesting it, it isn't something most people care about... as it still doesn't exist afaik but... when a behavior like bullet makes some obscure call to the engine to handle "reflections"... you know it is in there.

Truth of the matter is i burnt myself once by using a lot of Rex' old add-ons back in the day and ever since then i stay away from 3rd party things, even though there's great stuff being done.

Yeah these addons were great while they lasted. The only reason why I'm not that reluctant to touch 3rd party plugins is the simple fact that in most cases I'm probably able to fix an issue myself if a plugin breaks, at least if it's a relatively simple fix. But I think it demonstrates Ashleys points quite well. 3rd party support can just vanish from one day to the other for any reason, then something breaks and you're kinda screwed. Recent examples: ProUI and LiquidFun, and those were even paid addons, not some random free addon from the exchange.

But there's also the point that there's a lot of things people want that Ashley is reluctant to implement for one or the other reason. So what option is there other than a 3rd party addon?

Prime example is UI stuff. Highly requested for years at this point. Best we got was the HTML plugin. Mind you, that plugin is great for all kinds of purposes and I use it quite some, but not for making a good UI in a game due to the nature of DOM elements being almost entirely detached from the games rendering and always draw on top no matter what (+ some extra annoyances) Yes, implementing it on a canvas level has a rats tail, but it's an important rat regardless.

Just something like flexbox/scrollbox implementation for a start would already be a huge win, but alas.

is this because the official plugins use undocumented features or is it because their code is not publicly available in a plugin-like package?

The latter. You can access the code with the inspector if you know where to look and unminify it, but that's not exactly useful for anything other than looking at it.

I also tried Godot here and there, didn't like it either. Construct just hit's a spot other engines don't hit ¯\_(ツ)_/¯

That's me as well. I've looked at GDevelop, Construct 3, Godot, Unity, Unreal, GML, and Defold. These are the game engines I've downloaded, installed, and tested out. I thought GDevelop would get me to potentially switch over but the way they do functions is completely unintuitive (to me) compared with C3. Godot has a lot of great things going for it but the node-based system with the different signals and back and forth with the editor and what not just makes it clunky still for me. I have a background in C# mostly (and some python) but not enough to make that kind of a switch.

Defold was great and I watched an entire series on YT from a guy who looks and talks a lot like Bill Murray (David something or other). But still, it's mostly coding. I like coding but Lua is too much (?) like python and I got away from python several years ago.

The quick prototyping abilities with C3 are what keeps me coming back to consider subscribing. I didn't even realize it but apparently I used to be quite active on the C2 forums 10 years ago. Unity and Unreal were just too bulky for me; I even tried to figure out Blueprints but it just seemed unintuitive (similar to GML's visual scripting language for me).

I also looked at Buildbox but there were too many reports of them being scammy so that turned me away. Phaser, Cocos2D, Stride (C#), etc. etc. There are so many out there that offer this or that though most are a form of coding. I realize even C3 has javascript coding which doesn't scare me off too much though I still prefer the rapid prototyping with event sheets and asking questions online.