It is good time to make the Construct great again

I empathise with these points about protecting people from corrupting their projects with wacky plugins.

However, I've seen plugins (iirc Skymens experimental text plugin, experimental 9patch, even dynamic layers before this was officially added).

If one used these addons, and then a major change occurs with text/9patch/layers, wouldn't we be in the same position as if someone modified an official plugin? Raging bug reports but it all stems from a third party addon.

At the end of the day, Scirra don't offer support with 3rd party addons or modifications (and sometimes even do offer support in these cases but only if common/quick to solve). Whether it's a 3rd party addon or a "experimental fix" addon, or even if it were to be an official addon that's added a 2nd time as a modified addon, it would all fall under 3rd party addons, which Scirra won't support, which seems very understandable.

Whilst I do sincerely agree with protecting people, I guess I feel there's a point where people must be warned about what they're about to do (i.e. Labelling these plugins as experimental), but beyond that they're on their own.

Official plugins could be marked as protected, as to not allow modification (if someone did tweak platformer behaviour, then they'd need to install it as a 3rd party addon then "move their events over" to use this modified behaviour, rather than updating the official plugin - this would be time consuming for some, but prevents "hacky" workarounds and keeps things consistent.

I for one use events mostly, so this doesn't deeply affect me, but sometimes wondered if the community could enhance plugins such as the physics addon.

On another note, I think it's really interesting with Physics - I guess if there was much bigger demand, we could get a physics 2 addon or something? I have hit issues with current physics for many different reasons that could all be fixed by having better collision filtering, and always wondered "well it's within Box2D, I wonder why this can't be exposed in event sheets?", but now this makes sense.

I don't think those are good analogies - software is pretty abstract and personally I don't think maintaining a reliable software platform that other third-party developers build on top of has much relation to a restaurant. Tweaking random bits of internal code is fundamentally unmaintainable. This is widely understood among professional software developers. There is no way to make that work. The solution is a public documented API which you promise to support. That is what we have done.

I think a better analogy is: imagine a block of flats where any resident is allowed to make any structural, electrical, plumbing, gas, or water alterations, to any part of the building, at any time, without permission from anyone. Chaos would ensue and the result would probably be extremely dangerous. This is not a reasonable way to run a shared building. There are rules about what you can and can't do, and who is allowed to make which changes, specifically to prevent that end result. Residents who complain that they can't just break open a few walls and run another gas pipe through several neighbor's flats are not being unfairly restricted in their freedom to do what they want with their flat - the rules are there to make sure the building can continue to function and be properly maintained in the long term.

The default theme matches the system setting. If your system is set to use a dark theme, then Construct will already default to the dark theme.

I am sure people would still ignore the warnings, cause compatibility disasters for themselves including corrupting their projects, and then contact support and ask us to help rescue their project. Or we update Construct, it breaks the custom code change, and then the situation I described previously plays out again.

Well, let's speak concretely as I am genuinely curious:

I often make hacks of the engine, publish addons that break the rules, and lately I've even delved much deeper into engine hacks.

I've always tried to do my best by being vocal in the community so users who use my addons know who to come to when an issue happens. If an addon of mine gets broken by an update (most likely Animate Text), I do my best to fix it while the engine is still in a beta cycle. I beg users to report stuff to me, and only me, and I always try and fix it as soon as I reasonably can.

For more hacky addons, I provide warnings, call the stuff "Experimental", make it painfully clear that using the addon is at your own risk, and when the addon actually does break, I warn everyone I know has been using it on a larger project, and give them ways to either remove my addon, or update it so it works again.

For some other addons, I've even marked them as deprecated so they don't appear in the addon search, and people who aren't aware of my work can't break their project.

I do all of this because the LAST thing I want is for some entitled customer to come to Scirra and bother the team for an issue I have caused and I am perfectly willing to fix.

Now, what I want to know is:

- Has this happened?

- What can I do to minimise the chances of this happening? (I mean besides respect the rules since you've already made your point very clear, and we both agree that if I didn't use undocumented features, it wouldn't happen anyway)

Now, I hope you can understand that in many cases, Construct users find themselves needing a very specific feature for a very specific project, and it is simply not an option to:

- Ask for it and wait

- Ask for the SDK changes and wait

Often in those cases, the only choices are:

- Mod the engine to add that feature

- Drop that feature

Which is not an easy choice to make, and me as an addon dev, I often make the choice to write an addon that does add the feature, and keep it up to date as long as I can, while providing free support on work I'm not even paid to do. I've been happily doing that for the past 6 years, and it's always been done thinking about the possible effect this can all have on Scirra and trying to find ways not to be too much of a problem.

If I am a problem however, I would like to know, and I will do my best to minimise that.

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.

It is true that if a big enough influencer - or group of - showed just how great the platform was on youtube etc, then C3 would start to gain more traction.

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

I honestly don't care if anyone thinks my comments are too gushing, but we are very lucky to have an engine that hits the 'sweet spot' for so many. I've tried everything else, believe me.

C3 lacks 'something' tho, as most people have said. But for me, this 'something' is external factors, such as enough big dev/gaming/popular youtubers shouting about it, and some really strong games being championed - I have seen the same few games highlighted on the homepage for years now.

I agree with a lot of the things Ruskul is saying. Especially this part:

[...] and part of wanting to work with events is that they feel cleaner, more visual, to me, and the moment I can't, it just feels like the core advantage of c3 is no longer present and other environments offer cleaner code spaces.

There is only a single thing that basically everyone in the community can agree on, and that is that the event sheet system is awesome.

My concerns with the whole JS/TS focus lately is that there is no end to it, from now on it will always take a good chunk of resources away from improving the experience of using event sheets. Resources that we are told over and over again are very limited, and I get that, but I disagree with the allocation of those resources.

Entirely new product no one asked for, "Dogfooding" C3 with C&C but actually using Construct more like a framework, or even just as a renderer and doing everything else in JS (though tbf some of the best improvements to old plugin/behaviors actually came from this. But obviously only to the parts that were actually used and not circumvented with JS), C++, JS, now TS, ... where is this going? What is the plan? Is there a plan?

We get multiple new things exposed to the api every single update, but if you want some more ACE exposed for events sheets, from an old plugin or behavior, it's always a year/s long battle.

Another concern, and something that is already happening, is that it's splitting the community, where parts of it now literally speak a different language. It would be something different if it's only people who extend the functionality for all by creating new addons, but it's not. It's split in a way that it's more and more expected to use JS to fix your issue, even though you don't use it yourself.

If you say you don't want to use it you get told to try it, it's not that hard, or something like that. I did try it, but coming from GDScript, it's an awful coding experience in comparison and literally the polar opposite of what makes Construct great and why I use it.

I want to agree with Ashley on something here - working around software limitations is truly something everyone has or will face at some point, and that OK. In fact, it can be quite fun to break the loop and make you think outside the box for a second.

The game I've worked on for the past 3 years uses exactly 2 additional addons, one of them is Greenworks and the other Bound to Viewport (thank you skymen) can be recreated with events, but I wanted to see what it would feel like to use 3rd party addons, so I keep it in there. I use two JS libraries, one is generating very slick random IDs and the other one was made obsolete with the latest Construct stable release and the addition of Cryptography plugin. That leaves me with a handful of JS lines that I use on a project with 3123/2653/2303 ACE.

My point being, every time I hit a wall, it wasn't the limitations of the engine that stopped me from continuing further, it was my limited knowledge at the time.

I'll give a recent example - I'm a huge perfectionist, I can't have something that works somewhat, I need it to work exactly as I want it to. That's why I had a very bad couple of days trying to figure out how to make the player stick to a sticky surface on any given side. The Platform behavior was not playing ball and was messing tons of other conditions, since I have various ways a player or the surface itself can move. My player movement logic alone is 200 events (and that's not including the input method logic). Then I saw the gif of that one guy making his player go up slopes by using elevating platforms and it hit me, instead of trying to mess with the player, I can simply spawn a solid object under it so it seems like it's stuck on that surface, then apply whatever animations I need to make it look like it's stuck when it's actually just sitting on an invisible ground in mid-air. Then when a given action is performed, remove that invisible ground and the player is no longer stuck. That worked perfectly!

In that regard, I do not support messing with the engine code itself in undocumented ways nor do I think it's necessary. However, I don't see an issue with cloning an official plugin for example, renaming it, adding it to your project and messing with its code that way, and from what you guys are saying, that's not possible? Either way, not for me, but I'm sure many people will benefit from more ways to expand the engine core while at the same time avoiding "development hell" for Scirra.

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

We love Construct 3 too!

But sometimes people want to see it improve to become even better!

Due to humans being emotional beings, this desire to see changes can lead to anger or frustration (negativity).

Hope that helps your understanding!

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

The biggest fans are often the harshest critics. And there's just valid criticism to be had. I don't think most people make these comments from a place of negativity, even if it sounds like it.

However, I don't see an issue with cloning an official plugin for example, renaming it, adding it to your project and messing with its code that way, and from what you guys are saying, that's not possible?

Yes, that's not possible. It used to be possible in C2, but it seems that exactly that lead to some people playing the blame game and finding Scirra at fault when, in fact, they are at fault themselves. It's just human nature to attempt to find blame everywhere else except one self, anyone who played any amount of League of Legends or Overwatch can probably write a book about it. Teams losing? Must be (the game's bugged) and/or (lag) and/or (unbalanced character) and/or (anyone but me). It's never just "Oops, I screwed that up. I'm the problem."

Scirra also makes an easy target by nature since they are the company and they are getting paid. What are they supposed to do if a customer waddles in with their corrupted project due to a hacky plugin, blames them for it and expects it to be restored? Sure, as an individual you could easily say: "Lmao you didn't make backups? AND you messed around with a hacky, unsupported plugin? Unlucky buddy, learn from the experience, you messed that one up yourself." but as a company, in the end, you rely on people giving you money and ideally they are also happy doing so. Even if they give you a headache.

Well Ashley I am glad to know my way of doing things is at least working. If in the future a disaster happens because of my own addons, please let me know and I will do my best to help in any way I can, as quickly as I can.

About Animate Text, while I know it was hypothetical, I think it's still a great example: My addon does exactly what you suggest it does, and still I have to use undocumented features of the engine to make it work.

Animate Text does not have any "hacks" in it as I offloaded all of them into my Experimental Text Fix addon. I made sure not to change any parts of the engine for my addon.

Now you might think that everything you mentionned should and would absolutely fit inside the documented features but in fact they dont. I will refrain from going too much into the specifics to avoid derailing the subject, but in short I do my best to work around the limitations.

I rewrote code that I know is in the engine but don't have access to because it's "reasonable" for me to do so. (Like easings, tag parsing and typewriter) I even rewrote a bbcode parser to handle special cases like icon tags and tags with no params for animation before giving them back to C3's BBCode class.

Now, doing this means there will be very specific details that I cannot do without using undocumented features (or rewriting huge chunks of the engine). Very tiny details that make all the difference and that most people will be bothered by. These things I cannot work around, and most likely my addon is the only existing use case for having them available, so they will probably not be exposed.

In this case what am I supposed to do? Drop the whole addon because of one implementation detail? Ship without a core feature of the addon? Beg for months for a super niche feature that we all know full well will not be exposed to the SDK because nobody will ever use it ever again after me? Or just use undocumented features and maintain it when it breaks?

In fact this is what I think Ruskul meant by

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 (do as we say, not as we do). So instead you end up with behaviors that, in order to function correctly, need some back and forth boiler plate added either to the event side, or through scripting.

If the addon was made by Scirra this would not have been a problem at all, because you can just accomodate just fine for these kinds of minor changes. These kind of mini tweaks are done all the time in vanilla addons, and most of the time they are not exposed to the SDK because they are so niche it's reasonable to think no one will ever need them again.

Now, Animate Text is an outlier in the fact that it's the only addon I don't advertise as "Experimental" or "Unstable" while also relying on using undocumented features for a core feature. That's mostly because said undocumented feature is accessing your line and fragment count after your tag parser runs, and it's VERY reasonable to assume you will not remove line and fragments from your text renderer. Even if you break my code and change your entire architecture, these info would still be there somewhere. I can always fix my addon ad vitam eternam.

Anyway, this is mostly why I keep doing stuff that way. I make cool addons, make them available for free and make them open source. I keep maintaining my addons, and provide support for free as long as I can, and do my best to stay out of your way. In turn staying out of your way means not clogging the ideas board with sdk requests I think are useless to the community at large and doing whatever I need to do that's reasonable.

Staying out of your way also means that sometimes to prove an idea is doable, there is no better way than to just make it happen and show the result. Stuff like dynamic layers I've been asking for 5 years, and they were finally added as soon as I was able to prove the concept worked by making an addon that does it. I see no way of doing that without dabbling in a bit of engine hackery.

Anyway, I think we both made our points clear and I don't wanna engage in this SDK topic any more. Most other addon devs will agree that we do not want to bother the Construct team by making addons, far from it. I know Mikal for example has specifically avoided using engine hacks or undocumented features in his released addons for the reasons you outlined, and he has half a dozen proof of concept addons he is sitting on for the day they are possible without engine hacks.

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.

You are not lucky, you are just hoping not to be asked to deal with a problem most game dev teams are already dealing with themselves.

Astral Ascent is one of the biggest Construct games, and having read the code, it's a Construct game that scaled FAAAAR beyond what anyone in this thread seems to be able to imagine using Construct's core features. They have ran into MANY issues, as you do when making games and they have just dealt with it. They have locked their engine version to r225 that released 3 years ago.

In general, in game development if you start a large project, it's common practice to not update the engine that's under the game too much in the process because you risk creating regressions and unforseen issues. Stuff you cannot just see coming when writing backwards compatible code, or even just by using documented features. Updating the engine should only be done very carefully when you make 200% sure you absolutely need whatever fix or feature was added. It sometimes takes weeks to properly update, and in some other engines, the team are sometimes dedicated to remaking the entire game from scratch on the new engine version.

In Construct games, it's often not that dramatic because of the backwards compatibility work being done, but also because there are very few large Construct projects that have full teams collaborating on them. So we just forget how things are supposed to be done and complain when we hit the same walls we've been warned about.

If in the future a disaster happens because of my own addons, please let me know and I will do my best to help in any way I can, as quickly as I can.

I appreciate that, but my point is in the scenario I described previously, there is no solution. Nobody can help the person stuck in that situation: we can't, because they use third-party code, and you can't, because the hack has become impossible. They are on their own. The only way to prevent this is to avoid modifying the engine internals in the first place. I know software development is complicated and a bunch of difficult stuff happens over time anyway, but that situation I described is basically catastrophic. It ends in reviews like "I worked for a project for 5 years, a Construct update broke my project, and then they refused to help me". In that situation that's pretty much true, and is the kind of review that could cause major reputational damage to the company, and make other developers think they better not go anywhere near Construct.

I'd point out most other game engines rely on compiled binaries which are not feasible to modify, so hacking the engine is off the cards. People just use workarounds instead and can still get a lot done that way. The problem of being able to hack the engine is basically unique to Construct because JavaScript has historically had poor encapsulation. It now has better features for that like private fields. I'd quite like to update the engine to use that to prevent the possibility of disaster, and force the use of workarounds instead, which would bring us in to line with how most other game engines work. But it would probably permanently break most engine hacks. That's something I've always tried to emphasize is a possible outcome, and it could happen at any time for any other reason too, including inadvertently. This is why the software industry invented encapsulation and if you ignore the lessons learned over decades of software development, you'll probably eventually learn them again the hard way.