It is good time to make the Construct great again

This doesn't have to be something completely open in the public if there is a fear of discussing features that might never actually arrive, but maybe specific people like R0J0hound, Overboy, skymen, Mikal, etc. could be involved in giving their thoughts and early feedback before production even starts (If they would be willing to spend some of their time on this).

I would be very down for this to be honest. I know other engines have a similar thing with an insiders program, where handpicked ppl have a communication channel under NDA.

The plugin SDK is mainly designed for integrating third-party services, precisely because there are so many possible services out there, and even some individual third-party services have a huge feature set, there's no way we have the resources to cover it ourselves. So we made an SDK so other developers can integrate all that stuff without having to wait for us to do it. I guess some people want to tinker with the engine internals, but that type of thing has historically caused awful, horrible, nightmarish compatibility problems, so it's something I would specifically discourage. (And often I think the things people want to do are already possible, just if designed in a different and more maintainable way.) Anyway if there's specific and feasible suggestions for the SDK, they can be posted to the suggestions platform... but the key word is "feasible" (if your suggestion is "add an editor SDK so we can customise absolutely any part of the editor from plugins", then file that along with "make a full 3D engine").

As for an insiders program... it's actually very complicated - the release system is a fairly big and sophisticated bit of server-side software, and it would probably be a lot of work to create another release channel that only certain people can see. But I don't really see what that gains us anyway - we already release things to the beta channel as soon as there's something worth sharing, or if we want to ask the community about stuff, we do it in the forum. So everything we would do in an insiders program, we basically already do but in public, involving everyone. So we get more feedback, and avoid the political problem of some people feeling left out if we don't pick them for the insiders channel.

I understand where you're coming from Ruskul but I don't necessarily agree. I don't think it's fair to try to strictly apply code architecture principles to Construct's Event sheet system as they have been written with typical coding languages in mind, and not event sheets.

Instead I think it's far more sensible to apply a set of new coding principles that are designed around the event sheet and Construct's addon architecture instead.

That's a totally fair assessment. But I also think common code designs are created to solve particular problems. In some cases, construct has no good way of solving those problems in a handy way as it is. Take object pooling as an example. Construct handles it behind the scenes. That is spectacularly amazing. In pretty much any other major engine, you have to create the pooling system yourself afaik. But, for something where you need decorator or protected factories? That's where you can make those in construct, but there is no way to force other contributors to use those systems. right? So like, I can make a factory with events, but another programmer can still just spawn the object the factory is supposed to, without going through the factory. It's those types of problems that construct doesn't handle well imo, and if it had them baked in (like with object pooling), I think that would be great. Just a few architecture tweaks (such as creating protected, private object/family functions events would be great. But to do that, I think you would need per object event sheets, which would also cut down on some common boiler plate events that iterate through objects to apply instance specific logic anyway.

The idea that because you might outgrow an addon then you should absolutely avoid it doesn't make sense to me. If you truly have a good reason not to use built in features, I think writing a new behavior is a far better idea than trying to handle everything using events.

I should be clear - I do use them. But I am really careful about using them for more than a prototype. Being midway through a project and realizing you have to substitute several vanilla behaviors with custom ones is kinda pita. At this point, I have alot of the behaviors recreated, but then I don't benefit from any feature improvements. For a long time in c2, it was physics. I would have to keep adding my changes to the newest release when a simple inheritance scheme would allow users to specify additional ACES without having to recreate the whole thing.

I have seen projects scale just fine within Construct's features...

How can you deal with global space bloat in a large project without simply having to "get over it". For someone with pretty bad adhd, I have a aneurysm when autocomplete lists literally every function or object in the the game. The real big appeal to construct is how sleek it can be, at a smaller scale. It isn't that you can't scale in construct, its just that it you do have to just "deal with things" that you don't in other environments.

Also, with the recent addition of TS, and with the VS Code extension, I think Unity C# with Visual Studio isn't that much of a better coding environment compared to C3. The only thing maybe is that it doesn't integrate into the editor, and C3 scripts aren't treated the same way as Unity scripts.

That is pretty big, but still not quite as seamless. Also, the construct runtime still functions JS style, not TS. Unless I did something wrong.

TLDR, I think your disagreements are pretty fair.

Ashley

One of my main use cases for the Addon SDK, is portability and reuse of code. everything is packaged together nicely. a lot of things that can be done with JS is much more convenient to move to addon.

And I think that stems from JS and event not having good interoperability.

I totally agree with this.

Ruskul

Competition between the best coding environments... in my case, c# with visual studio support, or javascript without good intelesense/scope with construct. This isn't even a competition. [...]

In construct, starting a new project is fast. Creating new objects is fast. Prototyping features is a breeze, But refactoring is SLOW and gets even more tedious the larger the game gets. Construct, by its very nature, encourages poor architecture (with nearly EVERYTHING in global scope [...]

if you want add duck, duck rolling, ground pounds, jump forgivness, double jumps, wall runs, wall slides, phaseshifting, object lifting, rewind and timeshift, shooting and reloading, but only in some cases. No that original choice to use if/else trees looks pretty bad. You probably should be using some sort of state machine. But then what if you want the character abilities to be added and subtracted at runtime. [...]

It was easier to learn unity than grapple with c2 sdk [...]

but the addition of scripting is pointless as has been mentioned [...]

Effort should be spent making c3 have better event system features that enable us to do more in a scalable environment...

Based on the examples you mentioned, you already know the solution. There will be always a limit to what you can do with an easy no-code solution. You can't have the cake and eat it too.

You should use JavaScript (or TypeScript) to build the complex part of your game (like the state-machine/skills system you mentioned). You can choose to handle the more complex systems with code and use the event sheets for more systems.

construct.net/en/make-games/manuals/construct-3/scripting/guides/subclassing-instances

Using Construct with TypeScript and VS code is not much different than C# with VS. You should give it a try.

I've ported most of my 4x strategy game to Construct, and it is as scalable as it was before. (hex grid, pathfinding, splines, modular AI, etc... check it on itch). With good intelesense btw :)

skymen [...] with the recent addition of TS, and with the VS Code extension, I think Unity C# with Visual Studio isn't that much of a better coding environment compared to C3.

I agree with skymen . From my experience, I can say Construct 3 doesn't get in the way of having a scalable architecture (especially now with the official typescript support).

My two cents:

1) It's better to invest in promoting the TypeScript support (with tutorials, docs, examples and step-by-step guides), than trying to make event-sheets handle all use cases imaginable. When someone argues about how event-sheets are limiting, it shows that the way to go is to write actual code (be that with C3 or with any other tool).

2) The visual identity could improve

