[Feature Request] Programmer mode

Can we have a mode where we code everything instead of using event sheets? That'd be awesome, thanks!

Can we have a mode where we code everything instead of using event sheets? That'd be awesome, thanks!

Where to report bugs & post suggestions

No, no, semaphore mode!

No one's ever requested that.

Ashley In https://construct3.ideas.aha.io/ideas it asks for my email, is this view-able by anyone or is it private?

Technically you're welcome to program as much as you like as a JavaScript plugin/behavior addon, but then you still need events to make it interact with other plugins.

Visual scripting in Construct is not as slow as it seems, aside from specific complex loop/function/family things, you're going to be much faster doing it in events.

Visual scripting in Construct is not as slow as it seems, aside from specific complex loop/function/family things, you're going to be much faster doing it in events.

We can agree to disagree . I made a suggestion on that page, I hope they will add a programmer mode on construct 3. Doesn't hurt to have another option, it would help reach more people as well.

We can agree to disagree . I made a suggestion on that page, I hope they will add a programmer mode on construct 3. Doesn't hurt to have another option, it would help reach more people as well.

Except, I have actually done the work of porting a couple months of eventing work from Construct 2 to Unity/C#, and I can tell you that code-wise it has taken over double the time.

It was worth it for our console release targets, but that's a different discussion.

But yes, more keyboard-friendly interfacing for Construct would be nice to have still, even if it's not technically "programming mode"

>

> Except, I have actually done the work of porting a couple months of eventing work from Construct 2 to Unity/C#, and I can tell you that code-wise it has taken over double the time.

>

>

The problem is that you need to code everything in Unity, there is no "behavior" there. Every little thing you need to do is 9999 lines of code. That is Unity's problem. But in construct we have behaviors and we could code using that. I too have done games in construct 2 and unity, and I see the flaws on both but I think construct can do better by having the best of both worlds. Here's the suggestion: https://construct3.ideas.aha.io/ideas/C3-I-475

I created a bunnymark behavior just to compare the performance of plugins to event sheets - and the plugin was 3x as as fast as using events. So... There is an overhead to the event system. The trade-off, of course, is event sheet convenience - if no one notices the overhead then it doesn't matter....

Edit - this plugin was for c2 although it's likely the same for c3; I didn't check the forum title..!

Dang, I should have gone with smoke signals.

Longer distance, and the mobile platform is very big among millennials.

I created a bunnymark behavior just to compare the performance of plugins to event sheets - and the plugin was 3x as as fast as using events. So... There is an overhead to the event system. The trade-off, of course, is event sheet convenience - if no one notices the overhead then it doesn't matter....

Edit - this plugin was for c2 although it's likely the same for c3; I didn't check the forum title..!

We were mostly talking about the speed of coding, since more complex things are faster to do in visual events it's probably faster, although I guess more keyboard shortcuts while eventing never hurts.

That said, it's an impressive performance difference ditching the events. The runtime really should be pre-baked with the plugin/game code into one program on export, rather than interpreting the events IMO.

Otherwise, all Construct 2/3 is would be a fancy JSON editor if you can just grab c2runtime.js and slap your own data JS file with its HTML loader.