Feature Request: The next best thing to coding...

Hey everyone. Jeremy here.

I had an idea and I wanted to run it by you. Now I know the odds of ever getting a code editor in C2 or C3 are slim but what I think would be a better alternative is this.

The option to type out your events and actions versus double clicking. NOW, I know what you may immediately say; "why isn't that a waste when I can just click?" Yes and no.

For those who really like to type and program, we need that fix. I have a fixation with typing code. We need the feeling of typing to solve problems instantly, it's more gratifying. So, I am wondering if this is possible. Imagine this:

Blank event -> Hit 'Enter' on the event and it turns into a textbox (just like a comment box would look like). From there you enter the code needed to call the event. So, you would type in something like this.

everyTick(); [/code:20x9fqc2]

Once you hit enter it would look like the code block we are used to

System | Every Tick

I am completely serious with this because too many times I have felt tempted to go type out code elsewhere and always wound up back with Construct 2. Now, the reason I always wind up is because I love it's simplicity. I love it's events and although I love having the click everything option, I think having this option would soothe the need for coding all together. 

This was just an idea to put out there to gage how everyone else feels! 

Thanks for listening!

The problem is getting a good function name from all the actions and conditions, since they are mostly just sentences and there isn't any real consistency. I guess the function names from the runtime could be used, but I imagine some plugins could have some names completely different from the action/condition. Construct Classic allowed python scripting which allowed you to do this to an extent, but you couldn't do the same thing as with events.

Beyond that point the idea of a typed scripting version of events was proposed before and one argument against it was needing to deal with the syntax and typos of such a language, which is a task in and of itself. Kind of a different beast to what C2 does already.

You could unofficially do this already though, by generating event xml files. But it is a lot of work as I see it.

It has the same issue as trying to convert a capx file to say c++ source code: It's simple on a very small scale, but to support everything, fix bugs and support changes as C2 updates it becomes a ridiculous task.

R0J0hound that makes sense. I understand on a massive scale it's a huge ordeal but I really meant it just for the already existing C2 events and actions. Even if everything had to prefixed with CL (Construct Language) cl_everytick(); so it would define the function names... Also, if you had an object called obj_Player then it would access what is already there obj_Player.Platform.Speed = etc. etc.

It's never going to happen with C2.

Whether it will be a possibility with C3 is still unknown.

Would be nice though. I may look into seeing if people would want to collaborate into making it a viable plugin of sorts. It is a big idea, but if implemented - it could really benefit those who are more suited for typing code!

What you are asking here is a custom programming language specific to Construct ACE architecture, which I don't think it will ever going to happen because it's kind of defies the idea of what Construct is. You know, that "No Programming Required" thing.

That said. I really miss the "copy events to text" feature from CC and will really like to see it working both ways in C3. Where you could select bunch of events, hit ctrl+c and paste it in text editor, and also opposite of that, where you write some text and after pasting it into C2 event sheet, the editor will automatically create events for you - then probably what you are asking for could work as well.

I had a similar idea sometime ago and was going to propose it sometime soon. My insight was to just develop a way to pick events by typing instead of creating a full-blown new script system. Kind of an hybrid.

Streamlined lists could serve the purpose to expose all possible events and aid discoverability, while an alternative typed method could serve experienced users to gain production speed.

I discovered a fuzzy matching algorithm that seems to work very well and is very forgiving with typos. It can be used to match the display text of events, so it remains familiar to current users and doesn't require a new script system. I made a rough interactive mockup as a proof of concept that you can try below:

Autocomplete Proof 01

1 - Type the object name (can be very fuzzy like "sp3" for Sprite 3) 2 - Press ENTER or RIGHT ARROW to commit and go to next field 3 - Type the condition (skipping vowels or typing just the beginning of words still works very well *)

• BACKSPACE to clean the field (press again to go back one level)
• LEFT ARROW and RIGHT ARROW navigate fields

*you can also continue to type/repeat parts of a new word until it converges to it