Everade Construct needs a major makeover. Their website, logo, mascots, and how they advertise their engine all seem too playful. [...]

I agree with Everade that this would benefit Construct3. An example is GameMaker, which rebranded in 2012 to present a more professional/studio image. Among other things, the dark theme should be the default. I had the chance to witness someone's reaction to launching the guided tour for the first time. The seemingly outdated theme immediately put them off.

3) As skymen said, keep doing what you are doing. I understand that there might be challenges along the way, but the Ashley is doing a great job in improving the engine. I have seen many of the suggestions on Construct's suggestions website being brought to life (like TS!), and although not all suggestions are taken to heart, the curation has been quite decent so far.

...I guess some people want to tinker with the engine internals, but that type of thing has historically caused awful, horrible, nightmarish compatibility problems, so it's something I would specifically discourage. (And often I think the things people want to do are already possible, just if designed in a different and more maintainable way.)...

"Often" is the keyword. Often, but not always. I think the users who end up using monogame, for example, are the class of users that would have stayed if they could, but they can't.

One of the biggest things I needed to do in c2 was add collision layers to the platformer (so some objects could go through some things, some of the time), handle slopes (built in platformer is slope agnostic - The object gets pushed correctly from collision but is ignorant of y velocity as it travels up or down), get collision point, collision normal, etc, as well as a few other things. The built in platformer didn't cut my needs at all so I had already rolled one, but adding additional features to the collision system was... unfeasible. Recreated the whole project in Unity in 2 weeks.

Now, some of this is possible in c3 now, because features have been added. But this is years after I needed them. But the problem is the same now as it was then, in principle. If Scirra don't agree that a suggestion will benefit enough people, it's basically shot down. In other cases it takes YEARS before it is added (prismatic joints in box2d, as an example). 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. But I added it to my project and dealt with it. Regardless, I still can't get the surface normal of the collider an object is overlapping without adding more. Box2d provides raycasts, boxcasts, etc... so if you are already using physics, there are solutions already baked into the box2d behavior... but... not exposed. So I added workaround and hacks. If you aren't using physics, you quickly realize that the construct runtime does some shady black magic behind the scenes just to make behaviors like SOLID and Platformer interact.

Enter the desire to want to tweak the engine. Because you need it, even though Scirra doesn't see the need. Even though Scirra does see the need in their specific uses.

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.

TLDR, its hard to take such advice seriously when the Scrirra team authors behaviors that need engine tweaks in order to function (shadow caster, platformer, solid, dropthrough, etc... all have some internal engine stuff if I recall). Its frustrating in many cases and makes the itch to switch pretty strong.

