1StepCloser

I have a biased outlook on the matter, so I'll share that at the end if you care.

For me, this is what I have found, given my projects. I lean very heavy into abstraction every where I can and prefer modularity, rather than hardcoded solutions.

1. Using JS only has the limitations that you aren't utilizing one of constructs biggest strength amongst it's competitors; The eventsheet and the sol paradigm. I doubt anyone can match speed for speed if they only use JS, which then leads to the hybrid approach being favorable. Consider how many lines of JS it takes to emulate a simple "Is A overlapping B" condition.

The api is very verbose imo, and could be streamlined with a number of apis to emulate picking conditions. Without those, you have to recode a lot of stuff. The ghost shooter template is a good example, because it requires a lot of typing to simply do what a few events did. Not only that, it is making lazy overlap tests that would kill performance in a full scale game. At the time it was made, there wasn't a way to GetCollisionCandidates and make use of the internal collision cells.

2. Given the above, a hybrid approach is definitely a better workflow, taking advantage of ACES where can, and doing specialized stuff in JS. You can solve alot of construct's biggest weaknesses by utilizing oop through js modules and extending classes... But... But one issue here: The performance overhead of a single JS block is bad*

Every event block in an event sheet has some overhead behind the scenes. It really isn't bad, but a single blank event still has a cost. Looping a blank event duplicates its cost. A "custom Action" has a cost around 3x that of a blank event and a "function" can be around 4-7x slower than the base. A loop in construct duplicates the overhead of events, which is why they take so much longer than no loop, even if they are acomplishing the same things. A js block in an event sheet takes around 300x longer to run than a blank event, which means if you are doing something simple like computing a dot product from a math module, it's going to be slower by a lot than simply doing it in events.

So... if performance is an issue, now you CANNOT put js blocks into any sort of event sheet loop and you also have to make sure that what you are accomplishing with that Js block more than justifies its incredible overhead.

Now, js blocks can eliminate the need for loops by looping themselves, which is WAY faster than an event sheet loop, but now you are losing any potential to do things through events. Basically, you can create JS systems, and so long as you minimise the number of js blocks that are needed to interact with those systems, you are golden.

---

At the end, this is why I prefer authoring behaviors for some types of problems. they take longer to make, but if I need to constantly interact with them through the event sheet, they make sense from a performance perspective.

As an example, I do alot of vector math in my game, so I created a behavior that has alot of vector utilities, along side an arbitrary number of vectors a user can add to an object. Another example would be a property whose state I need to monitor and control how it is accessed and modified. This is painful to create with events every time you need it, so I made a behavior to handle the boilerplate.

In both cases, using a JS module and calling it from a JS block would make my game unplayable, while using behaviors I can still have 100s of entities/characters.

---

For my bias: I believe if you are doing too much scripting, then you may as well pick a different engine. I make behaviors because the initial investment pays dividends in the event sheet and in scalability, but authoring them is incredibly slow compared to the equivalent in unity. If you are straight up coding the game purely through js, I would ask why bother with construct at that point at all.

Almost every other game engine I have used has a much better workflow where coding is concerned. They have better, bigger, more elegant APIs, and offer more power and flexibility. Its also fair to note, I started with construct, so I should be biased towards it - and it was PAINFUL moving to unity, but once I learned it, it was better in a number of departments. I am choosing to make my current game in construct because I believe that given the my current projects lower complexity, construct will offer a shorter dev cycle than unity will, and I like the fast editor iteration times. I used c2 until about 2016, when I made the switch fully to unity. This is the first year back with c3, but I have always used construct as a prototyping tool.

Fingers crossed, because I am using the internal, private api, but I think I can get a game out faster here than in unity.

Thank you for taking the time to write this out Ruskul, very insightful! (claps)

Yeah, scripting is nice. There are just a handful of things that I find simply more convenient/simple to do in eventsheets, but I'd like to eventually move even more into scripting, at least when we're talking complex projects. I really like the eventsheet for simple projects though.

Are there any current downsides to utilizing 1) full java script with no events (is that even practical/possible?) 2) hybrid approach

I think the initial reason I veered away from it early on was primarily due to minification issues.

Has the saving time slowly increased as you’ve worked on the project or has it recently jumped up?

For me, it scaled in proportion to my project size (so one could say slowly). However, it got to the point where it was no longer reasonable. Without the project folder method, I think it would be quite difficult to work with larger projects.

Fundamental Performance Impact for moving actions:

Testing Environment:

To control for other factors. I closed all tabs, collapsed all project folders, and performed this test on a blank event sheet with only the single action moving from one place to another.

The Test

Moving the action from the bottom event to the top event.

Results

Blank Project with only the testing environment:

Re-Opening my project and doing nothing else but testing the action movement in the testing environment:

Performance Impact:

At baseline this shows that moving an action takes approximately 47 times longer to perform in my project compared to a blank project even when closing all tabs, collapsing all folders, and working with an isolated action in an isolated event sheet.

So this begs the question(s):

• What is C3 checking to perform this action?
• Is C3 looking at various other event sheets to move this isolated action within this isolated event sheet?
• Are objects, project folders, global variables, etc. being checked when moving this isolated action, when on the surface, it appears to involve none of them?

Considering this involves freshly opened projects, garbage collection isn't the focus.

Furthermore, considering that these two tests were performed in the same environment (same background tasks running), this seems to highlight a potential issue.

I'm sure this is quite tricky because there are various factors that need to be checked in some cases when moving events (duplicate variable names, group names, local vs global variable, etc), but perhaps when these checks are made can be optimized?

Awesome to hear dop,

Perhaps the performance issues I deal with are more isolated to projects of the size I'm working with.

Project Version: r332

I've tried with the Memory Saver Toggled On/Off, but this is the current setting:

After reading your post I updated Chrome, but I have data for the previous Chrome version and the most recent:

In Chrome Version: 110.0.5481.104

Project Open For Several Hours

This is how long it took to move a single action from one place to another:

After garbage collection it still took this long:

In Chrome Version: 110.0.5481.178

Project Open For ~30 minutes

This is how long it takes to move a single action from one place to another:

After garbage collection it still takes this long:

Memory footprint is relatively normal:

~2 GB

For me, the only reliable method thus far for maintaining smooth performance is to continually reopen the project every few hours.

Which supports the notion (in my case) that the clearance from garbage collection (unsurprisingly) doesn't meet the clearance from closing the project and reopening it.

Something seems to be stacking up over time that affects performance, but doesn't get addressed by garbage collection that is only noticeable in certain-sized projects:

Other details:

I save quite frequently (every 15 seconds or less if actively making changes).

The save method I use is project folder (It would take several minutes to save changes otherwise, which if I'm saving every 15 seconds...yikes).

I mention this as it could be a potential factor among other actions:

Save

Undo

Redo

Copy

Paste

Etc.

Another note-worthy observation (Cut / Paste):

After updating to the newest version of Chrome, I opened my project and changes made within those 30 minutes included a large amount of cut and paste actions of several events.

I'm inclined to think that might be a factor as the project had only been open for ~30 minutes, yet reflected the performance I see in my project when it's been open for several hours:

In other words:

Occasional cut / paste actions over several hours might resemble the performance impact of large amounts of cut / paste actions in a short amount of time.

I might test this out further and report back.