Now this is just a bare bones of what it could be, but it all revolves around a fuzzy matching system and the limitation to only pick existing events (there's no way to get syntax error due to mistyping). Ideally after picking the condition it should be able to navigate the condition fields using the arrow keys to type numbers, strings or objects. By pressing DOWN a flying list could appear bellow with the top 5 alternative matches, where you could switch by pressing UP or DOWN, then press ENTER, RIGHT ARROW, or go all way up to make the list disappear.

I used the final condition text in the mockup, but probably a way better alternative would be to first match the condition name (like it appears on current lists), and on pressing ENTER or RIGHT ARROW switch to the final condition text (e.g. "Compare X" => ENTER => "X = 0"). It's possible to leave it open to match both the condition name or the final condition text, but that probably may give some unexpected results sometimes (maybe not).

This fuzzy match system could very well be used to match objects, functions, variables, and all types of linked references in all kind of dialogs. Even for auto-casting similar conditions when an object type is changed: if one object type uses "set X" an another "set position X" it probably could detect it as the best match. It may not give a perfect match 100% of the time, but it sure would help in a lot of situations.

Animmaniac Yes! That is exactly all I was looking for! Fuzzy matching is brilliant and I love your proof of concept. It gives the versatility and even if that flying list was like code-hint on any other text editor, it's a game changer for a "no programming required" engine. Even with the alternative way, by pressing enter that still opens up the door to faster "programming" with Construct regardless if it's only approximate!

Also, the streamlined lists would be a lovely alternative to what we are currently using and I'm sure beginner programmers could see that as a more visual way to understand what the Construct Language actually has! *Hugely prefer this to the Objects with Expressions window.

My exact idea wasn't to say " Construct needs it's own script system "- but instead, it needs exactly what you have presented - streamlined/autocomplete manual entry!

Let me know how If I can help with this in anyway!

Animmaniac Yes! That is exactly all I was looking for! Fuzzy matching is brilliant and I love your proof of concept. It gives the versatility and even if that flying list was like code-hint on any other text editor, it's a game changer for a "no programming required" engine.

Thanks. Yeah, the idea for the flying list is basically like code-hint, but adapted to a system where the auto-complete is always on so it doesn't get in the way (only when the user wants to).

Let me know how If I can help with this in anyway!

I have some other good ideas to improve the evensheet with better structuring, an improved color coding, and some power edit-in-place features that could probably speed things up a lot. However these are just some mockups and ideas for a proposal. I have no power nor the knowledge to implement this in Construct, it's up to Ashley and Tom. I definitely would love to redesign the eventsheet and the overall C3 interface, but it's not on my hands.

Also I would not expect any changes like these for C2, if it happens it will probably be for C3.

Why not get rid of the event sheet altogether?

Make an event object to open a modal window in the layout.

Make it even more oop by tieing object events there too.

Right click sprite, edit sprite events.

UI is hard. I'm not saying it can't be improved, but I can think of several difficult problems with every proposal here.

Any form of typing in conditions and actions needs to be able to enter parameters as well. (If not you just have to bring up the parameters dialog again which kind of defeats the point of typing in events.) So typing in "Sprite overlaps Family at offset (3, 5)" requires having a way to unambiguously parse out the parameters "Family", 3 and 5 from the entered string. This is only semi-possible. It's not a strict enough system to remove ambiguities. For example imagine two conditions with these names:

Sprite: overlaps [object]

Sprite: overlaps solid

If you type in "Sprite: overlaps s", which condition are you typing in: "overlaps solid" or "overlaps [object]" with an object name beginning with "s"? I am sure there will be many examples like that, especially when including translations, which could make it pretty frustrating to use. There are also extraordinarily tricky parsing problems in cases such as this:

Sprite overlaps Family at offset (Function.call("calc", 3, 5), max(3, 5))

where the commas in the function call have to be identified as different to the comma from the condition description text, and similarly with the parentheses. Again I am sure in some cases this will be impossible to resolve unambiguously depending on the condition description text. So this could end up being a feature that sounds nice to have, but actually turns out being difficult to use and semi-impossible to implement. It could be fixed by using special tags to identify parameters, e.g.

Sprite overlaps ${Family} at offset (${Function.call("calc", 3, 5)}, ${max(3, 5)})

...but it seems to me that's a pretty ugly thing to have to type in, and is beginning to look like a weird mishmash of natural language and a pseudo-programming language! You could remove the natural language part and go full syntax with something like this:

Condition(Sprite.Overlaps, Family, 3, 5)

...but now you're in to the realm of inventing your own custom programming language, and you may as well go with a mature industry-standard like Javascript, which contradicts the "no programming" message we have been focusing on for years.

The alternative UI design is interesting. I could nit pick about scalability for large projects and lacking search boxes, but I think the main problem is information overload. It shows everything at once and has so many sections it's a sort of god-dialog that tries to encompass everything. I think good UI design is as simple as possible. Also IMO the biggest flaw is how it swaps the conditions list for expressions - the dialog is already so packed that there is no more room, so it recycles the middle pane for the fourth expressions panel. Lots of beginners get confused enough by the difference between conditions and actions, and then swapping conditions for expressions - which are very different things - will probably trip up a significant number of beginners in to being unable to figure out WTF is going on.

I'd point out the current system of using three separate "pages" with one floating dialog for the expressions list keeps everything simple by splitting the steps, and should be fully navigable by keyboard shortcuts. (I think I remember someone saying they can more or less "type in events" just by getting really good with the keyboard shortcuts.) There's also the back and next buttons to easily switch between conditions and objects while preserving as much state as possible. So I think it's closer to keyboard-navigable than some people think. Radical departures from this really need to be thought about very carefully. I'd add that I don't think I've seen anyone complain about the current system for a long time, so it seems to be working well.

The current system is almost perfect but the ideas proposed in this thread are certainly interesting.

What I'd like to see improved in the event editor is things like:

Having the ability to pick a specific instance in conditions, just like how Sprite(IID).property works. I know you can do that with Compare two values, but it would be more convenient to do the picking and condition in one step. Maybe an optional text field in every condition to pick an instance, or if left blank doesn't do any picking.

The same thing as above could be added to actions. I'm sure there are several cases where one wants to test a state of an instance of an object and then do an action on another instance of an object. There are of course ways to do this currently, but IMHO that would help reduce the lines of code.

Some slight improvements in copying pasting events and most important of all (in my opinion) when you delete an object in the layout, do not remove the code that references that object! Something like how an "Else(not valid here)" that turns red and gets disabled would be better I believe. The same thing could apply when you delete variables and families.

(I think I remember someone saying they can more or less "type in events" just by getting really good with the keyboard shortcuts.) There's also the back and next buttons to easily switch between conditions and objects while preserving as much state as possible. So I think it's closer to keyboard-navigable than some people think.

Yep, I very rarely use the mouse in the event editor. With C2's keyboard shortcuts, windows keyboard shortcuts, tab, search bars, arrow keys, and the like, you can "type out" events very quickly. The only time things are slow is when I'm filling out default array or dictionary info or something...but even then you could type out strings in local vars and run loops to split them up into arrays and such.

The alternate UI is interesting but I don't feel it's better or worse, just different. I like that I can see everything at once...but it's not really necessary. With the current system I can find everything I need quickly and easily, only seeing what matters in a given step of the process.

I guess my proposal didn't get clear enough. There's no need to parse anything apart from what is already parsed (like expressions).

The idea doesn't revolve around typing complete phrases (or code) and parsing them into events, that would be extremely hard. Instead you type into predefined form fields and use the fuzzy match to auto-complete. In a traditional programming language you would type a delimiter like "." to separate blocks of information for the parser. Likewise in my proposal you press ENTER or use the arrow keys to navigate to the next field, so the information is pre-parsed during filling.

Here's a step by step of how it should work:

Typed Events Mockup

*the image steps don't coincide with the steps below

1 - first initiate the typed method by pressing a shorcut like CTRL+E

2 - then type the object name and press ENTER or RIGHT ARROW to confirm and move to the next field.

It can be very fuzzy like "sp3" so you can economize a lot of key strokes and type faster. The fuzzy match algorithm does a lot of the job for you.

3 - type the condition field and confirm to start iterating It's parameter fields

4 - fuzzy type an object name, confirm

5 - type an expression to the X field, confirm

6 - type another expression to the Y field, confirm. When done you can then navigate to actions or add another event by pressing CTRL+E again.

So basically you just navigate these fields and type in them using the fuzzy match:

Object >> Condition >> Parameter 1 >> Parameter 2 >> Parameter 3 ...

Once you placed an event you could do a single click in a field to fuzzy type it again, or do a double click to edit using the mouse. Like opening an object dialog when an object field is double clicked...

...or click+drag a number to quickly edit it like in the editbox demo I posted earlier...

... or even edit expressions, conditions and actions in place.

This could unleash the power of edit in place (like in a traditional code editor) and probably speed things A LOT. I believe it may even surpass traditional approaches in terms of speed and efficiency, specially if you consider that it's virtually impossible to get code with syntax errors.

So my proposal is nothing different from the events system we already use and doesn't need another specialized parser. It's just a different approach to picking events in place without opening any dialog, so it can be faster.

I could nit pick about scalability for large projects and lacking search boxes, but I think the main problem is information overload.

I think that with the filter list it's probably more scalable than the current solution, since they can quickly narrow down the number of items to a subset pertaining to a single category, so it could still be manageable even with a very large number of objects/items. The folder structure also better match the filter list on the side than in the current implementation where folders mix with objects.

For search the idea is to be able to type and jump directly to the match like you do in some file explorers. The mouse cursor determines which list you are searching by hovering. Alternatively you could also navigate and type using the keyboard like you can now. The fuzzy match algorithm would help in this as well.

Regarding the information overload I don't agree that it's too much to be a problem, and it's also neatly organized. But either way if new users find it complicated it can still be simplified by displaying the descriptions only on hover or removing the lateral filter lists (could be an option).

Also IMO the biggest flaw is how it swaps the conditions list for expressions - the dialog is already so packed that there is no more room, so it recycles the middle pane for the fourth expressions panel.

The idea is to recycle both the left and the middle panel for picking expressions only while an editbox is in focus. The reason it changes state is not because there is no more room, it's just a possible solution to not use another window. I agree that the change of state is not the best of things, this is definitely a hard problem to solve. The floating panel is a possible alternative but it also has it's compromises. This is something that needs some testing to see if it's possible to make the change of state clear enough to not confuse users, otherwise it's always possible to launch a new floating panel.

The thing is that putting the steps side by side, besides helping streamline the process of picking events also results in some nice features. If you are editing a condition and suddenly needs to change the object, in the current system you need to back step 2 times, change the object, than step forward 2 times again. With the proposed system with a single click you can change instantly the object, keeping all the filled forms intact. If the object type is different and there's no perfect condition match, the fuzzy match algorithm could kick in and try to predict the best possible match ("set X" => "set position X"). In general this layout makes it less painful to edit events.

*ignore that all icons are default

Another idea is that the list should always be pre-filled with the previous event you were editing. There's a high chance the new event would be related to the previous one, so it's quicker to change just a few parameters than pick all again. For instance, most events created in a row will probably be related to the same object, so you don't need to waste time picking it again. You just edit the differing parameters like conditions or fields. Or if you are setting a bunch of variables, or setting position and scale, or dealing with animations, all conditions will be close to each other so they are a single click away. If they happen to be totally unrelated then you just have to pick all fields normally.

In my view the problem with the current wizard UI is that it demands too much time and clicks just to navigate the windows, especially for users who don't use the keyboard. If you consider the frequency that these actions are repeated during a project there's a lot of wasted work that could be optimized. Every step is modal, so you always waste some time adjusting to the new context and get some cognitive load creating mind maps of where you are. What I tried to do with my proposal is to make it the less modal as possible. The steps are disposed side by side so you get an overview of the process and minimize both the clicks and the switching of states.