I genuinely don't understand this - it was apparently not controversial when I opened our latest blog on JavaScript coding with "Construct's visual block system can produce amazing results without having to write a single line of code. However if you want to go even further... then you can also write JavaScript code in Construct." Here I am now demonstrating how you can go further. I think all this talk of backstabbing and kissing the ground is way over the top.
We've been advertising JavaScript support in Construct since 2019! We're aiming to build a tool that does both visual blocks and coding really well. Maybe you don't use the coding side, and that's fine! Everyone can choose which they prefer.
Currently it does an exact match on what you type, including spaces.
Ah right, I hadn't got it opened in a popup window. You're right, it doesn't focus the popup window in that case. I fixed that for the next beta.
It's not like we're taking away anything from event sheets. Everyone can choose whichever usage suits them! We're just providing extra options: event blocks, code, or a mix of both.
In this release if the find bar is already open, pressing Ctrl+F focuses the search field in the find bar. So it looks to me like it already does this - or did you mean something else?
I meant there are already lots of examples of larger Construct games made just using events. I wasn't trying to claim that we have a big percentage of the gaming market or anything. I don't think there are any large Construct games made mainly using scripting, and I'd like to provide an example of one with this project!
I'm just doing a coding side-project, and I explained all the reasons for choosing scripting in this blog post. I don't know why you have to talk about things like backstabbing. If you don't like the idea, well... you don't have to follow the project 🤷
I mention in this blog post how, for this architecture, it's actually impossible to use event sheets fully, because it's going to use multithreading.
There are already loads of big and impressive games made almost entirely using events in Construct, so I don't really feel we still need to prove that point.
I don't know why someone deciding to code would jeapordise anything. The fact Construct lets you do coding too means if you make that decision you can keep using Construct. If we had no coding support at all, then someone in that position has to move to a different tool and so we definitely lose their subscription. And it's not all about Unity - there are other coding tools Construct is strongly competitive with.
I think that's a wilful misreading of the post. I'm not saying event sheets aren't important or can't do amazing things. There are plenty of big Construct games already made entirely from events. In this project I want to focus on a different approach.
I think I'm just repeating myself here, but the goal of the project is to show Construct can be used for coding, as well as event sheets. I guess it might not be for everyone, but I've set out the goals and gone in to detail about why I've gone in this direction.
Events don't really translate to clean or readable code as they are a completely different paradigm. However in many cases the APIs for specific plugins and behaviors relate closely to corresponding actions and expressions.
I'm using C3's own editor for the time being. I might switch to VS Code later down the line, but C3's own editor is working fine so far.
Construct is also a JS engine, that's the point.
If you don't like the idea of the project, well... you don't have to follow it 🤷
Since the introduction of JavaScript coding in Construct back in 2019, we've been aiming to make Construct also good for coding, in addition to the event sheet system. We haven't, and aren't, neglecting the event sheet feature. We know lots of people use event sheets. But we'd like to draw some more attention to the coding feature and show what it's capable of. That's what this project is about.
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.