I think there are good arguments for steering most users away from doing this. But in my case, c3 clamping down on this literally steered me right towards another game engine. I cannot (quickly/easily) make some of things I did in c2, in c3, without modifying behaviors. If I have to rewrite behaviors from scratch, I'm going to do that in an engine where my power gains will be substantially higher. I really like working in construct, it is relaxing and less stressful ide (hard to explain, but opeing construct is fun. Opening unity is work), But, when a simple tweak to the engine would fix your problem but Scirra advocates essentially rewriting core components entirely on your own... If I sink my time in that, I want AAA rendering and postprocessing and access to 1000s of premade tools, etc...

Simply not being able to tweak pathfinding in c3, lead me to unity where I bought a* pathfinding project for $30. It solved my needs and now the prototype is sitting in a development environment where the clients can more easily take it further if they wish.

I still do alot of stuff in c2, and I do some stuff in c3. But every time I'm just about to buy c3, I remember its leased, yet doesn't offer the ability to adjust it to fit my needs without reinventing the wheel. So... basically... don't use inheritance, even if objectB is functionally the same as ObjectA but with one additional feature.

Zizaco

I'm curious what you ported your project form. Totally curious to check it out.

TS was brought to my attention by Skymen and Ashely as well. Unless I am not setting up correctly though, when working with builtins I still see anything in the c3 runtime (ex: SomeSpriteObjectInstance.AnythingAndEverything.AnthingAndEverything.Etc). Which makes it good, but only half the time.

TS only works while in VS right? not within c3?

I mentioned in response to skymen about scalability, that while there isn't a hard reason you can't make a complex project, how can you deal with object and function bloat besides just "dealing with it". In unity, for example, I can package up alot of code and forget it exists. I can't do that with events. Its super distracting to have to keep picking the same object type nested down 3 folders amongst 1000's of other objects. Unity doesn't care how many prefabs you have made, none of them are available to you code side unless you specifically add it, and even then, its whatever you named it in that script. Autocomplete works fine in construct, but there is no enforcement of scope across objects, functions, customactions, etc...and auto complete includes them all. 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. I'm not a fan of gamemaker language for a similar reason.

Ruskul

I ported it from Phaser+TypeScript

When writing scripts in Construct you are not forced to put everything into game objects, you can create a plain old class and use it in your code the way you'd want (singleton, composition, inheritance, etc). In my case: I wrote the code that handles the AI using the decorator pattern. That way I could extend the AI behaviours with composition.

The way I approached the problem might not have been the best (I would do it differently today), but in no moment I felt like Construct3 was in the way.

To get the most out of TS (i.e: intellisense) you have to use an TS enabled editor, like vscode (not to be confused with visual studio). With other engines, people use external editors all the time.

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

I see where you are coming from. Indeed events can be very clean for a lot of stuff, mainly because they are simple to use. You can use it to your advantage, which IMO is one of the strongest points of C3: to have core systems of a game handled with code (optional), while simple systems can be handled with simple/clean event sheets.

The ability to inline JS scripts within the events can be useful for handling more complex object-picking. For example:

Ruskul I understand your frustration when something doesn't work as you want, but let's be honest. If you don't like so much the engine, then better to move on something else, especially since C3 has a subscription model.

Forgive my question, but did you ever had a business? Even a small one? I had 2 in the past and now I have my third one as indie solo studio. From your sentence here, it doesn't seems that you understand what means to run a business, especially if in the case of Scirra, you have lots of clients to take care about.

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. But I added it to my project and dealt with it.

With my current business I work on my games, work as freelancer, develop assets and templates. At the moment I am busy with a client since 10 months, I barely work on my games and I haven't developed or updated any of my templates and assets.

It would take me just an hour per day to release an asset per week, though I have no free time for it. Why? Because I am too busy with other stuff, so that '10 lines of code' or a 32x32 pixel art sprite or whatever, can't be created because there is no time for it.

Can I hire another person to do it? Yes, of course. Do I not only recover cost, but make enough income to justify to hire another person for these little tasks, that I have anyway to spend time to explain how to do it? No, especially since it takes more time to explain what is needed, rather than do it. So there is no benefit sometime in scaling up the business, and therefore some things are delayed.

About sorting objects and functions, I still don't understand what's wrong, can't you type and search them as I have already posted earlier? I have no problem in finding objects even with lots of nested folder. Just type the name in the search and it will filter everything else out, like this:

I sleep all day, and pretty much always have. I am the laziest person at a software firm and I manage to hide from job cuts by making lists of things to do and then checking them off when they get done. The most important thing on my list are easy short fixes, because everyone thinks I will probably do it. But if I did, then I would have one less thing on my list, and I need lots of things on it.

I probably do know how to program, but after sleeping all day I never get to it. I probably do want new scripting stuff for C3 but I am too lazy to do anything more than event sheets and layout sheets. I am hoping that if I spend my time trying to make a good game rather than trying to satisfy my hunger for neat code I will be able to patch something together that people will be willing to play if I don't charge them.

But I change my mind so often and start over I never get anything finished so C3 as is is perfect for me. I envy computer talk, and I know how to make long lists of good things to do that sound difficult but what I really want is something where I have a ghost of a chance of finishing something someone might want to play.

your

humble servent

winkr7

How can you deal with global space bloat in a large project without simply having to "get over it". For someone with pretty bad adhd, I have a aneurysm when autocomplete lists literally every function or object in the the game. The real big appeal to construct is how sleek it can be, at a smaller scale. It isn't that you can't scale in construct, its just that it you do have to just "deal with things" that you don't in other environments.

I understand the point and I have a few tips for that.

For object types, the search bar is focused by default, so typing the name of the object will filter it immediately.

For global variables, instead of using them as is, I use a global object type and instance vars. This plugin was designed around that idea: construct.net/en/make-games/addons/539/globals-c3runtime

But you could do the same with an Array, Dictionnary or JSON object. (globals is just the same but with none of the data management features). This makes global variables hidden behind an object type that you can name whatever you like. In practice it works like variable folders.

For groups, I name them as "Parent Child SubChild" where each sub group takes its parents name and adds something at the end. This makes it infinitely easier to sort through them when enabling/disabling groups. It also makes sure there will never be name overlaps.

For functions, one thing that can be done is using custom actions instead on a globals/array like object. Custom Actions are similar in functionnality to the new functions, and adding them on unique global objects makes the object picking do nothing, so you end up with functions, but stored in objects. It can't do custom expressions though.

Overall, there are a few organisation tricks, and learning keyboard shortcuts, I end up mostly never using my mouse when writing events, and I never get lost searching for stuff.

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.

TLDR, its hard to take such advice seriously when the Scrirra team authors behaviors that need engine tweaks in order to function (shadow caster, platformer, solid, dropthrough, etc... all have some internal engine stuff if I recall). Its frustrating in many cases and makes the itch to switch pretty strong.

I deeply agree with that, and it's more or less why I have respectfully ignored such advice in the past. On the other hand, I can understand not wanting to do the extra work to "release" the hidden parts of the SDK, and also not wanting to deal with angry customers coming to them because a 3rd party addon broke.

So there is a gentleman's agreement where I will keep fixing my stuff, but they will accept that I will frequently just completely bypass the limitations of the SDK, to the point where I have now released multiple addons where the core functionnality entirely relies on deep engine hacks.

I don't agree that the SDK should only be used to add 3rd party services. In fact, I think JS is a FAR better solution for integrating 3rd party services because of how detached from the engine they are, and how much iteration is needed on them. Something like an ad provider for example might need frequent tweaks, updates and you might not implement all of it in one go. Having it as a JS script in your project that you can change is a much better workflow in my opinion. The addon SDK is definitely not designed for quick iteration and an ongoing list of small tweaks.

Instead I think the addon SDK is amazing at adding functionnality. Extending the engine with new features, and adding "premade" stuff everywhere. It is what 90% of the vanilla addons are doing, I don't see in what world it wouldn't also be 90% of 3rd party addons. If you ask ANY construct user what the addon SDK does, they will answer "do stuff like add platformer, physics or keyboard" and never ever "support newgrounds"

Also, there is a big topic about the a good chunk userbase of Construct not being able to code. Making addons that add features to the engine is the best way to share reusable code, and is IMO the best design paradigm not only in Construct but in all game engines. Having the entire engine's features be "a la carte" is phenomenal.

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.

I very much understand the problem, but sometimes having access to the code could just be helpful.

If I encounter some edgecase in my project, right now my only option is to file a bugreport. And then maybe I get a fix. It could also get hit with a "difficult" which usually means I can expect this bug to be in limbo for the next couple of months. Or it gets shot down as wontfix because it's just an accepted quirk and fixing it would break every other project. A last resort would be to somehow work around it with event logic or game design, but that could easily just be impossible. And if that's the case, I'm just screwed.

Meanwhile, I could theoretically just tear open the code and put the fix where I'd need it myself. Obviously with the full understanding that if I break something here, I don't get (official) support.

Put it behind developer mode, make a big box that says "If you touch this, no support!". Make it a per-project basis so if I actually break it, I can just revert to the original plugin/behavior script. I'd argue anyone bold enough to tinker around with the code is smart enough to understand the ramifications.